Last modified: 2008-12-10 14:13:12 UTC
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.
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.