Last modified: 2007-02-02 21:37:26 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: http://en.wikipedia.org/wiki/Wikipedia:Administrators'_noticeboard/IncidentArchive144#Blocks_failing which looks like the same issue but happening on wikipedia...not sure if that was resolved. Thanks, Chris Special:Version info: * MediaWiki: 1.9.0 * PHP: 5.2.0 (apache2handler) * MySQL: 5.0.27-standard
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.
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, Chris
Closing as FIXED.
Repurposing to the suggestion about update.php.
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.
Ah, okay.
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 necessary. Fixed on trunk in r19382, on 1.9 branch in r19383; will be in 1.9.1.
*** Bug 8862 has been marked as a duplicate of this bug. ***
