Part of the soft deprecated revision class, no known callers outside of a test, which hide the deprecation
Bug: T246284
Change-Id: I7b80c7e51e26845d2703d1dc5434baf9d0744d11
Part of the soft deprecated revision class, no known callers outside
of EditPage, which is updated, and tests, which hide the deprecation
Bug: T246284
Change-Id: I099cb93a12f3a1d9a720e18e3236374321ce7b0c
Also replace uses. Some callers had a user that could be null;
RevisionRecord::userCanBitfield requires a user, so add $wgUser
fallbacks at the callers with soft deprecations for using them,
and will hard deprecate in a subsequent task.
Bug: T245958
Change-Id: I137e21e3883b149fdd98d1b59d4e498d15b39dd9
Not passing a user to the following functions is deprecated:
* Title::getNotificationTimestamp
* Revision::newNullRevision
* WikiPage::insertProtectNullRevision
* PatrolLog::record
* LogEventsList::userCan
* LogEventsList::userCanBitfield
* LogEventsList::userCanViewLogType
* LogPage::addEntry
Bug: T242935
Bug: T243652
Change-Id: I8990bc16ac72680fb65f8ca37eb7908749a9e5cc
Added:
- ContentHandlerFactory
Tests:
- PHPUnit
Changed
- Calls of changed and deprecated
- DI for some service/api
Deprecated:
- ContentHandler::* then similar to ContentHandlerFactory
- ContentHandler::getForTitle
- ContentHandler::$handlers
Bug: T235165
Change-Id: I59246938c7ad7b3e70e46c9e698708ef9bc672c6
Scalar casts are still allowed (for now), because there's a huge amount
of false positives. Ditto for invalid array offsets.
Thoughts about the rest: luckily, many false positives with array offsets
have gone. Moreover, since *Internal issues are suppressed in the base
config, we can remove inline suppressions.
Unfortunately, there are a couple of new issues about array additions
with only false positives, because apparently they don't take
branches into account.
Change-Id: I5a3913c6e762f77bfdae55051a395fae95d1f841
These callers just need to load some data from DB_MASTER.
Subsequent code needing that latest title data should also use the
required flags, rather than relying on flakey global cache state.
Change-Id: I53248ea4b5bf1cd953f956c41b8244831ec5ef04
This removes most of the pre-actor user and user_text columns, and the
$wgActorTableSchemaMigrationStage setting that used to determine
whether the columns were used.
rev_user and rev_user_text remain 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_comment, rev_content_model, and
rev_content_format (and the addition of rev_comment_id and rev_actor).
ActorMigration'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. Code using
ActorMigration for accessing the core fields should be updated to use
the new actor fields directly. That will be done for in a followup.
Bug: T188327
Change-Id: Id35544b879af1cd708f3efd303fce8d9a1b9eb02
They belong in RevisionStore. This change removes the dependency on
Title for these methods and will assist in porting more code to
LinkTarget.
At the same time, deprecate the Title parameter to
RevisionLookup/RevisionStore getPreviousRevision/getNextRevision, and
add a $flags parameter to match the functionality of the Title versions.
Since code search turned up no callers that passed a Title outside core,
this variant is immediately hard-deprecated. The Title methods
themselves are only soft-deprecated.
Change-Id: I76bc6fd6ee1a9f35b5f29fa640824fb5da3bb78e
3e36ba655e added an option for passing a page ID to this method of
Revision, and e03787afd9 switched it to a Title and made it mandatory.
This behavior propagated to the method in RevisionStore. As far as I
can tell, the parameter does not help anything, but it can add a
database query to get the page ID if it's not cached, and impedes
conversion to LinkTarget. I can't figure out any reason to not
completely drop it. I've noted it as deprecated but still supported it
for now for compatibility -- I found one extension that does pass it.
(It's ignored, though, which theoretically would be a behavior change if
someone was passing a Title that didn't match the revision ID.)
While I was at it, I added the method to RevisionLookup, although it's
only used in later patches. Properly I should move that piece to a later
patch, but it didn't seem worth the effort.
I didn't change the Revision method, because the whole Revision class is
deprecated anyway.
Change-Id: I26ef5f2bf828f0f450633b7237d26d888e2c8773
This is semantically the same because the returned object can't be
anything but an object (which can never be false), or null. Personlly,
I find the more expressive "=== null" check does not help here, but
makes the code a little harder to read.
Change-Id: Ib7390a7680f24fec7f5b9cea716603c14ad3f2dd
This might hint at an edge-case in the PHP CodeSniffer sniff that should
detect if methods are separated by a single empty line. Feel free to
investigate. I, personally, can't invest more time in this than
suggesting this quick fix.
Change-Id: Ib3c60eac76f255b4fe929f7933de256222716576
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
Without this patch, getRevisionText would fail silently (by
returning false) when the text table no longer gets joined,
due to the switch to the new MCR schema.
Bug: T205808
Change-Id: Iffc25c82a5d2b865c28070c76156d39d390cc675
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
This patch exists to see if CI passes with
$wgMultiContentRevisionSchemaMigrationStage set to
SCHEMA_COMPAT_WRITE_BOTH | SCHEMA_COMPAT_READ_NEW.
NOTE: verify that $wgMultiContentRevisionSchemaMigrationStage
is explicitly set toSCHEMA_COMPAT_WRITE_BOTH | SCHEMA_COMPAT_READ_OLD
in production config (T197816) before merging this.
Bug: T198561
Depends-On: Ib718868d2c768b6ea851355eef047bc0e6593495
Change-Id: I15989adae2b5916577d164c50d7da88774e49324
Call the RevisionInsertComplete from RevisionStore for now, so extensions
that still rely on this hook don't break when more code uses RevisionStore
instead of Revision.
This specifically avoid breaking EventBus and Translate when If610c68f491
is merged.
Change-Id: I3356c8250d7934e0089d4627fdebddf7983f194f
Find: /isset\(\s*([^()]+?)\s*\)\s*\?\s*\1\s*:\s*/
Replace with: '\1 ?? '
(Everywhere except includes/PHPVersionCheck.php)
(Then, manually fix some line length and indentation issues)
Then manually reviewed the replacements for cases where confusing
operator precedence would result in incorrect results
(fixing those in I478db046a1cc162c6767003ce45c9b56270f3372).
Change-Id: I33b421c8cb11cdd4ce896488c9ff5313f03a38cf
This commit removes Revision::getRawUser(), Revision::getRawUserText(), and Revision::getRawComment(). All three were deprecated in 1.25 and are only used in unmaintained extensions.
Bug: T61113
Change-Id: I729985b791df89bc7e577fb823e647c48549e637
This introduces a convenience method for constructing a blob address
from a text ID. It's the inverse of SqlBlobStore::getTextIdFromAddress
Change-Id: I31b3ee5e40185c754fb2c119eb5edc50b903f5dc
This should have been done long ago. Now it is being done.
This also changes ar_text_id to NOT NULL, since it should never be null
anymore, and DEFAULT 0 in preparation for MCR stopping writing it.
Bug: T33223
Change-Id: I18f1c740b7537c7dc3cfeba9b241d0a9f31caa34
Storing the user name or IP in every row in large tables like revision
and logging takes up space and makes operations on these tables slower.
This patch begins the process of moving those into one "actor" table
which other tables can reference with a single integer field.
A subsequent patch will remove the old columns.
Bug: T167246
Depends-On: I9293fd6e0f958d87e52965de925046f1bb8f8a50
Change-Id: I8d825eb02c69cc66d90bd41325133fd3f99f0226
