Bug during installation of WordPress 2.3.2, 2.3.3

[marcgeldon]

There is a problem on different servers installing the new WordPress 2.3.2. I used Google and found out, that several other people have the same problem:

I cannot run the installation, because I get several SQL exceptions (for example something like: WordPress database error Table 'wordpress.wp_options' doesn't exist for query SELECT option_value FROM wp_options WHERE option_name = 'siteurl...

The function which creates the problem is "is_blog_installed()" in the file "/wp-includes/functions.php". In line 896 the function is trying to access tables, which do not exist at this time (because WordPress is not yet installed).

"is_blog_installed()" is called in line 168 in the file wp-settings.php. "wp-settings.php" is called in the file "wp-config.php" which is called from the "install.php"

If you need webspace to test or have any further questions, just contact me.

That is expected and shouldn't hurt anything. We can suppress the message inside is_blog_installed().

Replying to marcgeldon:

I cannot run the installation, because I get several SQL exceptions (for example something like: WordPress database error Table 'wordpress.wp_options' doesn't exist for query SELECT option_value FROM wp_options WHERE option_name = 'siteurl...

As Ryan suggests the experience needs improving, but the error messages aren't terminal. What do you mean you can't run the installation?

The problem is exactly that - upon attempting to run /wordpress/wp-admin/install.php I get a screenful of messages described above and installation aborts. Loading index.php gives back "WordPress database error Table 'testblog1.wp_options' doesn't exist for query SELECT option_value FROM wp_options WHERE option_name = 'siteurl'". Running Windows Server 2003 SP2, PHP 5.2.5, MySQL 5.0.51a. Can't find any sort of workaround, so the error message is very much terminal, at least so far.

I am having the same problem in WordPress 2.3.3 and many others are encountering it also: ​http://wordpress.org/search/%27wordpress.wp_options%27+doesn%27t+exist+for+query+SELECT+option_value+FROM+wp_options+WHERE+option_name+%3D+%27siteurl?forums=1

Most of the people having the issue are using IIS (including me).

This problem, however, cannot be reproduced on WordPress 2.3.1.

this is likely caused by the memory limit being 8MB for your host, see #5165 and #3141.

I am not sure if they are related... #3141 is fixed and WordPress 2.3.1 does not have the problem.

#3141 is fixed in 2.5, not 2.3.x.

About the only thing that changed between 2.3.1 and 2.3.2 is how database errors are reported. They are now written to the error log. Maybe try commenting out the following line and see if the install works:

error_log($error_str, 0);

That's on line 163 in 2.3.3.

​http://trac.wordpress.org/browser/tags/2.3.3/wp-includes/wp-db.php#L163

Please see ​http://wordpress.org/support/topic/150756?replies=7 as this is still an active bug effecting lots of users. I have memory_limit set to 128M and still get this problem even in 2.5 RC1. It started in 2.3.2 or 2.3.3.

see #5771

#5771 isn't it. I have log_errors on and still get the problem, see

​http://wpbug5720.mpangodev.com/wp-admin/install.php
​http://wpbug5720.mpangodev.com/phpinfo.php

iandunn, I just made another change on #5771 that might help. If you're using svn, update to the latest. If you're not using svn, download functions.php from the following links and copy it over your existing version of wp-includes/functions.php.

​http://trac.wordpress.org/browser/trunk/wp-includes/functions.php?rev=7405&format=raw

see also #5613

iandunn, does the file specified in your error_log option exist? Is it writable by the server? I've read that if it's not writable error_log() output will go to stderr, which would explain why you're seeing it output on the install.php page.

Ok, I had to manually create the file and give everyone rw rights. So, that fixed it.

But, WP should be able to handle not having logging turned on without dying...

iandunn, [7418] should work around unwritable error log files. 'Tis pretty silly to have an unwritable error log, but it seems to be a common enough configuration to need a work around.

Has this been dealt with?

supposedly. please re-open with feedback if not.