Ticket #600 (closed defect: fixed)

Opened 6 months ago

Last modified 3 months ago

Problems with custom first post on a new blog

Reported by: Miliio Assigned to: donncha
Priority: high Milestone:
Component: component1 Version:
Severity: normal Keywords:
Cc:

Description

There seems to be a problem with custom first posts in 1.5 rc1.

When I add a blog from the admin control panel (wpmu-blogs.php), it displays my custom first post just fine. But when I register a blog from wp-signup.php it always displays the default first post.

Change History

04/22/08 15:26:17 changed by donncha

  • owner changed from somebody to donncha.
  • status changed from new to assigned.

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

04/28/08 18:44:58 changed by Miliio

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.

06/26/08 04:01:57 changed by takooishi

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?

(follow-up: ↓ 5 ) 07/11/08 16:13:29 changed by donncha

  • status changed from assigned to closed.
  • resolution set to fixed.

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

(in reply to: ↑ 4 ) 07/27/08 01:30:06 changed by takooishi

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.