[pmwiki-users] Upgrade woes: PublishPDF and PmWiki 2.1beta25

John Rankin john.rankin at affinity.co.nz
Tue Feb 14 15:59:21 CST 2006


On Tuesday, 14 February 2006 4:56 PM, Patrick R. Michaud <pmichaud at pobox.com> wrote:
<snip>
>> I have changed the above to read
>> 
>> $FmtV['$Haystack'] = isset($_GET['haystack']) ? $_GET['haystack'] : '';
>> 
>> and it's now fine.
>
>This is (to me) unexpected behavior, so let me look into it and
>see what might be happening.  If $FmtV['$Haystack'] isn't set,
>then PmWiki won't substitute a null value for it, but if
>$FmtV['$Haystack'] is set, even with the GET version above,
>then a substitution should be performed.  So I think this can be 
>classified as a PmWiki bug.
>
>I think it may be that I've used "defined" where I really should
>be using "exists".
>
>In the meantime, one way to positively resolve it and avoid the
>conditional is to append a null string:
>
>    $FmtV['$Haystack'] = @$_GET['haystack'] . '';

Duh! Why didn't I think of that??
>
>> >Ideally, recipes will start to use $FmtPV and "{$PageVar}" in 
>> >preference to $FmtP -- it's both faster and a bit more flexible 
>> >in terms of what can be substituted.   However, I don't expect
>> >to be eliminating or changing the priority of $FmtP anytime soon,
>> >so it should be safe to continue using it.
>> 
>> Please give *plenty* of warning. In fact, I use $PageVars, as it's
>> text extracted from a form template and formatted for the page
>> being published. Using {$PageVar} causes the value to appear
>> wrapped in braces.
>
>To avoid possible confusion I didn't mean "{$PageVar}" literally--
>sorry if it came across that way.  I meant that {$...} is the new 
>page variable syntax,used both in markup and in strings passed to 
>FmtPageName(), and it causes values to be taken from the $FmtPV
>array.

So I *should* be adding {...} around default variables? Um, it seems
to work without them, and to maintain compatibility with 2.0, I'd
rather not add them at this stage.
>
>As far as $FmtP being substantially changed, looking into the future
>I think I can safely claim that it won't be changing in 2.1, or anytime
>in 2006.

And for backwards compatibility, I can continue to use FmtPageName
rather than the new PageVar function?

I'm very happy that PmWiki now uses { ... } consistently --
the presence or absence of { ... } has often caught me out.
>
>> Now I have to test the 2.1 wikistyles.php with our pdf channel 
>> modifications...
>
>I still haven't incorporated the wikistyles modifications you sent
>(off-list) into the distribution -- as I recall we had one or two 
>minor items left to be resolved.  But I can go ahead and do that if 
>you're ready to go with substantially what we had discussed.  Now
>would also be a good time as I need to revise it slightly for better
>width= and height= handling of other HTML elements.

Let me send you (separately) the wikistyles.php from beta 25,
modified along the lines we reached in the earlier discussion.
I need to carry out a few more tests on it, but I think it's 
working correctly.



-- 
JR
--
John Rankin






More information about the pmwiki-users mailing list