Last modified: 2008-04-18 15:01:28 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 12698 - new parser function for conditional transclusion based on page size
new parser function for conditional transclusion based on page size
Status: RESOLVED FIXED
Product: MediaWiki extensions
Classification: Unclassified
ParserFunctions (Other open bugs)
unspecified
All All
: Normal enhancement (vote)
: ---
Assigned To: Nobody - You can work on this!
: patch, patch-need-review
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-01-20 05:16 UTC by CBM
Modified: 2008-04-18 15:01 UTC (History)
3 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments
a possible implementation of the new parser function (4.70 KB, patch)
2008-01-20 05:16 UTC, CBM
Details
PAGESIZE parser function (1.92 KB, patch)
2008-04-10 18:59 UTC, CBM
Details
consolidate code (2.85 KB, patch)
2008-04-12 15:04 UTC, CBM
Details
use templatelinks (3.03 KB, patch)
2008-04-12 15:46 UTC, CBM
Details
PAGESIZE parser function (3.72 KB, patch)
2008-04-15 19:44 UTC, CBM
Details

Description CBM 2008-01-20 05:16:06 UTC
Created attachment 4562 [details]
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. 

I wrote some rough but working code that does it with a new parser function. The syntax implemented is {{#transcludeifsmaller:PageName|MaxSize|Otherwise}}.

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.
Comment 1 CBM 2008-04-07 16:51:11 UTC
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. 
Comment 2 CBM 2008-04-10 18:59:57 UTC
Created attachment 4800 [details]
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.
Comment 3 Chad H. 2008-04-10 19:04:20 UTC
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?
Comment 4 CBM 2008-04-12 15:04:21 UTC
Created attachment 4809 [details]
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.
Comment 5 CBM 2008-04-12 15:46:48 UTC
Created attachment 4810 [details]
use templatelinks

Track the PAGESIZE dependency in templatelinks, I should have thought of that originally.
Comment 6 Alex Z. 2008-04-12 19:41:11 UTC
(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.
Comment 7 CBM 2008-04-15 19:44:36 UTC
Created attachment 4819 [details]
PAGESIZE parser function

Moved incrementExpensiveFunctionCount() to Parser.php. This patch doesn't include the easy fix to call this inside #ifexist
Comment 8 Aryeh Gregor (not reading bugmail, please e-mail directly) 2008-04-18 15:01:28 UTC
Committed a variation on that patch in r33551.  Not sure if it will stay committed, though.  :)

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links