Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.As I've gone through the issues for this module it seems that others might agree that the settings are a bit annoying in that you must go separate "input formats." This can lead to nodes created with "Full HTML" formatting differently than those with "Filtered HTML" for example. Does anyone actually intend to do that?
I'm guessing that this is "baggage carried forward" in the sense that it was done this way back when Drupal was not as easy to configure.
Would you rather see a single configuration page ("Administration >> Site configuration >> Glossary")? If so, is there still a need or desire to separate the settings by filter type (this could be collapsible fieldsets)?
Comments
Comment #1
nancydruI have just committed the code to allow users the individual ability to turn off the Glossary indicators (http://drupal.org/node/143441), but it needs a setting, so this issue is getting more important.
Comment #2
nancydruLooking at the changes that have been requested, as well as some that already have been done, I'm going to proceed with this unless there are major objections.
Comment #3
nancydruThis appears to also be the best way to fix the caching problem.
Comment #4
luti commentedI personally would find the most comfortable and usable solution to control all settings through a central location (single administration page), but would sometimes need to exclude a filter per node, not per content type (such setting per each glossary term would be most flexible, but I understand it would be also very complicated to set it in case there are many terms defined...).
The reason for such a need is the situation where generally I want glossary to be active (as it is now), but in some cases it introduces only a confusion (when the same term is used for something totally different in certain contents, but it is the same content type), not to mention that it alltogether also looks ridiculous. The problem is those cases are of the same content type, so it should be on a per content (= node) basis.
For example, the term IP in electrical systems determines the protection degree (how dust- and watertight the product is), but if I publish some content about Internet on such site (including IP as a protocol or address), it makes a lot of confusion by readers (not to mention that it looks like I don't know what I am talking about...).
Maybe a more general solution would be to introduce a setting (a general setting for a majority of content, and possible different specific settings per each node) to allow applying this filter only if explicitely requested by author (through some additional tag in the content). Why? In some cases, I would like the explanations to appear in more occasions (all appearances of the term in a page), but if there are too many of them (a table or so), it doesn't look good either. In such case, maybe I would prefer its explanation only at the firs occurence, or only in first lines of each table or so...
Comment #5
nancydru@LUTi: You can do what you want by defining a new input format that points to a different glossary or doesn't even trigger the filter. For example, you could set "Filtered HTML" to point to the "electrical" glossary and then make another Input Format called, "Alternate" (or whatever you want), and have it either not glossify or have it point to an "Internet" glossary. Glad you asked this, it's definitely something I need to cover in my new documentation.
BTW, there is also a feature request to implement an "escape" mechanism that could be use to bypass glossifying part or all of an individual node.
As I envision it, the new settings page would actually have either tabs or collapsible fieldsets for each Input Format so that there would remain this capability. I would just be much more like what most modules use for settings.
After Moshe's comments on my second patch for the cache clearing problem, I see that I have little choice but to go this way.
Comment #6
luti commentednancyw, thank you for the tip. Sometimes, there are really simple solutions for some "big issues"...
The excape mechanism would however be great, in particular for partial bypass.
Comment #7
nancydruI will be working on the escape mechanism shortly.
Here's a screenshot of the new settings page. Note the tabs for the input formats. As soon as I get the documentation updated, I will commit this.
Comment #8
nancydrucommitted
Comment #9
(not verified) commentedAutomatically closed -- issue fixed for two weeks with no activity.