• View
• Edit
• History
• Attach
• Print
• Backlinks

GlossaryPlus-Talk

Comments

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: www.secretscotland.org.uk/index.php/Secrets/AABatteryBallymenach

While this page has no glossary items, and is unaffected: www.secretscotland.org.uk/index.php/Secrets/InchinnanOldParishChurch

Everything else seems to be running normally, as expected.

Happy to provide more info if needed.

Des January 05, 2012, at 09:31 AM

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: www.secretscotland.org.uk/index.php/Secrets/EskdalemuirSeismologicalRecordingStation 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: www.secretscotland.org.uk/index.php/Secrets/AABatteryBallymenach 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: www.secretscotland.org.uk/index.php/Secrets/AAEskdalemuirStation

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

$PageLogoUrl = 'http://herpsofarkansas.com/wikitest/pub/images/wikilogo.gif';

$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";

include_once("$FarmD/cookbook/glossaryplus.php");

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 secretscotland.org.uk/index.php/Manual/TextFormatting 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

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

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

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