Content elements with random containers
We have encountered a really weird issue where saving arbitrary existing content records moves them to
colPos=-1 which cannot be fixed within the content elements themselves. We had to add the column
-1 to our backend layouts to fix this via drag and drop.
After further investigation in our database we where able to identify the broken records by having a positive
colPos (not placed in a gridelement) but a positive value for
tx_gridelements_container at the same time. The really odd thing here: the value for
tx_gridelements_container is arbitrary and never a tt_content record with
CType=gridelements_pi1 as expected but e.g.
Has anyone ever encountered something similar or happens to know how this came to be?
We could find all broken records like this:
SELECT * FROM tt_content WHERE colPos > -1 AND tx_gridelements_container > 0
Based on this query we could fix all records at once:
UPDATE tt_content SET tx_gridelements_container = 0 WHERE colPos > -1 AND tx_gridelements_container > 0
#1 Updated by Jo Hasenau almost 5 years ago
- Status changed from New to Needs Feedback
This issues seems to be happening form time to time, but the reason for that behaviour is not known yet.
My personal guess is that there have been mass editing actions like copying nested grid structures, branches or single pages with all their content.
Sometimes these actions fail, leaving kind of "orphaned" records in the database, that have just a part of their relation information left intact.
This is due to the fact that by core default children will be copied first, followed by their parents.
Sometimes the bad guy was another extension that broke relations or inserted false relation information. i.e. there have been problems with flux or DCE that might have led to this broken database structure.
Since I would like to identify the actual source of the system, please provide more information about your system, the extensions and the GE configurations you are using.
#2 Updated by Jörg Wagner almost 5 years ago
Over the last 2 weeks we have been suddenly experiencing very similar effects in multiple projects.
Here are some details – partially vague – that seem to influence that effect.
- Our impression is that it happens with Drag&Drop operations on nested GridElements.
- The effect affects CEs that are completely separate (e.g. located on another page, not within any GridEl, not touched at all) so that they suddenly render in FE within the GridEls that were subjects of the DnD.
- The affected CE is not visible in it's render place in Page module of BE, but can be seen in List module as a child of the GE that it appears in. (This is also a way to move it back out again – sometimes necessary to copy it out and delete the original to get the situation solved!)
- The effect started happening within the last 2 weeks on multiple systems. We did not experience this before. The major changes within these two weeks have been:
- Update from TYPO3 6.2.10 to 6.2.11
- GridElements 3.1.0 introduced into our systems (before we used 3.0.0)
- TYPO3 6.2.11
+ GridElements 3.1.0
+ Static Info Tables 6.2.1
+ t3colorbox 3.0.0
- Activated System Extensions (beyond the default):
+ Indexed Search Engine
+ MySQL driver for Indexed SE
+ Link Validator
(hope I got them all)
Today we executed an identical series of drag&drop operations on a development system and on the corresponding live system (same setup but different PHP versions and different Operating Systems). The effect took place in both systems for the same elements. So it seems to be reproducible if only the page tree and the content elements are identical.
#4 Updated by Jo Hasenau almost 5 years ago
@Mathias: The query will find elements that should definitely be broken, but there might be elements that are broken due to other reasons.
So actually you should it the other way around. Execute the select query and check if the broken elements are in the resulting list of records.
If not, we will have to find other possible unwanted misconfigurations.
@Jörg: Could you please provide more information about the structures you have been working on and about the actions you executed to produce the described behaviour?
What really makes me nervous is the part about elements on completely different pages being affected when you drag & drop elements. Since this should not be possible at all with default Gridelements methods.
#5 Updated by Ralf Rings almost 5 years ago
We are experiencing the same problems on a new project using the following components:
+ Gridelements 3.1.0
+ DCE 0.11.6
+ News 3.1.0
+ Media 3.5.1
+ RealUrl 1.13.3
+ Formhandler 2.0.1
However, I cannot reliably reproduce the behaviour. Editing page properties or content elements (gridelements, DCEs, plugins etc.), as well as moving stuff around (copy&paste, drag&drop) does not seem to trigger the problem. Still, once in a while elements have "magically" moved out of place (wrong colPos). This appears to even happen on pages, that were not previously edited. Unfortunately I cannot be more specific, since I don't know how to reproduce this error.
Looks like we have to find a different solution to the whole FCE/DCE+Gridelements approach. TemplaVoila is essentially a dead end and - since we also need workspace support - FLUID POWERED TYPO3 (flux) is not (yet) a viable option. I guess we will have to make due with complicated backend-layouts and custom CTypes :-/
#6 Updated by Jo Hasenau almost 5 years ago
I guess one possible reason for that behaviour can be found in #65538.
The point is, that there was a missing check for the table name, so moving records of other tables touched tt_content records having the same ID.
People with a lot of activity on the tt_content table just don't notice that behaviour since the tt_content ID values are much larger than those of other tables then.
So the possibility of touching a record with the same ID as a tt_content record is close to 0.
This issue has been fixed in the current master and 3-0 branch, so could you please check if things don't change, when you apply the patch fixing that issue or checkout the current state?
#8 Updated by Jörg Wagner almost 5 years ago
I was waiting all that time to get a database dump of my colleague to analyze and then respond. But one thing I already noticed was, that the affected elements on foreign pages had very low IDs. So, I guess it is very likely that #65538 is actually the reason, Jo.
#9 Updated by Jo Hasenau almost 5 years ago
So currently the evidence points to the following scenario:
- #65538 leads to tt_content records being touched when records of other tables are moved
- This updates tt_content records with a value other than -1 in colPos and a value > 0 in tx_gridelements_container
- This again leads to other tt_content records being moved to the same "parent container" as soon as they are moved behind the record that has been updated in step 2
- This leads to colPos -1 being applied to the records of step 3, even though they might not be children of a real container at all
- This leads to elements that somehow magically seem to disappear from the page
So fixing #65538 should eliminate all these behaviours in the long run.