我接受了将克隆站点从 3.1.7 升级到 4.0.3 的任务。我已成功升级站点，但现在我尝试安装 Collective.lineage 并收到以下错误：
回溯（最内层最后）：
模块 ZPublisher.Publish，第 135 行，发布
模块 Zope2.App.startup，第 291 行，提交
模块 transaction._manager，第 93 行，提交中
模块 transaction._transaction，第 322 行，提交中
模块 transaction._transaction，第 416 行，位于 _commitResources
模块 ZODB.Connection，第 558 行，提交中
模块 ZODB.Connection，第 606 行，位于 _commit
模块 ZODB.Connection，第 640 行，位于 _store_objects
模块 ZODB.serialize，第 422 行，序列化
模块 ZODB.serialize，第 431 行，位于 _dump
PicklingError：无法 pickle
Quills 在升级之前已安装，但未安装网站上没有使用它，所以我在网站仍然是 3.1.7 时通过快速安装程序卸载了它（我不相信 quills 有卸载配置文件）。
此外，此错误不会影响所有附加组件，我昨天安装了collective.redirect，没有发生任何事件。
显然，Quills 没有完全卸载，但老实说，修复此问题时不知道从哪里开始。
任何帮助将不胜感激。
I was given the task of upgrading a plone site from 3.1.7 to 4.0.3. I've successfully gotten the site upgraded, but now I'm trying to install collective.lineage and I get the following error:
Traceback (innermost last):
Module ZPublisher.Publish, line 135, in publish
Module Zope2.App.startup, line 291, in commit
Module transaction._manager, line 93, in commit
Module transaction._transaction, line 322, in commit
Module transaction._transaction, line 416, in _commitResources
Module ZODB.Connection, line 558, in commit
Module ZODB.Connection, line 606, in _commit
Module ZODB.Connection, line 640, in _store_objects
Module ZODB.serialize, line 422, in serialize
Module ZODB.serialize, line 431, in _dump
PicklingError: Can't pickle <class 'quills.app.portlets.quillslinks.IQuillsLinksPortlet'>: import of module quills.app.portlets.quillslinks failed
Quills was installed before the upgrade, but wasn't being utilized on the site so I uninstalled it while the site was still a 3.1.7 via the quickinstaller (I don't believe quills has an uninstall profile).
Additionally, this error doesn't effect all add-on's, i installed collective.redirect yesterday without incident.
Obviously Quills didn't uninstall cleanly, but honestly don't know where to start when fixing this.
Any help would be greatly appreciated.
发布评论
评论（1）
在我看来，Quills 在某个地方分配了一些 portlet，当 Quills 被删除时，这些 portlet 并未被取消分配。
最好的解决方案是在删除 Quills 之前删除这些 portlet。不幸的是，我不知道有什么工具可以概述 portlet 的分配位置，并一目了然地识别出有问题的 portlet 的位置，以便将其删除。也许其他人知道这样的工具？
您可以尝试使用portal_setup 工具导出portlet 配置；生成的 portlet.xml 可能包含有关此 portlet 或多个 portlet 分配位置的信息。
或者，您可以尝试注册一个损坏的接口的虚拟替代品，而不是定位和删除 portlet（这应该出现在您的实例中某些产品的初始化代码中）：
不过，最后一个解决方案应该被认为是一个丑陋的黑客攻击。
It looks to me like Quills assigned some portlets somewhere that were not unassigned when Quills was removed.
The best solution would be to remove those portlets before removing Quills. Unfortunately, I'm not aware of a tool to get an overview of where portlets are assigned and identify at a glance where the offending portlet is so that you can remove it. Maybe someone else knows of such a tool?
You could try exporting the portlet configuration using the portal_setup tool; the resulting portlets.xml might include information on where this portlet or portlets are assigned.
Or instead of locating and removing the portlets, you could try registering a dummy replacement of the interface that's breaking (this should go in the initialization code of some product in your instance):
That last solution should be considered an ugly hack, though.