Hi all!
This is a heads up for extensions that expect to be installed via composer:
Starting with the release of 1.38, extensions MUST NOT access any MediaWiki
functions, variables, or constants in code that is executed by the composer
autoloader <https://getcomposer.org/doc/04-schema.md#files>. The earliest point
in time in which extensions MAY access SOME MediaWiki functions, variables, or
constants is the registration callbacks
<https://www.mediawiki.org/wiki/Manual:Extension.json/Schema#callback>, though
restrictions apply
<https://www.mediawiki.org/wiki/Manual:Extension_registration/Limitations> there
as well.
Note that managing extension installation via composer will continue to work as
before for now (though support for this is not well defined, see T250406
<https://phabricator.wikimedia.org/T250406>). Support is removed only for
interacting with functions, variables, or constants defined by MediaWiki before
extension.json is loaded. Doing this has long been known to cause problems, see
the discussion on T249573 <https://phabricator.wikimedia.org/T249573> and T61872
<https://phabricator.wikimedia.org/T61872>.
The immediate reason to remove support now is that we are working on allowing
MediaWiki to load configuration from JSON and YAML files
<https://phabricator.wikimedia.org/T292402> instead of setting global variables
in PHP files. Exploration in this area has shown the need to have external
libraries available early on during the initialization process, so we can use
them to process settings files. This makes it necessary to change the order of
initialization so that the auto-loading component of composer is executed before
we set up global state with default settings etc. Because of this, code that is
executed by the autoloader cannot have access to things that get initialized
later on.
This change has already been made to MediaWiki core as deployed on WMF sites. We
found out the hard way <https://phabricator.wikimedia.org/T295883> that there
are extensions that presently rely on accessing MediaWiki settings from code
that runs during autoloader initialization. After some discussion, it was
decided that it is time to remove support for this practice, since it has been
frowned upon for a long time, and there seems to be no good way to resolve this
hen-and-egg problem in the initialization sequence.
Please reply to this email if you have any concerns about this change.
--
Daniel Kinzler
Principal Software Engineer, Core Platform
Wikimedia Foundation