Problems with custom first post on a new blog

That's strange. I can't replicate that. Are you using memcached or another caching plugin?

I did some more testing by hacking the get_site_option function.

$value = $wpdb->get_var("SELECT meta_value FROM $wpdb->sitemeta WHERE meta_key = '$safe_key' AND site_id = '{$wpdb->siteid}'");

It works when I delete AND site_id = '{$wpdb->siteid}' in the value query. Somehow $wpdb->siteid is not set...

I'm not having a cache plugin at the moment.

I can confirm (and reproduce) this behaviour in wpmu 1.5.1

It seems that blog creation is always successful (with the specified custom $first_post from site options) when a valid user is logged in to the system, ie, when creating another blog from an existing user account, or when a new blog is created by the (logged in) administrator. It however, falls back to using the default $first_post in install_blog_defaults() when a valid user is not yet signed in at time of blog creation, which is apparently what happens when a new user goes through the wp-signup process and validates the account through the email link...

I can also confirm that Miliio's hack at get_site_option() also seems to fix the problem in a roundabout way, but as yet have not followed the code enough to form an opinion on the potential ramifications of ignoring what sounds like an important variable..

This behaviour has been confirmed by testing against several fresh installations of wpmu in various configurations on multiple server environments, none of which could be considered deviant from other typical installations. All of the installations, including the stock default ones, exhibit this..

Any ideas?

Fixed. The site_id wasn't set when WP_INSTALLING was set. It hardcodes it to 1 as a fall back.

Replying to donncha:

Fixed. The site_id wasn't set when WP_INSTALLING was set. It hardcodes it to 1 as a fall back.

Thanks donncha.