Summary: Talk page for GlossaryPlus.
Maintainer: Kaptainkory
Users: (View? / Edit)

This space is for User-contributed commentary and notes. Please include your name and a date along with your comment.


Previous comments have been removed as of 2009-06-07 as they (likely) will not apply to the current script.

I am very new to this so any help would be greatly appreciated including advice on how best to post bug reports.

I followed the instructions as of June 23rd and receive this error message when trying to open my pmwiki: "Parse error: syntax error, unexpected T_VARIABLE in /homepages/2/d210009773/htdocs/wiki/local/config.php on line 166"

I am using clean URLs as well as the Skittlish skin if that makes a difference. Line 166 of my config.php file is the third of the five that are supposed to be pasted into the config.php: $PageTextStartFmt .= "'></script>";

I have checked and rechecked that I followed the steps exactly as described. It seems like this is supposed to be pointing to the javascript file that I uploaded to the /pub/wz_tooltip/ directory and it is not finding it but that is a pretty much completely a guess.

Thanks in advance for any help!

Typo in instructions has been corrected. Try this:

$PageTextStartFmt .= "$PubDirUrl/wz_tooltip/wz_tooltip.js";

Kaptainkory June 28, 2009, at 03:19 AM

Thanks so much! That did the trick.

Lost Walter Zorn libraries

I have used this recipe for some time (thank you) and decided to look at the revised offering - which appears to have been added with no apparent problems.

However, the libraries referred to in the opening instructions regarding installation of the recipe are gone from the given location: JavaScript, DHTML Tooltips Library by Walter Zorn, and the link now just leads to a parked domain.

Perhaps another source can be identified and added where these may be found, to assist anyone that may be interested in using the glossary.

Des June 19, 2011, at 12:59 PM

Added wz_tooltip.js.txtΔ locally.

Utopiah December 19, 2011, at 09:42 AM

Possible bug disrupting url and properties generated by PmWiki for page logo

PmWiki allows the user to define a logo - via $PageLogoUrl - which appears in the top left corner of the page, and which can be clicked to return to the Home Page.

PmWiki also creates the title property so that this logo shows a tooltip with the page name - and this also seems to be the same title which is applied to the displayed page.

I am running the newest version of GlossaryPlus, and this appears to have introduced a bug to the internal formatting of the properties of this logo, and which was not present in the first version of GlossaryPlus.

When the recipe is activated by a glossary term being present on a page, the recipe appears to be identifying something in the scripting around the logo and identifying it as glossary item, and rewriting the html associated with the clickable page logo, thereby corrupting it. The page title is changed to a long piece of html, the tooltip associated with the logo is changed to the same html, and a segment of this html appears in the top left corner of the page, behind the page logo.

This does not happen on pages where there are no glossary items present, and the recipe is not active.

This can be seen on this page:

While this page has no glossary items, and is unaffected:

Everything else seems to be running normally, as expected.

Happy to provide more info if needed.

Des January 05, 2012, at 09:31 AM

Des, I have been unable to replicate your issues so far. Depending on when you downloaded the script, I did introduce an oopsy which was corrected a few hours later, but still the same release date. Please download again and see if the issues are not corrected.

Regardless, I am 99% sure the problem is not in $PageLogoUrl. The script appears to be matching a glossary term in the page title itself, where obviously it shouldn't.

If the newest script doesn't fix it, I may follow up for more info. If I can't replicate it, I can't fix it.

Thanks for the feedback.

kaptainkory January 05, 2012, at 07:36 PM

Thanks for the quick note, and the update.

Although it did not fix the problem I see, it might have pointed at the cause!

I was on this page: when I installed the update, and as can be seen this has a glossary entry, but did not produce the spurious text string in the top left corner. Things looked good.

But when I returned to the example page given above: the string was still in the corner.

Then I noticed an almost invisible difference - the title of the page included a glossary entry!

It is hard to see in the large bold type, but the 'AA' in the title (in this case AA Battery Ballymenach) is the cause of the spurious text.

As far as I can see, PmWiki inserts the page title into the 'title' property of the site logo at top left.

If this title also happen to include a glossary term, then this is rewriting the entry, and upsetting that title property.

I created a duplicate of the Eskdalemuir page, with the AA added in the page title. It can be seen here:

As can be seen, the spurious text has now appeared top left, although the page content is the same as that of the original Eskdalemuir page.

I would happily just use the usual trick to deal with this (and I often do this if I find a section heading includes a glossary term), but as the page title is created internally by PmWiki, this is not an option.

Fingers crossed this will let you reproduce the symptom - and if so, that is it an easy fix :-)

Anything else I can try or test, just ask.

Des January 06, 2012, at 05:11 AM

Des, I believe you are correct on where the glossary script is erroneously matching a term. However, PmWiki does not insert a title property for the site logo as you least it doesn't for the latest version and default skin.

I've set up a fresh wiki to try to break, but have been unable to do so. Please, feel free to see if you can break it:

I'm using the following GlossaryPlus settings in config:

$PageLogoUrl = '';

$PubDirUrl = 'http://' . $_SERVER['HTTP_HOST'] . '/wiki/pub';

$PageTextStartFmt = "\n<script type='text/javascript' src='$PubDirUrl/wz_tooltip/wz_tooltip.js'></script>\n<div id='wikitext'>\n";


I'd be happy to try a different skin or different config, if it might help in troubleshooting. At this point, I can only conclude that the latest GlossaryPlus script functions correctly for the latest PmWiki and default skin. And that's about all I can do unless given another lead on what might be happening. Again, if I can't replicate it, I can't fix it.

If it comes to it, you might just go to the cookbook attachments and fall back to the older version of the script. The recent revisions have made no upgrades or changes at all in how the script functions.

kaptainkory January 07, 2012, at 09:10 PM

When you mentioned skins, I thought I should carry out a quick check, and let you know the findings ASAP.

The normal site skin is Monobook, where I have been seeing the symptom reported to you.

I have Triad installed as a switchable option, as its layout can make heavy editing sessions easier.

When I switched to Triad, and looked at the Ballymenach page referred to above - the spurious text did NOT appear. (Obviously this is similar to the test site you set up, which used the default PmWiki skin.)

You can find the skin switching option hidden on the menu on the left of the page - just select Monobook or Triad to set either skin.

If you try this and go to the Ballymenach page after setting Triad skin, there is no spurious text on the page.

Also, under Triad, the 'AA' abbreviation in the article title is NOT detected by GlossaryPlus, and is not given a tooltip, or made into a link leading to the Glossary entry. Other glossary items in the page text work normally.

I'm not sure what this means, but it does suggest something in the Monobook skin is contributing to the appearance of the text.

Maybe I should be apologizing, and this is down to something structured into Monobook, and GlossaryPlus is working as intended.

I do like to try and keep software up-to-date for obvious reasons, but since you say the revisions don't involve any sort of upgrade or functionality, then I'm not losing anything by going back.

(Can I ask if there were any changes to the locations of directories or files though? I seem to remember having to fiddle with these to get things working after installing the later script - but that just might have been me misreading the relevant details, and putting something in the wrong place to start with.)

Des January 08, 2012, at 11:54 AM

Des, I still can't explain why the old GlossaryPlus script worked and the new one didn't (the changes made should not have made any observable/functional differences), but I'm calling the issue closed for now. The culprit does appear to be the Monobook skin. Likely there should be a Keep() function in the skin around the title processing--specifically to the template variable $Titlespaced--that would prevent additional markup processing (such as we see from GlossaryPlus). Apparently, the preventative Keep() function is not there, but I am not interested in troubleshooting someone else's skin.

A quick solution would be to add the following to your config:

$SkinPartFmt['wikititle'] = "$WikiTitle";

You will have less title than before, but it'll give you a place to start if you want to work on the issue further.

And no, no changes to locations/directories for files were changed in the latest version. I do admit though that this can be a tricky part of getting the recipe to work.

Thanks for your feedback and help.

kaptainkory January 08, 2012, at 11:50 PM

Yes, time to step back as the source lies elsewhere - but thank you very much for the checking that led to the cause.

I incorporated the quick fix, and it does indeed remove the offending scrap - and alter the title a bit.

I actually use an earlier version of Monobook - a later one updated the appearance a little, but I did not like the revisions.

But, I still have both versions installed, and tried the newer one. It still throws the spurious text, but unlike the earlier version, the text includes the whole page title, not just the latter part seen during out discussions. I really tried it to see if the markup processing might have been updated as per your suggestion, but obviously it had not.

(As this whole section is not really relevant to the recipe, you may wish to purge (or move) it now - I don't really see much reason to keep it here.)

Mixed-Case Terms Bug

This is probably due to something on my installation. Terms that begin with two or more uppercase letters followed by a lowercase letter, like EEGs, aren't recognized. It doesn't matter if the CaseSensitive flag is true or false, or if I use {$:EEG} or copy the entire entire definition. When I look at the source the name and ID for EEGs is %1C%1C348L%1C%1C . The same is true for terms that aren't plural of another, like HCl.

The only modification I made was adding an entry to the style sheet so the terms would be green and not underlined. Removing that made no difference.

Any ideas?

Jerod Poore May 20, 2014

So sorry it took so long to reply... I was unable to replicate the bug you describe on my setup. I did update the recipe slightly just recently, but for the only purpose to eliminate depreciated PHP code. You'll need to run it with PmWiki 2.2.58+. Beyond that, it would take a bunch of baby-steps to solve it...starting with a fresh install and then adding things that your site uses until it breaks. Good luck. Sorry I couldn't be much help.

kaptainkory December 31, 2014, at 06:29 PM'

Targeted Highlight ?

Is there any way to get a :target or similar CSS markup for the glossary page itself ? IE: click on a term in the wiki and it takes you to glossary#anchor. CSS :target theoretically lets you highlight the current/selected anchor on page load, but I've had zero luck getting it to work in pmwiki :(. I realize that 'case insensitive mode' wont work correctly with this (since it already breaks the target?) - it'd still be of benefit.

Separately, could case insensitive mode be altered so that it correctly targets the #anchor as it existed on the glossary page (ie: don't use it's own parsed text, but rather the existing anchor) ? Or something ?

-unfy July 22, 2015

Talk page for the GlossaryPlus recipe (users?).