Last modified: 2014-11-16 18:58:07 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T49960, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 47960 - ResourceLoader: wfDebugLog should bypass wfIsDebugRawPage() filter
ResourceLoader: wfDebugLog should bypass wfIsDebugRawPage() filter
Status: NEW
Product: MediaWiki
Classification: Unclassified
ResourceLoader (Other open bugs)
1.22.0
All All
: Normal normal (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2013-05-02 01:34 UTC by Krinkle
Modified: 2014-11-16 18:58 UTC (History)
4 users (show)

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


Attachments

Description Krinkle 2013-05-02 01:34:07 UTC
e.g. wgDebugLog( 'resourceloader', .. );
Comment 1 Tim Starling 2013-06-06 06:01:30 UTC
It seems that it already does bypass wfIsDebugRawPage(), if the relevant key in $wgDebugLogGroups is set. That's all I thought you were asking for: you don't want it to put debug lines from RL into $wgDebugLogFile when $wgDebugRawPage is false, do you?
Comment 2 Krinkle 2013-07-11 15:03:30 UTC
Well..

Previously ResourceLoader was using almost no "wgDebugLog( 'resourceloader', .. );" (it had 0 calls other than 1 single generic wfDebug call), I fixed that a few weeks ago by adding calls to wgDebugLog( 'resourceloader', .. ); and changing others to use the same pattern.

However that means I still only get those log entries if I explicitly set up $wgDebugLogGroups in local settings for 'resourceloader'. I can do that locally but I don't like having to tell others do that as well all-the-time whenever they run into a problem that turns out to be caused by update a file path somewhere in a module definition. As far as I know all errors in the 'resourceloader' group are major errors of the type "that must never reach master". Meaning, it doesn't makes sense for them to be optional (e.g. only when setting wgDebugRawPage=true or setting up a custom log group file for it).

I don't see why they shouldn't go to the general log like everything else does by default.

The only reason they're excluded is because wfIsDebugRawPage() returns true for load.php instead of just for action=raw. I suspect the original rationale for that was to avoid clogging up the log with duplicate errors that would emit on both the main request and the request for action=raw (gadgets, site scripts, user scripts).

However I don't think it makes sense for load.php since the type of errors emitted from there are almost entirely from a completely separate code path (the only common thing is WebStart).
Comment 3 Krinkle 2013-07-11 15:04:29 UTC
So I originally intended to create this bug as: remove load.php condition from wfIsDebugRawPage() but if I recall correctly Tim then suggested on IRC (when I brought this up in May 2013) that we instead have wgDebugLog() bypass wfIsDebugRawPage().
Comment 4 Andre Klapper 2013-09-26 14:32:13 UTC
[Assignee was removed, hence also resetting ASSIGNED status]
Comment 5 Marcin Cieślak 2014-11-16 18:58:07 UTC
Right now [resourceloader] entries get logged to the $wgDebugLog file but not on the MWDebug console, $wgShowDebug HTML body or $wgDebugComments HTML comment. 

I think this is okay, given that I can turn off [resourceloader] entries with

$wgDebugLogGroups = array(
   'resourceloader' => false,
);

Not sure I understand this bug report but I think it is working now as it should.

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


Navigation
Links