Today was interesting when an issue with saving content on a Plone 3.3.5 site got reported to me. The system was producing undecipherable error messages about ZEO disconnections and database conflicts whenever someone would try and create some content within Plone (folders, particularly). Errors looked like “Module ZEO.zrpc.connection, line 796, in wait. DisconnectedError” and “raise ReadConflictError(). ReadConflictError: database read conflict error”, and also “ERROR ZEO.zrpc (2515) can’t decode message: ‘(K\x11K\x01U\tserialnos(]((U\x08\x00\x00\x00\x00\x00X\x…’” — essentially the issue described here. My ZEO server was running ZODB3 3.9.5 with Python 2.6, and my client running ZODB3 3.8.3 with Python 2.4; almost everything worked.
Continue reading »
Okay. So, anyone out here who’s listening — particularly those overly-enthusiastic users — don’t try to recursively wget your Plone site (or other CMS, for that matter) whilst you’re logged in with an account that can make edits. It will lead to a very bad situation where your site administrator and technical team need to step in and fix your mistakes. For the uninitiated, a loose recursive wget (when logged in with some degree of Edit rights) will hit every link that’s on your pages, and I mean in the (X)HTML source. For a Plone site, this means hitting every “Edit” link, every “Revert to this version” link, and every other link that might be dangerous when clicked randomly. Oh, and if the account you’ve got has admin rights, well, it’s not getting any better and requires the Data.fs to be undone back to before it happened. Here’s how to do that easily.
Continue reading »
As the title suggests, there’s a conflict between a Zeo database instance being run together with a Plone 4/Zope instance, and them trying to share the same blob storage folder. But, this only happens if you misunderstand or incorrectly set the option of shared-blob = off, and blob-storage to be the same location as for Zeo in your buildout. If that previous set of (seemingly jumbled) thoughts doesn’t make any sense to you, then move along, nothing to see here.
Continue reading »
Another of the interesting things in my professional life has been migrating a Plone site from one database (where it lived as a dev site, along with many others) onto a nice, clean database of its own. Now, yes, I’m aware that the export/import feature of Zope ISN’T supposed to be used for migrating content or sites. I am also aware, however, through personal experience, that things have always been fine because I’m using the same eggs and essentially the same installations everywhere, thanks to buildout.
So, the process goes as follows, with the above-mentioned points considered already:
- Head to the root of your ZMI and export your given Plone site as ZEXP
- Shut down your instance (or do what you will with your old site and installation)
- Copy the ZEXP file into the ‘import’ folder of your new Zope instance
- Start your new instance, with your new empty database
- Log in to the root of the ZMI
- Add a new Plone site and call it anything you want (eg ‘foo’). I’ll explain why shortly.
- Delete your ‘foo’ Plone site.
- Import your existing Plone site and be happy because it’s now arrived safe and sound.
Note
The reason I highlight adding a new Plone site a point 6 is because if originally, you were like me and imported your site first to a bare Zope install, you’ll get errors everywhere in your site. They’ll look like “AttributeError: getGroups” or possibly something more obscure (if possible!) and everything will fall over and die.
Now, by creating a new Plone site first ‘massages’ the root of Zope, and then your site should be fine. Among other things, adding a site changes the acl_users of the ZMI (seeing an abnormal acl_users is what led me to the solution). At a guess, given its type, this acl_users change probably has something to do with the error above.