Page MenuHomePhabricator

Add global variable to disable newPP limit report
Closed, ResolvedPublic

Description

Author: plix.tixiplik.1

Description:
There is currently no way (that I can find) to disable the HTML comment added by the Parser detailing the "newPPP limit report" without restoring to changing the method call of enableLimitReport() in ParserOptions.

Not all wikis want or need that HTML comment, especially in API output where it will usually be stripped from the HTML down the line. A global like $wgEnableParserLimitReporting (default true) that could be added to LocalSettings.php and set to false would be much appreciated.


Version: 1.22.0
Severity: enhancement

Details

Reference
bz26792

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 11:14 PM
bzimport added a project: MediaWiki-Parser.
bzimport set Reference to bz26792.
bzimport added a subscriber: Unknown Object (MLST).

SVN trunk, and as such, 1.17 will have, &disablepp in action=parse on the API already...

Unless you plan to make this a 1.17 blocker, it isn't going in 1.17.

Tagging as (very) easy - addition of new global to DefaultSettings.php, use parser/Parser.php around line 534/535 and encompass down to around 560 and then document on mediawiki.org

Change 89758 had a related patch set uploaded by Reedy:
Add $wgEnableParserLimitReporting to control whether the NewPP limit report is included as a HTML comment.

https://gerrit.wikimedia.org/r/89758

Change 89758 merged by jenkins-bot:
Add $wgEnableParserLimitReporting to control whether the NewPP limit report is included as a HTML comment.

https://gerrit.wikimedia.org/r/89758

I don't understand the point of this global. Re-opening this bug for further consideration.

Can someone please provide a use-case for disabling this HTML comment?

(In reply to comment #6)

I don't understand the point of this global. Re-opening this bug for further
consideration.

Can someone please provide a use-case for disabling this HTML comment?

Surely the person requesting this is the use case?

(In reply to comment #7)

Surely the person requesting this is the use case?

Globals are annoying to maintain. My rough count in DefaultSettings.php at the time of this commit says there are about 730 global configuration variables. Before we add yet another, I'd like there to be a good reason. Database password, script path, etc. ... okay, that makes sense. But an option to disable an HTML comment from the parser output to a standard Web browser? Why?

There's currently one comment from one user (comment 0) saying he or she wants to disable the HTML comment. We have a robust Web API that includes a flag specifically to disable this HTML comment in machine-readable HTML output. What more is needed here?

If this still doesn't convince you, imagine you put every configuration variable next to a checkbox or drop-down menu in a graphical user interface. I doubt many people would think the additional user interface clutter is warranted here.

Tgr assigned this task to Reedy.
Tgr subscribed.

Done since forever.

Since there has been no activity on the discussion to revert, keeping this task open is misleading. A separate task(/patch/mail thread) is probably a better place for that discussion.