As per gurch, one big bug/request to output LocalSettings via API (meta=siteinfo ?)
Obviously, excluding sensitive ones, such as DB Username/password ;)
Version: 1.14.x
Severity: enhancement
Description
Description
Details
Details
- Reference
- bz17027
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Declined | Catrope | T19024 Get value of $wgLegalTitleChars through the API | |||
| Resolved | Catrope | T19025 Get value of $wgFileExtensions through the API | |||
| Declined | Catrope | T19027 Output LocalSettings.php Variables via API |
Event Timeline
Comment Actions
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 Actions
Bryan.TongMinh wrote:
(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 Actions
(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 Actions
Would it be possible to return the default value if a value isn't set in LocalSettings?
Comment Actions
(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 Actions
Oh, yeah, duh.
LocalSettings variables just replace the inital (ie default) decleration
Silly me ;)
Comment Actions
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 Actions
(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 Actions
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.