mediawiki-extensions-Gadgets/includes/GadgetRepo.php

120 lines
2.9 KiB
PHP
Raw Normal View History

<?php
namespace MediaWiki\Extension\Gadgets;
use InvalidArgumentException;
use MediaWiki\Linker\LinkTarget;
use Title;
abstract class GadgetRepo {
/**
* @var GadgetRepo|null
*/
private static $instance;
/**
* @var string
*/
protected $titlePrefix;
/**
* Get the ids of the gadgets provided by this repository
*
* It's possible this could be out of sync with what
* getGadget() will return due to caching
*
* @return string[]
*/
abstract public function getGadgetIds(): array;
/**
* Get the Gadget object for a given gadget ID
*
* @param string $id
* @return Gadget
* @throws InvalidArgumentException For unregistered ID, used by getStructuredList()
*/
abstract public function getGadget( string $id ): Gadget;
/**
GadgetRepo: Fix missing purging on delete and simplify hook handling == Motivation == On a local dev wiki and in CI, where no gadgets are defined yet, fetchStructuredList() is called on every load.php request and doing uncached database look ups. This is because T39228 (stale cache after Gadgets-definition was empty or created) was fixed by disabling the cache until the page exists. This seems like a poor solution, and commit I3092bcb162d032 recognises that the problem was not understood at the time. I propose to instead cache it always and purge it when the page is modified in any way. Cold calling fetchStructuredList() accounted for ~170ms of ~400ms when trying out debug v2 (T85805), thus making it significantly slower and causing a chain of dozens of requests to pile up. == Previously == * Legacy repo (MediaWikiGadgetsDefinitionRepo) only implemented handlePageUpdate. * handlePageUpdate was called from onPageSaveComplete for both any page edit, and for creations in the experimental namespace. * The experimental GadgetDefinitionNamespaceRepo is based on ContentHandler rather than global hooks. This system does not have a create-specific callback. It called update for edit/create, and delete for delete. The experimental repo relied on create being called from the global hook for the legacy repo, and update was then called twice. * There was no global hook for onPageDeleteComplete, thus the legacy repo did not get purges. == Changes == * Add onPageDeleteComplete hook to fix purges after deletion, with the legacy repo now implementing handlePageDeletion() and doing the same as handlePageUpdate(). * Fix handlePageUpdate() docs to reflect that it covers page create, since onPageSaveComplete() called it either way. * Fix experimental repo to include its namespace purge in its handlePageUpdate() method. * Get rid of now-redundant handlePageCreation(). * Get rid of handlePageDeletion() since its implementations would now be identical to handlePageUpdate(). All these hooks and handle*() methods are just for a memc key holding gadget metadata. We don't need to microoptimise this on a per-page basis. Gadget edits are rare enough that purging them as a whole each time is fine. We do the same in MediaWiki core with ResourceLoaderGadgetsModule already. Bug: T85805 Change-Id: Ib27fd34fbfe7a75c851602c8a93a2e3e1f2c38a0
2022-04-05 18:10:38 +00:00
* Invalidate any caches based on the provided page (after create, edit, or delete).
*
GadgetRepo: Fix missing purging on delete and simplify hook handling == Motivation == On a local dev wiki and in CI, where no gadgets are defined yet, fetchStructuredList() is called on every load.php request and doing uncached database look ups. This is because T39228 (stale cache after Gadgets-definition was empty or created) was fixed by disabling the cache until the page exists. This seems like a poor solution, and commit I3092bcb162d032 recognises that the problem was not understood at the time. I propose to instead cache it always and purge it when the page is modified in any way. Cold calling fetchStructuredList() accounted for ~170ms of ~400ms when trying out debug v2 (T85805), thus making it significantly slower and causing a chain of dozens of requests to pile up. == Previously == * Legacy repo (MediaWikiGadgetsDefinitionRepo) only implemented handlePageUpdate. * handlePageUpdate was called from onPageSaveComplete for both any page edit, and for creations in the experimental namespace. * The experimental GadgetDefinitionNamespaceRepo is based on ContentHandler rather than global hooks. This system does not have a create-specific callback. It called update for edit/create, and delete for delete. The experimental repo relied on create being called from the global hook for the legacy repo, and update was then called twice. * There was no global hook for onPageDeleteComplete, thus the legacy repo did not get purges. == Changes == * Add onPageDeleteComplete hook to fix purges after deletion, with the legacy repo now implementing handlePageDeletion() and doing the same as handlePageUpdate(). * Fix handlePageUpdate() docs to reflect that it covers page create, since onPageSaveComplete() called it either way. * Fix experimental repo to include its namespace purge in its handlePageUpdate() method. * Get rid of now-redundant handlePageCreation(). * Get rid of handlePageDeletion() since its implementations would now be identical to handlePageUpdate(). All these hooks and handle*() methods are just for a memc key holding gadget metadata. We don't need to microoptimise this on a per-page basis. Gadget edits are rare enough that purging them as a whole each time is fine. We do the same in MediaWiki core with ResourceLoaderGadgetsModule already. Bug: T85805 Change-Id: Ib27fd34fbfe7a75c851602c8a93a2e3e1f2c38a0
2022-04-05 18:10:38 +00:00
* This must be called on create and delete as well (T39228).
*
* @param LinkTarget $target
* @return void
*/
GadgetRepo: Fix missing purging on delete and simplify hook handling == Motivation == On a local dev wiki and in CI, where no gadgets are defined yet, fetchStructuredList() is called on every load.php request and doing uncached database look ups. This is because T39228 (stale cache after Gadgets-definition was empty or created) was fixed by disabling the cache until the page exists. This seems like a poor solution, and commit I3092bcb162d032 recognises that the problem was not understood at the time. I propose to instead cache it always and purge it when the page is modified in any way. Cold calling fetchStructuredList() accounted for ~170ms of ~400ms when trying out debug v2 (T85805), thus making it significantly slower and causing a chain of dozens of requests to pile up. == Previously == * Legacy repo (MediaWikiGadgetsDefinitionRepo) only implemented handlePageUpdate. * handlePageUpdate was called from onPageSaveComplete for both any page edit, and for creations in the experimental namespace. * The experimental GadgetDefinitionNamespaceRepo is based on ContentHandler rather than global hooks. This system does not have a create-specific callback. It called update for edit/create, and delete for delete. The experimental repo relied on create being called from the global hook for the legacy repo, and update was then called twice. * There was no global hook for onPageDeleteComplete, thus the legacy repo did not get purges. == Changes == * Add onPageDeleteComplete hook to fix purges after deletion, with the legacy repo now implementing handlePageDeletion() and doing the same as handlePageUpdate(). * Fix handlePageUpdate() docs to reflect that it covers page create, since onPageSaveComplete() called it either way. * Fix experimental repo to include its namespace purge in its handlePageUpdate() method. * Get rid of now-redundant handlePageCreation(). * Get rid of handlePageDeletion() since its implementations would now be identical to handlePageUpdate(). All these hooks and handle*() methods are just for a memc key holding gadget metadata. We don't need to microoptimise this on a per-page basis. Gadget edits are rare enough that purging them as a whole each time is fine. We do the same in MediaWiki core with ResourceLoaderGadgetsModule already. Bug: T85805 Change-Id: Ib27fd34fbfe7a75c851602c8a93a2e3e1f2c38a0
2022-04-05 18:10:38 +00:00
public function handlePageUpdate( LinkTarget $target ): void {
}
/**
* Given a gadget ID, return the title of the page where the gadget is
* defined (or null if the given repo does not have per-gadget definition
* pages).
*
* @param string $id
* @return Title|null
*/
public function getGadgetDefinitionTitle( string $id ): ?Title {
return null;
}
/**
* Get a lists of Gadget objects by category
*
* @return array<string,Gadget[]> `[ 'category' => [ 'name' => $gadget ] ]`
*/
public function getStructuredList() {
$list = [];
foreach ( $this->getGadgetIds() as $id ) {
try {
$gadget = $this->getGadget( $id );
} catch ( InvalidArgumentException $e ) {
continue;
}
$list[$gadget->getCategory()][$gadget->getName()] = $gadget;
}
return $list;
}
/**
* Get the script file name without the "MediaWiki:Gadget-" or "Gadget:" prefix.
* This name is used by the client-side require() so that require("Data.json") resolves
* to either "MediaWiki:Gadget-Data.json" or "Gadget:Data.json" depending on the
* $wgGadgetsRepoClass configuration, enabling easy migration between the configuration modes.
*
* @param string $titleText
* @return string
*/
public function titleWithoutPrefix( string $titleText ): string {
$numReplaces = 1; // there will only one occurrence of the prefix
return str_replace( $this->titlePrefix, '', $titleText, $numReplaces );
}
/**
* Get the configured default GadgetRepo.
*
* @return GadgetRepo
*/
public static function singleton() {
if ( self::$instance === null ) {
// @todo use Config here
global $wgGadgetsRepoClass;
// @phan-suppress-next-line PhanPossiblyUndeclaredVariable
self::$instance = new $wgGadgetsRepoClass();
}
return self::$instance;
}
/**
* Should only be used by unit tests
*
* @param GadgetRepo|null $repo
*/
public static function setSingleton( $repo = null ) {
self::$instance = $repo;
}
}