[pmwiki-users] Page variables in monospaced text

Allister Jenks zkarj at me.com
Thu Sep 27 18:01:46 CDT 2012


Thanks for the suggestions. Yes, I am familiar with the isolation technique you described. Hopefully others following along can learn something, though, because you described it very well. :-)

So I took another approach to the problem this morning. I went to the sandbox page and entered in

(:rel:423:)
Testing "{$:rel}"

I was rather surprised to get back

Testing "423"

Yes!!!

So I went back to my original page, took out some extra stuff I had been experimenting with and it works! I can only imagine there was somehow some caching going on, though I don't understand how with constant page edits.

Anyway, I have my working solution to the original problem. Woohoo!

The next person who has to follow this process at 3am when everything's falling apart will be very thankful. :-)

Communities rock.



On 27 Sep, 2012,at 06:32 PM, Peter Bowers <pbowers at pobox.com> wrote:

On Thu, Sep 27, 2012 at 12:22 AM, Allister Jenks <zkarj at me.com> wrote:
(:Country: Transylvania      :)
"{$:Country}"


"Transylvania "

In the above example I have added 5 spaces in a place where I saw a single space to emphasize what is causing the space before the closing quote.

It appears that your particular installation has different behavior.  That sounds like a problem with some sort of customization/recipe that you've installed.

First I would view the HTML source (CTRL-U when viewing the page via ?action=browse) and make sure it is actually a space and not some other HTML.  That will give you a hint of what to look for.

Then start disabling your customizations either one-by-one or in chunks (I usually use the /* ... */ comments for this because I can comment out half my config.php at a time to narrow things down quickly) and see when the behavior goes back to what you find on pmwiki.org.  When you've narrowed it down to a single recipe or customization then we can proceed from there...

-Peter

PS More detail (perhaps too much) on this debugging technique...  (If you are an experienced administrator or developer then this will be old hat, but it may be helpful for some who are just getting started.)  Let's say I have a config.php file with just 4 lines: 

===(snip)===
A;
B;
C;
D;
===(snip)===

I set up a page that clearly shows the problem I am having and make sure it is reliably reproduced.  Then I comment out half my config.php:

===(snip)===
/*
A;
B;
*/
C;
D;
===(snip)===

Now I re-load the page in my browser.  If the problem disappears then I know that it was either a problem with A or a problem with B.  If it doesn't disappear then I comment out the other half of my config.php:

===(snip)===
A;
B;
/*
C;
D;
*/
===(snip)===

Now I re-load the page in my browser.  If the problem continues then it is more complex -- perhaps a per-page or per-group customization or something with my PHP installation or etc.  But if the problem disappears then I know that the problem is with C or D.  I comment out C:

===(snip)===
A;
B;
/*
C;
*/
D;
===(snip)===

and try again.  Now I' know whether the problem is caused by C or by D.  I continue the process until there is a single customizaion or recipe that causes the problem to appear when it is active and causes the problem to disappear when it is commented out.

This same technique can be expanded to be used for config.php with many, many customizations.

Note that sometimes the problem occurs because of the interaction of one recipe with another (in other words either recipe on its own is fine, but when you have the two together they don't play nicely).  In that case this technique can actually confuse things rather than helping until you realize what's going on.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pmichaud.com/pipermail/pmwiki-users/attachments/20120927/0cc02dc6/attachment-0001.html>


More information about the pmwiki-users mailing list