aa3b388b5b
When rendering Special:RecentChanges for an user with rollback rights,
the software checks whether the user has permission to perform the
rollback action on each entry via User::probablyCan(), which
delegates to PermissionManager. This in turn checks for each entry
whether the title has protections (e.g. from action=protect) against the
"rollback" action, which is unlikely to be the case since by default
wgRestrictionTypes only supports create/edit/move/upload.
This triggers noticeable memcached I/O and overhead.[1]
So, as an optimization, avoid fetching page restrictions in
RestrictionStore for action types that are known to not be restrictable
via page protection. In the unlikely event that wgRestrictionTypes is
customised to offer separate restrictions for "rollback", this will
work continue to work as expected and is covered by tests.
-
[1]
|
||
|---|---|---|
| .. | ||
| Hook | ||
| Authority.php | ||
| GrantsInfo.php | ||
| GrantsLocalization.php | ||
| GroupPermissionsLookup.php | ||
| PermissionManager.php | ||
| PermissionStatus.php | ||
| RateLimiter.php | ||
| RateLimitSubject.php | ||
| RestrictionStore.php | ||
| SimpleAuthority.php | ||
| UltimateAuthority.php | ||
| UserAuthority.php | ||