2013-08-29 23:32:32 +00:00
|
|
|
<?php
|
|
|
|
/**
|
|
|
|
* Copyright © 2007 Daniel Kinzler
|
|
|
|
*
|
|
|
|
* This program is free software; you can redistribute it and/or modify
|
|
|
|
* it under the terms of the GNU General Public License as published by
|
|
|
|
* the Free Software Foundation; either version 2 of the License, or
|
|
|
|
* (at your option) any later version.
|
|
|
|
*
|
|
|
|
* This program is distributed in the hope that it will be useful,
|
|
|
|
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
* GNU General Public License for more details.
|
|
|
|
*
|
|
|
|
* You should have received a copy of the GNU General Public License along
|
|
|
|
* with this program; if not, write to the Free Software Foundation, Inc.,
|
|
|
|
* 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
|
|
|
|
* http://www.gnu.org/copyleft/gpl.html
|
|
|
|
*
|
|
|
|
* @file
|
|
|
|
*/
|
2022-02-06 18:54:47 +00:00
|
|
|
|
2023-10-25 22:32:58 +00:00
|
|
|
namespace MediaWiki\Extension\Gadgets;
|
|
|
|
|
2022-08-27 14:04:31 +00:00
|
|
|
use ApiMessage;
|
2022-02-06 18:54:47 +00:00
|
|
|
use Content;
|
|
|
|
use Exception;
|
|
|
|
use HTMLForm;
|
|
|
|
use IContextSource;
|
|
|
|
use InvalidArgumentException;
|
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
|
|
|
use ManualLogEntry;
|
2022-02-06 18:54:47 +00:00
|
|
|
use MediaWiki\Extension\Gadgets\Content\GadgetDefinitionContent;
|
2023-10-30 15:36:33 +00:00
|
|
|
use MediaWiki\Extension\Gadgets\Special\SpecialGadgetUsage;
|
2021-12-06 10:34:17 +00:00
|
|
|
use MediaWiki\Hook\BeforePageDisplayHook;
|
|
|
|
use MediaWiki\Hook\DeleteUnknownPreferencesHook;
|
|
|
|
use MediaWiki\Hook\EditFilterMergedContentHook;
|
2022-10-14 01:27:45 +00:00
|
|
|
use MediaWiki\Hook\PreferencesGetIconHook;
|
2021-12-06 10:34:17 +00:00
|
|
|
use MediaWiki\Hook\PreferencesGetLegendHook;
|
2023-09-07 13:42:23 +00:00
|
|
|
use MediaWiki\Html\Html;
|
2021-12-06 10:34:17 +00:00
|
|
|
use MediaWiki\Page\Hook\PageDeleteCompleteHook;
|
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
|
|
|
use MediaWiki\Page\ProperPageIdentity;
|
|
|
|
use MediaWiki\Permissions\Authority;
|
2022-08-27 14:04:31 +00:00
|
|
|
use MediaWiki\Permissions\Hook\GetUserPermissionsErrorsHook;
|
2021-12-06 10:34:17 +00:00
|
|
|
use MediaWiki\Preferences\Hook\GetPreferencesHook;
|
|
|
|
use MediaWiki\ResourceLoader\Hook\ResourceLoaderRegisterModulesHook;
|
2022-05-28 00:52:36 +00:00
|
|
|
use MediaWiki\ResourceLoader\ResourceLoader;
|
2021-12-06 10:34:17 +00:00
|
|
|
use MediaWiki\Revision\Hook\ContentHandlerDefaultModelForHook;
|
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
|
|
|
use MediaWiki\Revision\RevisionRecord;
|
2021-12-06 10:34:17 +00:00
|
|
|
use MediaWiki\SpecialPage\Hook\WgQueryPagesHook;
|
|
|
|
use MediaWiki\Storage\Hook\PageSaveCompleteHook;
|
2023-08-19 04:15:51 +00:00
|
|
|
use MediaWiki\Title\Title;
|
2021-12-06 10:34:17 +00:00
|
|
|
use MediaWiki\User\Hook\UserGetDefaultOptionsHook;
|
2023-12-05 18:00:37 +00:00
|
|
|
use MediaWiki\User\UserOptionsLookup;
|
2022-08-27 14:04:31 +00:00
|
|
|
use MessageSpecifier;
|
2023-12-05 18:00:37 +00:00
|
|
|
use MobileContext;
|
2022-02-06 18:54:47 +00:00
|
|
|
use OOUI\HtmlSnippet;
|
|
|
|
use OutputPage;
|
|
|
|
use RequestContext;
|
2021-12-06 10:34:17 +00:00
|
|
|
use Skin;
|
2022-02-06 18:54:47 +00:00
|
|
|
use SpecialPage;
|
|
|
|
use Status;
|
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
|
|
|
use TitleValue;
|
2022-02-06 18:54:47 +00:00
|
|
|
use User;
|
2018-04-06 00:18:46 +00:00
|
|
|
use Wikimedia\Rdbms\IDatabase;
|
2018-01-21 04:44:06 +00:00
|
|
|
use Wikimedia\WrappedString;
|
2022-02-06 18:54:47 +00:00
|
|
|
use WikiPage;
|
|
|
|
use Xml;
|
2013-08-29 23:32:32 +00:00
|
|
|
|
2021-12-06 10:34:17 +00:00
|
|
|
class Hooks implements
|
|
|
|
PageDeleteCompleteHook,
|
|
|
|
PageSaveCompleteHook,
|
|
|
|
UserGetDefaultOptionsHook,
|
|
|
|
GetPreferencesHook,
|
2022-10-14 01:27:45 +00:00
|
|
|
PreferencesGetIconHook,
|
2021-12-06 10:34:17 +00:00
|
|
|
PreferencesGetLegendHook,
|
|
|
|
ResourceLoaderRegisterModulesHook,
|
|
|
|
BeforePageDisplayHook,
|
|
|
|
EditFilterMergedContentHook,
|
|
|
|
ContentHandlerDefaultModelForHook,
|
|
|
|
WgQueryPagesHook,
|
2022-08-27 14:04:31 +00:00
|
|
|
DeleteUnknownPreferencesHook,
|
|
|
|
GetUserPermissionsErrorsHook
|
2021-12-06 10:34:17 +00:00
|
|
|
{
|
2022-08-16 15:24:01 +00:00
|
|
|
private GadgetRepo $gadgetRepo;
|
2023-12-05 18:00:37 +00:00
|
|
|
private UserOptionsLookup $userOptionsLookup;
|
|
|
|
/** @phan-suppress-next-line PhanUndeclaredTypeProperty */
|
|
|
|
private ?MobileContext $mobileContext;
|
2022-08-16 15:24:01 +00:00
|
|
|
|
2023-12-05 18:00:37 +00:00
|
|
|
public function __construct(
|
|
|
|
GadgetRepo $gadgetRepo,
|
|
|
|
UserOptionsLookup $userOptionsLookup,
|
|
|
|
// @phan-suppress-next-line PhanUndeclaredTypeParameter
|
|
|
|
?MobileContext $mobileContext
|
|
|
|
) {
|
2022-08-16 15:24:01 +00:00
|
|
|
$this->gadgetRepo = $gadgetRepo;
|
2023-12-05 18:00:37 +00:00
|
|
|
$this->userOptionsLookup = $userOptionsLookup;
|
|
|
|
$this->mobileContext = $mobileContext;
|
2022-08-16 15:24:01 +00:00
|
|
|
}
|
|
|
|
|
2020-06-25 17:10:43 +00:00
|
|
|
/**
|
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
|
|
|
* Handle MediaWiki\Page\Hook\PageSaveCompleteHook
|
2020-06-25 17:10:43 +00:00
|
|
|
*
|
|
|
|
* @param WikiPage $wikiPage
|
|
|
|
* @param mixed $userIdentity unused
|
|
|
|
* @param string $summary
|
|
|
|
* @param int $flags
|
|
|
|
* @param mixed $revisionRecord unused
|
|
|
|
* @param mixed $editResult unused
|
|
|
|
*/
|
2021-12-06 10:34:17 +00:00
|
|
|
public function onPageSaveComplete(
|
|
|
|
$wikiPage,
|
2020-06-25 17:10:43 +00:00
|
|
|
$userIdentity,
|
2021-12-06 10:34:17 +00:00
|
|
|
$summary,
|
|
|
|
$flags,
|
2020-06-25 17:10:43 +00:00
|
|
|
$revisionRecord,
|
|
|
|
$editResult
|
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
|
|
|
): void {
|
2020-06-25 17:10:43 +00:00
|
|
|
$title = $wikiPage->getTitle();
|
2022-08-16 15:24:01 +00:00
|
|
|
$this->gadgetRepo->handlePageUpdate( $title );
|
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
|
|
|
}
|
2020-06-25 17:10:43 +00:00
|
|
|
|
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
|
|
|
/**
|
|
|
|
* Handle MediaWiki\Page\Hook\PageDeleteCompleteHook
|
|
|
|
*
|
|
|
|
* @param ProperPageIdentity $page
|
|
|
|
* @param Authority $deleter
|
|
|
|
* @param string $reason
|
|
|
|
* @param int $pageID
|
|
|
|
* @param RevisionRecord $deletedRev Last revision
|
|
|
|
* @param ManualLogEntry $logEntry
|
|
|
|
* @param int $archivedRevisionCount Number of revisions deleted
|
|
|
|
*/
|
2021-12-06 10:34:17 +00:00
|
|
|
public function onPageDeleteComplete(
|
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
|
|
|
ProperPageIdentity $page,
|
|
|
|
Authority $deleter,
|
|
|
|
string $reason,
|
|
|
|
int $pageID,
|
|
|
|
RevisionRecord $deletedRev,
|
|
|
|
ManualLogEntry $logEntry,
|
|
|
|
int $archivedRevisionCount
|
|
|
|
): void {
|
|
|
|
$title = TitleValue::newFromPage( $page );
|
2022-08-16 15:24:01 +00:00
|
|
|
$this->gadgetRepo->handlePageUpdate( $title );
|
2020-06-25 17:10:43 +00:00
|
|
|
}
|
|
|
|
|
2013-08-29 23:32:32 +00:00
|
|
|
/**
|
|
|
|
* UserGetDefaultOptions hook handler
|
2017-08-27 14:07:08 +00:00
|
|
|
* @param array &$defaultOptions Array of default preference keys and values
|
2013-08-29 23:32:32 +00:00
|
|
|
*/
|
2021-12-06 10:34:17 +00:00
|
|
|
public function onUserGetDefaultOptions( &$defaultOptions ) {
|
2022-08-16 15:24:01 +00:00
|
|
|
$gadgets = $this->gadgetRepo->getStructuredList();
|
2013-08-29 23:32:32 +00:00
|
|
|
if ( !$gadgets ) {
|
2019-07-22 08:13:58 +00:00
|
|
|
return;
|
2013-08-29 23:32:32 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* @var $gadget Gadget
|
|
|
|
*/
|
|
|
|
foreach ( $gadgets as $thisSection ) {
|
|
|
|
foreach ( $thisSection as $gadgetId => $gadget ) {
|
2022-01-12 17:19:58 +00:00
|
|
|
// Hidden gadgets don't need to be added here, T299071
|
|
|
|
if ( !$gadget->isHidden() ) {
|
|
|
|
$defaultOptions['gadget-' . $gadgetId] = $gadget->isOnByDefault() ? 1 : 0;
|
|
|
|
}
|
2013-08-29 23:32:32 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2023-06-29 00:57:04 +00:00
|
|
|
/**
|
|
|
|
* Check whether the gadget should load on the mobile domain based on its definition.
|
|
|
|
*
|
|
|
|
* @return bool
|
|
|
|
*/
|
2023-12-05 18:00:37 +00:00
|
|
|
private function isMobileView(): bool {
|
|
|
|
// @phan-suppress-next-line PhanUndeclaredClassMethod
|
|
|
|
return $this->mobileContext && $this->mobileContext->shouldDisplayMobileView();
|
2023-06-29 00:57:04 +00:00
|
|
|
}
|
|
|
|
|
2013-08-29 23:32:32 +00:00
|
|
|
/**
|
|
|
|
* GetPreferences hook handler.
|
2017-08-27 14:07:08 +00:00
|
|
|
* @param User $user
|
|
|
|
* @param array &$preferences Preference descriptions
|
2013-08-29 23:32:32 +00:00
|
|
|
*/
|
2021-12-06 10:34:17 +00:00
|
|
|
public function onGetPreferences( $user, &$preferences ) {
|
2022-08-16 15:24:01 +00:00
|
|
|
$gadgets = $this->gadgetRepo->getStructuredList();
|
2013-08-29 23:32:32 +00:00
|
|
|
if ( !$gadgets ) {
|
2019-07-22 08:13:58 +00:00
|
|
|
return;
|
2013-08-29 23:32:32 +00:00
|
|
|
}
|
|
|
|
|
2021-11-05 22:12:36 +00:00
|
|
|
$preferences['gadgets-intro'] = [
|
|
|
|
'type' => 'info',
|
|
|
|
'default' => wfMessage( 'gadgets-prefstext' )->parseAsBlock(),
|
|
|
|
'section' => 'gadgets',
|
|
|
|
'raw' => true,
|
|
|
|
];
|
|
|
|
|
2023-12-05 18:00:37 +00:00
|
|
|
$safeMode = $this->userOptionsLookup->getOption( $user, 'forcesafemode' );
|
2023-09-07 13:42:23 +00:00
|
|
|
if ( $safeMode ) {
|
|
|
|
$preferences['gadgets-safemode'] = [
|
|
|
|
'type' => 'info',
|
|
|
|
'default' => Html::warningBox( wfMessage( 'gadgets-prefstext-safemode' )->parse() ),
|
|
|
|
'section' => 'gadgets',
|
|
|
|
'raw' => true,
|
|
|
|
];
|
|
|
|
}
|
|
|
|
|
2016-07-20 06:27:26 +00:00
|
|
|
$skin = RequestContext::getMain()->getSkin();
|
2023-12-05 18:00:37 +00:00
|
|
|
$isMobileView = $this->isMobileView();
|
2013-08-29 23:32:32 +00:00
|
|
|
foreach ( $gadgets as $section => $thisSection ) {
|
|
|
|
foreach ( $thisSection as $gadget ) {
|
2023-09-06 10:46:06 +00:00
|
|
|
// Only show option to enable gadget if it can be enabled
|
|
|
|
$type = 'api';
|
2016-07-20 06:27:26 +00:00
|
|
|
if (
|
2023-09-07 13:42:23 +00:00
|
|
|
!$safeMode
|
|
|
|
&& !$gadget->isHidden()
|
2016-07-20 06:27:26 +00:00
|
|
|
&& $gadget->isAllowed( $user )
|
2023-06-29 00:57:04 +00:00
|
|
|
&& $gadget->isTargetSupported( $isMobileView )
|
2016-07-20 06:27:26 +00:00
|
|
|
&& $gadget->isSkinSupported( $skin )
|
|
|
|
) {
|
2023-09-06 10:46:06 +00:00
|
|
|
$type = 'check';
|
2021-11-05 22:12:36 +00:00
|
|
|
}
|
2023-09-06 10:46:06 +00:00
|
|
|
$gname = $gadget->getName();
|
|
|
|
$sectionLabelMsg = "gadget-section-$section";
|
|
|
|
|
|
|
|
$preferences["gadget-$gname"] = [
|
|
|
|
'type' => $type,
|
|
|
|
'label-message' => $gadget->getDescriptionMessageKey(),
|
|
|
|
'section' => $section !== '' ? "gadgets/$sectionLabelMsg" : 'gadgets',
|
|
|
|
'default' => $gadget->isEnabled( $user ),
|
|
|
|
'noglobal' => true,
|
|
|
|
];
|
2021-10-07 19:52:18 +00:00
|
|
|
}
|
2021-09-29 12:53:39 +00:00
|
|
|
}
|
2021-11-05 22:12:36 +00:00
|
|
|
}
|
2021-10-07 19:52:18 +00:00
|
|
|
|
2021-11-05 22:12:36 +00:00
|
|
|
/**
|
|
|
|
* PreferencesGetLegend hook handler.
|
|
|
|
*
|
|
|
|
* Used to override the subsection heading labels for the gadget groups. The default message would
|
|
|
|
* be "prefs-$key", but we've previously used different messages, and they have on-wiki overrides
|
|
|
|
* that would have to be moved if the message keys changed.
|
|
|
|
*
|
|
|
|
* @param HTMLForm $form the HTMLForm object. This is a ContextSource as well
|
|
|
|
* @param string $key the section name
|
|
|
|
* @param string &$legend the legend text. Defaults to wfMessage( "prefs-$key" )->text() but may
|
|
|
|
* be overridden
|
|
|
|
* @return bool|void True or no return value to continue or false to abort
|
|
|
|
*/
|
2021-12-06 10:34:17 +00:00
|
|
|
public function onPreferencesGetLegend( $form, $key, &$legend ) {
|
2021-11-05 22:12:36 +00:00
|
|
|
if ( str_starts_with( $key, 'gadget-section-' ) ) {
|
2022-02-06 18:54:47 +00:00
|
|
|
$legend = new HtmlSnippet( $form->msg( $key )->parse() );
|
2021-11-05 22:12:36 +00:00
|
|
|
}
|
2013-08-29 23:32:32 +00:00
|
|
|
}
|
|
|
|
|
2022-10-14 01:27:45 +00:00
|
|
|
/**
|
|
|
|
* Add icon for Special:Preferences mobile layout
|
|
|
|
*
|
|
|
|
* @param array &$iconNames Array of icon names for their respective sections.
|
|
|
|
*/
|
|
|
|
public function onPreferencesGetIcon( &$iconNames ) {
|
|
|
|
$iconNames[ 'gadgets' ] = 'puzzle';
|
|
|
|
}
|
|
|
|
|
2013-08-29 23:32:32 +00:00
|
|
|
/**
|
|
|
|
* ResourceLoaderRegisterModules hook handler.
|
2022-02-06 18:54:47 +00:00
|
|
|
* @param ResourceLoader $resourceLoader
|
2013-08-29 23:32:32 +00:00
|
|
|
*/
|
2021-12-06 10:34:17 +00:00
|
|
|
public function onResourceLoaderRegisterModules( ResourceLoader $resourceLoader ): void {
|
2022-08-16 15:24:01 +00:00
|
|
|
foreach ( $this->gadgetRepo->getGadgetIds() as $id ) {
|
2016-12-28 10:25:47 +00:00
|
|
|
$resourceLoader->register( Gadget::getModuleName( $id ), [
|
2021-04-08 18:34:17 +00:00
|
|
|
'class' => GadgetResourceLoaderModule::class,
|
2015-08-03 06:37:32 +00:00
|
|
|
'id' => $id,
|
2016-12-28 10:25:47 +00:00
|
|
|
] );
|
2013-08-29 23:32:32 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* BeforePageDisplay hook handler.
|
2017-08-27 14:07:08 +00:00
|
|
|
* @param OutputPage $out
|
2021-12-06 10:34:17 +00:00
|
|
|
* @param Skin $skin
|
2013-08-29 23:32:32 +00:00
|
|
|
*/
|
2021-12-06 10:34:17 +00:00
|
|
|
public function onBeforePageDisplay( $out, $skin ): void {
|
2022-08-16 15:24:01 +00:00
|
|
|
$repo = $this->gadgetRepo;
|
2015-07-18 22:40:42 +00:00
|
|
|
$ids = $repo->getGadgetIds();
|
2023-12-05 18:00:37 +00:00
|
|
|
$isMobileView = $this->isMobileView();
|
2015-07-18 22:40:42 +00:00
|
|
|
if ( !$ids ) {
|
2019-07-22 08:13:58 +00:00
|
|
|
return;
|
2013-08-29 23:32:32 +00:00
|
|
|
}
|
|
|
|
|
2016-12-28 10:25:47 +00:00
|
|
|
$enabledLegacyGadgets = [];
|
2023-06-29 00:57:04 +00:00
|
|
|
$conditions = new GadgetLoadConditions( $out, $isMobileView );
|
2013-08-29 23:32:32 +00:00
|
|
|
|
|
|
|
/**
|
|
|
|
* @var $gadget Gadget
|
|
|
|
*/
|
2015-07-18 22:40:42 +00:00
|
|
|
foreach ( $ids as $id ) {
|
2015-08-03 06:37:32 +00:00
|
|
|
try {
|
|
|
|
$gadget = $repo->getGadget( $id );
|
|
|
|
} catch ( InvalidArgumentException $e ) {
|
|
|
|
continue;
|
|
|
|
}
|
2022-01-11 09:03:44 +00:00
|
|
|
|
2022-03-19 16:49:41 +00:00
|
|
|
if ( $conditions->check( $gadget ) ) {
|
2013-08-29 23:32:32 +00:00
|
|
|
if ( $gadget->hasModule() ) {
|
Implement support for specifying type=styles
T87871 formally introduced the concept of a styles module,
which sets mw.loader.state to "ready" when loaded through addModuleStyles().
Previously, addModuleStyles couldn't safely do that because a module may
contain scripts also, in which case mw.loader must still load the (rest)
of the module (causes styles to load twice).
In MediaWiki core or extensions this is easily avoided by calling not
calling both addModules() and addModuleStyles().
For Gadgets we call both as a workaround to allow users to provide styles
(without a FOUC), but also to provide scripts+styles. Since we don't declare
which one is intended (and some gadgets do both), we loaded them both ways.
This will no longer be allowed in the future (see T92459).
The new 'type=styles' Gadget attribute promises to ResourceLoader that a
gadget only contains styles.
Impact:
* [Bug fix] When mw.loader requires a styles module that already loaded,
it will not load again.
* [Feature] It is possible for a general scripts+styles gadget to depend on
a styles gadget. Previously this caused the styles to load twice.
* Specifying type=styles will load the module through addModuleStyles() only.
Use this for modules that contain styles that relate to elements already
on the page (e.g. when customising the skin, layout, or article content).
* Specifying type=general will load the module through addModules() only.
Use this if your module contains both scripts and styles and the styles
only relate to elements created by the script. This means the styles do not
need to be loaded separately through addModuleStyles() and will not apply
to noscript mode.
Effective difference:
* Gadgets with only styles: We assume type=styles.
This fixes the main bug (styles loading twice) and requires no migration!
* Gadgets with only scripts: We assume type=general.
This requires no migration! (And: No more empty stylesheet request)
* Gadgets with scripts (with or without styles): We assume type=general, but
unless type=general was explicitly set we'll still load it both ways so
that the styles apply directly on page load.
If this is not needed, set type=general.
If this is needed, it should become two separate modules. We do not support
a single module having two purposes (1: apply styles to the page,
2: provide scripts+styles). The styles module should be separate.
It can be made hidden, and listed as dependency of the other module.
The latter case is detected on page load and results in a console warning
with a link to T42284.
Bug: T42284
Bug: T92459
Change-Id: Ia3c9ddee243f710022144fc2884434350695699a
2016-09-01 23:31:14 +00:00
|
|
|
if ( $gadget->getType() === 'styles' ) {
|
|
|
|
$out->addModuleStyles( Gadget::getModuleName( $gadget->getName() ) );
|
2017-05-12 17:37:49 +00:00
|
|
|
} else {
|
Implement support for specifying type=styles
T87871 formally introduced the concept of a styles module,
which sets mw.loader.state to "ready" when loaded through addModuleStyles().
Previously, addModuleStyles couldn't safely do that because a module may
contain scripts also, in which case mw.loader must still load the (rest)
of the module (causes styles to load twice).
In MediaWiki core or extensions this is easily avoided by calling not
calling both addModules() and addModuleStyles().
For Gadgets we call both as a workaround to allow users to provide styles
(without a FOUC), but also to provide scripts+styles. Since we don't declare
which one is intended (and some gadgets do both), we loaded them both ways.
This will no longer be allowed in the future (see T92459).
The new 'type=styles' Gadget attribute promises to ResourceLoader that a
gadget only contains styles.
Impact:
* [Bug fix] When mw.loader requires a styles module that already loaded,
it will not load again.
* [Feature] It is possible for a general scripts+styles gadget to depend on
a styles gadget. Previously this caused the styles to load twice.
* Specifying type=styles will load the module through addModuleStyles() only.
Use this for modules that contain styles that relate to elements already
on the page (e.g. when customising the skin, layout, or article content).
* Specifying type=general will load the module through addModules() only.
Use this if your module contains both scripts and styles and the styles
only relate to elements created by the script. This means the styles do not
need to be loaded separately through addModuleStyles() and will not apply
to noscript mode.
Effective difference:
* Gadgets with only styles: We assume type=styles.
This fixes the main bug (styles loading twice) and requires no migration!
* Gadgets with only scripts: We assume type=general.
This requires no migration! (And: No more empty stylesheet request)
* Gadgets with scripts (with or without styles): We assume type=general, but
unless type=general was explicitly set we'll still load it both ways so
that the styles apply directly on page load.
If this is not needed, set type=general.
If this is needed, it should become two separate modules. We do not support
a single module having two purposes (1: apply styles to the page,
2: provide scripts+styles). The styles module should be separate.
It can be made hidden, and listed as dependency of the other module.
The latter case is detected on page load and results in a console warning
with a link to T42284.
Bug: T42284
Bug: T92459
Change-Id: Ia3c9ddee243f710022144fc2884434350695699a
2016-09-01 23:31:14 +00:00
|
|
|
$out->addModules( Gadget::getModuleName( $gadget->getName() ) );
|
2022-01-11 09:03:44 +00:00
|
|
|
|
|
|
|
$peers = [];
|
|
|
|
foreach ( $gadget->getPeers() as $peerName ) {
|
|
|
|
try {
|
|
|
|
$peers[] = $repo->getGadget( $peerName );
|
|
|
|
} catch ( InvalidArgumentException $e ) {
|
2021-12-28 21:29:05 +00:00
|
|
|
// Ignore, warning is emitted on Special:Gadgets
|
2022-01-11 09:03:44 +00:00
|
|
|
}
|
|
|
|
}
|
2016-11-18 04:54:17 +00:00
|
|
|
// Load peer modules
|
|
|
|
foreach ( $peers as $peer ) {
|
|
|
|
if ( $peer->getType() === 'styles' ) {
|
|
|
|
$out->addModuleStyles( Gadget::getModuleName( $peer->getName() ) );
|
|
|
|
}
|
2017-05-12 17:37:49 +00:00
|
|
|
// Else, if not type=styles: Use dependencies instead.
|
2016-11-18 04:54:17 +00:00
|
|
|
// Note: No need for recursion as styles modules don't support
|
|
|
|
// either of 'dependencies' and 'peers'.
|
|
|
|
}
|
Implement support for specifying type=styles
T87871 formally introduced the concept of a styles module,
which sets mw.loader.state to "ready" when loaded through addModuleStyles().
Previously, addModuleStyles couldn't safely do that because a module may
contain scripts also, in which case mw.loader must still load the (rest)
of the module (causes styles to load twice).
In MediaWiki core or extensions this is easily avoided by calling not
calling both addModules() and addModuleStyles().
For Gadgets we call both as a workaround to allow users to provide styles
(without a FOUC), but also to provide scripts+styles. Since we don't declare
which one is intended (and some gadgets do both), we loaded them both ways.
This will no longer be allowed in the future (see T92459).
The new 'type=styles' Gadget attribute promises to ResourceLoader that a
gadget only contains styles.
Impact:
* [Bug fix] When mw.loader requires a styles module that already loaded,
it will not load again.
* [Feature] It is possible for a general scripts+styles gadget to depend on
a styles gadget. Previously this caused the styles to load twice.
* Specifying type=styles will load the module through addModuleStyles() only.
Use this for modules that contain styles that relate to elements already
on the page (e.g. when customising the skin, layout, or article content).
* Specifying type=general will load the module through addModules() only.
Use this if your module contains both scripts and styles and the styles
only relate to elements created by the script. This means the styles do not
need to be loaded separately through addModuleStyles() and will not apply
to noscript mode.
Effective difference:
* Gadgets with only styles: We assume type=styles.
This fixes the main bug (styles loading twice) and requires no migration!
* Gadgets with only scripts: We assume type=general.
This requires no migration! (And: No more empty stylesheet request)
* Gadgets with scripts (with or without styles): We assume type=general, but
unless type=general was explicitly set we'll still load it both ways so
that the styles apply directly on page load.
If this is not needed, set type=general.
If this is needed, it should become two separate modules. We do not support
a single module having two purposes (1: apply styles to the page,
2: provide scripts+styles). The styles module should be separate.
It can be made hidden, and listed as dependency of the other module.
The latter case is detected on page load and results in a console warning
with a link to T42284.
Bug: T42284
Bug: T92459
Change-Id: Ia3c9ddee243f710022144fc2884434350695699a
2016-09-01 23:31:14 +00:00
|
|
|
}
|
2013-08-29 23:32:32 +00:00
|
|
|
}
|
|
|
|
|
2015-08-07 00:05:29 +00:00
|
|
|
if ( $gadget->getLegacyScripts() ) {
|
|
|
|
$enabledLegacyGadgets[] = $id;
|
2013-08-29 23:32:32 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-12-28 10:25:47 +00:00
|
|
|
$strings = [];
|
2015-08-07 00:05:29 +00:00
|
|
|
foreach ( $enabledLegacyGadgets as $id ) {
|
2021-12-06 10:34:17 +00:00
|
|
|
$strings[] = $this->makeLegacyWarning( $id );
|
2013-08-29 23:32:32 +00:00
|
|
|
}
|
2015-08-07 00:05:29 +00:00
|
|
|
$out->addHTML( WrappedString::join( "\n", $strings ) );
|
2013-08-29 23:32:32 +00:00
|
|
|
}
|
|
|
|
|
2020-10-12 09:32:09 +00:00
|
|
|
/**
|
|
|
|
* @param string $id
|
|
|
|
* @return string|WrappedString HTML
|
|
|
|
*/
|
2021-12-06 10:34:17 +00:00
|
|
|
private function makeLegacyWarning( $id ) {
|
2015-08-07 00:05:29 +00:00
|
|
|
$special = SpecialPage::getTitleFor( 'Gadgets' );
|
2013-08-29 23:32:32 +00:00
|
|
|
|
2015-08-07 00:05:29 +00:00
|
|
|
return ResourceLoader::makeInlineScript(
|
2016-12-28 10:25:47 +00:00
|
|
|
Xml::encodeJsCall( 'mw.log.warn', [
|
2015-08-07 00:05:29 +00:00
|
|
|
"Gadget \"$id\" was not loaded. Please migrate it to use ResourceLoader. " .
|
Implement support for specifying type=styles
T87871 formally introduced the concept of a styles module,
which sets mw.loader.state to "ready" when loaded through addModuleStyles().
Previously, addModuleStyles couldn't safely do that because a module may
contain scripts also, in which case mw.loader must still load the (rest)
of the module (causes styles to load twice).
In MediaWiki core or extensions this is easily avoided by calling not
calling both addModules() and addModuleStyles().
For Gadgets we call both as a workaround to allow users to provide styles
(without a FOUC), but also to provide scripts+styles. Since we don't declare
which one is intended (and some gadgets do both), we loaded them both ways.
This will no longer be allowed in the future (see T92459).
The new 'type=styles' Gadget attribute promises to ResourceLoader that a
gadget only contains styles.
Impact:
* [Bug fix] When mw.loader requires a styles module that already loaded,
it will not load again.
* [Feature] It is possible for a general scripts+styles gadget to depend on
a styles gadget. Previously this caused the styles to load twice.
* Specifying type=styles will load the module through addModuleStyles() only.
Use this for modules that contain styles that relate to elements already
on the page (e.g. when customising the skin, layout, or article content).
* Specifying type=general will load the module through addModules() only.
Use this if your module contains both scripts and styles and the styles
only relate to elements created by the script. This means the styles do not
need to be loaded separately through addModuleStyles() and will not apply
to noscript mode.
Effective difference:
* Gadgets with only styles: We assume type=styles.
This fixes the main bug (styles loading twice) and requires no migration!
* Gadgets with only scripts: We assume type=general.
This requires no migration! (And: No more empty stylesheet request)
* Gadgets with scripts (with or without styles): We assume type=general, but
unless type=general was explicitly set we'll still load it both ways so
that the styles apply directly on page load.
If this is not needed, set type=general.
If this is needed, it should become two separate modules. We do not support
a single module having two purposes (1: apply styles to the page,
2: provide scripts+styles). The styles module should be separate.
It can be made hidden, and listed as dependency of the other module.
The latter case is detected on page load and results in a console warning
with a link to T42284.
Bug: T42284
Bug: T92459
Change-Id: Ia3c9ddee243f710022144fc2884434350695699a
2016-09-01 23:31:14 +00:00
|
|
|
'See <' . $special->getCanonicalURL() . '>.'
|
2016-12-28 10:25:47 +00:00
|
|
|
] )
|
2015-08-07 00:05:29 +00:00
|
|
|
);
|
2013-08-29 23:32:32 +00:00
|
|
|
}
|
|
|
|
|
2015-08-03 06:37:32 +00:00
|
|
|
/**
|
|
|
|
* Valid gadget definition page after content is modified
|
|
|
|
*
|
|
|
|
* @param IContextSource $context
|
|
|
|
* @param Content $content
|
|
|
|
* @param Status $status
|
|
|
|
* @param string $summary
|
2021-12-06 10:34:17 +00:00
|
|
|
* @param User $user
|
|
|
|
* @param bool $minoredit
|
2015-08-03 06:37:32 +00:00
|
|
|
* @throws Exception
|
|
|
|
* @return bool
|
|
|
|
*/
|
2021-12-06 10:34:17 +00:00
|
|
|
public function onEditFilterMergedContent(
|
|
|
|
IContextSource $context,
|
2019-07-22 08:13:58 +00:00
|
|
|
Content $content,
|
|
|
|
Status $status,
|
2021-12-06 10:34:17 +00:00
|
|
|
$summary,
|
|
|
|
User $user,
|
|
|
|
$minoredit
|
2019-07-22 08:13:58 +00:00
|
|
|
) {
|
2022-01-16 17:10:59 +00:00
|
|
|
if ( $content instanceof GadgetDefinitionContent ) {
|
|
|
|
$validateStatus = $content->validate();
|
|
|
|
if ( !$validateStatus->isGood() ) {
|
|
|
|
$status->merge( $validateStatus );
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
$title = $context->getTitle();
|
|
|
|
if ( $title->inNamespace( NS_GADGET_DEFINITION ) ) {
|
|
|
|
$status->merge( Status::newFatal( "gadgets-wrong-contentmodel" ) );
|
|
|
|
return false;
|
|
|
|
}
|
2015-08-03 06:37:32 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Mark the Title as having a content model of javascript or css for pages
|
|
|
|
* in the Gadget namespace based on their file extension
|
|
|
|
*
|
|
|
|
* @param Title $title
|
2017-08-27 14:07:08 +00:00
|
|
|
* @param string &$model
|
2015-08-03 06:37:32 +00:00
|
|
|
* @return bool
|
|
|
|
*/
|
2021-12-06 10:34:17 +00:00
|
|
|
public function onContentHandlerDefaultModelFor( $title, &$model ) {
|
2015-08-03 06:37:32 +00:00
|
|
|
if ( $title->inNamespace( NS_GADGET ) ) {
|
2021-10-17 13:05:15 +00:00
|
|
|
preg_match( '!\.(css|js|json)$!u', $title->getText(), $ext );
|
2019-03-17 23:39:02 +00:00
|
|
|
$ext = $ext[1] ?? '';
|
2015-08-03 06:37:32 +00:00
|
|
|
switch ( $ext ) {
|
|
|
|
case 'js':
|
|
|
|
$model = 'javascript';
|
|
|
|
return false;
|
|
|
|
case 'css':
|
|
|
|
$model = 'css';
|
|
|
|
return false;
|
2021-10-17 13:05:15 +00:00
|
|
|
case 'json':
|
|
|
|
$model = 'json';
|
|
|
|
return false;
|
2015-08-03 06:37:32 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2015-10-27 13:29:26 +00:00
|
|
|
/**
|
|
|
|
* Add the GadgetUsage special page to the list of QueryPages.
|
|
|
|
* @param array &$queryPages
|
|
|
|
*/
|
2021-12-06 10:34:17 +00:00
|
|
|
public function onWgQueryPages( &$queryPages ) {
|
2023-10-30 15:36:33 +00:00
|
|
|
$queryPages[] = [ SpecialGadgetUsage::class, 'GadgetUsage' ];
|
2015-10-27 13:29:26 +00:00
|
|
|
}
|
2018-04-06 00:18:46 +00:00
|
|
|
|
|
|
|
/**
|
|
|
|
* Prevent gadget preferences from being deleted.
|
|
|
|
* @link https://www.mediawiki.org/wiki/Manual:Hooks/DeleteUnknownPreferences
|
|
|
|
* @param string[] &$where Array of where clause conditions to add to.
|
|
|
|
* @param IDatabase $db
|
|
|
|
*/
|
2021-12-06 10:34:17 +00:00
|
|
|
public function onDeleteUnknownPreferences( &$where, $db ) {
|
2018-04-06 00:18:46 +00:00
|
|
|
$where[] = 'up_property NOT' . $db->buildLike( 'gadget-', $db->anyString() );
|
|
|
|
}
|
2022-08-27 14:04:31 +00:00
|
|
|
|
|
|
|
/**
|
|
|
|
* @param Title $title Title being checked against
|
|
|
|
* @param User $user Current user
|
|
|
|
* @param string $action Action being checked
|
|
|
|
* @param array|string|MessageSpecifier &$result User permissions error to add. If none, return true.
|
|
|
|
* For consistency, error messages should be plain text with no special coloring,
|
|
|
|
* bolding, etc. to show that they're errors; presenting them properly to the
|
|
|
|
* user as errors is done by the caller.
|
|
|
|
* @return bool|void
|
|
|
|
*/
|
|
|
|
public function onGetUserPermissionsErrors( $title, $user, $action, &$result ) {
|
|
|
|
if ( $action !== 'edit' || !$title->inNamespace( NS_GADGET ) ) {
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
switch ( $title->getContentModel() ) {
|
|
|
|
case CONTENT_MODEL_JSON:
|
|
|
|
if ( !$user->isAllowed( 'editsitejson' ) ) {
|
|
|
|
$result = ApiMessage::create( wfMessage( 'sitejsonprotected' ), 'sitejsonprotected' );
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
case CONTENT_MODEL_CSS:
|
|
|
|
if ( !$user->isAllowed( 'editsitecss' ) ) {
|
|
|
|
$result = ApiMessage::create( wfMessage( 'sitecssprotected' ), 'sitecssprotected' );
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
case CONTENT_MODEL_JAVASCRIPT:
|
|
|
|
if ( !$user->isAllowed( 'editsitejs' ) ) {
|
|
|
|
$result = ApiMessage::create( wfMessage( 'sitejsprotected' ), 'sitejsprotected' );
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
// For any other pages in the namespace
|
|
|
|
if ( !$user->isAllowed( 'editsitejs' ) ) {
|
|
|
|
$result = ApiMessage::create( wfMessage( 'gadgets-protected' ), 'permissiondenied' );
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
return true;
|
|
|
|
}
|
2013-08-29 23:32:32 +00:00
|
|
|
}
|