Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.Terms are matched within HTML tags, which leads to broken displays and weird behavior. Perhaps Glossary could strip or ignore HTML tags somehow before filtering for terms.
Comments
Comment #1
njivy commentedI suppose an example would help:
Filtered output with spurious 'FreeBSD' match:
For more information about Apache, visit the on-line documentation at http://httpd.apache.org/docs or view the apachectl man paigei.
Glossary settings:
case-insensitive, left substring, superscript 'i'
Glossary terms:
FreeBSD, Apache, and other terms listed at
http://toughnail.com/glossary
Comment #2
(not verified) commentedI suspect that you use some other filter which messes glossary's output up.
Can you supply a list of enabled filters?
Gerhard
Comment #3
moshe weitzman commentedthis is a real problem ... i had an editor define the term 'font' in my site and that broke rendering of various posts.
Comment #4
killes@www.drop.org commentedFixed in cvs and 4.4. The fix assumes that there are no unpaired > and < in the code.
Comment #5
(not verified) commentedComment #6
chanel commentedhttp://cvs.drupal.org/viewcvs/contributions/modules/glossary/glossary.mo...
The fix linked above appears to catch (and bypass) matches that fall within an open anchor with href'd URL, but not ones that fall between the open and close anchor tags.
So, for example, if "RSS" is a glossary term, and the text being filtered against is
<a href="http://info.org/rss/moreinfo">more on RSS</a>then it would correctly bypass the RSS hit within the href, but incorrectly tag the RSS that falls between the open anchor and close anchor thus breaking the intended link.
If I change $opena and $closea back to their previous values then it properly skips both RSS instances and tags the next instance it finds (that's not in a link).
Comment #7
killes@www.drop.org commentedfixed.
Comment #8
(not verified) commented