Improper resource URLs generated in Plone 5.0.5

[zopyx]

Copied from Community.plone.org for your convenience:

I tried again to get my XML Director stuff flying on Plone 5.0 with the 5.0.5 release - however the nightmare with falling from one trap into another continues.

I have a stylesheet referencing to some SVGs in my resource folder:

a.type-file:before {
background-image: url(++resource++xmldirector.plonecore/images/svg/raw2.svg) !important;
}

a.type-file[href*='.xml']:before {
background-image: url(++resource++xmldirector.plonecore/images/svg/xml5.svg) !important;
}

a.type-file[href*='.html']:before {
background-image: url(++resource++xmldirector.plonecore/images/svg/html9.svg) !important;
}

a.type-file[href*='.pdf']:before {
background-image: url(++resource++xmldirector.plonecore/images/svg/pdf19.svg) !important;
}

a.type-file[href*='.css']:before {
background-image: url(++resource++xmldirector.plonecore/images/svg/css5.svg) !important;
}

The stylesheet is configured using cssregistry.xml:

<?xml version="1.0"?>
<object name="portal_css" meta_type="Stylesheets Registry">
 <stylesheet title="" cacheable="True" compression="safe" cookable="True"
    enabled="True"
    id="++resource++xmldirector.plonecore/styles.css" 
    media="screen" rel="stylesheet" rendering="link" />
</object>

However the resource files can not be loaded due to some improper URL.

Where is this ++plone++production/++unique++/... prefix in the URL of the resource files coming from?

[hvelarde]

@ebrehault this seems to be related to your previous changes in the resource registry in #1300.

[hvelarde]

maybe this is an stupid proposal but… anyway: has anybody on the @plone/framework-team thought about the following possible implementation for the resources registries story:

• remove completely the legacy bundle and associated stuff from the new implementation
• bring good old Products.ResourceRegistries back into Plone 5.0 as a hard dependency (to be removed in Plone 5.1) to deal with old stuff

what can we accomplish with this?

• smaller, cleaner and easier to maintain code for the future
• Plone 5 do the stuff the new way but old way coexist in the same way it was before without any magic bundles
• clear path for migration: in Plone > 5.0 we still will be able to use old Products.ResourceRegistries as a optional dependency

is that possible? do you want a PLIP?

[zopyx]

Note that I was not suggesting to bring back the old cmf registries back.

[hvelarde]

in my opinion what I'm proposing is what we should have done to get rid of the old resource registries in an orderly way:

• let's face it: the new resource registry was not tested enough before it was included in Plone; we didn't think about the implications for add-on developers and integrators and that leads to a low number of add-ons being compatible with Plone 5 and, because of that, a very low number of sites being migrated to Plone 5; adoption is low and is going really slowly; resource registries is one of the reasons for that
• Products.ResourceRegistries works; having old stuff using jsregistry.xml and cssregistry.xml there is already implemented
• new Plone legacy bundle is buggy and it has to keep support for old way of doing things; those things don't belong there
• resource consolidation is overrated, IMO; old resource registry works most of the time and you are able to serve a nice Plone site with very few resources; loading 1 or 3 JS files… 1 or 3 CSS files… things are not that bad and there are currently other ways to minimize the number of requests (HTTP/2 just to mention one); just to give you an example, on the sites we maintain we are able to easily get an A rating from PageSpeed Insights and a B rating from YSlow with very few work
• putting another stack of technologies to do simple things like adding a single JS or changing the color of a site is also bad, specially looking at how things move on the JS world and what we have chose for CSS development

I have no idea of the implications, but better now than later.

[zopyx]

Not sure what the old resource registries would solve in the context of Plone 5?

Adding a single JS file directly inside a template without any registration may lead to the welcome RequireJS errors. So the old registries would blindly inject the JS scripts in the same way with the same risk of random breaking. The fundamental limitation (not sure if I am allowed to call it a flaw) is that dominance of the RequireJS approach is often not compatible with third-party JS modules. There has to be a clear, well-defined and under all circumstances working way to have arbitrary JS code living side by side with stuff under the control of RequireJS. This is not a question how we register JS/CSS files (as bundles/resource or through the old CMF registries), the question is how both can live side by side without side-effects.

Side rant: the current limitation of one JS file per resource is neither friendly nor approachable.some JS modules have one main JS module and other JS modules as plugins...you need to define multiple resource in this case because a resource is limited to one JS file per resource. I personally don't care why this limitation exist but the leads to a huge configuration overhead and verbose configuration with the result that the related XML snippets in registry.xml become much larger than related configurations in jsregistry.xml. Readabilty and easy approachability is king (from the integrators prospective and in particular from the prospective of not so advanced Plone devs).

[rodfersou]

I get many dilemmas when I think about it.

The JavaScript we are used to write for Plone 4.x is not compatible with Plone 5.x. It needs to be rewritten to support AMD and RequireJS. So the addons need to break compatibility and have two supported versions. There's not an easy way to make an upgrade step to reuse the old JS, besides the registry would be different anyway.

On the other hand, we are thinking about adopting ReactJS instead of Backbone and every place I study ReactJS, they use a different approach to work with Javascript modules. They use Webpack, and Webpack figures out how to work with modules without using RequireJS.

So I don't know if it's the case to rewrite our registry – to stop using RequireJS and Grunt in favor of using Webpack instead – or if we are going to build a Frankenstein... Our way to manage resources will be disconnected with the way other places do ReactJS, which means that if we get in trouble, it will be our problem and we will not find easy help in the internet.

[keul]

I don't think using webpack is the way to go... not now.

Webpack is amazing but it won't work with the Plone add-ons ecosystem, you need to have full control of your JavaScript sources. AMD is the only way to go right now.

[ebrehault]

@zopyx this bug is due to my commit 45bd7db
That's what inserts the ++production++ thing at the begining of each URLs.
I made that change so relative URLs are not broken when bundles are merged, and it works with local URLs, but not with ++resources++ URLs (actually any URLs starting with "++" should be prefixed with "../../" and it should work).
I need to fix that.

Note: meanwhile, you can just exclude your bundle from merging and it should work fine.

[ebrehault]

@zopyx I got it. URLs prefixing works fine with bundles, but you have no bundle, you use cssregistry.xml. I need to dig a little bit more.

[keul]

@ebrehault any news about this? I've a similar issue as @zopyx but I'm using a bundle (a simple bundle with a CSS inside, that want to refers to resouces defined somewhere else).

Rght now I need to define CSS with relative URLs like ../../++resource++foo/... but I'm only able to make CSS working in production mode or development mode.

😞

[ebrehault]

@keul, well I haven't worked on this issue yet, but what you describe is a different issue (I have to admit I did not think about referencing external resources, I am afraid it will be quite complex to handle, but I will try to figure it out).

[keul]

Thanks @ebrehault, much appreciated.

[displacedaussie]

I ran into this yesterday and can confirm that @ebrehault's solution of turning off the merge_with option for the bundles helped for my more or less "default" site. I now have the following in my Plone 5 GS profiles:

<?xml version="1.0"?>
<registry>

  <!-- Bundles -->
  <records prefix="plone.bundles/plone"
            interface='Products.CMFPlone.interfaces.IBundleRegistry'>
    <value key="merge_with"></value>
  </records>

  <records prefix="plone.bundles/plone-logged-in"
            interface='Products.CMFPlone.interfaces.IBundleRegistry'>
    <value key="merge_with"></value>
  </records>

  <records prefix="plone.bundles/resourceregistry"
            interface='Products.CMFPlone.interfaces.IBundleRegistry'>
    <value key="merge_with"></value>
  </records>

  <!-- bundle -->
  <records prefix="plone.bundles/thememapper"
           interface='Products.CMFPlone.interfaces.IBundleRegistry'>
    <value key="merge_with"></value>
  </records>

</registry>

[emansije]

Sorry for the noob question, @displacedaussie, but how do I insert that XML in the GenericSetup?

[tkimnguyen]

@emansije you'd have to include that XML in a file system add-on, though a very recent merge gives Plone the ability to import XML like that through the web.

[cekk]

I had a similar issue too yesterday.
My situation was a Plone 5.1rc2 with updated mockup version (to fix a bug with a pattern).
To be able to see the mockup update in the site, i had to re-compile plone-logged-in from the control panel.

After compiling it, i had mockup patterns updated, but i lost tinymce button icons because there were some resources with a wrong url, for example:
http://localhost:8080/Plone/++plone++production/++unique++2018-01-05T17:32:55.304059/++plone++static/components/select2/select2.png

or a couple of fonts needed by plone-logged-in.css.

With @ebrehault and @displacedaussie trick, it seems to be fixed, but i don't know if this change will affect something else.

[pbauer]

The same issue appeared on demo.plone.de with Plone 5.1.1. I worked around this with collective/demo.plone.de@a1d41f5 but it needs a proper fix in the core.

[pbauer]

In 5.1.2-pending i could not reprocide it any more. Can this be closed? @ebrehault

[ebrehault]

@pbauer did you try to reproduce the original issue or the one described by @keul ?

[pbauer]

@ebrehault I had the same issue as @cekk but with tinymce-icons in a clean instance:

When running 5.1.1 in production I got requests to http://localhost:8082/Plone7/++plone++production/++unique++2018-04-18T13:49:25.560803/++plone++static/fonts/tinymce.ttf and http://localhost:8082/Plone7/++plone++production/++unique++2018-04-18T13:49:25.560803/++plone++static/fonts/tinymce.woff which do not exists so the icons in tinymce were broken. The workaround fixed these

In 5.1.2 the icons in tinymce work but Plone does not use a tinymce.woff and tinymce.ttf any more. The only font being loaded is roboto and that comes from http://localhost:8082/Plone8//++theme++barceloneta/less/roboto/roboto-regular.woff (yes there are two // in the url)

When I run in foreground the issue never appears.

Since the fix might be due to a change in tinymce the issue might still be open.

[ebrehault]

I think so, because I haven't seen any recent changes that could have fixed it.

[sunew]

Issue can be reproduced on 5.1.3-pending

Reproduce:
On a site running with instance start (not in debug mode).
Go to resource registry, set in debug mode. Save. Set it back to production. Save.
Now you get 404's on:

https://cms.integrationsviden.dk/++plone++production/++unique++2018-09-11T17:21:00.926425/++plone++static/fonts/plone-fontello.woff
https://cms.integrationsviden.dk/++plone++production/++unique++2018-09-11T17:21:00.926425/++plone++static/components/bootstrap/fonts/glyphicons-halflings-regular.woff2

[jensens]

Afaik this was fixed. Please reopen if i am wrong.

[scmos]

Just like @displacedaussie I am trying to change the tags to but I am still with Improper resource URL
http://10.38.239.35:8084/Plone/++plone++production/++unique++2020-01-16T20:27:36.971913/++plone++static/fonts/plone-fontello.woff

However in TTW override way I edit the file default.css and change the local routes with ../../fonts and the error is corrected.

I am using 5.1.6 migrated from 5.1.5

Any suggestion to definitively solve?