Last modified: 2007-02-02 21:37:26 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T10641, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 8641 - update.php doesn't work fully if previously it ran without appropriate permissions
update.php doesn't work fully if previously it ran without appropriate permis...
Product: MediaWiki
Classification: Unclassified
Installer (Other open bugs)
All All
: Normal enhancement (vote)
: ---
Assigned To: Nobody - You can work on this!
: 8862 (view as bug list)
Depends on:
  Show dependency treegraph
Reported: 2007-01-15 09:13 UTC by Chris Hecker
Modified: 2007-02-02 21:37 UTC (History)
1 user (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Description Chris Hecker 2007-01-15 09:13:32 UTC
When attempting to block a user by username on my installation of 1.9.0
(upgraded with update.php from 1.6.8 a couple days ago), but unchecking the box
for autoblocking blocking the ip, gives the following error page:

Database error
A database query syntax error has occurred. This may indicate a bug in the
software. The last attempted database query was:

    (SQL query hidden)

from within function "Block::insert". MySQL returned error "1054: Unknown column
'ipb_enable_autoblock' in 'field list' (localhost)".

I searched around to see if anybody else was having this problem, but I could
only find this link:'_noticeboard/IncidentArchive144#Blocks_failing

which looks like the same issue but happening on wikipedia...not sure if that
was resolved.


Special:Version info:
    * MediaWiki: 1.9.0
    * PHP: 5.2.0 (apache2handler)
    * MySQL: 5.0.27-standard
Comment 1 Andrew Garrett 2007-01-15 09:16:09 UTC
The column ipb_enable_autoblock was not inserted into your database. I have no
idea why this would not happen, unless update.php failed for some reason. Do you
have the output that update.php gave? Perhaps you could try running it again and
pasting the output.
Comment 2 Chris Hecker 2007-01-15 09:35:22 UTC
Hi, before I saw your reply I logged into the mysql db and snooped around. 
There was an ipblocks_old table in there as well, and it had an
ipb_enable_autoblock column, so I did a manual alter table ipblocks and made a
tinyint(1) not null default 1 column, and now things are working and I blocked
the user successfully.

My update.php failed once because I didn't give it the right mysql user
permissions, but I fixed the AdminSettings.php and reran and it ran to
completion with no errors.  I don't have the old output, unfortunately.  I
wonder if update.php can be made more robust in this case.  Is there an easy way
for me to see if there are any other columns missing from my tables?

Thanks for the speedy reply,
Comment 3 Andrew Garrett 2007-01-15 10:03:20 UTC
Closing as FIXED.
Comment 4 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-01-15 16:08:51 UTC
Repurposing to the suggestion about update.php.
Comment 5 Chris Hecker 2007-01-15 19:57:10 UTC
Just to be clear, update.php failed and said why (about not having permissions),
the problem was that when I fixed the permissions and reran it, it completed
with no errors, but silently left the db in a minorly hosed state (missing the
ibp_enable_autoblock column in the ipblocks table).  So, I think the noisiness
level is fine, it just needs to do more validation that it actually got the
tables updated correctly.

Comment 6 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-01-15 20:49:17 UTC
Ah, okay.
Comment 7 Brion Vibber 2007-01-17 11:54:32 UTC
On investigation, this doesn't actually appear to be a permissions problem at
all. There was simply an operation out of order in the updates applies to the
ipblocks table.

The update for ipb_anon_only does a total replacement of the ipblocks table in
order to apply a unique index at the same time. A later change, adding the
ipb_enable_autoblock field, was erroneously listed _before_ this change in the
updates list. As a result, upgrades from 1.7 or earlier would end up missing
this field as the ipb_anon_only update's new copy of the table dropped the
field. A second updater run would restore it, but this should no longer be

Fixed on trunk in r19382, on 1.9 branch in r19383; will be in 1.9.1.
Comment 8 Brion Vibber 2007-02-02 21:37:26 UTC
*** Bug 8862 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.