I am running a pretty much unmodified instance of Plone 5.0.
I created a lot of folders today, one of which was named "Layout" in a parent folder "Design", which was in the root folder.
This Layout folder caused an error in the view of the Design folder. All I see is the error page
We’re sorry, but there seems to be an error…
The error has been logged as entry number 1470387402.080.1605824509.
If you need to report this to the
Site Administration, please include this entry number in your message.
The error log of Plone has the following entry:
Exception Type
RuntimeError
Exception Value
maximum recursion depth exceeded
Traceback (innermost last):
Module ZPublisher.Publish, line 127, in publish
Module ZPublisher.BaseRequest, line 444, in traverse
Module Products.CMFCore.DynamicType, line 147, in __before_publishing_traverse__
Module Products.CMFDynamicViewFTI.fti, line 236, in queryMethodID
Module Products.CMFDynamicViewFTI.fti, line 197, in defaultView
Module Products.CMFPlone.PloneTool, line 771, in browserDefault
Module Products.CMFDynamicViewFTI.browserdefault, line 99, in getLayout
Module Products.CMFDynamicViewFTI.fti, line 136, in getViewMethod
Module Products.CMFDynamicViewFTI.browserdefault, line 72, in __call__
Module Products.CMFDynamicViewFTI.browserdefault, line 72, in __call__
Module Products.CMFDynamicViewFTI.browserdefault, line 72, in __call__
Module Products.CMFDynamicViewFTI.browserdefault, line 72, in __call__
Module Products.CMFDynamicViewFTI.browserdefault, line 72, in __call__
and goes on for a couple of dozen identical calls.
This only happens with this specific folder. I deleted it and created it again: same error. All other folders work fine, even much deeper folder structures work fine.
Any idea what is wrong with this specific folder name?
Sometimes this happen with Plone due to acquisition.
Some names are reserved (looking at your traceback the issue seems related to the view selection, and Layout is in fact a dangerous name).
Plone itself protects you from creating some bad ids but it can cover all the cases.
Another common case with this type of issue is calling a catalog index "data", or calling a content like a catalog index.
Just use a different name.
Related
I'd like to use transmogrifier to copy a little excerpt of the one Plone 4 site to another. I followed the instructions in the quintagroup documentation, e.g. here.
I added both collective.transmogrifier and quintagroup.transmogrifier to my buildout:
[instance]
eggs +=
Products.Marshall
collective.transmogrifier
quintagroup.transmogrifier
zcml +=
collective.transmogrifier
quintagroup.transmogrifier
However, the installed version 1.4 of collective.transmogrifier was not sufficient, since it lacks the traverse function in the utils module:
File ".../eggs/plone.app.transmogrifier-1.3-py2.7.egg/plone/app/transmogrifier/atschemaupdater.py", line 8, in <module>
from collective.transmogrifier.utils import traverse
zope.configuration.xmlconfig.ZopeXMLConfigurationError: File ".../parts/instance/etc/site.zcml", line 15.2-15.55
ZopeXMLConfigurationError: File ".../parts/instance/etc/package-includes/027-quintagroup.transmogrifier-configure.zcml", line 1.0-1.70
ZopeXMLConfigurationError: File ".../eggs/quintagroup.transmogrifier-0.5-py2.7.egg/quintagroup/transmogrifier/configure.zcml", line 11.4-11.50
ZopeXMLConfigurationError: File ".../eggs/plone.app.transmogrifier-1.3-py2.7.egg/plone/app/transmogrifier/configure.zcml", line 9.2-12.8
ImportError: cannot import name traverse
I specified collective.transmogrifier = 1.5 in my versions.cfg, and then changed eggs/quintagroup.transmogrifier-0.5-py2.7.egg/EGG-INFO/requires.txt which insisted in collective.transmogrifier<1.5 (why?) to
collective.transmogrifier<=1.5
After rebuilding and restarting I was able to add the quintagroup.transmogrifier in the quickinstaller view.
However, when I tried to export the site in the Generic Setup Tool, I failed miserably:
Traceback (innermost last):
Module ZPublisher.Publish, line 138, in publish
Module ZPublisher.mapply, line 77, in mapply
Module ZPublisher.Publish, line 48, in call_object
Module Products.GenericSetup.tool, line 583, in manage_exportSelectedSteps
Module Products.GenericSetup.tool, line 1038, in _doRunExportSteps
Module quintagroup.transmogrifier.exportimport, line 72, in exportSiteStructure
Module collective.transmogrifier.utils, line 118, in constructPipeline
Module quintagroup.transmogrifier.sitewalker, line 32, in __init__
Module collective.transmogrifier.utils, line 225, in __init__
AttributeError: Transmogrifier instance has no attribute 'configuration_id'
It didn't make a difference whether I saved the default export profile before or not.
Is there some configuration step missing, or is there some reason for the collective.transmogrifier <1.5 constraint? I'd like to see this work before taking on the task of selecting the whitelisted contents ...
I've come across this before, but I was able to avoid using quintagroup.transmogrifier in that case.
The pin was removed in this commit in master (though it was a little more complicated than that if you check the history of setup.py).
So basically you are going to have to check out that product in your buildout:
[sources]
...
quintagroup.transmogrifier = git https://github.com/collective/quintagroup.transmogrifier.git
and rerunning buildout (probably bin/buildout -c develop.cfg) should do it, though that should be considered a short term hack rather than a long term solution if you are doing it on production.
The long term solution is to build your own '0.5-tobias' egg using jarn.mkrelease or zest.releaser (more modern that mkrelease, but trickier to figure out) or raise an issue on https://github.com/collective/quintagroup.transmogrifier.git to ask someone to make an official release for you!
Can anybody explain me that error - and how I can repair it?
We use:
Plone 4
Zope 2.12.19
ZEO
zodb-temporary-storage
Error Log
Site Error
An error was encountered while publishing this resource.
Sorry, a site error occurred.
Traceback (innermost last):
Module ZPublisher.Publish, line 239, in publish_module_standard
Module ZPublisher.Publish, line 197, in publish
Module ZPublisher.Publish, line 197, in publish
Module ZPublisher.Publish, line 197, in publish
Module ZPublisher.Publish, line 173, in publish
Module plone.app.linkintegrity.monkey, line 17, in zpublisher_exception_hook_wrapper
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 419, in _commitResources
Module ZODB.Connection, line 767, in tpc_vote
Module ZEO.ClientStorage, line 1068, in tpc_vote
Module ZEO.ClientStorage, line 905, in _check_serials
ConflictError: database conflict error (oid 0x08, class Products.Transience.Transience.Length2, serial this txn started with 0x0394fddba7126fbb 2012-03-08 07:23:39,157504, serial currently committed 0x0394fddbb0a4cb22 2012-03-08 07:23:41,400873)
Troubleshooting Suggestions
The URL may be incorrect.
The parameters passed to this resource may be incorrect.
A resource that this resource relies on may be encountering an error.
For more detailed information about the error, please refer to the error log.
If the error persists please contact the site maintainer. Thank you for your patience.
I tried to repaire the Data.fs without any errors...
Thanks in advance.
Conflict Errors occur when two users try to update the same object (often one that is part of a catalogue data structure) at the same time and the system cannot resolve the conflict. You should ensure that your ZEO server includes all of the eggs from the Zope instance to ensure you have all the conflict resolution code.
If you are seeing these on simple views, then it probably means you have some code that is updating the database on rendering that view. This is not a good idea with ZODB.
In short, when I go into Site Setup -> Types and try and change the workflow for Images from "No Workflow" to any other workflow, I get the following error:
Traceback (innermost last):
Module ZPublisher.Publish, line 126, in publish
Module ZPublisher.mapply, line 77, in mapply
Module ZPublisher.Publish, line 46, in call_object
Module plone.app.controlpanel.types, line 165, in __call__
Module zope.event, line 31, in notify
Module zope.component.event, line 24, in dispatch
Module zope.component._api, line 136, in subscribers
Module zope.component.registry, line 321, in subscribers
Module zope.interface.adapter, line 585, in subscribers
Module plone.app.discussion.browser.controlpanel, line 181, in notify_configuration_changed
AttributeError: 'NoneType' object has no attribute 'forInterface'
I suspect the way we setup this Plone instance caused the issue. We have a 4.0.8 install (Staging) where we did our initial site construction. We setup another 4.0.8 install for production. Ran a backup on Staging and copied the Staging backup files and blobstorage over to Production. Production worked fine; appeared to be a perfect clone of Staging.
Later, we wanted to move to 4.1.1, so we created another install on 4.1.1 and repeated the above process from Production to our new instance. After a day of testing, it appears to work. Cool, we have a 4.1.1 Production box now. Week later, users want Images to operate under the same workflow (Intranet/Extranet) as all the other content and that's when I ran into the error.
I can change the workflow through the ZMI portal_workflow tool without any apparent problems.
Looking at the product code, It seems that when you change the contenttype's workflow the p.a.discussion product tries to update its configuration but in your instance fails to retrieve the registry.
As a fast solution you could try to force the inclusion of the registry by adding in a zcml of one of your products this code:
<include package="plone.app.registry" />
then:
1- go to zmi -> your site and check if in your plone site exists an item called "portal_registry"
2- go to zmi -> your site -> tab "Components" and check if exists this registration:
<utility interface="plone.registry.interfaces.IRegistry"
object="portal_registry" />
Had the same problem, could solve it by importing the steps 'Manage the configuration registry' and ' Plone caching' of the profile 'Configuration registry'.
I named an attribute (field) in a content-type 'string' instead of 'company'.
I've installed my product and after seeing this error, I changed it in my content type class, reinstalled the product, ran update security settings and update catalog. But I keep getting:
Module Products.CMFPlone.utils, line 392, in _createObjectByType
Module Products.CMFCore.TypesTool, line 290, in _finishConstruction
Module Products.CMFCore.CMFCatalogAware, line 148, in notifyWorkflowCreated
Module Products.CMFCore.WorkflowTool, line 291, in notifyCreated
Module Products.DCWorkflow.DCWorkflow, line 346, in notifyCreated
Module Products.DCWorkflow.DCWorkflow, line 430, in _changeStateOf
Module Products.DCWorkflow.DCWorkflow, line 529, in _executeTransition
Module Products.DCWorkflow.DCWorkflow, line 389, in updateRoleMappingsFor
Module Products.DCWorkflow.utils, line 64, in modifyRolesForPermission
Module AccessControl.Permission, line 92, in setRoles
AttributeError: string
How do I delete this string attribute that is persisted somewhere in ny ZODB since I've already removed it from my content type? I've reinstalled the product, restarted my instance, but I keep getting the same problem. Ideas? I can delete my Data.fs since it's a development machine, but if it happened in a production site, this wouldn't be an option.
PS: When I ran bin/instance fg:
2011-07-28 19:01:59 WARNING Init Class mynamespace.mypackage.content.mycontent.MyContent has a security declaration for nonexistent method 'string'
I found the problem. I changed in my content class, but didn't change in my content type interface.
paster creates a # -*- schema definition goes here -*- on interfaces.py as well. I did a grep string on my product directory and found it.
Here's the problem. I have mynamespace.mypackage that has as a dependency mynamespace.mydependencypackage, that is a local utility. It's registered using component registry.
In config.py from mynamespace.mypackage, I have
DEPENDENCIES = ['mynamespace.mydependencypackage']
And in my mynamespace.mypackage's setuphandlers.py this dependency is installed if not already installed.
Problem is: if I reinstall mynamespace.mypackage through ZMI, everything seems to perfectly install (since no errors are shown) but I keep getting a ComponentLookupError when using methods in mynamespace.mypackage that gets the utility:
Module zope.component._api, line 207, in getUtility
ComponentLookupError: (<InterfaceClass MY_UTILITY_INTERFACE, '')
I can 'fix' this problem, by reinstalling the mynamespace.mydependencypackage in my setuphandlers.py or through the ZMI as well when reinstalling mynamespace.mypackage, but this doesn't seem the best solution for me.
What am I missing about Generic Setup here? I didn't make this utility persist any value on ZODB whatsoever. I can just forget about all these problems and create a BrowserView with utilities methods, but I want to understand first why am I having these problems.
EDIT: Now, I have a bigger problem. The TypeError: ('object.__new__(MyClass) is not safe, use Persistence.Persistent.__new__()', <function _reconstructor at 0xb7783e9c>, (<class 'mynamespace.mydependencypackage.package.MyClass'>, <type 'object'>, None)) is being shown. Full traceback:
Traceback (innermost last):
Module ZPublisher.Publish, line 110, in publish
Module ZPublisher.BaseRequest, line 429, in traverse
Module ZPublisher.BeforeTraverse, line 99, in __call__
Module Products.CMFCore.PortalObject, line 94, in __before_publishing_traverse__
Module zope.event, line 23, in notify
Module zope.component.event, line 26, in dispatch
Module zope.component._api, line 130, in subscribers
Module zope.component.registry, line 290, in subscribers
Module zope.interface.adapter, line 535, in subscribers
Module zope.component.event, line 33, in objectEventNotify
Module zope.component._api, line 130, in subscribers
Module zope.component.registry, line 290, in subscribers
Module zope.interface.adapter, line 535, in subscribers
Module zope.app.component.site, line 375, in threadSiteSubscriber
Module zope.app.component.hooks, line 61, in setSite
Module Products.CMFCore.PortalObject, line 75, in getSiteManager
Module ZODB.Connection, line 761, in setstate
Module ZODB.Connection, line 819, in _setstate
Module ZODB.serialize, line 604, in setGhostState
Module ZODB.serialize, line 597, in getState
Module copy_reg, line 48, in _reconstructor
TypeError: ('object.__new__(MyClass) is not safe, use Persistence.Persistent.__new__()', <function _reconstructor at 0xb7783e9c>, (<class 'mynamespace.mydependencypackage.package.MyClass'>, <type 'object'>, None))
It sounds like you have custom Python code in your setuphandlers.py file to install the dependency. Is there a reason you don't note the dependency in the metadata.xml file? Or can you show us that code?
When activating an add-on in Plone, it does a before/after comparison of various entities to support deactivation. Among these are local persistent utilities, as defined by the componentregistry.xml file. Note: anything defined in GenericSetup xml files results in persistent changes - if you want non-persistent utilities, use ZCML files to register them.
So when you have custom code to add a local utility in your setuphandlers.py code, Plone thinks this utility belongs to your main add-on. If you reinstall that add-on the utility gets removed alongside anything else and then everything is installed again.
I'm guessing your "is it already installed" check fails after the reinstall and the utility isn't added again.
You can avoid all of this, by simple giving both the dependency and main add-on their own GenericSetup profiles and than noting a dependency in the main's metadata.xml, like:
<?xml version="1.0"?>
<metadata>
<version>1</version>
<dependencies>
<dependency>profile-my.dependency:default</dependency>
</dependencies>
</metadata>
Once you do that the dependencies profile will be activated independently and Plone keeps track of it on its own. If you then decide to reinstall the main add-on, the dependency won't be touched at all and remains intact.