Page MenuHomePhabricator

update.php doesn't work fully if previously it ran without appropriate permissions
Closed, ResolvedPublic


Author: checker

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

Version: unspecified
Severity: enhancement



Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 9:30 PM
bzimport set Reference to bz8641.
bzimport added a subscriber: Unknown Object (MLST).

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,

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.

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.

  • Bug 8862 has been marked as a duplicate of this bug. ***