Support » Plugins » Hacks » Trying to fix unsupported glossary plugin

  • I’ve tried a dozen other glossary plugins, and all of them seem to mess up somewhere.

    This plugin is called tooltipglossary

    It is designed to search for glossary words in the text, and replace them with links to the same word in the glossary.

    One problem is, when the keyword is found within another link, it still tries to replace it.

    So if I have a glossary term for “co-dominant” and “Dominant” then it replaces them twice. (Depending on which is processed first)

    Second, it will change a URL, if the url contains the glossary term.

    <a class="glossaryLink" href="" title="Glossary: Co-Dominant">co-<a class="glossaryLink" href="" title="Glossary: Dominant">dominant</a></a>

    I’ve already made a mod to where it prioritizes the term with the most recent modification date, first, (Ideally it should be the longest terms first) but I really need to tell it not to parse anything within ““, “<img>” or between tags. It would be wise to exclude between <script> tags as well.

    Here is partial code from the add-in

    foreach($glossary_index as $glossary_item){
        $glossary_title = $glossary_item->post_title;
        $glossary_search = '/\b'.$glossary_title.'s*?\b(?=([^"]*"[^"]*")*[^"]*$)/i';
        $glossary_replace = '<a'.$timestamp.'>$0</a'.$timestamp.'>';
        if (get_option('red_glossaryFirstOnly') == 1) {
            $content_temp = preg_replace($glossary_search, $glossary_replace, $content, 1);
        } else {
            $content_temp = preg_replace($glossary_search, $glossary_replace, $content);
        $content_temp = rtrim($content_temp);
        $link_search = '/<a'.$timestamp.'>('.$glossary_item->post_title.'[A-Za-z]*?)<\/a'.$timestamp.'>/i';
        if (get_option('red_glossaryTooltip') == 1) {
            $link_replace = '<a class="glossaryLink" href="' . get_permalink($glossary_item) . '" title="Glossary: '. $glossary_title . '" onmouseover="\'' . addslashes($glossary_item->post_content) . '\');" onmouseout="tooltip.hide();">$1</a>';
        }else {
            $link_replace = '<a class="glossaryLink" href="' . get_permalink($glossary_item) . '" title="Glossary: '. $glossary_title . '">$1</a>';
        $content_temp = preg_replace($link_search, $link_replace, $content_temp);
        $content = $content_temp;

    I am getting a bit lost in this one.

Viewing 3 replies - 1 through 3 (of 3 total)
  • Without thinking too deeply, the apparent solution to me would be to do it in three pass.

    First pass, break up the content into lines that aren’t contained within , <script> and <img> tags.

    Second pass, do a preg_match on strip_tags(text)

    Third pass, do your replacement on the original text using the matched values as the pattern.

    I know it’s not elegant but if it works, you can always figure out if it’s possible to do a single pass using regex 😀

    I’m not that good with regex. But it would sure be a whole lot faster.

    I just finished it, and did the exact same thing you came up with.

    I broke down the content into an array, tagging some elements as non-parseable. Then as I added links, I had to build a temp array splitting lines up even further.

    It’s not a high traffic site, otherwise I’d be seriously concerned about speed, but it at least parses correctly now.

    It’s certainly not elegant code, but it works.

    I’ve had people telling me that mastering regex is in a way mastering a programming language in itself 😉

    As for relative performance, I’m not so sure that breaking down the process into a few simpler passes would be that much more demanding that a complex regex query.

    If performance is really a concern, what I usually do for such situations is to save/cache the output on saving to the database rather than redoing all that processing every time somebody request for it. Getting more diskspace is cheaper/easier than getting more processing power which is in turn cheaper/easier than wasting time optimizing/refactoring code that isn’t core. 🙂

Viewing 3 replies - 1 through 3 (of 3 total)
  • The topic ‘Trying to fix unsupported glossary plugin’ is closed to new replies.