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.

checker wrote:

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.

ayg wrote:

Repurposing to the suggestion about update.php.

checker wrote:

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.

ayg wrote:

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. ***