Could not adapt error on select File objects with versioning enabled


This is my first post here, so apologies if I miss anything.

We have an error on our Plone 5.2.4 site with certain File objects when users try to add a new version, we get the following error,

  Module ZPublisher.WSGIPublisher, line 162, in transaction_pubevents
  Module ZPublisher.WSGIPublisher, line 371, in publish_module
  Module ZPublisher.WSGIPublisher, line 266, in publish
  Module ZPublisher.mapply, line 85, in mapply
  Module ZPublisher.WSGIPublisher, line 63, in call_object
  Module plone.z3cform.layout, line 63, in __call__
  Module plone.z3cform.layout, line 47, in update
  Module plone.dexterity.browser.edit, line 58, in update
  Module plone.z3cform.fieldsets.extensible, line 65, in update
  Module plone.z3cform.patch, line 30, in GroupForm_update
  Module, line 145, in update
  Module, line 22, in execute
  Module z3c.form.action, line 98, in execute
  Module z3c.form.button, line 315, in __call__
  Module z3c.form.button, line 170, in __call__
  Module plone.dexterity.browser.edit, line 30, in handleApply
  Module, line 124, in applyChanges
  Module zope.event, line 32, in notify
  Module zope.component.event, line 27, in dispatch
  Module zope.component._api, line 134, in subscribers
  Module zope.interface.registry, line 448, in subscribers
  Module zope.interface.adapter, line 619, in subscribers
  Module zope.component.event, line 36, in objectEventNotify
  Module zope.component._api, line 134, in subscribers
  Module zope.interface.registry, line 448, in subscribers
  Module zope.interface.adapter, line 619, in subscribers
  Module, line 62, in create_version_on_save
  Module Products.CMFEditions.CopyModifyMergeRepositoryTool, line 332, in save
  Module Products.CMFEditions.CopyModifyMergeRepositoryTool, line 500, in _recursiveSave
  Module Products.CMFEditions.ArchivistTool, line 267, in prepare
  Module Products.CMFEditions.ModifierRegistryTool, line 135, in getReferencedAttributes
  Module, line 117, in getReferencedAttributes
  Module Products.CMFEditions.CopyModifyMergeRepositoryTool, line 410, in retrieve
  Module Products.CMFEditions.CopyModifyMergeRepositoryTool, line 558, in _retrieve
  Module Products.CMFEditions.CopyModifyMergeRepositoryTool, line 634, in _recursiveRetrieve
  Module Products.CMFEditions.ArchivistTool, line 342, in retrieve
  Module Products.CMFEditions.ArchivistTool, line 510, in __getitem__
  Module Products.CMFEditions.ModifierRegistryTool, line 162, in reattachReferencedAttributes
  Module, line 188, in reattachReferencedAttributes
TypeError: ('Could not adapt', <File at template-service-agreement>, <InterfaceClass plone.dexterity.schema.generated.eidc_0_File>)```

This only seems to happen when versioning is enabled for File types and even then only for certain files, new files are fine for example.

All of the files involved appear to have a version Id of 0, I'm not sure if that is relevant to this, but thought I'd mention it.  The files that do work have a plone.dexterity.schema.generated without _0_, usually a longer more random ID.  Could this be something to do with it?

Any help would be much appreciated!


Hi Mike and welcome :blush:

Is there something about the files this happens with for which there is a pattern? What kind of files are they?

Is this a vanilla Plone site or do you have add-ons or customized content types or workflow?

They all appear to be Word/RTF type files, although there are over 6.5K files in the site so I haven't checked every one of them. I haven't been able to determine a pattern other than the versionId I mentioned in the original message.

It's a pretty much vanilla site, although it does have some addons enabled and a slightly customised theme based upon Barceloneta.

The addons are collective.pantry and EasyForm along with a simple one we wrote ourselves to display content without any Plone borders/menus etc. such that it can be embedded into other sites. I can't imagine any of these having any impact on our problem though, although maybe I'm missing something?

Does the error happen consistently again and again for the same files? Do you have multi-instance (ZEO) installation or just single instance? Does the issue continue after Plone restart?

Those “ schema.generated” interface identifiers are generated and applied for all related content type objects in runtime, so this really is a surprising issue :flushed:

Update: As written below, I was able to reproduce this and this does persist across restarts.

I was able to reproduce this in Plone 5.2.4

  1. Enable versioning on File content type
  2. Create a few content objects
  3. Customize File content type with a new field
  4. Try to update existing file

For me it seems that there is (or has been) a bug related to versioning dynamic Dexterity types with files or images (blobs). Reference to the dexterity schema at time is saved with the version, which breaks versioning after the type has been changed.

@lardymike TL; DR; I assume this be a bug in Plone related to versioning of "dynamic" content types with files. I was able to reproduce this in Plone 5.2.4 so that any change to versioned File content type (for example, adding a custom field) broke future changes for existing content of that type.

A possible workaround is collective.revisionmanager · PyPI which adds "Manage Revisions" control panel into Plone site setup. There it is possible to 1) "Recalculate Statistics" and then 2) remove histories for selected items. Once you have managed to remove history data for the problematic files, they may be edited again.

@datakurre Ah! That's good to know, I wasn't aware that any fields on the File content type had changed, but I can't be 100% certain other admins haven't added fields and then removed them. I will check.

Will also give that addon a try, thank you for the tip!

Would you remember if that site has received any Plone version upgrades? I see no reason why a Plone upgrade could not cause the same issue :thinking: This could be a relatively new issue, because I don't remember this before (and the features in question are old; it's just that underlying libraries have had major upgrades in the last few years).

Yes, it has had upgrades, the most recent being from 5.2.1 to 5.2.4, but I believe this problem was already happening in 5.2.1.

For info, the collective.revisionmanager addon does work. I find the piece of content and remove the history, it will then allow me to edit/update the file without issue, so thanks again for that tip! Unfortunately, for this site, retaining a content history, especially for files, is quite important, so this will work for some where it's not required, but do you think there will be a way to fix it so we can retain the history?

Yes. It will take some time, but I'll report back. So, don't remove all history yet :slight_smile:

Meanwhile, also copying a file would result a working version (while keeping the original untouched with broken history), but the copy would have no history nor references of the original.

I was unable to reproduce this issue on Plone 5.2.2. I assume this was introduced in Plone 5.2.3 (most probably technically in plone.dexterity==2.10.0). Unfortunately, rolling back would not fix the issues, but probably break edit for all the files that are now working.

@lardymike So, big thanks to you for reporting that, so that we can figure out a fix.

After looking the issue in more detail yesterday, I am quite confident that this could be fixed soon.

It's good to know that our site data wasn't at fault at least! :slight_smile: Thank you for taking the time to investigate and confirm we've identified a bug.

I look forward to testing the fix when it's made ready.

Test reproducing this issue and fix is now pending at Fix issue where versioning dynamic content types with blob fields broke after a schema update by datakurre · Pull Request #58 · plone/ · GitHub

Review and release process might take some time.

The fix requires no migration steps or changes to data or history. Just new code.

1 Like

@lardymike The fix has been released in · PyPI

Would be nice to hear if it worked also outside our regression tests :slight_smile:

1 Like

@datakurre have tested that on a local version of our live site and can confirm that it does indeed fix the problem we were having!

That's amazing work, thank you for rectifying this so quickly, it's most appreciated :+1:

1 Like