collective.catalogcleanup 2.0.0

用途和目标

将collective.catalogcleanup添加到您的buildout中的eggs。这将在Plone网站根目录中提供浏览器视图：@@collective-catalogcleanup。

这将遍历portal_catalog并删除所有对于getObject调用不起作用的目录大脑。换句话说，它删除不再属于网站中实际对象的大脑。

目标是消除可能引起问题的过时大脑，例如在升级到新主版Plone版本时。

默认情况下，@@collective-catalogcleanup执行的是干运行，因此它只报告问题。使用@@collective-catalogcleanup?dry_run=false来执行实际清理。

详细信息

那么目录清理做了什么呢？

• 它移除东西！您必须先备份！

• 它处理 portal_catalog。1.x 版本还处理 uid_catalog 和 reference_catalog。

• 对于每个目录，它会报告它包含的目录大脑数量。

• 它移除 UID 为 None 的大脑。

• 它移除对象损坏的大脑。这可能会发生在对象属于一个不再存在于 Plone 网站中的包时。

• 它移除找不到对象的大脑。

• 它寻找非唯一的 UIDs。我们接受一个对象，并为其他对象赋予一个新的 UID。

• 在浏览器中会打印出一个简单的报告。它可能看起来像这样

  Brains in portal_catalog: 20148
  portal_catalog: removed 25 brains without UID.
  portal_catalog: removed 100 brains with status broken.
  portal_catalog: removed 5 brains with status notfound.
  portal_catalog: 249 non unique uids found.
  portal_catalog: 249 items given new unique uids.

• 实例日志可能包含更多关于单个条目的信息。

替代方案

• 对 portal_catalog 的清除和重建应该有部分相同的效果，但它可能需要更长的时间，并且它可能无法解决上述提到的一些问题。但在尝试 collective.catalogcleanup 之前，这绝对是最合逻辑的事情。

兼容性

2.x 版本在 Plone 5.2 和 6.0 上运行，仅在 Python 3 上。对于较早的 Plone 和 Python 版本，请使用 1.x 版本。

作者

莫里斯·范·里斯

2.0.0 (2023-11-30)

• 不再接受非唯一的继承 UIDs。这对于讨论条目是必要的，但不再是了。[莫里斯]

• 修复了 Dexterity 内容和讨论条目的新 uuid 设置。1.x 版本的这部分似乎只为 Archetypes 工作。[莫里斯]

• 删除了对 reference_catalog 和 uid_catalog 的支持。这些仅适用于 Archetypes。[莫里斯]

• 放弃对 Python 2、Plone 5.1 及更早版本的支持。仅支持 Plone 5.2 和 6，在 Python 3 上。[莫里斯]

1.11.2 (2021-08-24)

• 当大脑路径是相对的时，不要对路径不同进行投诉。这在旧的 uid_catalog 和 reference_catalog 中会发生。[莫里斯]

1.11.1 (2021-08-13)

• 再次修复了当其中一个为 None 时排序 UIDs 的错误。[莫里斯]

1.11.0 (2021-07-29)

• 报告并删除具有错误路径的大脑。这些大脑是在给定的路径中找到对象的，但实际上这个对象的路径是不同的。这可能是由收购引起的：/Plone/folder/folder 已进入目录，但实际上只有 /Plone/folder 存在。[莫里斯]

• 当其中一个为 None 时修复了排序 UIDs 的错误。[莫里斯]

1.10.0 (2020-02-08)

• 要获取所有的大脑，当可用时使用 catalog.getAllBrains。这可在 Products.ZCatalog 2.13.30+ 或 4.1+ 中找到。我们回退到 unrestrictedSearchResults，否则仅调用目录。修复了 问题 16。[莫里斯]

• 错误 22：修复了缺少 Archetypes 时的启动错误。修复了 Plone 5.2 和 Python 3 的其他错误。现在应该与 Plone 4.3、5.1 和 5.2 兼容。[莫里斯]

1.9.0 (2018-09-25)

• 在获取大脑的对象时捕获 TypeError。当曾经可引用的对象不再可引用时可能会发生这种情况。修复了 问题 #19。[莫里斯]

• 禁用 CSRF 保护。修复了 问题 #17。[莫里斯]

• 在 dry run 模式下中止任何事务更改。这里本来就不应该有任何更改，但这确保了这一点。[莫里斯]

1.8.0 (2018-04-30)

• 不再在 Plone 4.1 和 4.2 以及 Python 2.6 上进行测试。[莫里斯]

• 在更多情况下捕获 KeyError 和 AttributeError 以便在 getPath 中。[莫里斯]

1.7.2 (2017-09-18)

• 添加了跟踪信息以帮助解决问题。[莫里斯]

1.7.1 (2017-03-07)

• 在 Plone 4.0 通过 5.1 上进行了兼容性测试。[hvelarde]

• 忽略不存在的目录。Plone 5 并不总是有 uid_catalog 或 reference_catalog。修复了 问题 #5。 [maurits]

1.7 (2017-03-03)

• 不要在 reference_catalog 中寻找非唯一的 ID。这看起来是正常的。至少，在一个 Plone 4.3 网站上，每次我运行代码时都会创建几个新的 uid。 [maurits]

• 不要对 reference_catalog 中的 brains 发出关于 getObject 返回 None 的抱怨。这种情况发生在没有明显问题的内容上。 [maurits]

1.6 (2016-08-23)

• 不要对指向 ...at_references/<uid of brain> 的 uid_catalog 中的引用 brains 发出抱怨。这很正常。我开始怀疑一个报告了超过 20,000 个此类问题的网站。 [maurits]

1.5 (2015-07-31)

• 移除所有路径中包含 portal_factory 文件夹的项。 [maurits]

1.4 (2014-05-12)

• 在获取 brain 的路径时捕获 KeyError。 [maurits]

1.3 (2013-09-02)

• 为继承其父 UID 的注释提供更不令人困惑的消息。它听起来太像错误了。 [maurits]

1.2 (2012-06-04)

• 改进了非唯一 uid 的清理。 [maurits]

1.1 (2012-05-14)

• 在进行 reindexObject 时，只重新索引 UID。 [maurits]

1.0 (2012-04-27)

• 初始发布 [maurits]