TYPO3 Core

Hi!

What purpose are you using this method for?
If the functionality is interesting for others as well, it would be very nice if you could contribute this to the TYPO3 project.

It took some time to answer due to legal issues on our side. We’re using the above function in our TYPO3 CDP (Content Delivery Platform) extension which is currently used in 3 different TYPO3 installations (4.2, 4.5, 6.1) with about 40 clients. The function is used because we need a low-level function to copy TYPO3 records.

Our extension allows us to distribute content from one master website to multiple client websites. The goal is to manage content in one central location which is then shared between several other websites (clients) on the same TYPO3 instance. In addition it is possible for every client to modify these inherited contents to make custom adjustments (of course these changes won’t be synced with other clients). Our extensions also deals with several TYPO3 functionalities like links to pages and uploaded files.

In detail it works like this:

• The admins/editors of the master website create default TYPO3 content elements, pages as well as other TYPO3 records (sys_template, templavoilà, …). The master website behaves exactly like a normal website, for example it can be previewed in the frontend.
• An admin triggers the publishing process of our extension effectively publishing all changes from the master website to all associated client websites. Alternatively publishing can also be triggered by a scheduler task. During the publishing process non-existing pages or content elements on the client will be created. Existing content elements will get the latest live version of the content elements on the master website, honoring TYPO3 versioning.

To create a new client for publishing it is sufficient to create one root page for that client and to connect that page with the master page. The next publishing process will then fill that client with the content from the master website.

The benefits of our system are that it’s very fast and solid to publish new content from the master to the clients. Although the same functionality could be accomplished with other methods (e. g. t3d export/import) these have some flaws which our solution doesn’t have.

I noticed in the meantime that other classes are also flagged as @todo Define visibility. Should we create more tickets or could someone update the issue title?
e.g. Proposal: Visibility of TYPO3 Core class function and properties

Affected Classes:

\TYPO3\CMS\Core\DataHandling\DataHandler (formerly known as t3lib_TCEmain)
public function copyRecord_raw($table, $uid, $pid, $overrideArray = array(), array $workspaceOptions = array())
Usage: Copy TYPO3 records

\TYPO3\CMS\Backend\Form\FormEngine (formerly known as t3lib_TCEforms)
public $formName = 'editform'; public $prependFormFieldNames = 'data'; public function initDefaultBEmode() public function setNewBEDesign() public function printNeededJSFunctions_top() public function printNeededJSFunctions() public function getSingleField_SW($table, $field, $row, &$PA) public function rplColorScheme($inTemplate)
\TYPO3\CMS\Backend\Template\DocumentTemplate (formerly known as template)
public $backPath = ''; public $form = ''; public $JScode = ''; public $postCode = ''; public function addStyleSheet($key, $href, $title = '', $relation = 'stylesheet') public function redirectUrls($thisLocation = '') public function startPage($title, $includeCsh = TRUE) public function endPage() public function insertStylesAndJS($content) public function makeShortcutIcon($gvList, $setList, $modName, $motherModName = '') public function sectionBegin() public function sectionEnd() public function section($label, $text, $nostrtoupper = FALSE, $sH = FALSE, $type = 0, $allowHTMLinHeader = FALSE) public function spacer($dist)
Usage: old fashioned BE Modules to get a consistent look between TYPO3 4.2-6.1.7.

\TYPO3\CMS\Backend\Tree\View\PageTreeView (formerly known as t3lib_pageTree)
public $makeHTML = 1; - \TYPO3\CMS\Backend\Tree\View\AbstractTreeView public $table = ''; - \TYPO3\CMS\Backend\Tree\View\AbstractTreeView public $defaultList = 'uid,pid,tstamp,sorting,deleted,perms_userid,perms_groupid,perms_user,perms_group,perms_everybody,crdate,cruser_id'; public $fieldArray = array('uid', 'title'); (Since there is no reset we can simply change the list that way without creating a new instance) public $tree = array(); - \TYPO3\CMS\Backend\Tree\View\AbstractTreeView - we are adding the parent row manually + iterrate through the result public function addField($field, $noCheck = 0) - \TYPO3\CMS\Backend\Tree\View\AbstractTreeView public function init($clause = '', $orderByFields = '') public function getTree($uid, $depth = 999, $depthData = '', $blankLineCode = '', $subCSSclass = '')
Usage: retrieve a page-tree (pages) to determine changes in a rootline

Im generally unhappy with the @define policy. Originally conceived as publicly defined functions should continue to maintain the same status imho! Im not sure if it would help in making a decision but couldn't you check the TER for usage count?

If you have any further questions concerning our extension feel free to ask.