https://bugzilla.wikimedia.org/show_bug.cgi?id=13260
Umherirrender <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected], | |[email protected] --- Comment #11 from Umherirrender <[email protected]> 2012-10-20 17:58:32 UTC --- Post expand size is build to hold the size of all expansions done by the parser to reach the html (including sub expansions like templates and parser functions). So this works as aspected. Some text: [[A]] contains "Big Text" (wikitext length: 8) [[B]] contains "{{:A}}" (wikitext length 6) [[C]] contains "{{:B}}" (wikitext length 6) The parser is starting at C, expanding B to "{{:A}}" which must be expand to "Big Text". This sub expansion adds it expand size (8) to post-expand include size. After this the parser returned the expand text and the expand process of B will add its expand length (also 8) to post-expand include size, which result in the end of a post-expand include size of 16. This way is needed to handle the following scenario: [[A]] contains "Big Text" (wikitext length: 8) [[B]] contains "{{#if:{{:A}}|A|B}}" (wikitext length 18) This gives a size of 9 (8 from the sub expand of A and 1 of the expand of B). Without the adding of each sub expand the post expand size in this scenario would be 1, which makes the limit useless, because the limit is build to avoid to big expansions in the process of parsing a page. There is no error in calculation of the post-expand size, it only contains also the size of each sub expansion. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. _______________________________________________ Wikibugs-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
