Extension talk:PSINoTocNum
Add topic--Dieter Wunderer 12:52, 31.03.2009 Here is a solution, since it seems that this extension does not work for anybody (see messages below). I cannot give a detailed explanation, since I do not know the exact mechanisms behind (Wiki caching algorythm must be pretty complex). In addition I combined this extension with Extension:MagicNoNumberedHeadings so that by using this keyword neither the headings in the text, nor the TOC are numbered. If you just want to avoid TOC numbering you need to find a different solution, but my way may still help you.
Short description. When rendering a page, Wiki tends to leave out some steps, i.e. hooks, taking information from cache. Therefore some functions are not called or if they are called the content is only the changed part, the rest seems to get fetched from the cache. Therefore we have to use different hooks than used in the original script. Here is the code which works for me (remarks done by me):
<?php
if (!defined('MEDIAWIKI')) {
die("This can not be run from command line");
}
$wgExtensionCredits['parserhook'][] = array(
'name' => 'PSINoTocNum',
'version' => '$Revision: 1.4 $',
'author' => 'Benedikt Meuthrath',
'url' => 'http://www.mediawiki.org/wiki/Extension:PSINoTocNum',
'description' => 'New MagicWord "<nowiki>__NOTOCNUM__</nowiki>".',
);
$wgHooks['MagicWordMagicWords'][] = 'PSINoTocNumMagicWordMagicWords';
$wgHooks['MagicWordwgVariableIDs'][] = 'PSINoTocNumMagicWordwgVariableIDs';
$wgHooks['LanguageGetMagic'][] = 'PSINoTocNumLanguageGetMagic';
//Originally 'ParserBeforeInternalParse' was used. Since it is not recommended according to [[Manual:Hooks/ParserBeforeInternalParse]]
//it was replaced by hook 'ParserAfterStrip', working perfectly for me.
$wgHooks['ParserAfterStrip'][] = 'MagicNoNumberedHeadings_AfterStrip';
//This is actually the most important part. We add the style to hide the TOC numbers right before the page is displayed. So nothing can
//get between our code and the result... ;-)
$wgHooks['BeforePageDisplay'][] = 'MagicNoNumberedTOC';
function PSINoTocNumMagicWordMagicWords(&$magicWords) {
$magicWords[] = 'MAG_NOTOCNUM';
return true;
}
function PSINoTocNumMagicWordwgVariableIDs(&$wgVariableIDs) {
$wgVariableIDs[] = MAG_NOTOCNUM;
return true;
}
function PSINoTocNumLanguageGetMagic(&$magicWords, $langCode) {
$magicWords[MAG_NOTOCNUM] = array( 0, "__NOTOCNUM__" );
return true;
}
function MagicNoNumberedHeadings_AfterStrip(&$parser, &$text, &$stripState) {
//Here we set the option to number the headings to false. During parsing the headings in the text are not numbered if false.
//Unfortunately this does not prevent the TOC to get numbered. Therefore we need another hood (see below).
if (MagicWord::get( MAG_NOTOCNUM )->matchAndRemove( $text ) ) {
$parser->mOptions->mNumberHeadings = (FALSE);
}
return true;
}
function MagicNoNumberedTOC (&$out) {
//Here we check if the option for numbering the headings is true. If not (no numbering) we hide the TOC numbers.
//Why numbers disappear: the numbers of the TOC are luckily formatted with a special class '.tocnumber', that's why this works.
//Why adding as script: because there is only a method to add CSS files, not just a CSS style directly. But you can add a script directly... ;-)
if (!$out->mNumberHeadings) $out->addScript('<style type="text/css"><!-- .tocnumber {display:none;} --></style>');
return true;
}
--Dtsig 17:59, 18 April 2007 (UTC)
Installed but am not seeing the numbering reduced. Have created the page, added to localSettings. I have tried putting the __NOTOCNUM__ in several places. If I am off in what I thought this would do just let me know
We have 'word' docs that have been converted but the section numbers were still there. So we have 1.0, 1.1, 1.2 etc.
With the extension added here is what we see ..
* 1 1.0 Scope & Requirements o 1.1 1.1 Product(s), Processes, and Scope + 1.1.1 1.1.1 Scope + 1.1.2 1.1.2 Other Processes Affected o 1.2 1.2 Justification and Benefits o 1.3 1.3 Requirements o 1.4 1.4 Dependencies and Impact o 1.5 1.5 Assumptions o 1.6 1.6 Risks</span> o 1.7 1.7 User Profiles and Perspectives o 1.8 1.8 Security o 1.9 1.9 High Level Flow Chart(s) * 2 2.0 Notes o 2.1 2.1 Product Verbiage o 2.2 2.2 Revision Log o 2.3 2.3 Comments,Notes o 2.4 2.4 Questions
- Take another look at what the extension does: it does not remove the numbers, it suppresses their display. Not really sure what you mean by "'word' docs that have been converted": if this means that you have converted the web-pages into Word, then the numbers are indeed likely to become visible. HTH HAND âPhil | Talk 10:25, 19 April 2007 (UTC)
- Phil is right. The extension only supress the display of the number only in MediaWiki by adding .tocnumber {display:none;} to the css scripts if __NOTOCNUM__ is present anywhere in the article. I don't know, what your word doc converter does to toc numbering. --BeneM 11:02, 20 April 2007 (UTC)
I just installed this extension. When I add the "__NOTOCNUM__" to an article, and preview it, the TOC does not include section numbers (so far, so good!). However, when I click "save" and then view the article, it reverts back to showing numbers in the TOC. Any ideas on why this and how I can fix it would be very appreciated.--Lost Student 18:23, 27 October 2007 (UTC)
- Could you please verify if it also shows numbers when you add "?action=purge" to the URL? If this solves it, than you have a problem with caching. --BeneM 13:47, 29 October 2007 (UTC)
- After ?action=purge is performed, numbers are gone. However after next edit and save, they reappear.
- Hi there,
- I have the same problem here. Can somebody explain, what kind of caching problem this could be?
- Best regards, Thomas (Thbaero 15:30, 15 January 2008 (UTC))
- I'm having the same problem (everything looks okay with "?action=purge" or any other non-default action). What I don't understand is how this could have anything to do with caching... :-? The CSS is simply missing when I'm viewing the page. What should I learn about the MW cache to fix this problem? --BigSmoke 00:21, 29 January 2008 (UTC)
- Ok. So I've educated my self a bit on the parser cache. (When I heard "cache", the first thing I thought was HTTP caching or some page cache.) However, from what I understand about the parser cache now, just disabling the parser cache would be a pretty dumb thing to do for my wiki which features some very long pages and heavy template usage. --BigSmoke 03:26, 29 January 2008 (UTC)
- Exactly the same problems as the rest here, does anyone have a fix on this yet? --Tskegel 14:09, 24 March 2008 (UTC)