Hi Frank, Yes, from what I've been told, settings named in the 'config' property each may have a "local-settable" flag - meaning an extension developer can use loadExtension() for all extension globals, including those 'internal' to the extension. That's later this year, though! /john
On 8/14/2015 1:55 PM, Frank Baxmann wrote: > Hi John, > > > So the > > upcoming user interface for re/configuring the base/extensions of a wiki > > won't know about them; meaning they won't be locally-settable in that > > user interface. > > does this mean, that on the other side all globals defined in extension.json > will be able to configure in the coming user interface? For some globals > I would not want this, they are only keeping status infos, they are not for > user/admin config. > > > On 14.08.2015 22:21, John McClure wrote: >> Hi Yaron, >> Indeed >> https://git.wikimedia.org/blob/mediawiki%2Fcore.git/01799a7cb33c707a675d8222ff9543934791aa13/includes%2Fregistration%2FExtensionProcessor.php#L261 >> mandates that globals (at least, those initialized by wfLoadExtension) >> must start with "wg". I think this a good thing in the final analysis. >> This conformity is important to upcoming changes to the Extension >> Registration subsystem due later this year -- including new tables to >> hold local global extension settings, a database central to mw's >> installer as well -- all this is a huge huge win! >> >> Objectives of extension registration: >> (1) provide a user interface to dynamically re/configure a wiki's base >> code and extensions >> (2) get people out of LocalSettings.php >> (3) keep people out of, e.g., extensions/SemanticForms/extension.json >> >> Much appreciation your way for letting other extension developers know >> about this, and also for continuing to keep your extensions so nicely >> aligned with MW core. >> /john >> >> Hi Frank, >> The only reason your approach won't always work is that, for those >> globals you're setting in the hook that also happen to be >> locally-settable, these will therefore not be so identified in the >> "config" attribute found in the extension.json structure. So the >> upcoming user interface for re/configuring the base/extensions of a wiki >> won't know about them; meaning they won't be locally-settable in that >> user interface. >> /john >> >> On 8/14/2015 12:47 PM, Frank Baxmann wrote: >>> oh no thx... ;) >>> >>> I put my globals in an early hook like "SetupAfterCache". I think this >>> will works for most extensions too... >>> >>> >>> On 14.08.2015 20:25, Yaron Koren wrote: >>>> Hi Frank, >>>> >>>> It wasn't my decision - if you want, you can take it up with people on >>>> that Phabricator bug. >>>> >>>> -Yaron >>>> >>>> On Fri, Aug 14, 2015 at 1:55 PM, Frank Baxmann >>>> <serv...@frankbaxmann.de <mailto:serv...@frankbaxmann.de>> wrote: >>>> >>>> Hi Yaron, >>>> >>>> this is the common naming convention for globals. >>>> But I don't see why new install procedures should not support >>>> others? >>>> >>>> Greetings >>>> Frank >>>> >>>> On 14.08.2015 17:32, Yaron Koren wrote: >>>> > Hi everyone, >>>> > >>>> > I didn't find this out until recently, but in the latest version >>>> of >>>> > MediaWiki, 1.25 (released in May), there is a new approach >>>> supported for >>>> > including extensions in LocalSettings.php. Instead of calling >>>> something >>>> > like: >>>> > >>>> > include_once( "$IP/ExtensionName/ExtensionName.php" ); >>>> > >>>> > You will be able to call: >>>> > >>>> > wfLoadExtension( "ExtensionName" ); >>>> > >>>> > (And the same will be true for skins.) >>>> > >>>> > To support that, each extension needs to have its own JSON >>>> settings file, >>>> > called "extension.json", where all the settings are defined in a >>>> structured >>>> > way. >>>> > >>>> > If you're interested, you can read more about it here: >>>> > >>>> > https://www.mediawiki.org/wiki/Manual:Extension_registration >>>> > >>>> > The whole thing seems like a good idea, and it will allow for more >>>> > automation - including, I assume, the elusive goal of being able >>>> to install >>>> > extensions from the web interface - but there are also >>>> downsides. One big >>>> > downside is that extension.json can only handle extension settings >>>> > variables that start with "$wg". And it doesn't look like the MW >>>> developers >>>> > are planning to change that requirement: >>>> > >>>> > https://phabricator.wikimedia.org/T97186 >>>> > >>>> > Unfortunately, some of the extensions I maintain have their own >>>> naming >>>> > prefixes for their settings variables - specifically, these five: >>>> > >>>> > - Semantic Forms (currently all variables start with $sfg) >>>> > - External Data (currently, $edg) >>>> > - Header Tabs (currently, $ht) >>>> > - Approved Revs (currently, $egApprovedRevs) >>>> > - Semantic Drilldown (currently, $sdg) >>>> > >>>> > Two other extensions that I maintain, Cargo and Widgets, >>>> fortunately >>>> > already use the $wg convention. And as far as I know, all the >>>> other >>>> > extensions I maintain don't have settings variables at all. >>>> > >>>> > So, over the next week or two, I'm planning to release new >>>> versions of >>>> > these five extensions that support the extension.json setup, and >>>> have all >>>> > their global variables renamed to use the "$wg[ExtensionName]" >>>> convention. >>>> > I know this will cause problems for administrators, but I think >>>> it's the >>>> > right approach, especially since starting with $wg is in fact the >>>> > recommended approach for all extension variables. (It wasn't >>>> always such an >>>> > explicit policy, which is partly why these five extensions have >>>> their own >>>> > naming schema, but that's another story.) I thought about >>>> keeping support >>>> > for the existing variable names as aliases, while making them >>>> deprecated, >>>> > but that's going to make the code complicated, and anyway the >>>> > wfLoadExtension() setup doesn't support the current names. >>>> > >>>> > To clarify, in each case I plan to simply replace the current >>>> prefix in >>>> > each variable name with "$wg" + the extension name, like >>>> "$wgSemanticForms". >>>> > >>>> > By the way, this issue will presumably at some point affect other >>>> > extensions that have non-standard global variable naming >>>> schemes, like >>>> > Semantic MediaWiki and Semantic Results Formats, but I'm not >>>> involved with >>>> > developing those so I can't comment. >>>> > >>>> > So, to anyone who has any of these five extensions installed, >>>> please be >>>> > aware of the upcoming changes; and I'm happy to answer any >>>> questions or >>>> > comments. >>>> > >>>> > -Yaron >>>> > >>>> >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> _______________________________________________ >>>> Semediawiki-user mailing list >>>> semediawiki-u...@lists.sourceforge.net >>>> <mailto:semediawiki-u...@lists.sourceforge.net> >>>> https://lists.sourceforge.net/lists/listinfo/semediawiki-user >>>> >>>> >>>> >>>> >>>> -- >>>> WikiWorks · MediaWiki Consulting · http://wikiworks.com >>> ------------------------------------------------------------------------------ >>> _______________________________________________ >>> Semediawiki-user mailing list >>> semediawiki-u...@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/semediawiki-user >> ------------------------------------------------------------------------------ >> _______________________________________________ >> Semediawiki-user mailing list >> semediawiki-u...@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/semediawiki-user > > ------------------------------------------------------------------------------ > _______________________________________________ > Semediawiki-user mailing list > semediawiki-u...@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/semediawiki-user ------------------------------------------------------------------------------ _______________________________________________ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
