Last modified: 2011-03-13 17:46:05 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 3438 - not all hooks (ParserBeforeStrip) available in template
not all hooks (ParserBeforeStrip) available in template
Status: RESOLVED WONTFIX
Product: MediaWiki
Classification: Unclassified
General/Unknown (Other open bugs)
1.5.x
PC Windows XP
: Lowest major with 1 vote (vote)
: ---
Assigned To: Eric Burnett
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-09-12 06:41 UTC by Andres Obrero
Modified: 2011-03-13 17:46 UTC (History)
4 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments
A patch to call the strip hooks when stripping included templates (1.75 KB, patch)
2007-11-12 00:59 UTC, Eric Burnett
Details

Description Andres Obrero 2005-09-12 06:41:52 UTC
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 );
}
?>
Comment 1 Rob Church 2006-12-26 03:49:07 UTC
Bug report needs to be clarified somewhat.
Comment 2 Eric Burnett 2007-11-12 00:58:23 UTC
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?
Comment 3 Eric Burnett 2007-11-12 00:59:23 UTC
Created attachment 4328 [details]
A patch to call the strip hooks when stripping included templates
Comment 4 Tim Starling 2007-11-13 04:38:06 UTC
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.
Comment 5 Eloy Lafuente 2009-01-29 15:45:55 UTC
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. ;-)
Comment 6 Kinsey Moore 2009-01-29 15:49:41 UTC
As a response to the P.S., please see bug 17131.  I believe it is the beginning of what is mentioned.
Comment 7 Eloy Lafuente 2009-01-29 16:02:44 UTC
Thanks Kinsey. bug 17131 looks promising! B-)
Comment 8 Mark A. Hershberger 2011-03-13 17:46:05 UTC
Changing all WONTFIX high priority bugs to lowest priority (no mail should be generated since I turned it off for this.)

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links