Last modified: 2011-03-13 18:04:58 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 T19027, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 17027 - Output LocalSettings.php Variables via API
Output LocalSettings.php Variables via API
Status: RESOLVED WONTFIX
Product: MediaWiki
Classification: Unclassified
API (Other open bugs)
1.14.x
All All
: Lowest enhancement with 1 vote (vote)
: ---
Assigned To: Roan Kattouw
:
: 19937 (view as bug list)
Depends on:
Blocks: 17024 17025
  Show dependency treegraph
 
Reported: 2009-01-14 22:06 UTC by Sam Reed (reedy)
Modified: 2011-03-13 18:04 UTC (History)
5 users (show)

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


Attachments

Description Sam Reed (reedy) 2009-01-14 22:06:57 UTC
As per gurch, one big bug/request to output LocalSettings via API (meta=siteinfo ?)

Obviously, excluding sensitive ones, such as DB Username/password ;)
Comment 1 Roan Kattouw 2009-01-14 22:09:35 UTC
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.
Comment 2 Sam Reed (reedy) 2009-01-14 22:11:30 UTC
Would be great!
Comment 3 Bryan Tong Minh 2009-01-14 22:46:35 UTC
(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.
Comment 4 Roan Kattouw 2009-01-14 22:54:03 UTC
(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.
Comment 5 Sam Reed (reedy) 2009-01-15 14:22:43 UTC
Would it be possible to return the default value if a value isn't set in LocalSettings?
Comment 6 Roan Kattouw 2009-01-15 14:25:27 UTC
(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 :)
Comment 7 Sam Reed (reedy) 2009-01-15 14:30:53 UTC
Oh, yeah, duh.

LocalSettings variables just replace the inital (ie default) decleration

Silly me ;)
Comment 8 Roan Kattouw 2009-01-16 21:04:26 UTC
Done in r45810.
Comment 9 Sam Reed (reedy) 2009-01-19 14:02:30 UTC
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
Comment 10 Roan Kattouw 2009-01-19 14:20:48 UTC
(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
Comment 11 Sam Reed (reedy) 2009-01-19 14:22:43 UTC
Fair enough, wondered if that'd be the case, no big deal.

Thanks
Comment 12 Brion Vibber 2009-01-20 22:59:33 UTC
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.
Comment 13 Roan Kattouw 2009-07-28 11:28:51 UTC
*** Bug 19937 has been marked as a duplicate of this bug. ***

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


Navigation
Links