Page MenuHomePhabricator

API edit "section" parameter really bad handled
Closed, ResolvedPublic

Description

It seems that a new bug was recently introduced to the trunk.

What to do:

  • Edit any article with many sections an try to rewrite completely the article (no "section" parameter)

What you get:

  • Your new content replaces only the introduction (section=0)

What you want:

  • Your new content replacing the whole page

Remarks:

  • The live version (r43634) does not have the bug, but the head does has the problem.
  • Adding $params['section'] = ''; line 120 of ApiEditPage.php avoids the problem.
  • The problem does not concern the user interface... only the API.
  • I think that something was changed in EditPage.php with the form field handling and that impacts the API.

Version: 1.14.x
Severity: blocker

Details

Reference
bz16581

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 10:30 PM
bzimport set Reference to bz16581.

Tracked it down to r44015 (Article.php):

...
+ function replaceSection( $section, $text, $summary = '', $edittime = NULL ) {

		wfProfileIn( __METHOD__ );
  • if( $section == '' ) {
  • // Whole-page edit; let the text through unmolested.

+ if( $section === '' ) {
+ // Whole-page edit; let the whole text through
...

If you edit through the API, $section is null here, so the identity operator won't work here.

I'd suggest to just use ..if(!$section) .. or would that be bad style?

On second thought, (!$section) of course wouldn't work, as '0' is false, too. So probably just change it back to ($section == '').

I'm marking this bug as blocker for now, as it really should be fixed before the next scap, or else the bots out there would create a giant mess on all projects within minutes.

(In reply to comment #2)

On second thought, (!$section) of course wouldn't work, as '0' is false, too.
So probably just change it back to ($section == '').

I'm marking this bug as blocker for now, as it really should be fixed before
the next scap, or else the bots out there would create a giant mess on all
projects within minutes.

Good idea. I'll tell Brion about this to make sure he doesn't accidentally scap this. I'd fix it earlier, but I'm kind of busy this week and I haven't looked into the possible side effects of changing === '' back to == ''.

(In reply to comment #3)

and I haven't looked
into the possible side effects of changing === '' back to == ''.

Turns out I didn't need to, passing '' instead of null was good enough. Fixed in r44394.