Page MenuHomePhabricator

new parser function for conditional transclusion based on page size
Closed, ResolvedPublic


Author: cbm.wikipedia

a possible implementation of the new parser function

A recurring problem on enwiki is this: we have a central page that transcludes several other pages that are actively edited. If the subpages get too long, the main page hits the transclusion limits. It would be helpful if there was a parser function that would handle conditional transclusion, so that we could automatically switch some of these pages from being transcluded to being linked when they cross a size threshold.

If a different approach is desired, I'll work on switching the code to that. I only wrote this for the new parser, since I assume the old one will be deprecated. I tried to keep code duplication from the parser to a minimum, but the code depends on some internal behavior of the parser. I added a small amount of code to the new parser to avoid duplicating much more in the parser function code.

Version: unspecified
Severity: enhancement

attachment trans.diff ignored as obsolete



Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 10:05 PM
bzimport added a project: ParserFunctions.
bzimport set Reference to bz12698.
bzimport added a subscriber: Unknown Object (MLST).

cbm.wikipedia wrote:

A more robust possibility would be to add a parserfunction to return the size of a page, and then use #ifexpr to do conditional transclusion based on that.

cbm.wikipedia wrote:

PAGESIZE parser function

New patch for a parser function PAGESIZE that returns the size of the page. This would resolve the original issue above.

Should the code for checking $parser->mExpensiveFunctionCount be moved into the Parser class, either inside or parallel to Parser::incrementIncludeSize()? Accessing the global variable in every expensive parser function seems redundant.

The patch has an quirk that if {{PAGESIZE:Foo}} is called within page Foo, the size before the save will be displayed at first, because the old size is fetched from the database. This isn't ideal behavior, but I don't know how to fix it.

attachment pagesize.diff ignored as obsolete

On this note, wouldn't a good idea be to implement an overall $wgMaxInclusionSize wherein a page isn't included if it's over X bytes?

cbm.wikipedia wrote:

consolidate code

There is a maximum size for total transcluded pages implemented in the parser. The issue here is that if 100 smaller pages are transcluded, the limit can be reached sooner than expected, especially in light of bug 13260

Updating the patch to consolidate the logic for incrementing the expensive function count. This might belong in Parser.php.

attachment pagesin.diff ignored as obsolete

cbm.wikipedia wrote:

use templatelinks

Track the PAGESIZE dependency in templatelinks, I should have thought of that originally.

attachment pagesin.diff ignored as obsolete

(In reply to comment #4)

Updating the patch to consolidate the logic for incrementing the expensive
function count. This might belong in Parser.php.

Expensive function count is also incremented by ifexist in the ParserFunctions extension, so this might be best.

cbm.wikipedia wrote:

PAGESIZE parser function

Moved incrementExpensiveFunctionCount() to Parser.php. This patch doesn't include the easy fix to call this inside #ifexist


ayg wrote:

Committed a variation on that patch in r33551. Not sure if it will stay committed, though. :)