Difference between revisions of "Blog Post:23"

From mwstake
Jump to: navigation, search
(Created page with "{{Blog Post |title=Breaking Change - Settings Variables for MediaWiki Extensions Will Need to be Renamed |tags=Updates, 1.25, Breaking, Change, Variables, Extensions, Extensio...")
 
Line 17: Line 17:
 
As Yaron Koren describes the change in his post on semediawiki-user, "The whole thing seems like a good idea,...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"
 
As Yaron Koren describes the change in his post on semediawiki-user, "The whole thing seems like a good idea,...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"
  
According to [https://phabricator.wikimedia.org/T97186 the discussion on Phabricator] there are folks who don't wish to allow for customized extension setting variables. Extension authors, like Yaron, will have to modify their extensions in order to be registered through this new mechanism. This also means that admins will have to pay particular care during their upgrade process of extensions not using the "$wg" prefix. Be ye warned, things might break!
+
According to [https://phabricator.wikimedia.org/T97186 the discussion on Phabricator] there are folks who don't wish to allow for customized extension setting variables. Extension authors, like Yaron, will have to modify their extensions in order to be registered through this new mechanism. This also means that admins will have to pay particular care during their upgrade process of extensions not using the "$wg" prefix. Be ye warned, things will break!
  
 
Yaron notes that the extensions he maintains will be impacted in the near future. They are:
 
Yaron notes that the extensions he maintains will be impacted in the near future. They are:

Revision as of 15:29, 14 August 2015

by Chris Koerner on 14 August 2015 15:28 (EDT)

Tag.png Tags: 1.25, Breaking, Change, Extension Development, Extensions, Updates, Variables
Person.png People: Yaron Koren

If you're a extension developer or a MediaWiki admin you'll want to pay attention to some changes coming your way. As of 1.25 (released in May of 2015) there is a new way to register extensions.

In the past you registered a new extension in your LocalSettings.php with something like:

include_once( "$IP/ExtensionName/ExtensionName.php" );

Now you can include an extension.json that stores all of your extension settings an call it with:

wfLoadExtension( "ExtensionName" );

As Yaron Koren describes the change in his post on semediawiki-user, "The whole thing seems like a good idea,...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"

According to the discussion on Phabricator there are folks who don't wish to allow for customized extension setting variables. Extension authors, like Yaron, will have to modify their extensions in order to be registered through this new mechanism. This also means that admins will have to pay particular care during their upgrade process of extensions not using the "$wg" prefix. Be ye warned, things will break!

Yaron notes that the extensions he maintains will be impacted in the near future. They are:

  • Semantic Forms (currently all variables start with $sfg)
  • External Data (currently, $edg)
  • Header Tabs (currently, $ht)
  • Approved Revs (currently, $egApprovedRevs)
  • Semantic Drilldown (currently, $sdg)

It's also worth noting that other extensions will be impacted by this change. Semantic MediaWiki and Semantic Results Formats are both mentioned by Yaron. You can read his full post and some of the comments on the semediawiki-user archive and can chime in on the Phabracator task.