Hello,
I've installed collective.glossary 1.0b1 on a fresh Plone 5.08 installation.
But the tooltips are not working which is the key feature to me (feature is documented here: https://pypi.python.org/pypi/collective.glossary/) (of course tooltips are anabled in configuration...)
Any ideas what to do?
My configuration:
Plone 5.0.8 (5018)
CMF 2.2.10
Zope 2.13.26
Python 2.7.12 (default, Nov 20 2017, 18:23:56) [GCC 5.4.0 20160609]
PIL 3.4.2 (Pillow)
Is that maybe dependent on the browser you use?
I would look through https://github.com/collective/collective.glossary/issues and report it if there isn't an existing (or closed) issue for it.
Well, I've tried this in several browsers.
Alternatively I tried to install
eea.glossary ( https://github.com/eea/eea.glossary )
But when I run buildout it says:
Getting distribution for 'eea.glossary'.
Error: Couldn't find a distribution for 'eea.glossary'.
What does this mean?
AFAIK buildout never get anything directly from github. All 'distributed' software comes from pypi.python.org and eaa.glossary is not on pypi at least under this name, so the European Environment Agency never bothered to publish their fork on pypi it seems. They even did not bother to update to README published on github to explain why they forked the project or anything, just copied it verbatim. Well, no comment but I'd stick with the original if I were you.
Then this would be my next step
I tested collective.glossary and the tooltip seems not to be working with Plone 5; as @tkimnguyen mentioned you have to open an issue on GitHub.
be aware that we're not using this package in Plone 5 and development is currently in stand by.
I've tried to understand what was the problem; before I spend more time is there a ready made Plone 5 solution for this use case ?
You could build a simple glossary with rapido in Plone 5: http://rapidoplone.readthedocs.io/en/latest/use-cases/glossary.html
the issue is legacy JavaScript registration in Plone 5; I have stated before that I don't want to have 2 registrations on our add-ons because it pollutes the code.
the chief problem is that fixing the resource registry in Plone 5 has taken more time that I expected; maybe we have to revisit this at some point, when we have a new project that justifies it.
Ah then you could add the required JS to your theme instead
Is there an error in your browse console?
'add the required JS to your theme' ? is this the official way to handle javascript included with add-ons ? extract it by hand, add it to the theme and hope for the best ??? And poor me who was searching why it was not working, thinking naively it was supposed to work automagically 
I guess that your post makes all sense to an experienced add-on developer.
However, there are a few points unclear to me.
What I tried:
include the addon naively. Did not work. Looked at the javascript loaded in the browser, both anonymous and logged in, no trace of the addon javascript
rebuild TTW of the plone and plone-logged-in bundles. No trace of the addon javascript. Looked at the generated code in the resource_overrides directory, not a whiff of glossary.
since you are talking of legacy, did not try to rebuild legacy bundle since the Plone UI don't allow it to be rebuilt
installed plone-compile-resources, ran it: then the collective.glossary javascript was finally somewhere, in the plone-logged-in.js files. However while there are tentatives indications in the (very few) comments in Plone code that the newer resources should be used, the files (on the file system, in the CMFPlone/static directory) are not loaded by the browser, the resources in the ZODB (portal_registry/resource_overrides) are still used. I guess this is making sense because they are overrides. Maybe. In desperation tried to stuff the generated files into the resource_overrides, got nowhere and cancelled it (but I did not try very hard, am not sure that I did not do a mistake)
Finally: I thought that I should first have tried development mode, where everything is loaded from the file system. Then I got the collective.glossary Javascript loaded in the browser (even if all this was hideously slow of course). And it did not work anyway, because the site address in the first line of main javascript is undefined:
// Plone 5 does not include global variables anymore
var portal_url = (portal_url === undefined) ? $('body').attr('data-portal-url') : portal_url;
$('body') has no data-portal-url attribute when the add-on javascript is activated.
so although the glossary can be loaded fine by itself, the add-on javascript can't do it.
Could be a resource order loading problem but I did not investigate further.
So my question is what are you talking about with 'resource' ? the resource loading problem or the $body problem ? The first could be fixed with better Plone code I hope, but is the $body problem a more fundamental limitation of collective.glossary Javascript with Plone 5 (this is Plone 5.1 latest BTW)
that's exactly the problem: the whole thing is complicated like hell and prone to errors.
it makes no sense to include the JS in the logged in bundle as we didn't have that in our registration:
I'm almost sure that I tested this in the past under Plone 5 and it was working.
feel free to create a pull request if you find the issue; as I mentioned above, we are busy with the things that pay the bills right now.
I hope you understand that I was proposing a way for you to try to get it to work. Obviously it's not ideal and it's not the official way to do anything.
I hope you understand I was half joking, that's what the smiley is for.
Anyway, I am not really desperate to make this add-on work, as @tmassman explained there are other ways to do it. However what I am trying to achieve is to help to make Plone a bit better and in the process learning enough to be able to fix problems that could appear on sites that I would manage. Having a site at the last Plone version and existing add-ons compatible with it matters. If I am responsible for a system I should be able to fix or find a way around most trivial problems and that's I am after. Now I understand better how resources are managed. Not all is clear but some things are.
I have finally collective.glossary working in all its glory in Plone 5.1. Sort of, I think my patch would frighten to death any Javascript developer, but one can't have everyone liking his code.
Here it is!
--- main.js.ori 2018-01-27 15:32:19.204510000 +0000
+++ main.min.js 2018-01-30 14:04:13.737996391 +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 }
$(function(){
$('#content-core').glossarizer({
why this syntax is better now with Plone 5.1 is a JQuery mystery. It's far beyond my ken at the moment. Advice welcome if a master is passing here. I am ready to learn.
However, what of the resources ? I was completely wrong. The Javascript resources of collective.glossary were well and truly loaded all the time. I was missing them because they are hidden in the plone-legacy bundle. Yes your beautiful code is branded 'legacy' by the Plone core developers. I'm not responsible, that's just the fact. What had made me miss it is that I was not expecting it at all. There is also that they are minified by default so they are not exactly obvious in this awful Firefox debugger (you may have noticed that I have renamed your main.js to main.min.js to fool Plone into thinking it was already minified Javascript because debugging in a minified file with Firebug or whatever is not doable for me at least.)
And yes there is a resource bug, but not where you think; when unregistering an add-on the resources are not removed from the plone-legacy bundle. I'm planning to address that.
But with Plone 5.1 latest, the only sane way I have found to change the cooked code of an add-on inside plone-legacy is:
@hvelarde How do I know what YOU are using?
How do I know that it would be relevant to me what YOU are using?
I just wanted to install an official plone add-on that is said to be compatible with Plone 5 and has the features as documented.
I agree with @gp54321 !
I am not a developer, I am a normal user, and I think this discussion reflects what is wrong with Plone.
All these great technical discussions, these wonderful pieces of sourcecode in every discussion and documentation.
I just wanted to use a simple glossary as documented in my Plone...
Don't forget the user!
I agree with @gp54321 !
(...)
Don’t forget the user!
I hope that you are not suggesting that I share any bad feeling toward Plone developers especially @hvelarde who contributed so much in the collective (that is not part of Plone per se). His remarks have greatly helped me (to fix things you have first to understand how they are supposed to work) and I am duly grateful. If I can find the time to actually understand the fix I have suggested and to be sure it is correct I'll send it to the collective.glossary project and it could work better next time.
in fact this discussion reflects the Tragedy of the commons.
as you are new here I want to explain clearly a couple of things: when you use open source software you have to be aware of the following:
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
package under the collective namespace are not "official" Plone add ons, but the work of community members to solve their use cases, shared for the benefit of everybody.
I'm one of the maintainers of the package and we do everything in our hands to deliver good products; we do this for a living and we don't work for free (most of the time).
I know that for a newbie is going to be difficult to understand the reasons for some decisions and I'm really tired of repeating why I'm not embracing Plone 5.
having said that I'm not moving a finger for someone who is not doing his/her part; the right way of contributing is not ranting in this forum, but:
if you're not doing neither thing then I don't care about YOUR use case; package is already working for us to solve OUR customer's use case, and our customer is not paying for further development.