These three classes:
- TitleArray
- TitleArrayFromResult
- TitleFactory
We need to move these and the rest of files under title/ to Title/ (and
namespace them) but the patch will become way too big given that Title class is
also one of them.
Bug: T321882
Change-Id: Iac1688172ee457348a08a470c86e047571feb8e0
30+ API modules had nearly identical code to split and validate
the value of the 'continue' parameter.
Introduce the ApiBase::parseContinueParamOrDie() method and use it to
replace most usages of ApiBase::dieContinueUsageIf(). A few remain in
modules with more complex continuation handling.
Inline most single-use variables that remained after validation was
moved into the new method.
Change-Id: I66bd59ecd4ad16e2039e90f7d66cfa276e6c1c2a
Currently, it's picking up tl_target_id index which leads to massive row
scans when it tries to check cascade protection of highly used
templates.
Tested locally and it works just fine.
Bug: T308207
Change-Id: Id0e6ff623be8e23619961730e012b6b0fcb4723d
Even the service does not long stay in that classes,
it should be injected to avoid global state
Bug: T304780
Change-Id: Ib488037f5a6966ab61042ed3cd889ddc50f1ba8e
This covers all occurrences of /onfig->.*get( '/ in includes/.
Undoubtedly there are still plenty more to go.
Change-Id: I33196c4153437778496f40436bcde399638ac361
- In Info action and its API counter part
- In LinkBatch::constructSet
- In Title::getLinksFrom
Bug: T304780
Change-Id: I449f041986acdd16feecac818e3579987b4b11be
Make phan stricter about null types by setting null_casts_as_any_type to
false (the default in mediawiki-phan-config)
Remaining false positive issues are suppressed.
The suppression and the setting change can only be done together
Bug: T242536
Bug: T301991
Change-Id: I0f295382b96fb3be8037a01c10487d9d591e7e01
The value in the attribute displaytitle must contain valid HTML. The
sanitizer of the {{DISPLAYTITLE}} parser ensures that only valid HTML
is accepted.
If there is no {{DISPLAYTITLE}} in the wikitext then displaytitle
falls back to $title->getPrefixedText(). Here an HTML encoding of
special characters is necessary. This affects only the replacement of
& by & because other special characters like < and > are not
allowed in the title.
This change affects the displaytitle fallback on the following places:
* ApiParse
* ApiQueryInfo
* InfoAction
* Parser
The displaytitle fallback in OutputPage is also updated to this
behavior although
Sanitizer::normalizeCharReferences( Sanitizer::removeHTMLtags( $html )
also replaces & by &.
Also add test cases with & in the displaytitle to:
* ApiParseTest
* ApiQueryInfoTest
* parserTests
Bug: T291985
Change-Id: I8ee1e2731d9bfa49725d663b34986e7e3073e4ca
Removes deprecated API endpoints and modules for dealing with
CSRF tokens.
Note: i18n messages are removed in a followup for ease of revert.
Bug: T280806
Depends-On: Ic83f44587db119ff2e3e6d5ff33a10894e0695e7
Change-Id: I58aedec6942ac5d3c21574cb0072f00ef365098c
Returns the prefixed title for the associated page,
if it could exist (i.e. does not do anything for special pages)
Bug: T257014
Change-Id: I49cdc138c6182b323c4933e90dc96c5e06b6ccba
array_fill_keys() was introduced in PHP 5.2.0 and works like
array_flip() except that it does only one thing (copying keys) instead
of two things (copying keys and values). That makes it faster and more
obvious.
When array_flip() calls were paired, I left them as is, because that
pattern is too cute. I couldn't kill something so cute.
Sometimes it was hard to figure out whether the values in array_flip()
result were used. That's the point of this change. If you use
array_fill_keys(), the intention is obvious.
Change-Id: If8d340a8bc816a15afec37e64f00106ae45e10ed
Replaces calls directly to PermissionManager with calls to
the Authority object available from Context or the
GroupPermissionLookup service.
This patch does not address use of PermissionManager for
blocks.
Deprecations:
- ApiBase::checkUserRightsAny deprecated passing optional
User parameter
- ApiBase::checkTitleUserPermissions deprecated passing
LinkTarget as first parameter, takes PageIdentity instead
Bug: T271462
Bug: T271854
Change-Id: I5d7cac1c28a37e074750c46cda03283980a07fca
This is micro-optimization of closure code to avoid binding the closure
to $this where it is not needed.
Created by I25a17fb22b6b669e817317a0f45051ae9c608208
Change-Id: I0ffc6200f6c6693d78a3151cb8cea7dce7c21653
The code didn't properly handle requests for info about non-existing
pages.
Bug: T271804
Bug: T271815
Change-Id: If4e56ff5ecb4a048767833c89847bb58269cad43
The expiry is returned as a separate key, 'watchlistexpiry', to match
other APIs, and because some clients might expect 'watched' to be a
boolean (or blank string depending on the formatversion).
Bug: T268834
Change-Id: I227d6ed42e70ba1ddec0139e8198f536dfba0b46
Several important extensions (Disambiguator, ProofreadPage, and
SoftRedirector) use the GetLinkColours hook to add additional CSS
classes to links on article pages. Parsoid previously relied on
backdoor knowledge of the way Disambiguator used the page property
table to support these, but they should be exported properly from the
API.
Bug: T237538
Change-Id: I945940aa872541d7e01f1e543ca854231c857fe2
Yes, the methods are all deprecated, as is using that API path, but
until they can be removed we can at least reduce the use of $wgUser
Bug: T243708
Change-Id: I34df7dc3b1c3b1258d3bd3dca4bdb261124004cd
Migrate all callers of Hooks::run() to use the new
HookContainer/HookRunner system.
General principles:
* Use DI if it is already used. We're not changing the way state is
managed in this patch.
* HookContainer is always injected, not HookRunner. HookContainer
is a service, it's a more generic interface, it is the only
thing that provides isRegistered() which is needed in some cases,
and a HookRunner can be efficiently constructed from it
(confirmed by benchmark). Because HookContainer is needed
for object construction, it is also needed by all factories.
* "Ask your friendly local base class". Big hierarchies like
SpecialPage and ApiBase have getHookContainer() and getHookRunner()
methods in the base class, and classes that extend that base class
are not expected to know or care where the base class gets its
HookContainer from.
* ProtectedHookAccessorTrait provides protected getHookContainer() and
getHookRunner() methods, getting them from the global service
container. The point of this is to ease migration to DI by ensuring
that call sites ask their local friendly base class rather than
getting a HookRunner from the service container directly.
* Private $this->hookRunner. In some smaller classes where accessor
methods did not seem warranted, there is a private HookRunner property
which is accessed directly. Very rarely (two cases), there is a
protected property, for consistency with code that conventionally
assumes protected=private, but in cases where the class might actually
be overridden, a protected accessor is preferred over a protected
property.
* The last resort: Hooks::runner(). Mostly for static, file-scope and
global code. In a few cases it was used for objects with broken
construction schemes, out of horror or laziness.
Constructors with new required arguments:
* AuthManager
* BadFileLookup
* BlockManager
* ClassicInterwikiLookup
* ContentHandlerFactory
* ContentSecurityPolicy
* DefaultOptionsManager
* DerivedPageDataUpdater
* FullSearchResultWidget
* HtmlCacheUpdater
* LanguageFactory
* LanguageNameUtils
* LinkRenderer
* LinkRendererFactory
* LocalisationCache
* MagicWordFactory
* MessageCache
* NamespaceInfo
* PageEditStash
* PageHandlerFactory
* PageUpdater
* ParserFactory
* PermissionManager
* RevisionStore
* RevisionStoreFactory
* SearchEngineConfig
* SearchEngineFactory
* SearchFormWidget
* SearchNearMatcher
* SessionBackend
* SpecialPageFactory
* UserNameUtils
* UserOptionsManager
* WatchedItemQueryService
* WatchedItemStore
Constructors with new optional arguments:
* DefaultPreferencesFactory
* Language
* LinkHolderArray
* MovePage
* Parser
* ParserCache
* PasswordReset
* Router
setHookContainer() now required after construction:
* AuthenticationProvider
* ResourceLoaderModule
* SearchEngine
Change-Id: Id442b0dbe43aba84bd5cf801d86dedc768b082c7
There is no security issue using RIGOR_FULL here, because the
information is not used to take an action. It is used for information to
the caller and the caller may not allow the action.
But even the caller allows the action, the action api code would check
permission with RIGOR_SECURE before doing the action.
Also use the constant to make clear which string is from api and which
one is from the PermissionManager
Bug: T239451
Change-Id: If182f0e967187704ba3fdd14592a0badff097571
