[pmwiki-users] Upgrade woes: PublishPDF and PmWiki 2.1beta25
John Rankin
john.rankin at affinity.co.nz
Mon Feb 13 20:51:58 CST 2006
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
More information about the pmwiki-users
mailing list