Change tags to apply to an edit can now be passed directly to the
WikiPage::doEditContent function. They are then passed to the
RecentChange::notifyNew/Edit functions where tagging is made
after the recent change is saved. This ensures that other callers
of doEditContent will not run into the same issue as T100248.
ApiRollback is fixed in this way.
In addition, we'll have to pass tags in this way for core tagging
of edits (I2e48bd458fc8d7c289f04dc276f9287516e0b987), and this makes
it possible to merge the arrays of tags and call ChangeTags::addTags
only once.
Change-Id: I829960c7a33b70464065839d7504d7529dfd0b72
A few semantic changes result from this:
* If multiple pages are edited in a request, the updates happen
in the same order relative to each other, but all in one second
step instead of after each page edit.
* If the same page is edited twice in a request, the WikiPage hook
argument will reflect the last request edit, not always the edit
that fired the hook.
Bug: T120718
Change-Id: I9429f29e5a90f24e4d7af5797a80e63a9cc34146
ParserCache::get is documented for WikiPage, so do it from Article class
This avoids magic calls due Article::__call
Change-Id: I92b91bd112383d1c0132530c3325b39596d95768
Adds all public functions from WikiPage to Article
Adds all public functions from WikiFilePage that
are not in Article to ImagePage
WikiCategoryPage has no methods that need moving
Removed __call from Article
If extensions extend WikiPage and rely on the __call
method in Article they may break with this change.
They cal easily call $article->getPage()->method..
Change-Id: I8cd8d69d0d59c67f4879212535206688387bead4
With I779aa1c017abc9a17047fd5335f2d082148daa6f all public functions from
WikiPage were copied as delegator into Article.
Now remove the unused functions and add a release notes
Change-Id: I9cc79acedecb003048e1add568e8bba96ddbb41a
Add all public function from WikiPage to Article and replace the magic
__call
__call has the problem, that new functions to WikiPage will also be
available through Article.
It also makes deprecating of some functions harder. Having each function
as an own function will allow to add deprecated notice to just some and
maybe delete some functions earlier than others.
Also some static code analyzer can benefit from separately functions.
Change-Id: I779aa1c017abc9a17047fd5335f2d082148daa6f
Previously various language objects would install a hook to update the
shared conversion table cache when the object was constructed. This is
not a good idea since language objects may be constructed even when they
are not the content language, but only the content language is
associated with variant conversion and the conversion cache.
Instead, have WikiPage call a method on $wgContLang directly. I put this
with message cache update since the logic is almost identical.
Change-Id: Ief9c0ef993e39645e74a6e158cb4e6e2139ce91d
A few semantic changes result from this:
* If multiple pages are created in a request, the updates happen
in the same order relative to each other, but all in one second
step instead of after each page edit.
* If an extension set some extra Status info or errors via the
PageContentInsertComplete hook, they will not be seen by the
caller (unless it was a CLI script possibly). Few callers use
$status at all, and I did not see any that mutated it. Since
the page is already committed when this hooks run (as has always
been) they cannot veto edits and callers do not care or know what
to do with random hook-set status errors; there was never much use
in changing the Status anyway.
Bug: T120718
Change-Id: Ieba35056be31b2f648c57f59d19d3cbbe58f1b05
This makes the following (minor) fixes to file patrol:
- If a documentation page for a file was recently created
before the file itself was uploaded, and the page creation
was patrolled, this now allows to patrol the file upload
from the file documentation footer.
- It attempts to retrieve a recent change for the latest
file upload, even if patrolled, so that this info can
be cached.
- It makes some extra code comments.
Change-Id: Ibdebcbbee7c081b99372c44ca64b5ddd86ae5ace
This allows to patrol file uploads, both new files and new file
versions, from the description page, provided $wgUseFilePatrol
is set to true. Special:NewFiles can be filtered to hide patrolled
files.
Bug: T11501
Change-Id: If71af58719a4461f12d125455b7bef07164525ca
This makes it easier to migrate the methods to using atomic
sections without having the PageContentInsertComplete hook
change to ending up in separate transaction than
ArticleSaveComplete.
Bug: T120718
Change-Id: I492514413ec9c37c2f9343bb207798fc8e24a5a9
* Make the method sizes a bit more manageable.
This will be useful for replacing the begin/commit
calls later (with startAtomic/endAtomic).
* Cleaned up a few inconsistencies in code style.
Change-Id: I8d66503a5575ca369cd5feb56058af7d24001629
* 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
* Recursive link updates no longer mention an category changes.
It's hard to avoid either duplicate mentioning of changes or
confusing explicit and automatic category changes.
* LinksUpdate no longer handles this logic, but rather WikiPage
decides to spawn this update when needed in doEditUpdates().
* Fix race conditions with calculating category deltas. Do not
rely on the link tables for the read used to determine these
writes, as they may be out-of-date due to slave lag. Using the
master would still not be good enough since that would assume
FIFO and serialized job execution, which is not garaunteed.
Use the parser output of the relevant revisions to determine
the RC rows. If 3 users quickly edit a page's categories, the
old way could misattribute who actually changed what.
* Make sure RC rows are inserted in an order that matches that
of the corresponding revisions.
* Better avoid mentioning time-based (parser functions) category
changes so they don't get attributed to the next editor.
* Also wait for slaves between RC row insertions if there where
many category changes (it theory it could well over 10K rows).
* Using a separate job better separates concerns as LinksUpdate
should not have to care about recent changes updates.
* Added more docs to $wgRCWatchCategoryMembership.
Bug: T95501
Change-Id: I5863e7d7483a4fd1fa633597af66a0088ace4c68
This avoids contention slams and synchronous master DB writes
on HTTP GET requests.
Bug: T119742
Bug: T92357
Change-Id: I7b3ebac0d6a11542c47ddf3219911be54380c537
* Use READ_LATEST when needed to distinguish slave lag
affecting new pages from page deletions that happened
after the job was pushed. Run-of-the-mill mass backlink
updates still typically use "masterPos" and READ_NORMAL.
* Search for the expected revision (via READ_LATEST)
for jobs triggered by direct page edits. This avoids lag
problems for edits to existing pages.
* Added a CAS-style check to avoid letting jobs clobber
the work of other jobs that saw a newer page version.
* Rename and expose WikiPage::lock() method.
* Split out position wait logic to a separate protected
method and made sure it only got called once instead of
per-title (which didn't do anything). Note that there is
normally 1 title per job in any case.
* Add FIXME about a related race-conditions.
Bug: T117332
Change-Id: Ib3fa0fc77040646b9a4e5e4b3dc9ae3c51ac29b3
