'LEFT-TO-RIGHT MARK' (U+200E) is not needed in the source code
comments.
c8caf26ffd9 removed already the LRM/RLM from Names.php.
Change-Id: I7a737760bd69983703bc324592e56c5ee4acfaad
This hook needs the old call structur as there is not a interface for
it.
When CodeEditor extension is changed to provide that interface, this
needs to be moved to another class, because the extension is optional
and the interface not loaded on all installs.
This change is a follow-up to b504a6f496
and reverts the change for hook CodeEditorGetPageLanguage because
onCodeEditorGetPageLanguage is still a static function.
Bug: T271014
Change-Id: I0ac6f353be099c4c9b4cb36b65cb463b7b7b89ea
* Remove most APCu logic, including the reverse checking of WANCache
touch time to validate the APCu key
The APCu expiry had a 7-15s blind TTL before this check took place.
Keep the conservative part of this (blind TTL). This should be
more than enough to debounce memcached traffic.
* Simplify WAN handling with plain key and delete (using the default
holdoff tombstone, which should take care of edge cases like second
DC warming up the WAN key shortly after a delete).
* Fix incorrect method doc about being by section. The returned
list is not by section.
Change-Id: If14ff83a29367df58d1824615bcf0bcd2edc886f
== 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
Locally these tests are failing for me on master every time.
In WMF CI, it seems they are passing right now, although they
too would start failing as of Ib27fd34fbfe7a7. My guess is that
my change there causes the service container to be initialised
earlier and thus causes the modified global to no longer be seen.
At the very least this should have been using setMwGlobals(), which
would have also avoided the issue by ensuring a service reset,
however use setGroupPermissions() since it's tailor made for this
purpose, and avoids potential problems later with default groups
not existing.
Change-Id: I8f02ffc996d6077ca6e7433229b1ea5d8fc6ce7c
