This also removes assumptions that when a page
in one Namespace should be watched / removed
that the page in the talk / subject ns for the
page should have the same action applied
This should maintain all backward compatability
for the WatchedItem class
This also includes tests written by:
- WMDE-leszek
- Addshore
Bug: T127956
Change-Id: Iad9abafe4417bb479151a3bfbee6e1c78a3afe3c
If a page language in database is set then use the current preferred variant
of this language.
Bug: T117667
Change-Id: Idfe1165346ae0068a4b73de441dc9dfa107b8e8b
If the Title object isn't the title of the current viewed WikiPage, the page_lang
field of the database isn't requested. This results in the problem, that
Title::getPageLanguage() always returns the default content language, even if
the page language is different (changed with Special:PageLanguage, if
wgPageLanguageUseDB is true). That is problematic for the Translate extension,
which relies on the correct page language.
This change makes sure, that getPageLanguage() always return the correct page
language. If the page language isn't loaded already, Title::getPageLanguage()
now does a database lookup (if $wgPageLanguageUseDB is true) to get the correct
page language. It will use LinkCache for the page_lang field.
Bug: T121666
Change-Id: I0ae5ea39f7a124ed427ca5dfb26c1a116b27a94e
With the roll-out of the Gadget namespace, these are going to be
especially misleading and likely to cause bugs.
Change-Id: I61f1f56762711fab173bbc54d110a7c48604d464
This will always return a MediaWikiTitleCodec object.
This is called in Title::secureAndSplit which expects
the method splitTitleString which is only in this
implementation and not the interface
Change-Id: Ibb6cdcf7deb6c1080e320379aa58981e9935ca33
To be used by things that do not care if they are
passed a Title or TitleValue so long as it has a
dbkey, namespace, possible fragment and text
Example uses include:
LinkBatch::addObj
MediaWikiPageLinkRenderer methods
MediaWikiTitleCodec methods
PageLinkRenderer methods
TitleFormatter methods
Change-Id: I2aa1a82129bb01155924a8e6a403c7a47391432f
This is the cause of the T76305 debug log entries relating to SpecialExport
and Echo.
Bug: T76305
Bug: T116034
Change-Id: I64d629d31be79c4b4702a4298bce68fd544df6e8
getPageLanguage() from ContentHandler already returns a Language object.
wfGetLangObj is not necessary.
Change-Id: I556236419e445ce549598dd1752b29f619b0ca3c
* Using addUpdate() makes sure purges are coalesced and
de-duplicated.
* Also removed incosistent $wgUseSquid checks. If CDN caching
is not used, then $wgSquidServers will just be empty anyway.
Bug: T119016
Change-Id: I8b448366f037f668385d252f9d68289b71d1a707
Specify null as allowed value to make this method more easy to use.
The method is often used like that already and this makes it official.
Previously we were on a months-long trajectory to try and remove all
instances of passing null, but it was a never-ending quest (with new
ones introduced all the time). And in all cases the added handling
in the caller is the same as the handling for when this method
returns null. Requiring the caller to bounce null makes code more
complex, duplicates logic and serves no reason. Let this method be
a non-throwing validation method that returns null if given null.
Bug: T76305
Change-Id: I47517021471ac6fd6daca6deee039c8047224a33
Using the new system introduced in
1c57794e37 (see T47843).
This change allows Title::getUserPermissionsErrors() to include
MessageSpecifiers instead of string message keys in its return value.
This doesn't seem to have any bad effects, and should work seamlessly as
long as callers aren't trying to do anything stupid and just pass the
value to PermissionsError or OutputPage::showPermissionsErrorPage()
or wfMessage() or some such.
If the callers *are* trying something stupid, nothing worse than
duplicated or otherwise less-than-perfect error messages (in code
which tries to handle some message keys specially) should happen.
(I fixed wfMergeErrorArrays(), but who knows what else lurks in all
this code.) Any problems should only affect new-style errors using
MessageSpecifier, though.
Since MessageSpecifiers tend to be stringable, we probably won't get
fatals, but might get incorrect checks. Should we try to log this
happening somehow?
Goes with I42a0c5b0ea7e61088dd609b764dd7d1396c60cd5 in TitleBlacklist.
Bug: T115258
Change-Id: I1334ba21a2862973a9d8ff5be2c9bec06a82698b
None of these places need it to happen right now,
so for performance and consistent style, defer
them too.
Change-Id: Id0a2a352bfc04a783c3ebc54b059b241bb6a6f7e
This allows them to be stored in the session, for example.
Note that properly serializing a Message requires that all its
parameters be serializable as well; we don't attempt to account for that
here.
Change-Id: I3a42a2a883e8eef900eeb02355fc3b064411f642
strtr() is marginally faster as it runs through the string only
once. A better fit for one-for-one character translation.
The strtr() function also supports an associative array as second
parameter for entire string replacements. This, too, has the same
performance and predictable behaviour (starts with the longest key).
Whereas str_replace is for more aggressive needs where you want
multiple passes until there are no further matches.
The associative array form is arguably also easier to understand
and harder to mess up since the needle/replacement pairs are
explicitly connected instead of two separate arrays.
Also:
* Use getFormattedNsText instead of strtr( getNsText, .. ) which
reduces duplication of this fact through a more semantic intent.
Change-Id: Ie23e4210a5b6908dd79eebc8a2b931d12fe31af6
Anomie pointed out that I am the only person who writes it as "? :", and
that all other instances in core use no space.
Change-Id: I01b68eed5f866fa7582fb4257f795c4c2d1244d1
* 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
