Last modified: 2014-09-23 22:55:49 UTC
I have created an extension that uses a tag to generate new sections. This tag basically takes some parameters and displays as a section heading of the desired depth. The section content is listed as the inner HTML of the tag. The problem that I am encountering is that the sections, so generated, do not show up in the table of contents (hereafter TOC). Some relevant information is at http://www.mediawiki.org/wiki/Project:Support_desk#Sections_added_with_tag_extension_do_not_show_up_in_TOC_24342. A transcript: "I have written a tag extension that allows for parameters to be given with a new section, which is processed by a section custom tag. I have dealt with the nesting issue [[bugzilla:1310]] by implementing the suggested amendments to Preprocessor_DOM.php. Everything works just fine, the sections are displayed with their correct header levels etc.etc. There is just one problem. Namely, that the sections written using this section tag do not show up in the table of contents. Some var_dumps revealed to me that these headers do get their UNIQ modifiers. But apparently the TOC is incapable of taking these extra sections into account. Please note that I am not looking for a solution that involves replacing the tag with a parser function; due to extensive presence of $\LaTeX$ the inability to use double closing braces anywhere is too crippling. Furthermore, entering whole sections as an argument to a parser function is obviously not a good and readable coding style. Thank you for looking into this."
Hi, without a minimal testcase it's hard to debug or to find out if there is a bug in the MediaWiki codebase, or in your extension. Also, against which MediaWiki version do you try this?
Created attachment 11843 [details] Code used for the tag extension The literal PHP code used, for debugging purposes
Created attachment 11844 [details] Minimal example exhibiting the issue
The MediaWiki version used is the latest, 1.20.2. In addition to the minimal example I added as an attachment, a live example is at http://www.proofwiki.org/wiki/User:Lord_Farin/Sandbox/Help:Wiki_Editing.
Is there anything else that I can do to speed up the debugging process? The issue is reasonably urgent to ProofWiki because it limits the deployment of the extension, which is critical for proper execution of some long-overdue maintenance projects. (This may be considered a bump.)
I am not sure. Given your pretty deep analysis I think it requires attention from somebody much better versed in parser code. I've seen similar issues with counting sections for a longer time, so I am not sure if this is something easy to fix without breaking some other ways to handle wikitext; I guess it is also not a recent breakage (feel free to try if it ever worked properly :/).
I've performed an exhaustive search once again, throwing var_dumps wherever it seemed that something useful was going on. I am led to conclude that the Parser->formatHeadings function is messing things up when fed with the third parameter $isMain set to false (at the very least, it's performing a lot of redundant operations every time a call to recursiveTagParse comes in). I would like to ask someone who knows their way around this function to go through it and ensure that only the part of formatHeadings that is essential for recursiveTagParse (or any other things calling formatHeadings with $isMain set to false) is executed when said parameter is not set to true.
I've done further testing. There are two relevant conclusions: 1: Running formatHeadings with $isMain set to false is completely superfluous as far as I've been able to determine (using the shipped PHPUnit tests). If this is tested and investigated further, it can improve page load times (expensive but useless preg_match() calls are applied on the entire wiki page). 2: The sections that do not show up in TOC are hidden by a UNIQ identifier for the extension tag, which is not resolved until $this->mStripState->unstripGeneral() is called from the main parse() -- which is way after the TOC is determined using the main call to formatHeadings() in internalParse(). This state of affairs (which I suspect to tie in with the problems concerning section editing and templates) naturally means that some unstripping should be done before TOC is generated. Therefore, my proposal is as follows: To create a designated third unstrip type e.g. entitled "sections" (the first two being "nowiki" and "general", defined and used in StripState.php), which is called before determining TOC, expanding those UNIQ markers whose content may hide sections. Upon creation of a new extension, one can indicate whether or not it may contain new sections using a flag. This course of action occurs to me as the least intrusive way to resolve this bug (and hopefully, related ones). Thoughts are welcomed.
Created attachment 13111 [details] Modified version of minimal example that works around the issue. Logically speaking, I would expect that $parser>recursiveTagParse to create headings like normal. On the other hand, that would probably screw things up with edit section links, if treated precisely as normal. You can kind of work around this issue by making the headers you create be the actual html tags, and everything else you do be manually made strip items. (The section edit links seem to get borked with nested uses of the tag, but nested tag uses don't work anyways since the first closing tag closes the outer nesting, and not the inner nesting, so that's probably not that big a deal (So if what you want to do, is suround the section and all its contents in an extension tag, you may be out of luck for an entirely other reason). You could maybe partially work around the nestedness issue by regexing it out, and not passing all of it to recursiveTagParse. Anyhow, see attachment for crappy work around (To be clear, I still think this is definitely a bug, just showing one way to work around it). ----------- >To create a designated third unstrip type e.g. entitled "sections" (the first >two being "nowiki" and "general", defined and used in StripState.php), which is >called before determining TOC, expanding those UNIQ markers whose content may >hide sections. Upon creation of a new extension, one can indicate whether or >not it may contain new sections using a flag I wonder if it would just make sense to call formatHeadings some point after unstripGeneral. I don't think anyone is really using general strip markers to hide headings from the TOC. (This thought is just an initial reaction. Would need to do more research to see if that's remotely sane).
Having a need for nested tag use, I've already implemented an according patch in the DOM preprocessor. Accordingly, I've decided to try and follow up on your suggestion: > I wonder if it would just make sense to call formatHeadings some point after > unstripGeneral. I don't think anyone is really using general strip markers to > hide headings from the TOC. (This thought is just an initial reaction. Would > need to do more research to see if that's remotely sane). I've just tried it, and it works -- the sections now appear in the ToC. This ties in with my observation that there is no actual use for the $isMain parameter to formatHeadings (the function just shouldn't be called if this parameter is false). It also makes sense conceptually to create a ToC only after the content (or at least, the structure) of the entire page has been determined (but of course, before nowiki strip markers are replaced), and as such, it needn't be processed by recursiveTagParse/internalParse; a call in the main parse routine suffices. My attempt added the formatHeadings call directly after unstripGeneral. Some testing does reveal, however, that moving the formatHeadings call spoils the edit section links (PHPUnit tests show that they do not get rendered any more). This needs to be dealt with, but for our wiki it is not a problem since section-wise editing is discouraged anyway.
