Page MenuHomePhabricator

not all hooks (ParserBeforeStrip) available in template
Closed, DeclinedPublic

Description

Author: andres

Description:
to make the problem a bit clearer i wrote a small php script (see code below)
add it into LocalSettings.php as usual and write one page [ [ template:sample ]
] with the content
'abc'
and one page [ [ sample ] ] with the content
abc and { { sample } }
which should include template:sample.

the result is:

#ParserBeforeStrip[0]#*ParserAfterStrip[1]*%ParserBeforeTidy[2]%@ParserAfterTidy[3]@abc@@%%**##
%ParserBeforeTidy[2]%@ParserAfterTidy[3]@abc@@%%

Both lines should be identical.
The interpretation of the result is, that a template does not pass
'ParserBeforeStrip' and 'ParserAfterStrip' or ignore the modifications somehow
(&$ problem?).

Here the sample extension: (don't forget LocalSettings.php)

<?php
define ("_PATT_", "abc");
$wgExtensionFunctions[] = 'myTestHook';
$my=0;
function myTestHook(){

global $wgHooks;
global $wgParser;
$wgHooks['ParserBeforeStrip'][]= 'pbs';
$wgHooks['ParserAfterStrip'][] = 'pas';
$wgHooks['ParserBeforeTidy'][] = 'pbt';
$wgHooks['ParserAfterTidy'][]  = 'pat';

}
function pbs(&$article, &$text, &$strip_state){ global $my;

$text = preg_replace("/("._PATT_.")/i",

"#ParserBeforeStrip[".($my++)."]#$1##" , $text );
}
function pas(&$article, &$text, &$strip_state){ global $my;

$text = preg_replace("/("._PATT_.")/i", "*ParserAfterStrip[".($my++)."]*$1**"

, $text );
}
function pbt(&$article, &$text){ global $my;

$text = preg_replace("/("._PATT_.")/i", "%ParserBeforeTidy[".($my++)."]%$1%%"

, $text );
}
function pat(&$article, &$text){ global $my;

$text = preg_replace("/("._PATT_.")/i", "@ParserAfterTidy[".($my++)."]@$1@@"

, $text );
}
?>


Version: 1.5.x
Severity: major
OS: Windows XP
Platform: PC

Details

Reference
bz3438

Event Timeline

bzimport raised the priority of this task from to Lowest.Nov 21 2014, 8:48 PM
bzimport set Reference to bz3438.

robchur wrote:

Bug report needs to be clarified somewhat.

ericburnett wrote:

The bug reporter is noting that when template content is pulled into the main body of the text during parsing to HTML or preprocessing, the ParserBeforeStrip and ParserAfterStrip hooks aren't being called. We can note that the text IS being stripped, as evidenced by <nowiki> tags functioning in templates.

NOTE: When viewing a template, the hooks are run. It is only when including said template that they are not.

Attached, 3438.patch, is a patch to the Parser.php file to properly call the hooks before and after strip. This has been tested and does not cause any of the ParserTests in maintainence to fail.

If a developer could apply this patch, or point out a reason that these hooks shouldn't apply for included templates?

ericburnett wrote:

A patch to call the strip hooks when stripping included templates

Attached:

ParserBeforeStrip is called once only per parse() call. This is the stable behaviour expected by the many extensions that use this hook. Changing its behaviour may break those extensions in ways which would be very difficult to work around in a version-independent manner. Find some other way to do whatever it is you're doing.

stronk7 wrote:

Just in case this helps to somebody.

We have some normal wiki pages, called:

Moodle 1.9.4 release notes => http://docs.moodle.org/en/Moodle_1.9.4_release_notes
Moodle_1.8.8 release notes => http://docs.moodle.org/en/Moodle_1.8.8_release_notes

And then, one "container" (Latest release notes => http://docs.moodle.org/en/Latest_release_notes) page including them by using:

{{:Moodle 1.8.8 release notes}}
{{:Moodle 1.9.4 release notes}}

Our ParserBeforeStrip and ParserAfterStrip hooks weren't processing those "included" contents when they work perfectly in the individual pages. We have changed those hooks to InternalParseBeforeLinks and now it seems that "included" content is being processed properly. Not sure why, but it works. Just in case this helps to somebody.

Ciao, stronk7 :-)

This is our version page: http://docs.moodle.org/en/Special:Version

P.S: I really think this IS a bug and "included" content should be processed too. Else there is one important inconsistency between how pages are rendered individually and when included in others. ;-)

nyphbl8d wrote:

As a response to the P.S., please see bug 17131. I believe it is the beginning of what is mentioned.

stronk7 wrote:

Thanks Kinsey. bug 17131 looks promising! B-)

Changing all WONTFIX high priority bugs to lowest priority (no mail should be generated since I turned it off for this.)