mediawiki-extensions-Gadgets/tests/phpunit/integration/MediaWikiGadgetsJsonRepoTest.php

41 lines
1.4 KiB
PHP
Raw Normal View History

Goodbye Gadget/Gadget_definition namespaces! == What == * Remove the empty Gadget and Gadget_definition namespaces. * Remove the "gadgets-definition-edit" user right. * Remove need for custom namespace permissions that previously had to extend editsitejs to apply to NS_GADGET. == Why == Simplify the (unused) "GadgetDefinitionNamespaceRepo" backend for Gadgets 2.0 by making it less radically different from the status quo. The experimental 2.0 branch will now make use of the "gadget definition" content model via "MediaWiki:Gadgets/<id>.json" pages, instead of through a dedicated namespace. When I first worked the Gadgets 2.0 branch, content models were not a thing in MediaWiki, and interface-admin wasn't a thing yet either. Now that we have per-page permissions and per-page content models, we don't really need a separate namespace. This follows the principle of least surprise, and fits well with other interface admin and site configuration tools such as: - Citoid, MediaWiki:Citoid-template-type-map.json, - VisualEditor, MediaWiki:Visualeditor-template-tools-definition.json, - AbuseFilter, MediaWiki:BlockedExternalDomains.json, - the upcoming "Community Config" initiative. If/when we develop the SpecialPage GUI for editing gadget definitions, this can save its data to these pages the same as it would in any other namespace. Similar to how Special:BlockedExternalDomains operates on MediaWiki:BlockedExternalDomains.json. See also bf1d6b3e93 (I6ffd5e9467), which recently removed the gadgets-edit user right in favour of the editsite{css,js,json} rights. Change-Id: I5b04ab251552e839087d0a8a6923d205adc7f771
2023-12-05 23:28:45 +00:00
<?php
use MediaWiki\Extension\Gadgets\MediaWikiGadgetsJsonRepo;
/**
* @covers \MediaWiki\Extension\Gadgets\MediaWikiGadgetsJsonRepo
* @group Gadgets
* @group Database
*/
class MediaWikiGadgetsJsonRepoTest extends MediaWikiIntegrationTestCase {
public function testGetGadget() {
$this->editPage( 'MediaWiki:Gadgets/test.json',
'{"module":{"pages":["test.js"]}, "settings":{"default":true}}' );
$services = $this->getServiceContainer();
$repo = new MediaWikiGadgetsJsonRepo(
$services->getConnectionProvider(),
$services->getMainWANObjectCache(),
$services->getRevisionLookup()
);
Goodbye Gadget/Gadget_definition namespaces! == What == * Remove the empty Gadget and Gadget_definition namespaces. * Remove the "gadgets-definition-edit" user right. * Remove need for custom namespace permissions that previously had to extend editsitejs to apply to NS_GADGET. == Why == Simplify the (unused) "GadgetDefinitionNamespaceRepo" backend for Gadgets 2.0 by making it less radically different from the status quo. The experimental 2.0 branch will now make use of the "gadget definition" content model via "MediaWiki:Gadgets/<id>.json" pages, instead of through a dedicated namespace. When I first worked the Gadgets 2.0 branch, content models were not a thing in MediaWiki, and interface-admin wasn't a thing yet either. Now that we have per-page permissions and per-page content models, we don't really need a separate namespace. This follows the principle of least surprise, and fits well with other interface admin and site configuration tools such as: - Citoid, MediaWiki:Citoid-template-type-map.json, - VisualEditor, MediaWiki:Visualeditor-template-tools-definition.json, - AbuseFilter, MediaWiki:BlockedExternalDomains.json, - the upcoming "Community Config" initiative. If/when we develop the SpecialPage GUI for editing gadget definitions, this can save its data to these pages the same as it would in any other namespace. Similar to how Special:BlockedExternalDomains operates on MediaWiki:BlockedExternalDomains.json. See also bf1d6b3e93 (I6ffd5e9467), which recently removed the gadgets-edit user right in favour of the editsite{css,js,json} rights. Change-Id: I5b04ab251552e839087d0a8a6923d205adc7f771
2023-12-05 23:28:45 +00:00
$gadget = $repo->getGadget( 'test' );
$this->assertTrue( $gadget->isOnByDefault() );
$this->assertArrayEquals( [ "MediaWiki:Gadget-test.js" ], $gadget->getScripts() );
}
public function testGetGadgetIds() {
$this->editPage( 'MediaWiki:Gadgets/X1.json',
'{"module":{"pages":["MediaWiki:Gadget-test.js"]}, "settings":{"default":true}}' );
$this->editPage( 'MediaWiki:Gadgets/X2.json',
'{"module":{"pages":["MediaWiki:Gadget-test.js"]}, "settings":{"default":true}}' );
$services = $this->getServiceContainer();
$dbProvider = $services->getConnectionProvider();
Goodbye Gadget/Gadget_definition namespaces! == What == * Remove the empty Gadget and Gadget_definition namespaces. * Remove the "gadgets-definition-edit" user right. * Remove need for custom namespace permissions that previously had to extend editsitejs to apply to NS_GADGET. == Why == Simplify the (unused) "GadgetDefinitionNamespaceRepo" backend for Gadgets 2.0 by making it less radically different from the status quo. The experimental 2.0 branch will now make use of the "gadget definition" content model via "MediaWiki:Gadgets/<id>.json" pages, instead of through a dedicated namespace. When I first worked the Gadgets 2.0 branch, content models were not a thing in MediaWiki, and interface-admin wasn't a thing yet either. Now that we have per-page permissions and per-page content models, we don't really need a separate namespace. This follows the principle of least surprise, and fits well with other interface admin and site configuration tools such as: - Citoid, MediaWiki:Citoid-template-type-map.json, - VisualEditor, MediaWiki:Visualeditor-template-tools-definition.json, - AbuseFilter, MediaWiki:BlockedExternalDomains.json, - the upcoming "Community Config" initiative. If/when we develop the SpecialPage GUI for editing gadget definitions, this can save its data to these pages the same as it would in any other namespace. Similar to how Special:BlockedExternalDomains operates on MediaWiki:BlockedExternalDomains.json. See also bf1d6b3e93 (I6ffd5e9467), which recently removed the gadgets-edit user right in favour of the editsite{css,js,json} rights. Change-Id: I5b04ab251552e839087d0a8a6923d205adc7f771
2023-12-05 23:28:45 +00:00
$wanCache = $services->getMainWANObjectCache();
$repo = new MediaWikiGadgetsJsonRepo( $dbProvider, $wanCache, $services->getRevisionLookup() );
Goodbye Gadget/Gadget_definition namespaces! == What == * Remove the empty Gadget and Gadget_definition namespaces. * Remove the "gadgets-definition-edit" user right. * Remove need for custom namespace permissions that previously had to extend editsitejs to apply to NS_GADGET. == Why == Simplify the (unused) "GadgetDefinitionNamespaceRepo" backend for Gadgets 2.0 by making it less radically different from the status quo. The experimental 2.0 branch will now make use of the "gadget definition" content model via "MediaWiki:Gadgets/<id>.json" pages, instead of through a dedicated namespace. When I first worked the Gadgets 2.0 branch, content models were not a thing in MediaWiki, and interface-admin wasn't a thing yet either. Now that we have per-page permissions and per-page content models, we don't really need a separate namespace. This follows the principle of least surprise, and fits well with other interface admin and site configuration tools such as: - Citoid, MediaWiki:Citoid-template-type-map.json, - VisualEditor, MediaWiki:Visualeditor-template-tools-definition.json, - AbuseFilter, MediaWiki:BlockedExternalDomains.json, - the upcoming "Community Config" initiative. If/when we develop the SpecialPage GUI for editing gadget definitions, this can save its data to these pages the same as it would in any other namespace. Similar to how Special:BlockedExternalDomains operates on MediaWiki:BlockedExternalDomains.json. See also bf1d6b3e93 (I6ffd5e9467), which recently removed the gadgets-edit user right in favour of the editsite{css,js,json} rights. Change-Id: I5b04ab251552e839087d0a8a6923d205adc7f771
2023-12-05 23:28:45 +00:00
$wanCache->clearProcessCache();
$this->assertArrayEquals( [ 'X1', 'X2' ], $repo->getGadgetIds() );
}
}