Subrequests issued during programatic setup of a Plone site

I have a custom setup script for a Plone 5 demo site (for XML Director).

This code leads to an unexpected error

-> addPloneSite(app, 'xml-director', extension_ids=['plonetheme.barceloneta:default', 'xmldirector.plonecore:default', 'xmldirector.demo:default', 'pp.client.plone:default'])

2016-08-27 12:35:23 ERROR plone.subrequest Error handling subrequest to http://nohost/xml-director/++resource++xmldirector.plonecore/ag-grid/dist/ag-grid.js
Traceback (most recent call last):
File "/home/ajung/.buildout/eggs/plone.subrequest-1.7.0-py2.7.egg/plone/subrequest/", line 143, in subrequest
traversed = request.traverse(path)
File "/home/ajung/.buildout/eggs/Zope2-2.13.24-py2.7.egg/ZPublisher/", line 525, in traverse
return response.notFoundError(URL)
File "/home/ajung/.buildout/eggs/Zope2-2.13.24-py2.7.egg/ZPublisher/", line 718, in notFoundError

Resource: %s

" % escape(entry))

Where is this subrequest coming from? Why is there a need for a subrequest during the installation/setup of a new site?

set a breakpoint and find out

Well...resource registry again:

-> addPloneSite(app, 'xml-director', extension_ids=['plonetheme.barceloneta:default', 'xmldirector.plonecore:default', 'xmldirector.demo:default', 'pp.client.plone:default'])
-> 'profile-%s' % content_profile_id)
-> dependency_strategy=dependency_strategy)
-> message = self._doRunImportStep(step, context)
-> return handler(context)
-> return importResRegistry(context, _REG_ID, _REG_TITLE, _FILENAME)
-> importer.body = body
-> self._importNode(dom.documentElement)
-> cookWhenChangingSettings(self.context, legacy)
-> response = subrequest(siteUrl + '/' + resource.js)
> /home/ajung/.buildout/eggs/plone.subrequest-1.7.0-py2.7.egg/plone/subrequest/
-> assert url is not None, 'You must pass a url'

The old resource registries used type specific hacks to emulate a request and obtain the standard resource content (used for cooking, caching, bundling, ...) -- a cause for many problems associated with resource registries.

Apparently, the type specific approach has now been abandoned in favor of general "subrequest" support (this is good).

Likely, you should not ask where the "subrequest" comes from but why the subrequest does not find the resource. I can see two potential causes:

  1. The url/path to the resource is not correct (for whatever reason)

  2. The "GenericSetup" configuration may lack a dependency declaration for one or more steps. Missing necessary dependency declarations, "GenericSetup" can show apparently non-deterministic behaviour with regard to the step order. This means, when it sometimes works without problems this does not mean that all necessary dependency declarations are in place; in may easily fail in another situation.

1 Like

Please no unrelated meta comments that have nothing to do with the resolution of the primary problem.


My reply does not contain a meta comment nor is it unrelated: it explains why you see a "subrequest" (a replacement for a formerly type sepcific request emulation) and suggests where to look further for a potential cause of the problem you observe (check where the url comes from; check whether your "GenericSetup" profile lack a dedendency declaration).

I get more and more the impression that you are not really interested in suggestions to get your problem solved but that your primary interest is to criticize. As a consequence, I will start to ignore your posts. (Yes, this paragraph contains a meta comment).

1 Like

Yes, please.


I tested the addPloneSite() issue with other add-ons defining a cssregistry.xml or jsregistry.xml: same result. So adding a Plone site programmatically with "old-style" registries is completely broken.

So I need to bring back the discussion about supporting old-style registries in Plone 5.1. Given the myriad of bugs with old-style resources I strongly recommend to drop their support for Plone 5.1 completely because the problems can not be fixed. Fixing one issue causes two new bugs to pop up. Unfortunately that will make porting older add-ons to Plone 5 even more painful.


Would you PLIP this and lead to make it happen?

1 Like

I think the Mephisto sprint next wk is a good place to discuss this. Not sure about contributing/removing stuff due to very little background in the old and new implementation of the resource registries.


If you could prepare a PLIP, Ramon and Narhan might be happy to remove that legacy registry support :slight_smile: (AFAIK, it would not require remove anything related to old registries, just remove the added [possibly hacky] support from the new registries.)

Will do that right now while flying to Leipzig.

1 Like