I recently tried to enable an account using the administer users interface (that is, checking the account at /admin/user/user and choosing enable) that had previously been manually disabled by setting its status in the database to zero. I got the following errors (I'm running PostgreSQL):

* warning: pg_query(): Query failed: ERROR: zero-length delimited identifier at or near """" at character 74 in /var/www2/upgtesti/includes/database.pgsql.inc on line 125.
    * user warning: query: INSERT INTO bloginfo (uid, title, description, format) VALUES (0, "", "", 0) in /var/www2/upgtesti/includes/database.pgsql.inc on line 144.

The error itself can probably be attributed to the fact that single quotes should be used instead of double quotes. However, I'm not posting a path for that just yet, because the module seems to be working fundamentally wrong way. First, my opinion is, that nothing done on /admin/user/user page should cause bloginfo to change, unless the account is deleted altogether. Second, even if it should, your code tries to find out user's UID by calling arg(1), which is doomed to fail on admin pages. Thus, it should either omit altering bloginfo there at all, or find the UID using some more robust method.

Comments

plj’s picture

plj commented

Note: I've now created a separate issue (and attached a patch) for the broken PostgreSQL support.

mfer’s picture

mfer commented

My intent was not to have it run on the admin pages. Just on the user pages.

Let me try to get something straight just to clarify what's going on. You selected an account on /admin/user/user by check it's checkbox, selecting an update option from the drop down menu, and clicked update? Or, was it something else?

mfer’s picture

mfer commented

will fix when my host has my db back up and running. grrrr

plj’s picture

plj commented

My intent was not to have it run on the admin pages. Just on the user pages.

I think it should still run on admin page, if an account is deleted. Otherwise junk data (that doesn't belong to any user) is left in the database. But not otherwise.

However, I'm not sure if this works or not, because I rarely delete accounts, I just block them instead.

Let me try to get something straight just to clarify what's going on. You selected an account on /admin/user/user by check it's checkbox, selecting an update option from the drop down menu, and clicked update? Or, was it something else?

Yes, just that. I checked a user (I really did this for only one user) and chose update option Unblock the selected users. The user got unblocked, but I also got the stated SQL error.

Now that I've patched #146877 the query succeeds, but it makes no sense, because it just runs INSERT INTO bloginfo (uid, title, description, format) VALUES (0, '', '', 0). However, it seems that this is only done, if the line is not there yet. If it has already been inserted before, nothing happens.

Thus, I think I can cope with this… it is not very nice behaviour to INSERT an unnecessary db record, but it won't break things either. So if you fell lazy, you can just claim this bug to be by design. As log as #146877 gets fixed. ;)

plj’s picture

plj commented

As an afterthought: I think you could just add a test for arg(1) before writing anything to the database to make sure that it makes sense (it shoud be an integer and have a value > 0).

mfer’s picture

mfer commented

I feel lazy all right ;-) but I can't stand leaving some poor logic out there. It's just going to bug me so expect it to get fixed.

Though, if you can live with it I might wait a couple weeks. This is crunch time with reviewing core patches for D6.

mfer’s picture

mfer commented

the single quotes fixed this error but it's not throwing some ugly stuff into the database because it doesn't have the user info.... this should be fixed shortly

mfer’s picture

mfer commented
Status: Active » Fixed

This is fixed in head. After doing a little more bug fixing I'll post a release that contains this fix.

Anonymous’s picture

(not verified) commented
Status: Fixed » Closed (fixed)