With all the recent improvements, it's time this module got
promoted away from legacy. Its no longer just an old script to
that provides preview functionality and is minimally
maintained within "legacy", its reborn!
Minor clean up follows-up:
* e75054174c
* b12dc64a11
Change-Id: I85ca97a1d8df25a09baad78030d6da379a06c0f1
Make userWasLastToEdit a static method in the Revision class, so it can be
reused by extensions, etc.
Change-Id: Ib44423c3544dabab3be7fe6eb675315f2480838e
- This is needed to for I90965346 ((bug 37453) Move
$wgDisable(Lang|Title)Conversion to ParserOptions)
because that change sets an option based on the Title,
and I don't want to duplicate that to all ParserOptions
that need it.
- Refactored ApiParse to have a WikiPage object available
and changed some part to take advantage of having this
object available. Also used ApiBase::getTitleOrPageId()
to reduce code duplication.
Change-Id: Iec98e472af9c43d940f77261367a796b0d7b4b54
New copyright warning is to be just above the edit box.
This message is intended to be optional and locally customized.
Similar to editpage-tos-summary.
See Micro Improvements for more information.
http://www.mediawiki.org/wiki/Micro_Design_Improvements
Change-Id: Ifbd842ebef8775630d97491a3c735e046df5d0df
This comes from
https://translatewiki.net/wiki/Thread:Support/MediaWiki:Missing-article
that asks for a link to the deletion log in the
'missing-article' message.
Instead of simply changing that message I replaced
it with two news messages 'missing-revision' when trying
to view an old revision and 'difference-missing-revision'
when showing a difference. This removes the "lego"
construction of 'missing-article' with 'missingarticle-rev'
and 'missingarticle-diff' submessages.
I had to keep current messages since they are still
used in extensions.
Change-Id: Ibe60c84cfea922a78b3ad22cc48185a109cd617d
* Previously, this code would select FOR UPDATE unless ALF_NO_LINK_LOCK
was set in $wgAntiLockFlags (which in fact was set for wmf sites for ages
to reduce contention). In this case, it was just loading from the master,
without locking, and relying on the page_latest check. Now, it just never
selects FOR UPDATE, regardless of the lock flags, relying on page_latest.
Change-Id: Ie6301de4415f56e6be3899cf4ab37924963ce8c4
Language::truncate subtracts the length of ellipses from the whole
length since 1.18, that means, there is no need for a buffer for the
ellipses.
Change-Id: I5c39a6c4160f16156c8928dd954f065f9e3c7a5c
When inserting XML elements inline <such as this one>, doxygen chokes
about it not being known. Simply enclosing the tag in double quotes
prevents doxygen from emitting a warning.
Also enclosed a few invalid functions calls such as \. and double quoted
the HTML entities such as &foobar;
Change-Id: I4019637145e683c2bec3d17b2fd98b0c50a932f1
* The problem is that Title::userIsWatching() relies on $wgUser,
which is not suitable on every case. Instead User::isWatched()
requires both an User and a Title object.
* Replaced all core calls from the former to the latter
* Added a cache in User for the WatchedItem instances so we do not
need to do a database request every time something want to know
whether a page is watched or not, which can happen several times
per request.
Change-Id: Ifa9c55b7ffb487ce6893c74df233eedc7654dc5e
This way other code will be able to obtain the copyright warning without
duplicating the logic. Kept getCopyWarn() around for backwards
compatibility
Change-Id: I439d2b8a19c35716b208ae7f9926cd92ab482777
Aborting a save from the ArticleSave hook and putting an error in
$status didn't actually propagate the error message to the user, but
instead displayed the edit conflict page (!). Fix this so that if we get
an unrecognized error from ArticleSave, we treat it as an extension
error and render it rather than going into conflict mode.
Similarly, make the API attempt to render the error through
dieUsageMsg() like it already does for AS_END
Change-Id: Iccf78480240d0c7ed321438c8190472805957099
In WikiPage.php:
* Added WikiPage::$mDataLoadedFrom to store the source of the data used to load the state of the object and four new WikiPage::DATA_* constants for its possible values.
* Added WikiPage::convertSelectType() to convert 'fromdb', 'fromdbmaster' and 'forupdate' to the new WikiPage::DATA_* constants.
* Added $options to WikiPage::pageData(), WikiPage::pageDataFromTitle() and WikiPage::pageDataFromId() so that the "FOR UPDATE" option can be passed to DatabaseBase::select().
* Added new possibility "forupdate" to WikiPage::loadPageData() load the data from the master database using SELECT FOR UPDATE; this avoids to have to do this by LinkCache (via Title::getArticleID( Title::GAID_FOR_UPDATE ) )).
* Changed WikiPage::doDeleteArticleReal() to use this new feature so that all the data stored in WikiPage is up-to-date.
My point is also to deprecate the loading using SELECT FOR UPDATE in Title and remove LinkCache::forUpdate() at some point (there are still one usage in Title::moveTo(), two other in UploadFromUrlTest plus some in extensions).
In EditPage.php:
* Don't call WikiPage::clear() after fetching informations from master, this destroys all we work we did to get the correct data.
* Reload the whole data from master using SELECT FOR UPDATE directly in WikiPage and not only in Title. The problem was that before, the up-to-date information was only available in Title and not in WikiPage.
Consider the following sequence from a MySQL prompt (where both revision 1 and 2 belong to page one, revision #2 being the current one):
mysql> UPDATE page SET page_latest=1 WHERE page_id=1;
mysql> COMMIT;
// Now grad the edit form for page #1 from the web and do some changes
mysql> BEGIN;
mysql> SELECT page_latest FROM page WHERE page_id=1 FOR UPDATE;
// Now submit the web form
mysql> UPDATE page SET page_latest=2 WHERE page_id=1;
mysql> COMMIT;
Before you ended-up with a "edit conflict" form with revision #1's text being displayed as current text (even if the texts are mergeable), due to the fact that
in the submit request the WikiPage object was loaded at the moment where page_latest was 1 (certainly due to MySQL's "consistent read" feature) making the
"UPDATE page SET ... WHERE page_id=1 AND page_latest=1" query of WikiPage::updateRevisionOn() return zero row, and thus WikiPage::doEdit returing a fatal Status object with message "edit-conflict".
Now the SELECT FOR UPDATE is done in the WikiPage, meaning that the object has the correct data and EditPage will correctly try to merge the revisions (and show the correct edit conflict if needed).
Change-Id: Ic4878ddb4dd96432b7ecaf43f9f359458d966999
Change editnotice from content language to user language. I see no
need to disable possible translations (for multilingual wikis). As
there is no default content, it'll always default to the editnotice
in the content language anyway. Slashes in page titles are converted
to hyphens, so there are no collisions.
Patch set 3, 4: Rebase against master
Patch set 5: wrap commit msg
Change-Id: I3d7ccec0bf407324821c3c853a60c27db5e5c519
Fix notices from r94259 due to undefined variables
$previewtext and $class in the isWikitextPage()==true case.
Change-Id: I6ae2486d8860d2c28d656cdbd594ebc3a1263537
This is a followup to https://gerrit.wikimedia.org/r/#change,3978 .
Splitting the message previewnote to two messages: one is the note
itself, as it was before change 3978, and the other is the link text.
This change relieves the translators from the need to type wiki code
in the translated message and to wonder whether they should translate
"editform" or not.
Change-Id: I50aaf6dd48aaeee86cacf5c8fc06594869b38fd9
message text
This is useful, because the textbox is already preloaded with the
default message text and than it is nice to get the diff against that
text.
Change-Id: Icbfb0090c32ea09e34ec3ccba26863189854f8a6
Allow spamPageWithContent() to accept an array of matches, rather than just one.
Not dependent on other half of fix.
Change-Id: I75faac51f24bbb2569b36bc2e44f3cd5c43b1bd7
