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
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
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 |
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.
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.
(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 ;)
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:
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.