Only one remaining use, not deployed, patch pending at
I0b088f5851cf63b2bb0ff1d7127e2fbefcd2c62e anyway
Bug: T246284
Change-Id: I40e26ee669fd914db781fb3ace8e21148fb5c108
Also updates CategoryMembershipChange to accept a RevisionRecord
instead of a Revision.
Bug: T246284
Change-Id: I30024b7278e108b0f4e20ef1eb44647916fad47c
As well hard-deprecate RevisionStore::listRevisionSizes.
It was marked as @deprecated, but the release for the
deprecation was not specified. Let's say it's 1.35.
Additionally, in order to avoid temporary code duplication,
listRevisionSizes now uses getRevisionSizes and ignores the
database object injected into it. This is ok since we're
hard-deprecating the method and all the usages have been
removed.
Bug: T246284
Change-Id: Ifad1c25a0af892b88fce492b2d34c8cf71279b70
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
