Last modified: 2011-09-14 22:00:08 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 T32897, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 30897 - enableSemantics() without $namespace causing fatal error
enableSemantics() without $namespace causing fatal error
Status: RESOLVED FIXED
Product: MediaWiki extensions
Classification: Unclassified
Semantic MediaWiki (Other open bugs)
unspecified
All All
: Unprioritized minor (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-09-14 16:17 UTC by Daniel A. R. Werner
Modified: 2011-09-14 22:00 UTC (History)
2 users (show)

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


Attachments

Description Daniel A. R. Werner 2011-09-14 16:17:03 UTC
function enableSemantics( $namespace = null, $complete = false ) without $namespace will cause an fatal error since wfWarn() is called in line 57 (as of r97000).
In since enableSemantics most likely is called during LocalSettings.php, before parser initialization, global wiki functions are not available as well.

Perhaps it would be cleaner to setup SMW like any normal extension with help of $wgHooks['ParserFirstCallInit'][]
Comment 1 Markus Krötzsch 2011-09-14 18:59:40 UTC
As explained in INSTALL, the method enableSemantics() should not be called with null but with a namespace string. It is okay if it creates an error if called with the wrong kind of parameters. We could make the error less fatal but the very purpose of the current design is to prevent the use of SMW without fixing some reasonable namespace. This is so since we do not know of any method for obtaining a stable namespace in PHP. We need a namespace and this is our way of enforcing it. We could change it to require some variable to be set and throw an error if this is missing, but this would just be a syntactic issue. I guess this is not what bug report was aiming at (if it was, then it can of course be reopened).

In any case I don't see a problem with setting a namespace. It can simply be one of the URL bases of your wiki. Just pick the one that you like most.
Comment 2 Markus Krötzsch 2011-09-14 19:03:51 UTC
Sorry, I misread the report to mean that no error should be created at all. Of course you are right that this call to wfWarn is not good if it fails at this stage. Maybe we could throw a PHP error instead or indeed use MW hooks to do the check later on.
Comment 3 Jeroen De Dauw 2011-09-14 19:28:38 UTC
I changed it to use die() in r97089. This seems more appropriate then throwing an error, as errors are often not shown, and in some cases come with a backtrace, which is not relevant.
Comment 4 Daniel A. R. Werner 2011-09-14 20:21:11 UTC
In the original code there was only a warning and I think the code kept running pretty well.
So I would suggest making $namespace not an optional parameter because when it is optional, the wiki shouldn't just die without any further message, this could make searching for the cause quite hard if you're not into SMW.

Or if $namespace really is intended to be optional but should throw at least a warning as intended in the original code design, then only registering another function for $wgHooks['ParserFirstCallInit'][] and doing all the stuff done in enableSemantics() there at the right time when global functions are loaded (the clean way in my opinion anyway)
Or you could make enableSemantics() obsolete at all and introduce another config var to define the namespace, of course all of this depends on whats happening in enableSemantics(), didn't look into that too deep.
Comment 5 Daniel A. R. Werner 2011-09-14 22:00:08 UTC
I just saw that you pass a message along with die( '...' ) so everybody who's not blind as me could see what's wrong anyway.

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


Navigation
Links