On Sat, Aug 29, 2009 at 12:38, Petko Yotov<5...@5ko.fr> wrote:
> On Friday 28 August 2009 09:48:53 Dominique Faure wrote:
>> So, I first see a bug in DisableMarkup(), where the $MarkupRules isn't
>> declared as global
> ...
>> This mean that the two functions Markup(...) and DisableMarkup(...) should
>> use:
>>
>> unset($GLOBALS['MarkupRules']);
>>
>> to have it taken in account. BTW, the $MarkupRules wouldn't need to be
>> declared global there anymore.
>
> Hi. Thanks for your review -- this was modified in the latest SVN pre-release
> and on the live pmwiki.org site. It would be great if you have the chance to
> test it and report any problems.
>
> Notably, the previous way of not-really-unsetting global variables may have
> had some side-effects on current core and local settings. I wonder if there is
> a risk for some of these settings to stop working after the fix.
>
> Petko
>
>
Before the modification, even if the $MarkupRules array wasn't
rebuilt, a call to DisableMarkup(...) from config.php wasn't really
taken in account until the first call to MarkupToHTML, which usually
occurs in the skin and pagelist rendering.
OTOH, there's a bunch of cookbook recipe which are calling
MarkupToHTML directly, but I suspect few of them are also calling
DisableMarkup(...).
BTW, I was fearing of what could happen while having Markup(...) or
DisableMarkup(...) called via some recipe code triggered from a markup
definition: While processed by some call to MarkupToHTML, the
$MarkupRules array would have been immediately unset, which could have
interfered on the rendering itself, but hopefully, the function is
using it's own copy of the rules array.
Nevertheless, this kind of recipe won't give automatically the
expected results, since the altered markup rules are built only one
time before looping on the page text.
If I have for example (untested):
Markup('my_markup', 'directives',
'/\\(:my_markup:\\)/ei', "MyMarkupFunc()");
function MyMarkupFunc(...) {
...
Markup('my_new_markup', 'inline',
'/\\(:my_new_markup:\\)/i', 'hello world');
...
return '';
}
the (:my_new_markup:) token won't be taken in account until an extra
call to MarkupToHTML(...), which next occurence is extremely context
dependent.
I would suggest to also modify the following MarkupToHTML line from:
if ($RedoMarkupLine) { $lines=array_merge((array)$x,$lines); continue 2; }
to:
if ($RedoMarkupLine) {
$lines=array_merge((array)$x,$lines);
$markrules = BuildMarkupRules();
continue 2;
}
Therefore using PRR(...) would allow handling of new markup text, even
if some of their definition is made dynamically.
[PM comments welcome at this point]
--
Dominique
_______________________________________________
pmwiki-devel mailing list
pmwiki-devel@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-devel
