Blog Types Not Saving

I’m sorry I can’t give you more to go on. This is so weird. Blog Types has been working great for a long time for us. It hasn’t been saving for a while now (maybe two weeks) though I didn’t catch it until now. When you select the types and click “Save” everything appears normal and it even comes back with the “Settings Saved” update. BUT the data is not actually in the database.

WP 3.1.2

Blog Types 2.0.5 (I don’t think 2.0.4 worked either) though it worked before that.

Oddly enough however 2.0.5 is working ok on a different installation with pretty much identical data / plugins / versions.

If I add rows manually to wp_blog_types table they will get deleted when I save Blog Types in the dashboard which tells me the global $value is 0.

Same behavior in FF and Chrome.

I know I’m probably missing something silly here. Any help would be hugely appreciated! Thanks!

  • ClvrTv
    • Site Builder, Child of Zeus

    Thanks, David – I totally agree. In fact, this is one of those things that I wouldn’t believe myself if I was someone else trying to help me :slight_smile: Aggravatingly strange. Anyway, config attached. I tried swapping different versions (as I make versions whenever I modify it) to go back to an older one but the problem persisted. So then my next thought was maybe a conflict somewhere. And I tried disabling recently added plugins. No dice. There’s an odd load behavior on save, where I see an error indication flash for a split second in Chrome Dev Tools, but it reloads to a new page too fast to catch what it is – and that’s when I get the “Settings Saved.” But there’s almost an intermediate pageload in there? Anyway, hope this is making sense. I can’t believe I’m actually describing the problem this way.

    Note: I’ve added an extra element to the array for use in mods we’ve done to other places. So, that’s what that is.

    Thank you for your time!

  • ClvrTv
    • Site Builder, Child of Zeus

    Ok, I have got to get this fixed so I’ve been spending more time on it and have some additional info that might help you help me :slight_smile: I resolved the discrepancy between the two environments – they only appeared to be working differently but the test scenarios were different so results were skewed. Behavior is the same on both dev and production environments and here’s what I’m seeing:

    1) Existing blogs can be added / removed from blog types without issue

    2) New blogs created with the build in “add site” function can be added / removed from blog types

    3) New blogs created programmatically with wpmu_create_blog() CANNOT be added to blog types

    Although it still says “settings saved” these 3rd kind of blogs, for whatever reason, are not able to be added to blog types.

    Another factor about this 3rd category of blogs is that they are clones of another blog (similar _options table with blog-specific name values changed). This 3rd type of blog did not used to have any issues with blog types and worked just like the 1st and 2nd kind. I am wondering if there is any newer _options dependent version or status checking going on where the older blog they are being cloned from is out of sync with the newer requirements of the latest versions of blog_types and therefore it is ignoring them some how when it runs it’s queries.

    Anyway, hopefully that gives you enough to go on to pinpoint this. Super frustrating. Like I said – never was a problem before, but surfaced in the last 2-3 weeks. Our process has not changed within that timeframe.

    Let me know if you have any thoughts! Thanks!


  • DavidM
    • DEV MAN’s Mascot

    Hi Andrew,

    I’ll ask one of the developers to stop in and look at this as I can’t see a reason that would occur. Just to clarify though the problem at this point is simply the following, correct?

    New blogs created programmatically with wpmu_create_blog() CANNOT be added to blog types.

    If that’s the case, it’ll certain help nail down the issue.



  • ClvrTv
    • Site Builder, Child of Zeus

    Thanks, David. That is correct. Upon further testing I have eliminated the cloning / wp_options copy as a factor in the equation. As far as I can tell, that is the only difference between scenarios where it works and doesn’t work.

    Blog types do not seem to be savable / updatable from blogs that have been created programmatically with wpmu_create_blog(). I have verified this on two separate networks. Hopefully you’ll be able to reproduce the issue and determine the solution quickly.

    Thanks so much.

  • ClvrTv
    • Site Builder, Child of Zeus

    Hi, Aaron – thanks for chiming in.

    I thought so initially too, but I verified that is not the case by (Scenario 1):

    1) creating a blog in Network Admin > Sites > Add Site [blog_types works]

    2) running our cloning code on that new site [blog_types still works]

    We keep self-registrations disabled, but I wondered about whether or not Add Site used wpmu_create_blog() as well or not.

    We have an internal tool we developed that let’s us clone sites, optionally creating them, copying an existing site, and configuring a few things all in one process. Each step can be turned on / off. The scenario that breaks it (Scenario 2):

    1) creating a blog through our internal tool using wpmu_create_blog() [blog_types does not work]

    2) running our cloning code on that site [blog_types still doesn’t work.

    The cloning code is identical between Scenario 1 and 2. Blog Types still works in 1 but not in 2. It would be totally fair for you to think that the problem is on our end, but we’ve been using our internal tool for a long time and this issue with blog_types only surfaced in the last few weeks. Also, nothing else seems to be amiss… the new sites created and cloned this way work perfectly otherwise.

    Here is the call to wpmu_create_blog() in our tool where we create the blogs. Maybe we are missing something totally elementary?

    $site_id = wpmu_create_blog( $site_domain, $site_path, $site_title, $user_id , 1, $current_site->id );

  • ClvrTv
    • Site Builder, Child of Zeus

    Actually, in a fit of desperation figured it out!

    The issue was that by default from the call above to wpmu_create_blog it does not set the Public flag of the new blog to 1 and apparently Blog Types must be checking (?) if the blog is public before updating it? So, the undocumented $meta param in the codex has to be set like this to ensure that the newly created blog is public:

    $meta['public'] = 1;
    $site_id = wpmu_create_blog( $site_domain, $site_path, $site_title, $user_id , $meta, $current_site->id );

    However, highly recommend that you update Blog Types to throw an error message if it detects that blog_types have tried to be saved but couldn’t when the target blog is not Public. Because right now someone will never know there is a problem because it will say that “Settings Saved” even when they are not.

Thank NAME, for their help.

Let NAME know exactly why they deserved these points.

Gift a custom amount of points.