我在TYPO3 CMS中遇到了一种奇怪的行为:我在多个页面上使用了内容元素“Grid-Element”。
“网格元素”CE始终具有不同的子元素,如图像或文本。今天,所有子元素突然移动到网站的每个页面上的“网格元素”之外。我不得不手动修复它们。基本上什么都没有丢失,但结构被打破了。
我还检查了编辑历史,但没有任何相关内容。
我想知道这是怎么发生的,以及如何防止这种情况再次发生。有任何想法吗 ?
使用gridelements时,您可以为每个内容元素配置一个配置。它存储在数据库中,主要存储在根页面上。
对于容器中的每个字段,您可以设置colPos
编号。你的破碎结构可能因为:
colPos
值colPos
值在99%的情况下,当更新TYPO3核心而没有安装gridelements时会发生这种情况。运行数据库比较会将字段colPos的SQL配置从signed更改为unsigned,从而将-1更改为0。
由于-1是网格容器的子元素的指示符,因此该指示符会丢失。
你可以通过运行来解决这个问题
UPDATE tt_content SET colPos = -1 WHERE tx_gridelements_container > 0
另外1%的人真的无法重现症状的原因,所以目前我们还不确切知道他们到底出了什么问题。
最近有一个错误修复,也可能在这里修复症状。所以我们似乎找到了其他答案中提到的1%的原因。
请查看最新的主人,看看它是否也解决了你的问题:https://forge.typo3.org/issues/85511
更新:2个事件中有1个可以追溯到一个问题,而不是陷入困境(见下文)。
我也有这个效果。
tt_content.colpos
的数据类型:是不是已签名?tt_content.colPos
改回签名(非签名)UPDATE tt_content SET colPos = -1 WHERE tx_gridelements_container > 0
因此,(可能)发生的事情是colPos被更改为无符号,导致所有-1值都更改为0.因此,gridelements的结构不再被正确解释。
核心将colPos设置为unsigned,gridelements覆盖它并将其设置为signed。
如果一切正常,那么数据库模式的这种变化不应该真正发生。
这些是我的测试用例:
更新:测试用例2可以追溯到具有混乱的composer.json的(开发)扩展。这是一个相当模糊的场景,可能非常罕见,但它确实对TYPO3 PackageManager中列出的扩展造成了严重破坏,导致gridelements架构无法加载。
为了完整起见:您可以使用已停用扩展的composer.json中另一个激活扩展的扩展键来重现它,例如:在ext1 / composer.json中:
"replace": {
"ext2": "self.version",
"typo3-ter/Uniolexample": "self.version"
}