Last modified: 2011-03-13 18:04:58 UTC
As per gurch, one big bug/request to output LocalSettings via API (meta=siteinfo ?) Obviously, excluding sensitive ones, such as DB Username/password ;)
Something like: api.php?action=query&meta=siteinfo&siprop=config&siconfigvars=wgLegalTitleChars|wgFileExtensions would probably be nice, yes. Of course, there'd have to be a blacklist with 'sensitive' variables.
Would be great!
(In reply to comment #1) > Something like: > > api.php?action=query&meta=siteinfo&siprop=config&siconfigvars=wgLegalTitleChars|wgFileExtensions > > would probably be nice, yes. Of course, there'd have to be a blacklist with > 'sensitive' variables. > Due to the sensitive nature of fetching any global variable, I'd go for a whitelist.
(In reply to comment #3) > Due to the sensitive nature of fetching any global variable, I'd go for a > whitelist. > Yeah, probably a good idea.
Would it be possible to return the default value if a value isn't set in LocalSettings?
(In reply to comment #5) > Would it be possible to return the default value if a value isn't set in > LocalSettings? > It wouldn't be possible not to :)
Oh, yeah, duh. LocalSettings variables just replace the inital (ie default) decleration Silly me ;)
Done in r45810.
Will this make it into 1.14? If not, is there any chance of backporting (or whatever it is), so that it does? Or is it not important enough to do so/too late? Thanks
(In reply to comment #9) > Will this make it into 1.14? > > If not, is there any chance of backporting (or whatever it is), so that it > does? Or is it not important enough to do so/too late? > Backporting is the term, yes. However, it's our policy to only backport fixes for obviously broken things, so as to stabilize it for the release. New features such as this one are generally not backported. List of recent API changes that were backported and will go into the 1.14 release: * (bug 16798) JSON encoding errors for some characters outside the BMP * (bug 16629) prop=info&inprop=protection lists empty legacy protections incorrectly * (bug 15261, 16262) API no longer outputs invalid UTF-8 * Fix broken list=alllinks paging and make alunique actually work
Fair enough, wondered if that'd be the case, no big deal. Thanks
Reverted in r45940 -- this produces a much too tight coupling between internal implementation details and the stable external API. Don't assume that any of these internal configuration variables will still exist or have the same meanings in the future.
*** Bug 19937 has been marked as a duplicate of this bug. ***