Page MenuHomePhabricator

EditPage::getCurrentContent unexpectedly changes $currentModel and $currentFormat
Closed, ResolvedPublic

Description

tl,dr: Remove the ability of EditPage::getCurrentContent to change other stuff unexpectedly and function only as a getter


Will working through the EditPage class for T157658: Factor out a backend from EditPage / T20654: EditPage.php needs rewrite: Separate DB and UI logic, I discovered that calling EditPage::getCurrentContent from within the class (i.e. $this->getCurrentContent()) does more than documented:

/**
 * Get the current content of the page. This is basically similar to
 * WikiPage::getContent( Revision::RAW ) except that when the page doesn't exist an empty
 * content object is returned instead of null.
 *
 * @since 1.21
 * @return Content
 */

Thus, calling it at the wrong time can break things.


History:
The overwriting was added by @daniel in 2012 in [1] as part of reworking EditPage to use the content object - work in horrible progress. At the time, it included a comment #FIXME: nasty side-effect! A few months later, in [2] the comment was changed to # nasty side-effect, but needed for consistency, which is how it remained until T139249 replaced it with Content models should always be the same since we error out if they are different before this point. (the current comment)

[1] https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+/c6eaef668133657fa1dc06b33643e2eed5a8a3aa%5E%21/#F2
[2] https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+/a1f145591b343f8e278603de84fc0f926960cf28%5E%21/#F0


Prior tasks:
In T139249: Show changes button on edit page does not work when using a non-default format with a content model that supports multiple formats, logging was added whenever the content model and format were being overwritten
In T145044: Clicking undo on an edit that changed the content model results in a MWException, undoes were exempted from the model and format being overwritten

Currently, when these overwrites occur, debug logs are created in the editpage channel. Are there any recent entries of Overriding content model from current edit ... or Current revision content format unsupported. Overriding ...? If not, I propose that the overwriting be removed. According to the inline comment, the content model (and format) should already be the same when they need to be.

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald Transcript
DannyS712 added subscribers: Bawolff, Legoktm.

Adding subscribers of the previous related tasks
Demonstration that this breaks things if called at the wrong time: https://gerrit.wikimedia.org/r/592445 - just adding $ignoreThisUnusedVariable = $this->getCurrentContent(); causes a test failure

Change 593649 had a related patch set uploaded (by DannyS712; owner: DannyS712):
[mediawiki/core@master] EditPage::getCurrentContent don't change $currentModel or $currentFormat

https://gerrit.wikimedia.org/r/593649

eprodromou triaged this task as Medium priority.

@eprodromou can I ask why this was reassigned, given that I have a patch already submitted?

@eprodromou can I ask why this was reassigned, given that I have a patch already submitted?

It was assigned to me for review. Makes it easier for me to keep track. Unfortunately, Phabricator only has one "assignee".

If that makes things harder to track for you, just assign them back.

@eprodromou can I ask why this was reassigned, given that I have a patch already submitted?

It was assigned to me for review. Makes it easier for me to keep track. Unfortunately, Phabricator only has one "assignee".

If that makes things harder to track for you, just assign them back.

No problem, was just wondering.

{{ping}} @daniel any update on the review? This is going to block T157658: Factor out a backend from EditPage at some point

The proposed change is VERY scary. No explanation was really provided for why is this code not needed anymore, and I do not believe this code is no-op.

As a start in investigation, I propose to create a bogus change where the logging in that area is replaced with throwing an exception - let's see if any tests in CI fail.

I couldn't find the logs in production, so this makes me think the change is going to the right direction.

The proposed change is VERY scary. No explanation was really provided for why is this code not needed anymore, and I do not believe this code is no-op.

As a start in investigation, I propose to create a bogus change where the logging in that area is replaced with throwing an exception - let's see if any tests in CI fail.

I couldn't find the logs in production, so this makes me think the change is going to the right direction.

I don't think the logs are sent to production logstash - should they be to check if they exist?

Change 636983 had a related patch set uploaded (by Ppchelko; owner: Ppchelko):
[operations/mediawiki-config@master] Temporary enable 'editpage' warn logging

https://gerrit.wikimedia.org/r/636983

I don't think the logs are sent to production logstash - should they be to check if they exist?

right. I am always getting confused with these logging settings thingy.. https://gerrit.wikimedia.org/r/636983

Change 636983 merged by jenkins-bot:
[operations/mediawiki-config@master] Temporary enable 'editpage' warn logging

https://gerrit.wikimedia.org/r/636983

Now we have some logging in beta and production around the code @DannyS712 proposes to drop. let's wait and see if it's ever executed.

Mentioned in SAL (#wikimedia-operations) [2020-10-28T18:55:56Z] <tgr@deploy1001> Synchronized wmf-config/InitialiseSettings.php: Config: [[gerrit:636983|Temporary enable 'editpage' warn logging (T251023)]] (duration: 00m 57s)

Now we have some logging in beta and production around the code @DannyS712 proposes to drop. let's wait and see if it's ever executed.

Sure - how long should we wait?

Next week (Nov 02-08) train will already have a scary number of EditPage changes, so piling this one on top is kinda risky. But week after that will probably have no train since there will be a lot of holidays which would means this will be blocked for quite a while.

Let's reconvene on Monday and think it through again if there's still no log messages.

Next week (Nov 02-08) train will already have a scary number of EditPage changes, so piling this one on top is kinda risky. But week after that will probably have no train since there will be a lot of holidays which would means this will be blocked for quite a while.

Let's reconvene on Monday and think it through again if there's still no log messages.

Any log messages so far? This is going to be blocking further progress fairly soon, since SelfRedirectConstraint and the rest of MissingSummaryConstraint depend on the current content

None, and we've waited a long long time. Let's remove it.

Change 593649 merged by jenkins-bot:
[mediawiki/core@master] EditPage::getCurrentContent don't change $currentModel or $currentFormat

https://gerrit.wikimedia.org/r/593649

DannyS712 claimed this task.
DannyS712 removed a project: Patch-For-Review.

Change 640491 had a related patch set uploaded (by DannyS712; owner: DannyS712):
[mediawiki/core@master] EditPage::getCurrentContent - $content is never false

https://gerrit.wikimedia.org/r/640491

Change 640491 merged by jenkins-bot:
[mediawiki/core@master] EditPage::getCurrentContent - $content is never false

https://gerrit.wikimedia.org/r/640491