Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.Hello,
The glossary links are not added in the node page on words that have special characters, if these special characters are converted into html entities like they should, for example with a WYSIWYG editor like FCKeditor.
Example :
- in the vocabulary "Glossaire" I have a term "atmosphère"
- in a node body I enter somewhere "atmosph&eagrave;re" (plain text editor) or "atmosphère" in a WYSIWYG editor and the editor converts it into "atmosph&eagrave;re"
- the glossary link is not added on "atmosphère" when viewing the page, because in fact in the source code it is "atmosph&eagrave;re" and the glossary filter is looking for "atmosphère".
I tried to create the html entities converted term instead of the plain term with special characters, but it's not nice since in the glossary page, the output is the html entities code (example : the output in the glossary page is "atmosph&eagrave;re" and not "atmosphère".
Another solution would be to disable the html entities conversion of special characters in the WYSIWYG editor. It's possible with FCKeditor, but it's not very standards friendly.
I think the best solution would be if the glossary filter could look, for each term, for the real term (special characters) and for the html-entitified term. Do you agree with that ?
| Comment | File | Size | Author |
|---|---|---|---|
| #1 | glossary-352545-1.patch | 2.64 KB | GuillaumeDuveau |
Comments
Comment #1
GuillaumeDuveauHere's a patch that does the job with extra code inside _glossary_get_synonyms.
If no WYSIWYG editor is installed (from the list fckeditor, tinymce, htmlbox, jwysiwyg, yui_editor, to be continued), then _glossary_get_synonyms does its job as usual.
If there is one, we're assuming the textarea will convert special characters to htmlentities, and that we need to have some kind of virtual synonyms :
The query has to be splitted into two recursive queries :
1) Fetch the terms of the vid and look if they have special characters. If yes, add the htmlentities version as a synonym.
2) Check if the term has any (real) synonyms. If yes, add the synonym. Then if the synonym has special characters, add the htmlentities version as well
It's my first patch that adds a feature in Drupal, I hope it's not too ugly. Maybe the feature should be chosen as an option in the glossary settings, but I believe that the automatic triggering if any WYSIWYG editor is installed is better.
Comment #2
GuillaumeDuveauHello,
What about that patch ? Would you be willing to integrate it if I update the patch to the latest dev ?
For now, Glossary is useless with a lot of languages and WYSIWYG editors.
See you
Guix
Comment #3
seren10pity CreditAttribution: seren10pity commentedThank you very mutch for this patch !!!
I'm french, I just created a new website, and I had the problem with the htmlentities conversion that were not understood by Glossary...
I just added the 'wysiwyg' module in the ' if condition ' of your patch ; and it rocks !
Thanks again ;)
Comment #4
GuillaumeDuveauThanks ! I'll add wysiwyg to a new patch against -dev if I get a positive review by Moshe.
Comment #5
GuillaumeDuveauBump, Nancydru would you like me to roll a new patch ?
Comment #6
milos1234 CreditAttribution: milos1234 commentedguix - please, that would be really helpful thanks!
i am using the current stable version, with a few modifications to get multi-language working properly. but am having much troubles with special characters in the other languages in the synonyms.
thanks!!
Comment #7
GuillaumeDuveauI don't know which source to patch against, HEAD is still 5.x. DRUPAL-6--1 ?
Comment #8
jcbou CreditAttribution: jcbou commentedSubscribing
Comment #9
nonsieBumping priority on this since it makes glossary on multilingual sites unusable.
Comment #10
NancyDruAdding the other spellings as synonyms should make it work.
@guix: I only use HEAD when starting a new Drupal branch, so HEAD will not be updated until I start on D7, which is going to be a bear because taxonomy terms become fields rather than easily gathered stuff. The easiest way to figure which branch to operate against is the "View CVS messages" in the project page.
Comment #11
GuillaumeDuveauHello,
For now we are still not using Glossary and unfortunately I'm too busy to roll a new patch...
Comment #12
asiby CreditAttribution: asiby commentedHello
What's the hold up with this subject? Has it been solved? Do you need help doing anything so that we get this patch integrated in the stable release?
I am asking all these questions because I have a internal policy that is "never patch a live production version of Drupal except for security updates". The reason for this is that the customer may lose some features if the patch is not part of the following release of the module and if someone accidentally update the module without applying the patch (if the patch is still compatible ... which is unlikely). That would be really annoying.
So when a patch such as this one is found to be really useful, we try to make sure that it will be part of the future releases.
So again, will this patch be part of future releases? How can I help in that regard?
Keep up the good work.
Cheers.
A. Siby
Comment #13
N4R4YAN CreditAttribution: N4R4YAN commentedThis is superneeded! Subscribing! :/
Simply everything that has an accent cannot be tagged because of the string append by editors :/
Comment #14
asiby CreditAttribution: asiby as a volunteer and commentedClosing due to lack of activity. Besides, the module no longer has any stable release for Drupal 6. Time for this version to retire.