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'.
Related
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.
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!
Overview
A client contacted us requesting that when they fill in a form on their site (created with PloneFormGen), they want the input of the form sent to the customer in PDF format (the converted form must be then printed, signed and posted back to the customer).
I jumped on the Plone.org IRC room and asked the guys there, they suggested I use the zopyx.smartprintng.plone add-on. This seemed perfect because they have a script adapter example for PloneFormGen that I can use to convert the form input into a PDF file.
The docs for the add-on are on this page:
http://docs.produce-and-publish.com/#produce-publish-client-connector
Going on that I was told I only needed to install the "Produce and Publish Client Connector" I proceeded to follow the installation instructions on the documentation.
The Installation
The buildout installation went fine, it reported no errors at all and my buildout reflects exactly what they state it must on that installation documentation page.
However I noticed that under "Add/Remove Add-ons" in the Plone Control Panel, I could see no reference to this add-on, thus preventing me from actually enabling it on the particular site I am working on. (I have a feeling this may be the cause of the problem I am experiencing, but I have no idea how to resolve it). - I have checked portal_quickinstaller and it's not there either.
The Problem
According to the documentation appending ##asPlainPDF to the URL of the page you want to render will then render the PDF for you.
So I enter mysite.com/front-page/##asPlainPDF in my browser.
Upon doing this I receive this traceback:
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 zopyx.smartprintng.plone.browser.pdf, line 249, in __call__
Module zopyx.smartprintng.plone.browser.pdf, line 85, in __call__
Module zopyx.smartprintng.plone.browser.pdf, line 232, in __call2__
Module zopyx.smartprintng.client.zip_client, line 192, in convertZIP2
Module xmlrpclib, line 1224, in __call__
Module xmlrpclib, line 1578, in __request
Module xmlrpclib, line 1264, in request
Module xmlrpclib, line 1292, in single_request
Module xmlrpclib, line 1439, in send_content
Module httplib, line 954, in endheaders
Module httplib, line 814, in _send_output
Module httplib, line 776, in send
Module httplib, line 757, in connect
Module socket, line 571, in create_connection
error: [Errno 111] Connection refused
If you need more information than this please tell me where to get it and I shall provide it to you.
I have Google'd the error: [Errno 111] Connection refused message but it is either people experiencing issues with a Python program they are writing or a different add-on named zopyx.smartprintng.lite
I did find this thread however: https://groups.google.com/forum/#!msg/plone-users/wCuO4RCUIQk/VslwOXvs4XwJ
So as one user suggested I tried installing zopyx.smartprintng.server however that started complaining that I had the wrong version of zope.configuration, and wants >=3.8.0dev upon pinning that to 4.0.2 as it was the latest I could find, it then started complaining about another add-on and I got some buildout errors, which then bricked my Plone server (stopped the clients from coming up) and I had to re-run buildout from a backup buildout.cfg I made so it would make the necessary zope.conf files.
Server information
Plone 4.2.1.1 (4207)
CMF 2.2.6
Zope 2.13.16
Python 2.7.3 (default, Oct 18 2012, 15:13:00) [GCC 4.6.3]
Summary
Followed these installation instructions:
http://docs.produce-and-publish.com/#produce-publish-client-connector
Received the above traceback trying to convert PDF when appending ##asPlainPDF to URL
Attempts to install zopyx.smartprintng.server have failed.
The Produce-and-publish set of components does indeed require the server to be set up. The Plone product you installed is merely the integration point between Plone and that server.
Please to follow the instructions on http://docs.produce-and-publish.com/server/installation.html to install that separate server (it can have it's own buildout).
(If you run into problems with that installation, feel free to ask a new question here on Stack Overflow, or ask on the Plone Users mailinglist, or contact the author (which may require you to pay Zopyx for such support)).
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.