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