https://bugzilla.wikimedia.org/show_bug.cgi?id=45317
--- Comment #9 from Bawolff (Brian Wolff) <[email protected]> --- Created attachment 13111 --> https://bugzilla.wikimedia.org/attachment.cgi?id=13111&action=edit 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). -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug. _______________________________________________ Wikibugs-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
