Manual:Hooks/ParserBeforeStrip

Details
$text will hold the text for the page. To change the page text, modify this value. E.g. to add the phrase "The mighty oracle gives forth this proclamation: " to the front of the page text, you would use the following code:

$text = "The mighty oracle gives forth this proclamation: ". $text;

Note that this hook is called on the edit page (and possibly elsewhere) with the contents of the disclaimer under the edit box. If you use this function to add content to the page, which shouldn't be added in these circumstances, you should check what action was used to view the page, and only add the extra content if it is not being edited. I will add more info about this once I have figured it out. --HappyDog 04:24, 17 June 2006 (UTC)


 * One way to check this out is to check the global  variable, since it is defined to be the current action.  Make sure you setup will ignore pages where   and you should be good in that respect.  I've also ignored the history pages with   and the Special and Help pages with   and the like.  I've still got some more tweaking to do, but otherwise it works out pretty nicely. -- Chad.burrus 00:34, 20 December 2006 (UTC)


 * You should not be accessing the private class variables (begininning with little 'm') directly - there should be wrapper functions to get these for you (I'm guessing $parser->getTitle and $title->getPrefixedText...). Also, you should check the namespace using the numeric namespace ID, rather than the hard-coded name, otherwise your page will only work on English wikis. --HappyDog 01:24, 8 January 2007 (UTC)


 * To get the numeric ID of namespaces here, use $parser->getTitle->getNamespace. --Mlogic 23:11, 17 April 2008 (UTC)


 * Multiple runs of the parser hook can happen at any time, not just during editing. For example, the galery feature will run its own parsing within one page, and many extensions might do the same if they hook to certain &lt;tags> (in which case they get raw wiki text that they need to parse on their own). I do not know yet of any way to distinguish those parses other than by checking their content. The parser objects look just the same, I think, though maybe the parser options could sometimes give some hint. But filing a proper bug might be more useful to really solve the issue. Idea: the parser or its parser options contain a property that states their purpose from a set of predefined constants, and parsing the main article text is just one value which is not the default. Two other relevant cases might be: parsing a message (e.g. the disclaimer) and parsing inline pieces of text (e.g. the galery, and many extensions). --Markus Krötzsch 17:38, 23 March 2007 (UTC)


 * The following code seems to work:


 * --HappyDog 06:10, 8 November 2007 (UTC)
 * Doesn't work under all circumstances. It doesn't work after saving a page before the first page purge because you get the text from the previous version which is different from the new edited text. So the code is useless. Any better ideas? --Danwe 23:45, 23 October 2009 (UTC)
 * checking for  works so far. Looks like this this is only set when the main article text is in the parser. --Danwe 18:38, 27 February 2010 (UTC)
 * it acts similarly to the method above due to caching. i still need to purge the cache to make any use of getEnableLimitReport. By disabling page cache and reducing parser cache time one can "solve" this, but it it still doesn't work right after saving a page. --Piksi 19:07, 4 March 2010 (UTC)