Last modified: 2012-11-01 00:38:26 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 18257 - wfMsgExt() with 'parse' or 'parseinline' crashes when $wgTitle == null
wfMsgExt() with 'parse' or 'parseinline' crashes when $wgTitle == null
Status: RESOLVED WONTFIX
Product: MediaWiki
Classification: Unclassified
Parser (Other open bugs)
1.15.x
All All
: Normal enhancement (vote)
: ---
Assigned To: Tim Starling
:
Depends on:
Blocks: 17852
  Show dependency treegraph
 
Reported: 2009-03-30 13:33 UTC by Roan Kattouw
Modified: 2012-11-01 00:38 UTC (History)
2 users (show)

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


Attachments

Description Roan Kattouw 2009-03-30 13:33:18 UTC
When wfMsgExt() is called with the 'parse' or 'parseinline' option while $wgTitle is null (say, from a parser hook while parsing stuff in the API), a fatal error occurs. Either the dependency on $wgTitle should be removed, or wfMsgExt() should handle this case gracefully.
Comment 1 P.Copp 2009-03-30 13:57:39 UTC
cf. bug 17329.
IMHO the only way to solve both bugs properly is to write an own member function of $wgParser (->msgExt)? and use it from within the parser instead relying on global functions which in turn rely on $wgTitle.
Comment 2 Roan Kattouw 2009-03-30 15:30:56 UTC
(In reply to comment #1)
> cf. bug 17329.
> IMHO the only way to solve both bugs properly is to write an own member
> function of $wgParser (->msgExt)? and use it from within the parser instead
> relying on global functions which in turn rely on $wgTitle.
> 

I think wfMsgExt() using e.g. "Msg" as a dummy title (I seem to recall it did that once) would be good enough. Hardly anyone relies on {{PAGENAME}}-like stuff in such messages anyway.
Comment 3 Chad H. 2009-03-30 15:35:56 UTC
(In reply to comment #2)
> I think wfMsgExt() using e.g. "Msg" as a dummy title (I seem to recall it did
> that once) would be good enough. Hardly anyone relies on {{PAGENAME}}-like
> stuff in such messages anyway.
> 

Not a bad idea. How many places are we working around this so far? It would make far more sense to just throw a dummy title in there.
Comment 4 P.Copp 2009-03-30 16:04:36 UTC
(In reply to comment #2)
> I think wfMsgExt() using e.g. "Msg" as a dummy title (I seem to recall it did
> that once) would be good enough. Hardly anyone relies on {{PAGENAME}}-like
> stuff in such messages anyway.
Well, that would be another dirty hack, wouldn't it? There could be a {{PAGENAME}} in nearly any customized message. See for example bug 17442, where apparently this behavior caused a lot of confusion.
Comment 5 Roan Kattouw 2009-05-02 14:51:45 UTC
(In reply to comment #3)
> (In reply to comment #2)
> > I think wfMsgExt() using e.g. "Msg" as a dummy title (I seem to recall it did
> > that once) would be good enough. Hardly anyone relies on {{PAGENAME}}-like
> > stuff in such messages anyway.
> > 
> 
> Not a bad idea. How many places are we working around this so far? It would
> make far more sense to just throw a dummy title in there.
> 

Did this in r50132, but of course it's just a temporary workaround. Code unnecessarily depending on $wgTitle should die.
Comment 6 Rob Lanphier 2012-11-01 00:38:26 UTC
Deprecated function, no comments since 2009, so resolving wontfix.

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


Navigation
Links