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

[Patrick R. Michaud]

On Tue, Feb 14, 2006 at 03:51:58PM +1300, John Rankin wrote:
> >> 2. FPLByGroup function
> >> 
> >> It was a bit of a surprise to see the FPLByGroup function removed. 
> >
> >Also, see my note at the bottom of this message regarding using
> >transition.php to "restore" the FPLByGroup function to the
> >core.
> 
> Ah! I'll use that.

Note that FPLByGroup isn't in transition.php in the current beta
release, but I'll add it.

> >> 4. $FmtV substitution
> >> 
> >> I note that by design, if the value of $FmtV['$SomeVar'] is not 
> >> set, FmtPageName returns '$SomeVar'. This is a real pain, as I 
> >> have to track down every use of $FmtV and check whether the 
> >> variable assigned to it is set and if not set the value to ''. 
> >
> >I think the larger question here is... why are there dollar-signs
> >in the format strings being passed to FmtPageName that don't
> >correspond to substitution variables?
> 
> Well, I have a line that said
> 
> $FmtV['$Haystack'] = @$_GET['haystack'];
> 
> The same code is shared by all publish search functions, some
> of which do not set a GET haystack variable. In those cases,
> I see $Haystack in the 2.1 output; I used to see ''. 

OOOOPS!  I totally misread your question -- I didn't catch that
you were referring to $FmtV[] substitutions.  

> 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'] . '';

> >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.

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.

> 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.

Pm