docs/design.txt was removed half a year ago in change I85be15a68f
(commit 6760216e10), and was long outdated even then, so let’s stop
pointing people at it.
Change-Id: I165ff1e12fb79c480930289d25833992be61b891
This removes most of the pre-CommentStore text columns, and the
$wgCommentTableSchemaMigrationStage setting that used to determine
whether the columns were used.
rev_comment remains in the code, as on Wikimedia wikis the revision
table is too large to alter at this time. A future change will combine
that with the removal of rev_user_text, rev_content_model, and
rev_content_format (and the addition of rev_comment_id and rev_actor).
CommentStore's constructor continues to take a $stage parameter, and
continues to have the logic for handling it, for the benefit of
extensions that might need their own migration process.
Bug: T166733
Change-Id: I1479c73774e01ead1490adf6128f820c09bce9d4
These are automatic, and happen regardless of whether the user
performing the action has patrol-related rights.
Bug: T190408
Bug: T184791
Change-Id: Icd1f3826c378ae759f501d87ffb9988766775b27
We currently show SVGs in default languages unless overridden with
lang=... URL parameter (and we have UI for setting it). This change
makes it display thumbnails in wiki language, if translation is available.
Bug: T210814
Change-Id: Ieb0b5e9e27f45b71ef119bb3c1d3f2cd4d7100e5
This mismatch between the documentation and how the code behaves was
introduced via Ia4c20a9 in December 2017. The getComment() methods have
never been documented to return null, but now do.
I tried to fix this both ways (see I32202df for the other approach), but
decided it's easier and cleaner to keep the null. Reasoning:
* The code behaves like this for more than a year already. Removing the
null would possibly be as desruptive as when it was introduced.
* Removing the null breaks Wikibase.
* I think returning null is the right thing to do.
I did a brief check of all callers of these two methods. I found a few
that might misbehave a little bit when they are confronted with null, e.g.
in MobileFrontend or Echo. In the vast majority of cases the null will be
silently casted to an empty string and be fine. In a few cases a "the
comment is empty" message might disappear, and the null be shown in the UI
instead, possibly resulting in an empty, confusing HTML element. I would
argue this is an issue with the frontend code then. It should not expect
to have access to all comments. Some might be supressed.
Bug: T174025
Change-Id: I0e1ff9686d1d875812460631c29330c398e74bcf
This would prevent double entries in logs when the same protection
is applied twice within a few minutes. Trying out usage of the
parent patch's new functionality.
Bug: T210983
Change-Id: Ibd6e481db2faa5955f52f36d5d7368adc8747c9c
Show log extract if the user is sitewide blocked, or is partially
blocked and not allowed to edit their user page or user talk page.
Bug: T203171
Change-Id: I9bcc50cfc1fad23f6bbbe5374a9a866f77bebc11
These new classes provide a mechanism for defining the
behavior of slots, like the content models it supports.
This acts as an extension point for extensions that need
to define custom slots, like the MediaInfo extension
for the SDC project.
Bug: T194046
Change-Id: Ia20c98eee819293199e541be75b5521f6413bc2f
Before I81a70ca03fd219d2e96b17714645d9cc4f99b3b9
the archivedRevisionCount argument of the ArticleDeleteComplete
hook used to be an integer, now it's an string. This is backwards
incompatible and needs to be changed back.
Bug: T210013
Change-Id: I297594803fe05cc00cdf209696933b2450d020b6
Added __EXPECT_UNUSED_CATEGORY__ as a behavioral switch. Adding
this switch to category pages prevents them from appearing in
Special:UnusedCategories.
Bug: T96041
Change-Id: I055e59f5311347155e0f801dd5ec9a6d4a68c9cc
Use these in place of various wfWikiID() calls.
Also cleanup UserRightsProxy wiki ID variable names and removed unused
and poorly named getDBname() method.
Change-Id: Ib28889663989382d845511f8d34712b08317f60e
The rd_fragment field is 255 bytes wide, but there is no limit on how
long title fragments can be. We don't want to let the database silently
truncate the fragment for us, because that can result in invalid UTF-8.
Instead, truncate it before insertion in a UTF-8-aware way.
Bug: T207876
Change-Id: I12745f3f4c174eaced56d80f3661a71d0e5637e6
Replace a fragile <div> wrapper with the robust
OutputPage::wrapWikiTextAsInterface() wrapper.
Bug: T205624
Change-Id: I0a1ba0da6af97f0233afdd8ba7202abed0998419
ImagePage::render() was calling parent::view() instead of
parent::render(), thus skipping Article::render() entirely.
Therefore the logic to disable section edit links (and also,
to add an 'X-Robots-Tag: noindex' header) was not being used.
This fixes T65891 and T21415 for pages in 'File:' namespace.
Bug: T206546
Change-Id: I36ae716c9a363ae29b7a785cc41430301250baba
This ensures that broken messages can't break the <div> wrapper and
that the output is tidy.
Bug: T205624
Change-Id: I2511adf593a13528e205a82d9fcdc8a524d0a95f
This change ensures that the output is tidy, and is necessary to support
future parsers which will not be able to produce untidy output.
Bug: T198214
Change-Id: I743f4185a03403f8d9b9db010ff1ee4e9342e062
If a user creates a redirect to a Media namespace title, a fatal
error is thrown on viewing such rediect because we protect against
redirecting to virtual namespaces. This fix catches this kind of
redirect and modifies the namespace to be File before the Title object
is created.
Follow-up from 613e2699.
Bug: T203942
Change-Id: Ib211d98498f635862fea6bf3e7395f4f8718b3d8
When this was originally written, the plan was to read both the old and
new fields during the transition period, while stopping writes to them
midway through. It turns out that the WHERE conditions to do read-both
correctly are generally not handled well by the database and working
around that would require a lot of complicated code (see what's being
removed from ApiQueryUserContribs here, for example).
We can simplify things greatly by instead having it write both fields
during the transition period, reading from the old for the first part
and the new for the second part, as is being done for MCR.
Bug: T204669
Change-Id: I4764c1c7883dc1003cb12729455c8107319f70b1
Depends-On: I845f6ae462f2539ebd35cbb5f2ca8b5714e2c1fb
Depends-On: I88b31b977543fdbdf69f8c1158e77e448df94e11
During development a lot of classes were placed in MediaWiki\Storage\.
The precedent set would mean that every class relating to something
stored in a database table, plus all related value classes and such,
would go into that namespace.
Let's put them into MediaWiki\Revision\ instead. Then future classes
related to the 'page' table can go into MediaWiki\Page\, future classes
related to the 'user' table can go into MediaWiki\User\, and so on.
Note I didn't move DerivedPageDataUpdater, PageUpdateException,
PageUpdater, or RevisionSlotsUpdate in this patch. If these are kept
long-term, they probably belong in MediaWiki\Page\ or MediaWiki\Edit\
instead.
Bug: T204158
Change-Id: I16bea8927566a3c73c07e4f4afb3537e05aa04a5
Pages with many revisions experience transaction size exceptions,
due to archiving revisions. Use the job queue to split the work
into batches and avoid exceptions.
Bug: T198176
Change-Id: Ie800fb5a46be837ac91b24b9402ee90b0355d6cd
The old behavior was that the audience was RAW if the revision object
parameter got passed in, otherwise PUBLIC. This was undocumented and
not used outside core; this patch gets rid of it in favor of an
explicit argument.
Bug: T205578
Change-Id: Ic7cdb38f658f6d85c48ff13c7f84c64a45c9b1ee
