Manual:एक्सटेंशन विकसित करना

This page is a translated version of the page Manual:Developing extensions and the translation is 55% complete.

Outdated translations are marked like this.

Extensions :

अगर आप विकिमीडिया साइटों पर अपना एक्सटेंशन तैनात करना चाहते हैं, Writing an extension for deployment पढ़ें

This page is a guide to developing extensions for MediaWiki. Before you start, browse the list of extensions to see if an extension already exists for your use case.

Extension development consists of these parts:

सेटअप
Implementation
स्थानीयकरण
Publication

सेटअप

To set up a new extension, start by setting up a local development environment for MediaWiki , and follow the instructions to install and copy the BoilerPlate extension.

विकसित करते समय आप $wgMainCacheType = CACHE_NONE और $wgCacheDirectory = false सेट करके कैशिंग अक्षम कर सकते हैं, वरना सिस्टम संदेश और दूसरे बदलावों को दिखने में समय लग सकता है।

Structure

एक मिनिमल एक्सटेंशन में यह संरचना मौजूद होगी:

MyExtension/extension.json: सेटअप के निर्देश का संग्रहण। फ़ाइल के नाम को 'extension.json' होना चाहिए। (मीडियाविकि 1.25 से पहले सेटअप के निर्देश एक्सटेंशन के अनुसार नामित एक MyExtension/MyExtension.php फ़ाइल में थे। कई एक्सटेंशन अभी भी इस PHP फ़ाइल में पीछे की ओर की संगतता शिम हैं।)
MyExtension/includes/ (or MyExtension/src/): एक्सटेंशन के लिए PHP निष्पादन कोड रखता है।
MyExtension/resources/ (or MyExtension/modules/): एक्सटेंशन के लिए क्लाइंट-मुखी जानकारी जैसे जावास्क्रिप्ट, CSS, LESS आदि रखता है।
MyExtension/i18n/*.json: एक्सटेंशन के लिए स्थानीयकरण की जानकारी रखता है।
MyExtension/README.md: एक्सटेंशन को कैसे स्थापित और कॉन्फ़िगर करना है, यह बताते हुए एक README फ़ाइल जोड़ देना एक अच्छी प्रथा है। Use either plain text or Markdown. उदाहरण के लिए Extension:Page Forms के लिए Phabricator Diffusion पृष्ठ देखें। अगर आप मार्कडाउन का इस्तेमाल करते हैं, .md फ़ाइल एक्सटेंशन जोड़ें। उदाहरण के लिए Phabricator Diffusion पर Parsoid के लिए README.md फ़ाइल देखें।

जब आप एक एक्सटेंशन विकसित करेंगे, MyExtension को आपके एक्सटेंशन के नाम से बदल दीजिएगा। उसकी डिरेक्ट्री और PHP फ़ाइल(ओं) के नाम 'अपर कैमल केस' में रखें; यह साधारण फ़ाइल नामकरण प्रथा है।^[1]

Registration

मीडियाविकि संस्करण:

≥ 1.25

The extension.json file contains the configuration data for the extension. Here is an example of a minimal extension.json:

{
	"name": "MyExtension",
	"author": "John Doe",
	"url": "https://www.mediawiki.org/wiki/Extension:MyExtension",
	"description": "This extension is an example.",
	"version": "1.5",
	"license-name": "GPL-2.0-or-later",
	"type": "validextensiontype",
	"manifest_version": 2
}

कई फ़ील्ड्स वैकल्पिक हैं, मगर उन्हें भर देना एक अच्छी प्रथा है। For a more complete example of extension.json, see the BoilerPlate extension.

manifest_version उस स्केमा का संस्करण है जिसके विरुद्ध extension.json फ़ाइल को लिखा गया है। उपलब्ध संस्करण हैं 1 और 2। इस सुविधा के बारे में प्रलेख के लिए यहाँ देखें। अगर आपको मीडियाविकि के किसी अधिक पुराने संस्करण को समर्थित करने की ज़रूरत नहीं, नवीनतम संस्करण चुनें।

Once you have an extension.json file set up for your extension, the extension will appear on your local Special:Version page.

लाइसेंस

MediaWiki is an open-source project and users are encouraged to make any MediaWiki extensions under an Open Source Initiative (OSI) approved license compatible with GPL-2.0-or-later (Wikimedia's standard software license).

We recommend adopting one of the following compatible licenses for your projects in Gerrit:

GNU General Public License, version 2 or later (GPL-2.0-or-later)
MIT License (MIT)
BSD License (BSD-3-Clause)
Apache License 2.0 (Apache-2.0)

For extensions that have a compatible license, you can request developer access to the MediaWiki source repositories for extensions. To specify the licence in code and with "license-name" a key should be used to provide its short name, e.g. "GPL-2.0-or-later" or "MIT" adhering to the list of identifiers at spdx.org.

अपने एक्सटेंशन को कॉन्फ़िगर करने योग्य बनाना

Ideally, users should be able to install your extension by adding only one line to LocalSettings.php:

wfLoadExtension( 'MyExtension' );

अगर आप चाहते हैं कि सदस्य आपके एक्सटेंशन को कॉन्फ़िगर कर पाएँ, आपको कुछ कॉन्फ़िगरेशन पैरामीटरों को परिभाषित और प्रलेखित करना होगा, और आपके सदस्य का सेटअप कुछ ऐसा नज़र आएगा:

wfLoadExtension( 'MyExtension' );
$wgMyExtensionConfigThis = 1;
$wgMyExtensionConfigThat = false;

अगर आप चाहते हैं कि सदस्य आपके एक्सटेंशन को कॉन्फ़िगर कर पाएँ, आपको एक या एकाधिक कॉन्फ़िगरेशन वेलिएबल्स प्रदान करने होंगे। उन वेरिएबलों को अनूठे नाम देना अच्छा होगा। उन्हें मीडियाविकि की नामकरण प्रथाओं का भी पालन करना होगा (जैसे ग्लोबल वेरिएबलों की शुरुआत $wg से होनी चाहिए)।

उदाहरणस्वरूप, अगर आपके एक्सटेंशन का नाम "MyExtension" है, आप अपने सभी कॉन्फ़िगरेशन वेरिएबलों की शुरुआत में $wgMyExtension जोड़ सकते हैं। यह सुनिश्चित करना ज़रूरी है कि मीडियाविकि मूल में से कोई भी वेरिएबल इस तरह से शुरू नहीं होता है, और आपको यह भी जाँचना चाहिए कि कोई भी प्रकाशित एक्सटेंशन इस तरह से वेरिएबलों की शुरुआत नहीं करता है। अगर ओवरलैप होने वाले वेरिएबलों के नामों की वजह से सदस्यों को आपके या किसी दूसरे एक्सटेंशन के बीच किसी एक को चुनना पड़े, आपकी खैर नहीं होगी।

अपनी स्थापना की टिप्पणियों में हर कॉन्फ़िगरेशन वेरिएबल के लिए विस्तृत प्रलेख शामिल करना भी एक अच्छी प्रथा है।

Here is an example of how to set up a configuration variable in extension.json:

{
	"config": {
		"BoilerPlateEnableFoo": {
			"value": true,
			"description": "Enables the foo functionality"
		}
	}
}

ध्यान रखें कि wfLoadExtension( 'BoilerPlate' ); को कॉल करने के बाद ग्लोबल वेरिएबल $wgBoilerPlateEnableFoo मौजूद नहीं होता। अगर आप वेरिएबल को सेट करते हैं, मान लीजिए LocalSettings.php पर, तब extension.json में निर्दिष्ट डिफ़ॉल्ट वैल्यू का इस्तेमाल नहीं किया जाएगा।

अनुकूलित एक्सटेंशनों के अंदर ग्लोबल वेरिएबलों के बारे में अधिक जानकारी के लिए Configuration for developers देखें।

स्वतः लोडिंग के लिए वर्ग तैयार करना

अगर आप अपने एक्सटेंशन को लागू करने के लिए वर्ग का इस्तेमाल करते हैं, मीडियाविकि पर एक सरलीकृत तंत्र है जिससे PHP उस स्रोत फ़ाइल को आसानी से ढूँढ़ पाएगा जहाँ पर आपका वर्ग स्थित है। ज़्यादातर मामलों में इस कारण आपको अपना __autoload($classname) साधन लिखने की ज़रूरत नहीं पड़ेगी।

मीडियाविकि के स्वतः लोडिंग तंत्र का इस्तेमाल करने के लिए आपको AutoloadClasses फ़ील्ड में एंट्रियाँ जोड़नी होंगी। हर एंट्री की कुँजी वर्ग का नाम होगी; वैल्यू उस फ़ाइल का नाम होगा जिसमें वर्ग की परिभाषा मौजूद होगी। किसी साधारण एक-वर्ग-वाले एक्सटेंशन के लिए वर्ग को आम तौर पर एक्सटेंशन का नाम दिया जाता है, तो आपका स्वतः लोडिंग अनुभाग कुछ इस तरह का नज़र आएगा (एक्सटेंशन का नाम है MyExtension):

{
	"AutoloadClasses": {
		"MyExtension": "includes/MyExtension.php"
	}
}

फ़ाइल का नाम उस डिरेक्ट्री के सापेक्ष है जिसमें extension.json फ़ाइल मौजूद है।

अधिक जटिल एक्सटेंशनों के लिए नामस्थानों का इस्तेमाल किया जा सकता है। विस्तार के लिए Manual:Extension.json/Schema#AutoloadNamespaces देखें।

निर्भरताएँ हैंडल करना

मान लें कि एक्सटेंशन को किसी दूसरे एक्सटेंशन की उपस्थिति की ज़रूरत होती है, उदाहरणस्वरूप क्योंकि कार्यक्षमताएँ या डेटाबेस टेबल्स का इस्तेमाल किया जाता है और गैर-उपस्थिति के मामले में त्रुटि संदेशों से बचा जाता है।

उदाहरणस्वरूप, CountingMarker एक्सटेंशन को विशिष्ट फ़ंक्शन्स के लिए HitCounters एक्सटेंशन की उपस्थिति की ज़रूरत होती है।

इसे निर्दिष्ट करने का एक तरीका होगा extension.json में requires कुँजी का इस्तेमाल करना।

एक दूसरा विकल्प है ExtensionRegistry (मीडियाविकि 1.25 से उपलब्ध) का इस्तेमाल करना:

	if ( ExtensionRegistry::getInstance()->isLoaded( 'HitCounters', '>=1.1' ) {
		/* do some extra stuff, if extension HitCounters is present in version 1.1 and above */
	}

Currently (as of February 2024, MediaWiki 1.41.0) the name of the extension-to-be-checked needs to exactly match the name in their extension.json.^[2]^[3]

Example: if you want to check the load status of extension OpenIDConnect, you have to use it with a space

	if ( ExtensionRegistry::getInstance()->isLoaded( 'OpenID Connect' ) {
    ...
	}

Implementation

For an overview of code architecture, structure, and conventions for extensions, see Best practices for extensions .

Extension points

MediaWiki core provides several ways for extensions to change the behavior, functionality, and appearance of a wiki. Most extensions use more than one of these extension points. For a complete list of extension points supported in extension.json, see the schema reference .

General

Hooks : Inject custom code at key points in MediaWiki core code, such as when a user logs in or saves a page. Extensions can also define new hooks.
API modules : Define API modules based on the Action API or REST API . These modules can be called by bots or clients.
Jobs : Add jobs to MediaWiki's JobQueue to perform process-intensive tasks asynchronously, such as sending notification emails.

Pages

Display a special page : Special pages provide dynamically generated content, often based on system state, database queries, and user inputs.
Perform a page action : The action URL parameter generates a custom page based on the current page, usually to provide information (such as page history) or to perform an action (such as edit the page). In addition to the default actions provided by MediaWiki core, extensions can define a new page action.
Add a tracking category : Help users find pages with similar characteristics by automatically adding pages to custom categories.

Content

Extend wiki markup : Extensions can add custom functionality to MediaWiki's wikitext markup using template syntax ({{...}}) or tags (‎<example />). These customizations are used to generate content and to interact with MediaWiki during page rendering.
Support a content model : By default, wiki pages can be stored using a few standard content models, such as wikitext and JSON. Extensions can provide support for new content models by adding a content handler.
Support a media type : Extensions can add to the default set of supported media file types by adding a media handler.

Moderation tools

Log a user or system action : On wiki, actions are tracked for transparency and collaboration. To support this feature, extensions can add custom entries and functionality to Special:Log.
Add a recent-changes flag : Extensions can add custom flags to the following special pages to help moderators track page changes: Special:RecentChanges, Special:Watchlist, Special:RecentChangesLinked
Add a revision tag : Extensions can add annotations associated with a revision or log entry, such as for edits made using the VisualEditor extension.

Authentication

Add a provider : Extensions can add support for new login mechanisms and session management methods.

डेटाबेस टेबल्स जोड़ना

सुनिश्चित करें कि एक्सटेंशन मूल डेटाबेस टेबलों को बदलता नहीं है। इस बजाय, एक्सटेंशन को प्रासंगिक MW टेबलों तक बाहरी कुँजियों वाले नए टेबल्स बनाने चाहिए।

चेतावनी:

अगर आपके एक्सटेंशन का इस्तेमाल WMF द्वारा होस्ट किए जाने वाले किसी विकि पर किया जा रहा है, कृपया स्केमा बदलाव गाइड का पालन करें।

अगर आपके एक्सटेंशन को अपने डेटाबेस टेबल्स जोड़ने की ज़रूरत है, LoadExtensionSchemaUpdates हुक का इस्तेमाल करें। उपयोग के बारे में अधिक जानकारी के लिए मैन्युअल पृष्ठ देखें।

Registering attributes for other extensions

Attributes allow extensions to register something, such as a module, with another extension. For example, extensions can use attributes to register a plugin module with the VisualEditor extension. For more information, see Extension registration .

स्थानीयकरण

Localisation – पर मीडियाविकि के स्थानीयकरण इंजन के बारे में चर्चा की गई है। विशिष्ट रूप से, स्थानीयकृत करने योग्य सुविधाओं की एक सूची, और स्थानीयकरण में शामिल मीडियाविकि स्रोत कोड के कुछ वर्गों का एक वर्णन है।
नए संदेश बनाना
Localization checks – पर स्थानीयकृत संदेशों की साधारण समस्याओं की एक चर्चा है
नामस्थान

विकसित करते समय आप $wgMainCacheType = CACHE_NONE और $wgCacheDirectory = false सेट करके कैशिंग अक्षम कर सकते हैं, वरना सिस्टम संदेश में बदलावों को दिखने में समय लग सकता है।

अगर आप चाहते हैं कि आपके एक्सटेंशन के इस्तेमाल उन विकियों पर किया जाए जो एकाधिक भाषाओं में उपलब्ध है, आपको अपने एक्सटेंशन पर स्थानीयकरण का समर्थन जोड़ना होगा।

<language-key>.json में संदेश रखें

एक स्थानीयकरण JSON फ़ाइल में संदेशों की परिभाषाएँ रखें, जहाँ हर भाषा कुँजी आपके एक्सटेंशन की एक अनुवादित भाषा को प्रतिनिधित करेगी। संदेशों को एक संदेश कुँजी और संदेश के साथ मानक JSON प्रारूप में रखा जाता है। हर संदेश छोटे अक्षरों में होना चाहिए और उनमें रिक्त स्थान नहीं होने चाहिए। हर कुँजी के नाम की शुरुआत छोटे अक्षरों में एक्सटेंशन के नाम से होनी चाहिए। एक उदाहरण आप [$url MobileFrontend एक्सटेंशन] में पा सकते हैं। यह रहा एक मिनिमल JSON फ़ाइल का उदाहरण (इस मामले में 'en.json'):

en.json

{
	"myextension-desc": "Adds the MyExtension great functionality.",
	"myextension-action-message": "This is a test message"
}

संदेश प्रलेख qqq.json में रखें

संदेश की कुँजियों के लिए प्रलेख qqq कोड वाली छद्म-भाषा के लिए JSON फ़ाइल में रखा जा सकता है। उपरोक्त उदाहरण का एक प्रलेख हो सकता है:

qqq.json:

{
	"myextension-desc": "The description of MyExtension used in Extension credits.",
	"myextension-action-message": "Adds 'message' after 'action' triggered by user."
}

स्थानीयकरण फ़ाइल लोड करें

अपने extension.json में अपनी संदेश फ़ाइलों का स्थान निर्दिष्ट करें (उदाहरणस्वरूप, i18n/ डिरेक्ट्री में):

{
	"MessagesDirs": {
		"MyExtension": [
			"i18n"
		]
	}
}

PHP में wfMessage का इस्तेमाल करें

अपने सेटअप और कार्यान्वयन कोड में संदेश के हर शाब्दिक उपयोग को wfMessage( $msgID, $param1, $param2, ... ) के एक कॉल से बदल दें। IContextSource (और SpecialPage के उपवर्गों जैसे कुछ अधिक) का इस्तेमाल करने वाले वर्गों पर आप $this->msg( $msgID, $param1, $param2, ... ) का इस्तेमाल कर सकते हैं। उदाहरण:

wfMessage( 'myextension-addition', '1', '2', '3' )->parse()

जावास्क्रिप्ट में mw.message का इस्तेमाल करें

जावास्क्रिप्ट में भी i18n फ़ंक्शन्स का इस्तेमाल किया जा सकता है। विस्तार के लिए Manual:Messages API देखें।

प्रकाशन

अपने मौजूदा एक्सटेंशन के प्रलेख को स्वतः श्रेणीबद्ध और मानकीकृत करने के लिए कृपया साँचा:Extension देखें। अपने नए एक्सटेंशन को इस विकि पर जोड़ने के लिए:

A developer sharing their code in the MediaWiki code repository should expect:

Feedback / Criticism / Code reviews: Review and comments by other developers on things like framework use, security, efficiency and usability.

Developer tweaking: Other developers modifying your submission to improve or clean-up your code to meet new framework classes and methods, coding conventions and translations.

Improved access for wiki sysadmins: If you do decide to put your code on the wiki, another developer may decide to move it to the MediaWiki code repository for easier maintenance. You may then create a विकासक खाता to continue maintaining it.

Future versions by other developers: New branches of your code being created automatically as new versions of MediaWiki are released. You should backport to these branches if you want to support older versions.; Incorporation of your code into other extensions with duplicate or similar purposes — incorporating the best features from each extension.

Credit: Credit for your work being preserved in future versions — including any merged extensions.; Similarly, you should credit the developers of any extensions whose code you borrow from — especially when performing a merger.

Any developer who is uncomfortable with any of these actions occurring should not host in the code repository. You are still encouraged to create a summary page for your extension on the wiki to let people know about the extension, and where to download it.

तैनात-कार्य और पंजीकरण

अगर आपका उद्देश्य है अपने एक्सटेंशन को विकिमीडिया साइटों (संभवतः विकिपीडिया समेत) में लागू करवाना, प्रदर्शन और सुरक्षा में अतिरिक्त सावधानी का आश्वासन ज़रूरी है। Writing an extension for deployment देखें।

अगर आपका एक्सटेंशन नामस्थान जोड़ता है, आपको इसके डिफ़ॉल्ट नामस्थानों को पंजीकृत कर देना चाहिए; उसी तरह, अगर यह डेटाबेस टेबल्स जोड़ता है, आपको उन्हें database field prefixes पर पंजीकृत कर देना चाहिए।

कृपया ध्यान रखें कि विकिमीडिया साइटों पर नए एक्सटेंशनों के निरीक्षण और तैनात-कार्य की प्रक्रिया काफ़ी धीमी हो सकती है, और कुछ मामलों में तो इसे दो से भी ज़्यादा वर्ष लग जाते हैं।^[4]

सहायता प्रलेख

आपको अपने एक्सटेंशन द्वारा प्रदत्त सुविधाओं के लिए एक सार्वजनिक डोमेन सहायता प्रलेख प्रदान करना चाहिए। The convention is for extensions to have their user-focused help pages under a pseudo-namespace of Help:Extension:<ExtensionName>, with whatever subpages are required (the top level page will be automatically linked from the extension infobox if it exists). एक अच्छा उदाहरण है Help:CirrusSearch । आपको addHelpLink() फ़ंक्शन की मदद से सदस्यों को प्रलेख की एक कड़ी देनी चाहिए।

Releasing updates

There are a number of common approaches to releasing updates to extensions. These are generally defined according to the compatibility policy of the extension (master, rel, or ltsrel):

master – Releases may be tagged with version numbers on the master branch, and documentation provided on the extension's homepage describing which extension versions are compatible with which core versions. Release branches will still be created automatically, and you may wish to delete these if they are not intended to be used.
rel और ltsrel – Release by backporting changes to the REL1_* branches (either all changes, or only critical ones). Version numbers are generally not needed unless the extension is a dependency of another (the version number can then be provided in the other extension's configuration to ensure that incompatible combinations aren't installed). Many extensions will stay at the same version number for years.

दूसरे मूल संस्करणों का समर्थन

मीडियाविकि मूल के पुराने संस्करणों को समर्थित करने की दो प्रचलित प्रथाएँ हैं:

Master: एक्सटेंशन की master शाखा, मूल जितने हो सके उतने पुराने संस्करणों से अनुकूल है। इससे अनुरक्षण पर ज़रा-सा बोझ पड़ता है (पीछे की तरफ अनुकूलता के लिए हैक्स काफ़ी लंबे समय तक रखने पड़ते हैं, और एक्सटेंशन में बदलावों को मीडियाविकि के कई पुराने संस्करणों पर परीक्षित करना पड़ता है), मगर मीडियाविकि के पुराने संस्करण चला रहे साइटों को एक्सटेंशन पर हाल में जोड़ी गई कार्यक्षमता से फ़ायदा हो सकता है।
प्रकाशन शाखाएँ: एक्सटेंशन की प्रकाशन शाखाएँ मूल की उचित शाखाओं से अनुकूल हैं, जैसे मीडियाविकि 1.43 का इस्तेमाल करने वाले साइटों को एक्सटेंशन की REL1_43 शाखा का इस्तेमाल करना होगा। (Gerrit पर होस्ट किए जाने वाले एक्सटेंशनों के लिए, ये शाखाएँ मीडियाविकि के नए संस्करणों के प्रकाशित किए जाने पर अपने आप बना दी जाती हैं।) इससे कोड साफ़-सुथरा रहता है और विकास की तेज़ी बढ़ जाती है, मगर पुराने मूल संस्करणों का इस्तेमाल करने वाले विकियों को बग-सुधारों और नई सुविधाओं से फ़ायदा नहीं होता अगर उन्हें सदस्यों द्वारा बैकपोर्ट न किया जाए।

एक्सटेंशनों के अनुरक्षकों को {{Extension }} साँचे के compatibility policy पैरामीटर से यह घोषित कर देना चाहिए कि वे किस प्रथा का पालन करते हैं।

सहायता / सहयोग प्रदान करना

एक्सटेंशन के विकासकों को विकिमीडिया के Phabricator पर एक खाता बनाना चाहिए, और एक्सटेंशन के लिए एक नई परियोजना का अनुरोध करना चाहिए। यह एक सार्वजनिक मंच प्रदान करेगा जहाँ सदस्य समस्याएँ और सुझाव प्रस्तुत कर पाएँगे, और आप सदस्यों और विकासकों के साथ मिलकर बग्स ठीक कर सकते हैं और अपने एक्सटेंशन के लिए सुविधाओं की योजनाएँ बना सकते हैं।

ये भी देखें

Manual:Extension registration – provides further developer documentation on how to register extensions and skins.
API:Extensions – बताता है कि आपका एक्सटेंशन क्लाइंट्स को API कैसे प्रदान कर सकता है
Manual:Extending wiki markup
Manual:Coding conventions
एक्सटेंशनों के लिए सर्वोत्तम प्रथाएँ
ResourceLoader

Learn by example

Extension:Examples – विस्तृत इनलाइन प्रलेख के साथ कुछ उदाहरण सुविधाएँ लागू करता है
- इस और दूसरे उदाहरण वाला examples गिट रिपॉज़िटरी
Extension:BoilerPlate – एक काम करने वाला बॉइलरप्लेट एक्सटेंशन, जिसे आप अपने एक्सटेंशन के लिए शुरुआत का एक स्थान मानकर चल सकते हैं (गिट रिपॉज़िटरी)
- Example एक्सटेंशन पढ़ें, और अपने कोड को BoilerPlate एक्सटेंशन पर आधारित करें।
cookiecutter-mediawiki-extension – एक cookiecutter साँचा जो एक बॉइलरप्लेट एक्सटेंशन बनाता है (वेरिएबलों आदि के साथ)
- इससे आप तुरंत अपना एक्सटेंशन बनाना शुरू कर सकते हैं।
- BoilerPlate एक्सटेंशन भी बना सकता है।
List of simple extensions - उनसे विशिष्ट कोड की प्रतिलिपि बनाएँ

सन्दर्भ

[1] rchive:wikitech-l/2011-August/054839.html

[2] ttps://www.mediawiki.org/wiki/Project%3ASupport%20desk/Flow/2024/02#h-%5BDeveloper_question%5D_ExtensionRegistry%3A%3AgetInstance%28%29-%3EisLoaded%28_%27OpenIDConnect%27-20240204084500

[3] ttps://phabricator.wikimedia.org/T356596

[4] ricator:T148848

[1]

[2]

[3]

[4]