* This should not happen as doEditContent() saves the parser cache,
so only the rare casing if incompatible options should have misses
* The bug could also cause post-save misses with edit stashing
* Avoid the second page parse post-redirect by making sure cache
timestamps match up instead of calling time() at several points
* Likewise for null edits, which used a different code path
* Removed redundant purge in onArticleCreate() as the new row sets _touched
* Removed pointless purge in onArticleDelete() as there is no row to update
(the method no-ops in that case to avoid contention already)
Change-Id: I178fe334a3f8691ffd9452bec30561a0c5d37c6c
WikiImporter now uses NaiveImportTitleFactory, which in turn uses Title::makeTitleSafe,
bypassing the internal title cache. To avoid (potentially cached) Title objects obtained
via Title::newFromText getting out of sync, WikiImporter now clears the title
cache in addition to clearing the LinkCache.
NOTE: a test for this is provided by I2be12fa7d439b.
Bug: T89307
Change-Id: Ib50c48d4797fc21c62090c0be69e87f7e7d07428
Without this, you have to call:
getArticleID( Title::GAID_FOR_UPDATE )
then either use that directly (bypassing the TitleExists hook) or
call exists afterwards.
Change-Id: Ieec5579e4de2a289795364e7001028932535e435
includes/Title.php
* The private method Title::secureAndSplit() now throws a
MalformedTitleException instead of returning false on invalid
titles.
* Added Title::newFromTextThrow(), which behaves exactly like
Title::newFromText() but throws MalformedTitleException instead of
returning null on invalid titles.
includes/title/MediaWikiTitleCodec.php
* Provide more information with the thrown MalformedTitleExceptions.
includes/MediaWiki.php
* Use the new Title::newFromTextThrow() to get detailed error
information, display it.
Change-Id: I4da8ecb457a77473e32d745ba48ab8505b35e45f
ContentHandler::getDefaultModelFor() always returns a contentmodel,
so this exception is never thrown.
Change-Id: I7678964f229da8fcd15eb49e9e8c8e9a258e35a1
* Title::newFromRow() will actually load page_restrictions, which
should normally be empty. This avoids queries in getRestrictions().
Those queries could add 100-200ms to edit form views.
* getLinksFrom() has been simplified to use newFromRow(), thus
loading the old restrictions in passing.
Change-Id: I225955589a82e4accbf059d17390a5e28e2fa1ca
This broke a few things, and the debug line was basically pointless.
Instead, continue to only throw an exception if $text is an object, but only
warn if it's otherwise not a string.
This reverts commit 372ded2fea.
Change-Id: I060da9191cdbd00c4873caba875bfb77c917bcd7
This prevents warnings from PHP from array_key_exists().
Also make sure Title::newFromText throws an exception before it can trigger this.
Bug: T76305
Change-Id: I2b36b7a3b96b37e29fe06f69c13a185b3ec592a7
We review documentation all the time. Even if this was a big, notable
review, it was 5 years ago. It's probably outdated again, e.g. because
methods changed but the corresponting documentaion did not. In my
opinion the fact that a review happened 5 years ago is not useful any
more.
Change-Id: I6f4fb88ea790520bf2443aae4144cdde394b5e78
There's a bunch of stuff that probably only works because the database
representation of infinity is actually 'infinity' on all databases
besides Oracle, and Oracle in general isn't maintained.
Generally, we should probably use 'infinity' everywhere except where
directly dealing with the database.
* Many extension callers of Language::formatExpiry() with $format !==
true are assuming it'll return 'infinity', none are checking for
$db->getInfinity().
* And Language::formatExpiry() would choke if passed 'infinity', despite
callers doing this.
* And Language::formatExpiry() could be more useful for the API if we
can override the string returned for infinity.
* As for core, Title is using Language::formatExpiry() with TS_MW which
is going to be changing anyway. Extension callers mostly don't exist.
* Block already normalizes its mExpiry field (and ->getExpiry()),
but some stuff is comparing it with $db->getInfinity() anyway. A few
external users set mExpiry to $db->getInfinity(), but this is mostly
because SpecialBlock::parseExpiryInput() returns $db->getInfinity()
while most callers (including all extensions) are assuming 'infinity'.
* And for that matter, Block should use $db->decodeExpiry() instead of
manually doing it, once we make that safe to call with 'infinity' for
all the extensions passing $db->getInfinity() to Block's contructor.
* WikiPage::doUpdateRestrictions() and some of its callers are using
$db->getInfinity(), when all the inserts using that value are using
$db->encodeExpiry() which will convert 'infinity'.
This also cleans up a slave-lag issue I noticed in ApiBlock while
testing.
Bug: T92550
Change-Id: I5eb68c1fb6029da8289276ecf7c81330575029ef
Don't include edit notices that parse to nothing in the output
array.
Similar filtering logic currently exists in VisualEditor. This
helps support systems like the one on English Wikipedia where an
Editnotice page may exist, but conditionally outputs the actual
notice.
Bug: T91715
Change-Id: Ic8fb038fd6acf18830cafdd09a8ca86f3950c7a5
* Callers that should not use caches won't
* Aliased the old "bypassCache" param to "latest"
bug: T89184
Change-Id: I9f79e5942ced4ae13ba4de0b4c62908cc746e777
* Refactored getUserPermissionsErrors "expensive" checks flag to be
a bit more general.
bug: T51419
Change-Id: Ic1882aa2957eed2b978761b5fc34ea9bdd8981b5
This also includes the integration test from SemanticMediaWiki that
caught this issue.
Bug: T74870
Change-Id: I699e14958ee36ec5e86278e5dc0caed2a015d9af
Unless Title::GAID_FOR_UPDATE is specified, Title::getArticleID() will not
use the link cache if the Title already has the ID of the page. Account for
this by directly calling LinkCache::addLinkObj() in three other methods of
Title: getContentModel(), isRedirect(), and getLength().
Follows-up r33008 (aed9d4b912) and dd5c1b7fb7, and reapplies part of
388b14a15d.
Bug: T86974
Change-Id: I7eff0bffd4f632ceb8d2124af317d684dbcaf2cb
Revision->getRawUser()
=> Revision->getUser( Revision::RAW )
Revision->getRawUserText()
=> Revision->getUserText( Revision::RAW )
Revision->getRawComment()
=> Revision->getComment( Revision::RAW )
The body of Revision->getRawUserText() has been moved
into Revision->getUserText().
Every usage has been replaced.
Change-Id: Ic6fbfbc0507dcf88072fcb2a2e2364ae1436dce7
Xhprof generates this data now. Custom profiling of various
sub-function units are kept.
Calls to profiler represented about 3% of page execution
time on Special:BlankPage (1.5% in/out); after this change
it's down to about 0.98% of page execution time.
Change-Id: Id9a1dc9d8f80bbd52e42226b724a1e1213d07af7
Deprecated it in Title, and updated all current references to use the
non-deprecated version in MediaWikiTitleCodec
Change-Id: I2b9c36992028c97f695f2b95ba027fbb11904b57
Title::getRestrictions is assumed to return user rights, but in most
real contexts it actually returns user groups. This is super
confusing and has caused serious permission bugs. Adding an
explanation to the function comments.
Change-Id: I58013ba5e553d1feecacf6bfef066e1569fcc236
The former is by far the most common.
Skipped:
* resources/lib/jquery.ui/jquery.ui.datepicker.js
* resources/src/mediawiki.special/mediawiki.special.upload.js
Change-Id: I73c93797e745128ba703e4865080c36784caa474
A bit of history:
* when added by Aaron Schulz with commit
df1f744757, the method made use of
a hardcoded `0`;
* Lisa Ridley noted that with
commit bc1023ac89 by adding
"uses hardcoded namespace index instead of constants";
* Max Semenik changed `0` to `NS_MAIN`, thus making the comment
obsolete, with commit a35fe1f5f2.
Change-Id: I0c2dad773219da80cc4db04ad6a8007a03207e5c
They're currently documented as a 'compatibility hook'
in docs/contenthandler.txt. No longer used in any Wikimedia-hosted
git repository.
Superseded by the ContentHandlerDefaultModelFor hook.
Change-Id: I212230da7d6080cf500f930d4aa5a9024959d5f9
In trying to avoid hitting RequestContext::getLanguage() from a call to
User::idFromName(), I05aacd30 made it no longer safe for user input.
A closer analysis of the call stack involved reveals that
Title::makeTitleSafe() is constructing a prefixed dbkey using the
localized name for NS_USER, and then Language::getNsIndex() is needing
to get the variant in order to handle that localized name. But if we use
the canonical name for NS_USER, Language::getNsIndex() short-circuits
and skips the problematic code path.
And it turns out that it doesn't actually matter which prefix
Title::makeTitleSafe() uses, since the prefix doesn't make it anywhere
into the resulting Title object. So let's revert I05aacd30 and Ibeef0409
and just do that instead.
Change-Id: Ib902573996c69d1e77527cc7b2faf4e7fa5d3daf
* AbortMove hook is removed in favor of two more specificly focused
hooks: MovePageCheckPermissions and MovePageIsValidMove.
** MovePageIsValidMove is for extensions to specify whether a page
cannot be moved for technical reasons, and should not be
overridden.
** MovePageCheckPermissions is for checking whether the given user
is allowed to make the move.
* Title::moveNoAuth() deprecated
* Title::moveTo() deprecated
* Title::isValidMoveOperation() broken down into
MovePage::isValidMove() and MovePage::checkPermissions().
* Title::getTitleProtection() is now public, and returns
unprefixed fields
Change-Id: Ic5026384b92a0d68d628397ffe1de6e5b6183f02
Anything else is confusing, especially given the message text
we have there.
Example:
https://www.mediawiki.org/wiki/Special:Search?search=en%3Afoo&fulltext=1
Also fix the documentation of Title::isLocal as that was misleading
and fooled me (in PS1).
Change-Id: Iccb69de4c7243bf144a12deb8b86505e56a111dd
This moves most of the Title::moveTo() function into a new MovePage
class, and the entirety of the Title::moveToInternal() function.
No actual code was changed except for requiring a User object in
function arguments instead of relying up on $wgUser, and changes
to "$this" as necessary.
Change-Id: I5479fa8f3920a51ddf789d55edae7dd0d9b24382
cl_type might need to be changed if the page was moved between
special-cased namespaces (Category ↔ File ↔ (other)).
Also update cl_collation, which also might have changed in the
meantime.
Bug: 69740
Change-Id: I46032a8ba04d77005731c02680f77a8808974087
