More specifically, disablepp may be ignored when using oldid (where the specified revision id is the current revision) or page or pageid, due to MediaWiki fetching the ParserOutput from the parser cache.

This also implies that if the page isn't already cached, then this API query would cause the version without the limit report to be cached, which is also probably not the best thing.

So perhaps the thing to do is to have WikiPage::isParserCacheUsed return false if $parserOptions->getEnableLimitReport() is false.

Whilst the disablepp parameter does nothing when using the page parameter, it does have an effect when using the text parameter instead, see https://www.mediawiki.org/w/api.php?action=parse&text=[[foo]]&disablepp=true

However, the mere existence of the disablepp parameter removes the PP report, regardless of whether its set to false, or indeed anything at all: https://www.mediawiki.org/w/api.php?action=parse&text=[[foo]]&disablepp https://www.mediawiki.org/w/api.php?action=parse&text=[[foo]]&disablepp=bar

Save the limits report separately from HTML and append it in ParserOutput::getText()?

(In reply to mdowdell from comment #2)

However, the mere existence of the disablepp parameter removes the PP
report, regardless of whether its set to false, or indeed anything at all

That's the normal behavior for all boolean parameters in the API.

(In reply to Svick from comment #4)

(In reply to mdowdell from comment #2)

However, the mere existence of the disablepp parameter removes the PP
report, regardless of whether its set to false, or indeed anything at all

That's the normal behavior for all boolean parameters in the API.

And I often write:

->request( array(

'..other..params..' => '..values..',
( $disablepp ? 'disablepp' : 'nodisablepp' ) => '',

) );

(In reply to Svick from comment #4)

(In reply to mdowdell from comment #2)

However, the mere existence of the disablepp parameter removes the PP
report, regardless of whether its set to false, or indeed anything at all

That's the normal behavior for all boolean parameters in the API.

I would expect it to show the PP report if disablepp was set to false, or rather anything that wasn't true. Ideally it should throw an error if it wasn't a boolean or what's the point of it being a boolean in the first place?

(In reply to mdowdell from comment #6)

(In reply to Svick from comment #4)

(In reply to mdowdell from comment #2)

However, the mere existence of the disablepp parameter removes the PP
report, regardless of whether its set to false, or indeed anything at all

That's the normal behavior for all boolean parameters in the API.

I would expect it to show the PP report if disablepp was set to false, or
rather anything that wasn't true. Ideally it should throw an error if it
wasn't a boolean or what's the point of it being a boolean in the first
place?

API "boolean" parameters work like checkboxes in HTML forms: If the box is checked, it sends whatever is defined as the value for the <input>. If the box is not checked, it sends nothing. So to determine if the checkbox was checked at the most basic level, you look for "was this parameter provided at all" without paying any attention to the value provided.

But this is offtopic for this bug report.

• Bug 64860 has been marked as a duplicate of this bug. ***

Cannot reproduce anymore with the testcase above: curl -s "https://en.wikipedia.org/w/api.php?action=parse&format=jsonfm&page=User:Svick/Sandbox&prop=text&disablepp" | grep NewPP show no output. Obsolete?

In T49333#4845812, @Aklapper wrote:

Cannot reproduce anymore with the testcase above: curl -s "https://en.wikipedia.org/w/api.php?action=parse&format=jsonfm&page=User:Svick/Sandbox&prop=text&disablepp" | grep NewPP show no output. Obsolete?

That in itself wouldn't be sufficient to test the bug, since something first needs to populate the parser cache for that call to return the cached data.

But after investigating it a bit more, this was likely fixed by rMW3d94c63b909e: API: Rename disablepp and introduce disabletidy and then more generally by rMW1e2b3fb37f34: ApiParse: Clean up parsing code.