Bug #24193
closed
Impexp fail to import recursive Templavoila flexform db reference data
0%
Description
When using impexp to export & import pages and content using Templavoila and DB reference data (as in DS for pages and FCE with relations with tt_content, for example) the references on the FlexForms are not imported correctly. So, the integrity of the importing while using Templavoila is not warranted.
This happens if the importing has to remap the id's of pages and tt_content.
Having this scenario:
- Root of exported tree (pages:12) (tx_templavoila_ds =>1 , tx_templavoila_to =>1) * DS Object 1 (Page template) (id=1) * TO Object 1 (Page template) (id=1) * DS Object 2 (FCE) (id=2) * TO Object 2 (FCE) (id=2)
- Child page 1 (pid => 12, uid=>13, tx_templavoila_flex => (points to tt_content 20) )
- Flex content on page 1 (tt_content:20) (tx_templavoila_ds =>2 , tx_templavoila_to =>2, tx_templavoila_flex => (points to tt_content 21) )
- Content on page 1 (tt_content:21)
(...)
- Child page n
Where:
- pages:12 is not on rootlevel
- tx_templavoila_ds:1 is a page template so has a field in the FlexForm with a DB relation to tt_content
- tx_templavoila_ds:2 is a FCE having at least a field in the FlexForm with a DB relation to tt_content
Steps to reproduce:
- Using impexp on the source TYPO3 installation, we export the tree from pages:12 with infinite recursion. On the preview all seems to be fine. We download de T3D file
- Upload the T3D file to a destination TYPO3 installation, using the same TYPO3 and Templavoila versions. Importing runs succesfully but some data is not imported correctly.
Data not imported correctly:
- The imported counterpart of pages:12 mantains the original tx_templavoila_ds and tx_templavoila_to id's (the referencing objects are correctly imported though)
- The data from fields "tx_templavoila_flex" from pages:13 and tt_content:20 is wrong. The references to the migrated tt_content id's are done correctly but written on other FlexForm fields, so the references are lost.
(issue imported from #M16555)
Updated by Michel Nederlof almost 14 years ago
We ran into the same problem and fixed it doing the following:
1. We made some changes to the TCA array by creating a new extension which has the following TCA declarations in the ext_tables.php:
$TCA['tt_content']['columns']['tx_templavoila_pito']['config']['foreign_table'] = 'tx_templavoila_tmplobj';
$TCA['tt_content']['columns']['tx_templavoila_ds']['config']['foreign_table'] = 'tx_templavoila_datastructure';
$TCA['tt_content']['columns']['tx_templavoila_to']['config']['foreign_table'] = 'tx_templavoila_tmplobj';
$TCA['pages']['columns']['tx_templavoila_ds']['config']['foreign_table'] = 'tx_templavoila_datastructure';
$TCA['pages']['columns']['tx_templavoila_to']['config']['foreign_table'] = 'tx_templavoila_tmplobj';
$TCA['pages']['columns']['tx_templavoila_next_ds']['config']['foreign_table'] = 'tx_templavoila_datastructure';
$TCA['pages']['columns']['tx_templavoila_next_to']['config']['foreign_table'] = 'tx_templavoila_tmplobj';
Before exporting from the source website, we made sure this extension was installed and installed after TemplaVoila (obviously..), so the declarions are not overwritten by TemplaVoila itself.
2. Then we needed to comment out the following hook calls in ext_localconf.php (line 42/43/44 in tag 1.5.2, not using the latest release since this produces an error in the TemplaVoila module page):
#$GLOBALS ['TYPO3_CONF_VARS']['SC_OPTIONS']['t3lib/class.t3lib_tcemain.php']['processDatamapClass']['templavoila'] = 'EXT:templavoila/class.tx_templavoila_tcemain.php:tx_templavoila_tcemain';
#$GLOBALS ['TYPO3_CONF_VARS']['SC_OPTIONS']['t3lib/class.t3lib_tcemain.php']['processCmdmapClass']['templavoila'] = 'EXT:templavoila/class.tx_templavoila_tcemain.php:tx_templavoila_tcemain';
#$GLOBALS ['TYPO3_CONF_VARS']['SC_OPTIONS']['t3lib/class.t3lib_tcemain.php']['moveRecordClass']['templavoila'] = 'EXT:templavoila/class.tx_templavoila_tcemain.php:tx_templavoila_tcemain';
We found out that the tx_templavoila_ds field was set properly when it entered the TCE class, but because of the hook it was blanked out, because it tried to locate the DS based on the given TO... Somehow this goes wrong. This is something for the TemplaVoila guys to fix.
Because the DS field was emptied by the hook, the importer was not able to reference the flexform correctly, because it needs the flexform declarations based on the record referenced by the id set in field tx_templavoila_ds.
These hooks caused our tx_templavoila_ds field in the pages table to be empty, thus flexform relations not updating for tt_content.
Hopefully this provide enough formation for a proper fix in a newer version.
So in a nutshell:
On source install (where you export from):
1. adjust TCA of templavoila
2. make new export using typo3 import/export tool
On the target installation:
1. Adjust the TCA of templavoila
2. Unset (or comment) the given hooks in TemplaVoila
3. Import your t3d file
4. Enable the hooks of templavoila again (it is needed when you continue to work in TYPO3)
You can leave the TCA modifications as is or remove it if you prefer. What it does is allowing TYPO3 to save the references between the table.
Updated by Alexander Opitz about 11 years ago
- Status changed from New to Needs Feedback
- Target version deleted (
0) - Is Regression set to No
Hi,
as this issue is very old. Does the problem still exists within newer versions of TYPO3 CMS (4.5 or 6.1)?
Updated by Alexander Opitz over 10 years ago
- Status changed from Needs Feedback to Closed
No feedback within the last 90 days => closing this ticket.
If you think that this is the wrong decision or experience this issue again, then please write to the mailing list typo3.teams.bugs with issue number and an explanation or open a new ticket and add a relation to this ticket number.