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

[John Rankin]

Thank you; comments below.

On Tuesday, 14 February 2006 11:49 AM, Patrick R. Michaud <pmichaud at pobox.com> wrote:
>On Tue, Feb 14, 2006 at 10:04:21AM +1300, John Rankin wrote:
>> 1. (:searchresults:) versus (:pagelist:)
>> ...
>> I have been able to work around this by changing the Markup rule 
>> for this action so that (:pagelist:) markup generates 
>> 
>> '<:block>'.Keep(FmtPageList(...)) 
>> 
>> I haven't been able to work out why this is needed for pagelist 
>> and not searchresults and suspect it may be a bug.
>
>It may indeed be a bug.  I'm thinking that Keep() will become a
>bit smarter and automatically recognize when it contains block
>markup and use that information to prevent adding of <p>...</p>
>tags around the results (this is essentially what <:block>
>does).

In the mean time, I'll test the Keep modification with 2.0.13.
It shouldn't cause a problem...
>
>> 2. FPLByGroup function
>> 
>> It was a bit of a surprise to see the FPLByGroup function removed. 
>> ...
>
><snip>
>
>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.
>
>> 3. Search and the current page
>> 
>> On Main.HomePage, when I search for 'sandbox', I get a list of 
>> one page -- Main.WikiSandbox. On Main.WikiSandbox, when I search 
>> for 'sandbox', I also get a list of one page -- Main.HomePage. 
>> In both cases, it tells me it has searched one page. Is this a 
>> bug, a feature, or a mis-configuration?
>
>If you're using "list=normal" in a pagelist, then it's because
>list=normal has recently been modified to exclude the current page
>from the output listing.  Based on what you've just written, this
>may be the wrong thing to do (although several have remarked that
>it seemed like the right thing to do at the time).

If it's a "feature" I'll leave it, log an issue and see if
anybody complains. We are using "list=normal".
>
>> 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 ''. 
>>
><snip>
>
>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 ''. I have 
changed the above to read

$FmtV['$Haystack'] = isset($_GET['haystack']) ? $_GET['haystack'] : '';

and it's now fine.
>
>> 5. $FmtP versus $FmtPV
>> 
>> I note that variables once set in $FmtP are now set in $FmtPV. 
>> It appears that if the same substitution variable is set in 
>> both places, $FmtP takes precedence. 
>
><snip>
>
>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.
>
>----
>
>As a prime example of this, I don't have any issue with adding
>FPLByGroup() (and the other now-missing FPL functions) into
>transition.php.  Then a recipe that expects FPLByGroup to be
>available could do:
>
>    $Transition['fplbygroup'] = 1;
>
>and the FPLByGroup function would be automatically loaded from
>transition.php even though it's no longer used by the core.

Yes, please! :-)

Now I have to test the 2.1 wikistyles.php with our pdf channel 
modifications...
>
>Hope this helps,

Definitely, as always.

>


-- 
JR
--
John Rankin