At some point in the evolution of a Plone instance, I installed collective.venue which depends on plone.formwidget.geolocation and plone.patternslib. Then I stopped using this feature and uninstalled the addons, but for some reason the Plone instance seems addicted to plone.patternslib;
when I try to compile my resources using ./bin/plone-compile-resources,
it failed miserably...
How to manage the registry of resources in order to fix this issue?
I already spent days trying everything I could... Help!
Edit/Update:
Part of the solution was to run "Plone Patternslibs uninstall" in /portal_setup/manage_fullImport
But I must keep plone.patternslib in my buildout (even if I don't need it...)
Is there a better solution?
44 errors related to the absence of plone.patternslib, like:
ERROR:plone.subrequest:Error handling subrequest to http://nohost/Plone/++plone++patternslib/bundle-leaflet.js
ERROR:plone.subrequest:Error handling subrequest to http://nohost/Plone/++plone++patternslib/components/desandro-matches-selector/matches-selector.js
ERROR:plone.subrequest:Error handling subrequest to http://nohost/Plone/++plone++patternslib/components/ev-emitter/ev-emitter.js
In /config.js there's more traces of patternslib (in the requirejs.config array), even when patternslib is not in the buildout:
The problem is, that plone.patternslib defines an uninstall profile, but there is no "uninstall" directory in profiles folder, which should remove all resource/bundle keys defined in plone.patternslib/registry.xml at master · plone/plone.patternslib · GitHub ... either you add this in a PR of plone.patternslib or you remove them manually in /portal_registry ... first solution very welcome
It still does not solve the problem, my Plone instance is still addicted to plone.patternslib...
It seems that plone.mosaic needs it installed or else plone-compile-resources stops because of a dependency for pat-base:
Running command: /home/vagrant/Plone/zinstance/node_modules/grunt-cli/bin/grunt --gruntfile=/home/vagrant/Plone/zinstance/Gruntfile.js compile-all
Running "requirejs:filemanager" (requirejs) task
>> Error: ENOENT: no such file or directory, open '/pat-base.js'
>> In module tree:
>>
>> /home/vagrant/Plone/buildout-cache/eggs/cp37m/plone.staticresources-1.4.3-py3
>> .7.egg/plone/staticresources/static/filemanager.js
>> mockup-patterns-filemanager
Warning: RequireJS failed. Use --force to continue.
Even if I provide it, there's a new error:
Running command: /home/vagrant/Plone/zinstance/node_modules/grunt-cli/bin/grunt --gruntfile=/home/vagrant/Plone/zinstance/Gruntfile.js compile-all
Running "requirejs:bundle-leaflet" (requirejs) task
Running "requirejs:filemanager" (requirejs) task
>> Error: ENOENT: no such file or directory, open '/text.js'
>> In module tree:
>>
>> /home/vagrant/Plone/buildout-cache/eggs/cp37m/plone.staticresources-1.4.3-py3
>> .7.egg/plone/staticresources/static/filemanager.js
>> mockup-patterns-filemanager
Warning: RequireJS failed. Use --force to continue.
This plone-compile-resources business is very unfriendly...
No, the main cause has less relevance to the resource registry: if an add'on has an install profile that applies settings to the configuration/contentdb, it is good custom to also provide an uninstall profile that does the reverse of applying all those settings.
Normally there is a obvious warning next to an add'on that you cannot uninstall it. (this is when there is an install, but no uninstall profile registered). Then you are warned as a non technical user, here be dragons. The nasty twist here is that there apparently is an incomplete or even empty uninstall profile. So in this case it is a developer mistake: the empty uninstall profile shouldn't have been registered so as an end user you'd have been warned that this add'on is a one way street.
What is an issue with the resource registry is a design choice that was made or 'what is worse' for how resources are handled in Plone 5.X. If you register a resource, but the resource later on cannot be retrieved through the given url/location for whatever reason, and this is just one, what should the bundler do: silently ignore the css and js, skip the resource, still create the productin css/js bundle and let all kinds of strange side effects happen in your website of which your users/visitors onlly notify you 2 weeks later? And then let the great search for root cause begin? Or sound the alarm and/or break of bundling immediately so that you know something is going on?
With a developer mindset you want to fail early, as an end user/webmaster mindset you just want everything to always work perfectly because somebody else didn't forget or have the need or time to create an uninstall profile....
This issue touches another discussion here on the forum on the future of TTW development with Plone. This is a fine example of the dilemma's we face when we want to continue with 'foolproof TTW' capabilities. It's not just the tools, it's also the mindset how you want the tools to function
I am pretty sure 'the default setup' of Mosaic does not need it (because I have some theme fragments that requires patternslib, and they do not work if I dont install it
You can try with bin/plone-compile-resources -b <bundle name> to compile only your specific bundle and its dependencies .... the other bundles might need more node_modules installed then you have. Generally the ZODB-resource-registry-gruntfile-generator-driven-js-compiling™ was always a "bit" overengineered and we are happy to get rid of it in Plone 6 with ES6 and webpack for developing Javascript.
Yes, but I still can't get rid of plone.patternslib... What I discovered is that I can disable plone.patternslib so it's not included in the automated default.js and default.css aggregated resources. It's good enough, so I will consider my issue "solved"... Thank's all for your help.
