I appreciate when someone takes time and effort to dig into an issue; I would answer some of your doubts here, but I would prefer to continue the discussion on GitHub so we can land at the end with a fix and a new release.
please open a pull request and I would ask @rodfersou to help you.
"legacy" in the new Plone 5 resource registry terminology means JS and CSS resources that are loaded using an older approach: in Plone versions < 5 there were the portal_css and portal_javascript utilities; you registered your static resources there using a simple XML file that you can see here:
that was good enough in the old days, but showed its limitations as soon as client side code became more and more popular.
the new resource registries use a different approach and tries to bundle everything at runtime; that's IMO the chief problem: instead of keeping the old machinery and deprecate it gradually, core developers decided to replace the whole thing with something new and more complicated that is not playing well with old-style add-ons.
on a related topic, we have developed a completely new approach of bundling resources in our add-ons using webpack and we are pretty happy with it.
I think the first thing we need to do is update collective.glossary resources to use this approach; then it would be easier to fix and maintain it.
I didn't want to embarrass you @hvelarde .
In fact I appreciate your contribution to the community.
I've been promoting Plone for more than 15 years starting from Release 1 back in 2002, so just call me Newbie, I am fine with that.
But as I said, I am not developer, so I just want to ask, why is this addon working as documented by you (tooltip) at your customer and not in a new Plone 5 installation, when it is said to be compatible with Plone 5?
you're not embarrassing myself at all; I don't know you and I don't like this-is-what-is-wrong-with-Plone kind of comments from people I've never seen here before and just joined the forum the other day.
so, there's something wrong if after 15 years in the community you still don't get how OSS works: ranting is allowed, but if you want to get something done, you must give something back.
as mentioned before, if you found an issue, in this case an add-on not working as expected in a particular version of Plone, open an issue in the issue tracker.
exchanging messages on a general forum doesn't help at all.
I just asked a question, because I could have done something wrong in installing the addon.
And as you said there is no bug, as it works as defined for you.
If you think that everything is okay with Plone regarding documentation, marketing and enduser focus it's okay - but I won't agree.
This should be discussed on a general forum some other time, so let's get back to work...
As I understand it @hvelarde has customers with Plone 4. There is an indication in the code that there was some changes to adapt to Plone 5 but no such claim in the Readme and all the screen posted are Plone 4.
For the record I have now given a whirl to glossary on a vanilla 5.08 install and it does not work also, so the test done by @hvelarde must have been a bit quick; if I add the following hack to main.js
--- main.js.ori 2018-01-31 17:21:32.184441000 +0000
+++ main.js 2018-01-31 17:54:42.536616357 +0000
@@ -1,5 +1,6 @@
// Plone 5 does not include global variables anymore
var portal_url = (portal_url === undefined) ? $('body').attr('data-portal-url') : portal_url;
+if (portal_url == undefined) { portal_url = (this.PORTAL_URL == undefined) ? this.URL: this.PORTAL_URL }
$(function(){
$('#content-core').glossarizer({
it seems to work, but it's clear that is no proper fix since it works only in logged-in mode and also it's clear that I don't understand really what I have done so it's bad. But if you are desperate to have it working you can try it. Follow the indications I have given in this thread (uninstall, fix the resource registry, change the code, install again. I have done it to my 5.08 install in less than 5 minutes. But you should probably investigate the solution suggested by @tmassman.
That's interesting, I'd just first learning to use webpack. Not in the immediate future though, there are probably a few Plone bugs still lurking in the 5.1 code. And I will have to earn some money with real projects, this is also a concern for me.
That's really not what Hector was saying. He was saying that the add-on works for his client, in their particular environment.
It's quite possible for an add-on to have worked perfectly and then, a few weeks later, not work as well because of a change in some underlying browser component or other dependency.
as explained in the comment to the issue, there is a remaining issue but very probably unrelated: I did not see anything obviously similar in the existing issues from their titles alone (I did not read each issue one by one). I could tackle this one but I always hope that someone will say 'ahah ! this is a trivial problem and here is the solution'. Hope never dies in the face of the dark reality.
the resource registry and resource loading seems to work even if there are a few differences with Plone 4, however the debugging experience is worse indeed with Plone 5; I share your misgivings about it
The add-on resources are mixed with plone-legacy in logged-in mode, and with default.js in anonymous mode. That was what fooled me in thinking that it could not work in anonymous mode, while the problem was more childish: I had forgotten to publish the glossary !
What is truly annoying also is that when something is wrong in the add-on Javascript (not your work obviously it was my fumblings experiences) the normal ressources control panel cease to work and there is no obvious or even non-obvious way to restore it. The default (non javascript) resources control panel displayed in this cas gives the wise counsel to delete 'customizations', this is totally not a good idea to try to delete anything in this case, and also to go to the portal registry to switch the development mode in the registry, but this just does not work and it is dubious il would correct the cooked javascript anyway.
I ended up editing the javascript by accessing the Zodb by hand. I guess that running buildout to remove the add-on could have worked but I am too lazy for that.
on a more positive note, people wanting to debug Javascript and using Firefox should use Firefox 59 developer edition the debugger works quite nicely in comparison to the abject standard Firefox debugger. Recommended.
I guess that it would not be an incredibly complex thing to do to add a checkbox to switch the development mode with the non Javascript resource panel and that would redo the resource cooking as is doing the Javascript resource control panel.
What is more difficult to fix is that the resource cooking is done by the server as a text only manipulation, the Python interpreter can't check the Javascript validity. Anyway, working in full-blown developement mode is possible also, I was not using it mainly because I wanted to be sure things would work in production mode with all stuff cooked and things turned a bit sour but that's life if you write bad code you can be bitten.
err, no there was in fact a remaining problem with Tinymce.
I am not clear if it is linked to differences between Tinymce 3 and 4 or the specific Plone implementation.
Anyway, there is a workaround even if it's a bit ugly
strange that in searching for some thing or the other on DuckDuckGo i stumbled on these very words that I wrote 2 months ago, and in a good position. After these 2 months of using Plone, I can say that this is not generally true. They are only (probably) true in the specific context of wanting to replace minified code in plone-legacy by non minified code as the file name could be used to block minification, however if one wants only to do a quick test of a simple change, the plone-legacy bundle is cooked every time the 'save' button is clicked in the Resources Manager. I hope that this post could correct any misunderstanding for people using search engines and trusting what they see on forums (a very big mistake by itself...)
