Feeding the return value of the DB query through timstamp conversion
made it so that false was turned into the current timestamp, causing
confusion and cache churn.
Bug: T298520
Change-Id: I6e10b21f6b0e40ce7e3403ffc9a41a307e945354
The functions returning null or the class property is set explict null
Found by phan strict checks
Change-Id: I4a271093fb6526564d8083a08249c64cb21f2453
Title::newFromText with empty string will always yields null.
But the decision to return null is only made after applying
various normalization and filtering routines, which will
eventually have zero effect on the return value. So we may
just return the null early as we do with null itself.
Change-Id: Ic277a6e8c8c0b2a0b6af78f6524b80574c4602af
Skin::getLanguages() was consuming 4% of index.php CPU time. In local
testing, it was called three times per page view. So:
* Memoize it, analogous to the nonfunctional code in SkinVector.
* Simplify ClassicInterwikiLookup by removing the option to pass a CDB
file path. This was only ever supported by a WikimediaMaintenance
script. In the unlikely event that someone is using this feature, they
have the same motivation to switch to PHP as we did in T122362.
* Increase the size of ClassicInterwikiLookup's MapCacheLRU from 100 to
1000. This helps greatly in the case when $wgInterwikiCache is false
and more than 100 interwikis are requested and seems harmless
otherwise.
* Optimise Title::getNsText() by assuming that the canonical name of
NS_MAIN is the empty string.
* Rearrange Message::__construct() to avoid duplicate type checks.
Change-Id: I736cb74efc267fd2473a3267471735238217251c
The main call to Title::getEditNotices is in EditPage, where the global
title used by the message parser is correct. In other Action like
DeleteAction this would also be correct.
However, when called in API context (eg. ApiVisualEditor), or from a
special page that acts as a page action (such as
Special:EditMassMessageList or Special:Undelete) then the global title
is wrong (somewhat akin to wgPageName vs wgRelevantPageName).
Bug: T300184
Change-Id: I242e042317a1e16c8d51edbf7800c8b7d70d468e
* The Title::inNamespace() method discouraged use of getNamespace()
for comparison.
This was added 10 years ago in r103893 (commit 3414e91bae),
however no such "change" has been made, and the new LinkTarget
stable interface and TitleValue class contains the same getNamespace()
method, and no warning against its use.
My main reason for removing this comment is so that avoid fear
against using `in_array()` with TitleValue->getNamespace() which
this comment seems to discourage. While Title has plural
inNamespaces(), TitleValue does not. This seems fine, as one can
simply use in_array for more complex use cases where a range or
list is compared against.
* Fix Doxygen warnings about invalid or unsupported XML tags
such as `<a>`, `<siteinfo>` etc. Rephase or use backtics,.
* Fix useless IDE tooltips and Doxygen output by removing empty stubs
from method overrides that add no new information, yet obscured
the otherwise inherited parent destination which does have useful
information.
* Clarify that `renderForComment` must not be mixed with other ones.
This seems to be how it is intended. Upon realizing that, I think
this is unreasonable and should perhaps be removed. For now, I've
documented the hack that it seems to exist for.
* Consistently use imperative mood when phrasing method docs, and
consistently use a brief first line description, and
consistently separate it from other paragraphs and annotations
with one line break.
Change-Id: I7e1819a5d7124c635de84bc64d2371a122195928
The cost of creating closures adds up, so avoid it if we can be using
method names instead.
Bug: T297236
Change-Id: Ifb78d5f310fe45db58fd450c9db3c7af295ae399
Calling getPageById when the page ID is known was supposed to improve
query performance, but since it bypasses LinkCache, it ended up causing a
spike in database queries.
This optimization can be re-introduced once we also cache PageRecords by ID.
Bug: T296063
Change-Id: Ia4ee75b7b5a71d7d858f818d6467793bc642697b
For now, let's just proxy the title object and set the
interwiki but to make things nicer, we should not provide
a title via setUp(), we should use providers.
Bug: T275763
Change-Id: I761de85ae5a839e8a695b85ce0fd7200b498da22
This causes Title to no longer look up fields in the database
individually, but use LinkCache instead to load an entire row from the
page table at once.
This patch also causes Title to use in-process caching for some
getters that did not use caching before, such as isNewPage()
and getTouched(). These methods do not appear to be used on critical
code paths that involve database updates.
Note that getTouched() used to take an options $db parametr. This
appears to be unused, and has been deprecated in favor of a $flags
parameter, for consistency with other getters on the class.
DEPLOY: Risky! This re-implements the internal caching logic of Title
and slightly modifies caching semantics in some cases. This may have
unforeseen consequences.
Bug: T285389
Depends-On: I103b9e1d2bf594bfc1b0ea12b980dd20bb911c3a
Change-Id: I2df81df7186025e001520f24fd498623c7184772
These type-hints are definitely correct, but it's still
a relatively risky patch cause of how messy Title is.
I did some manual review of Title, all tests are passing,
but even still if this is approved, I'll add it to phab
as a risky deployment.
Change-Id: I1ed98ddae30066956e7adbde6780d6bab54dec04
New option 'absoluteURLs' was added to getText method
of the ParserOutput object that replaces all links
in the page HTML with absolute URLs.
Removing the action=render special case from Title
seems safe cause we will end up replacing the result
with absolute URL if we're in a render action no matter
where Title::getLocalUrl was called from.
This change is safely revertable from the perspective
of ParserCache.
Bug: T263581
Change-Id: Id660e1026192f40181587199d3418568f0fdb6d3
Also remove the "@unstable" annotation from DeletePage.
Methods without known usages were hard-deprecated, the others
soft-deprecated.
Bug: T288758
Bug: T288759
Change-Id: I30c62572fd533526779a8ade3ab178f35bebb522
The behavior of getCascadeStrictionSources was changed by Ia73ea587586cb69eb5
to conform to the documented behavior: it would always return false as the
first element of the return value if there were no cascading restriction sources,
as specified in the documentation.
Hopwever, the previous behavior was to return an empty array in that
case, unless the $getPages parameter was false. That behavior seems more
senible, and there is existing code that relies on it.
This patch restores the previous behavior and updates the documentation
instead.
Bug: T218395
Needed-By: I31ca0a8987f9694bc3b312a48c2c111ceda6fa3e
Change-Id: I1f24703b80566220ac6fe8ee500e838ed7fd29af
There are no callers of this method anywhere in our codebases. Seems
like a relic from past refactoring. But maybe I'm wrong.
Change-Id: Id8296ca28518a54d1712bca6b9770b918c92e0c2
This makes the data stored by LinkCache compatible with PageStoreRecord,
so we can use LinkCache inside PageStore.
This causes PageStore to make use of local caching as well as WANObjectCache.
Note that getPageById() does not yet benefit from cache, but does
populate the cache.
Bug: T278940
Change-Id: Icc27a0d9299a3e4ce45521daef87ad06ec06f064
These not only make the code more robust, but also help a lot when
writing unit tests: if a method is return-typehinted and its class is
mocked, the mock method will automatically return a mock of its declared
return type. Otherwise it will return null, and developers are forced to
manually mock the method if the return value is used by the SUT in a way
that doesn't accept null.
Depends-On: I628fcb1807133390c7b9b47984f512f5b1ae58d0
Depends-On: I7080bc505f5838b2f51a368da562104e206063b0
Change-Id: I59068cfed10aabf6c6002f9e9312a6ef6e7e9441
This allows checking restrictions without a dependency on Title, based
only on a PageIdentity.
Additional fixes along the way:
* Correctly return false instead of 'infinity' for
getRestrictionExpiry( 'create' ) on an existing page
* Correctly handle non-special pages that can't exist (like media pages)
in listApplicableRestrictionTypes() (return empty array instead of
'create')
* Improve readability of isProtected()
The expectation change in TitleTest::testIsProtected() is because the
test was formerly broken, since it set mRestrictions without setting
mRestrictionsLoaded. (Which illustrates how this approach to testing is
essentially broken.)
Co-authored-by: Vedmaka <god.vedmaka@gmail.com>
Bug: T218395
Change-Id: Ia73ea587586cb69eb53265b2f8f7a296a2573dd0
Per docs added in I18767cd809f67b, these don't need normalization
as they are only compared against predefined strings, and besides
are generally entered manually in a form, and even then would not
require the kinds of Unicode chars that have multiple/non-normalized
forms.
In nearby areas to also fix some trivial cases:
* getVal('title') obviously needs normalization.
Use getText() to make this more obvious.
* getVal() compared against simple string literals within the code
obviously don't need normalization (e.g. printable === 'no').
* Change hot code in MediaWiki checking for whether 'diff' or 'oldid'
are set to getCheck (which uses getRawVal) instead of getVal.
As a bonus this means it now handles values like "0" correctly,
which could theoretically have caused bad behaviour before.
Change-Id: Ied721cfdf59c7ba11d1afa6f4cc59ede1381238e
Title::resetArticleID() clears various caches and is meant for when a
page was inserted or moved or similar. I can't see any reason that it
needs to be called by Title::castFromPageIdentity. Doing so wastes
resources and prevents use of the method in unit tests. It is also
surprising for a cast to have side effects.
Change-Id: I71c523e7406d493c52199c3a5a9ca7cd414bb5eb
First step here is to avoid accessing the Title class members directly.
Instead, use their corresponding accessor methods. Affected members are,
$mTextform, $mUrlform, $mDbkeyform, $mNamespace, $mInterwiki, and $mFragment.
TODO: The next step from here would be to find usage of direct access and
replace them with calls to accessor methods while making the members
private.
Bug: T275763
Change-Id: I9b3efe7a43597f14e19d5db8e824f65aeb169d0b
… including PHPDoc tags like `@return <type> $variableName`.
A return value doesn't have a variable name. I can see that
some people do this intentionally, repeating the variable
name that was used in the final `return $var;` at the end
of a method. This can indeed be helpful. I leave a lot of
these untouched and removed them only when it's obviously
wrong, or does not provide any additional information in
addition to what the code already says.
Change-Id: Ia18cd9f25ef658b08ad25b97a744897e2a8deffc
The following methods no longer support Revision parameters:
- CategoryMembershipChange::__construct
- ContentHandler::getUndoContent
- DerivedPageDataUpdater::prepareUpdate
- DifferenceEngine::getRevisionHeader
The following methods were removed entirely:
- Title::countAuthorsBetween
The following methods return arrays that formerly include
a 'revision' key that would emit deprecation warnings when
accessed and return a Revision object. The Revision object
has been removed from the arrays, and the 'revision-record'
key should be used to get the relevant RevisionRecord instead:
- PageUpdater::doModify
- PageUpdater::doCreate
- Parser::statelessFetchTemplate
The ParserOptions `templateCallback` option is a callback
that is called in Parser::fetchTemplateAndTitle() and should
return an array - the 'revision' key to that array used to
be a Revision object and was used if no 'revision-record'
was returned - it is now ignored.
Bug: T247143
Change-Id: I163ada88d649c75697aff4fa31a3a3c0bdef78b7
