WordPress MU

I'm trying to figure out how I can change the properties of multiple blogs. For example, I've made a plugin that creates a blog but I want the blog's owner to have the editor role, not administrator. It's pretty simple to do if I just add this:

$user = new WP_User($user_id);
$user->set_role('editor');

However that change is applied to blog #1, not my new blog. How can I set it so that it will be applied to any blog I want?

Are we doing this for a new blog or a blog already created or what? Some details would be helpful.

Whoops, didn't mean to say I was making a plugin, it's a stand-alone script I can use to create blogs via command line.

I have created a new blog using:

$blog_id = wpmu_create_blog($domain, $path, $blog_title, $user_id, array());

That sets up a blog with the user in the admininstrator role, but I would like to place them in the editor role instead. To do so I follow that up with:

$user = new WP_User($user_id);
$user->set_role('editor');

I traced through wpmu_create_blog() and it looks like I should add:

switch_to_blog($blog_id);

I'm making this as a standalone script and that seems to be causing some problems, such as preventing switch_to_blog() from working. I'm using the following includes on my page:

define("WP_INSTALLING", true);
require_once('../wp-config.php');
require_once(ABSPATH . WPINC . '/registration.php');

Perhaps there's something more I need to do to be able to use switch_to_blog() ? I'll keep poking around with it.

I'm still not having any luck setting a user's role on blogs. Setting WP_INSTALLING to "true" seems to work, but is there a recommended way to do command-line scripts with MU-Wordpress? Here's the gist of my script.

define("WP_INSTALLING", true);
require_once('../wp-config.php');
require_once(ABSPATH . WPINC . '/registration.php');

/* Set variables here */

if (($user_id = username_exists($username)) == null) {
	echo "Creating user: $username";
	$user_id = create_user($username, $password, $email);
} 

$blog_id = wpmu_create_blog($domain, $path, $blog_title, $user_id, array('blogdescription' => ''));
switch_to_blog($blog_id);

$user = new WP_User($user_id);
$user->set_role('editor');

if (is_wp_error($blog_id))
	print "Error creating blog.";
else
	print "Blog created: $blog_id";

The end result is that $user_id is set to the editor role on blog 1, not on blog $blog_id. Am I not using switch_to_blog() correctly? Is there a different set of files I should be including for command-line scripts?

I still don't see why this doesn't work. Here's a full script so anyone can see for themselves. Just drop it in the wpmu root directory and call it up in a web browser (after setting your $domain and $path). When executed, it will create a new blog and then assign the user to the editor role on blog 1. But I'm telling it to make them editor of the new blog. Why can't I do that?

<?php
ini_set("display_errors", "1");
define("WP_INSTALLING", true);
require_once('wp-config.php');
require_once(ABSPATH . WPINC . '/registration.php');

// Set variables
$username = "testuser";
$password = "testpass";
$email = "test@test.com";
$blog_title = "Test Blog";
$domain = "www.example.com";
$path = "/wpmu/" . strtolower($username) . "/";

echo "<pre>";

// Create a new user or get their existing user_id
if (($user_id = username_exists($username)) == null) {
	echo "Creating user: $usernamen";
	$user_id = create_user($username, $password, $email);
}

// Create the blog
$blog_id = wpmu_create_blog($domain, $path, $blog_title, $user_id, array('blogdescription' => ''));

if (is_wp_error($blog_id))
	exit("Error creating blog.");

echo "Blog created: $blog_id";
switch_to_blog($blog_id); // Does nothing

// Set the user's role to 'editor'.
$user = new WP_User($user_id);
$user->set_role('editor'); // Applies the change to blog 1, not blog $blog_id

echo "</pre>";
?>

I give up. I hate to hard-code SQL queries but I'm not seeing any other option and I need to have this to continue. If I make the following change it works. Why the code above doesn't work is beyond me.

// From:

switch_to_blog($blog_id);
$user = new WP_User($user_id);
$user->set_role('editor');

// To:

global $wpdb;
$wpdb->query("UPDATE $wpdb->usermeta SET meta_value = 'a:1:{s:6:"editor";b:1;}' WHERE user_id = $user_id AND meta_key = 'wp_" . $blog_id . "_capabilities'");
$wpdb->query("UPDATE $wpdb->usermeta SET meta_value = '7' WHERE user_id = $user_id AND meta_key = 'wp_" . $blog_id . "_user_level'");

If anyone can help me out I'd appreciate it, otherwise I'm not going to waste any more time on this and will just continue to write out SQL queries as I need them.

I'm amazed no one answered your query, Vimm. I don't know the answer but I too came here wanting help with switch_to_blog().

That's probably because when the create blog function is called within MU, it follows a certain criteria.

Of which, the information for when it inserts the new user can be edited so that it creates them as an editor, vice admin for their new blog.

No additional queries or switches needed. Granted, it means editing a core file, but that's just the way it goes usually. As long as it's kept track of, it isn't a big deal.

Does it echo the expected $blog_id at the end of the script? I notice that in your hard coded example you aren't using $blog_id

-- I'd be doing this properly as a plugin (could even use XML_RPC if you wanted)

Richard

I'll stick to my original comments. No plugin needed. One minor edit. Done.

Adding a new plugin to do this means it would probably be in mu-plugins, and parsed every, single, time.

One little edit, and it's all good, without more bloat.

And with xml-rpc... that just isn't exactly "smart", IMHO.

Lunabyte I don't appreciate the "smart" comment, I don't mind you disagreeing with me but I feel your use of "smart" was unwarranted. Please retract.

Also, I think plugins are far more desirable than editing core files because edits can be cause problems you don't expect -- it is a lot easier to remove plugins that may be causing issues than undoing core edits also core edits are a nightmare to keep track of during upgrades.

Core edits may also be why some things don't work properly for people who come to this forums with unusual errors.

I am yet to find anything I need to use a core edit for that I can't do with a plugin.

Plugins when done properly - use separate include(s) with the plugin logic code from the filters/action code using a single if statement means that 99% is not parsed unless needed. I would not call this bloat.

As more XML_RPC I am unsure why you feel it is not a smart suggestion. Admitted I'm seeing this from my wordpress use.

In education (where I work and holidays which is why I'm on the forums at the moment) user lists are usually already in a database. Many administrtion scripters are able to adapt vbscript or similar to take user lists and add them to active directory so using XML_RPC methods (added by plugins). Having a system that allows hundreds or thousands of users to be added and configured easily via XML_RPC seems highly desirable.

Richard

Retract? Re.... tract?

Retract what? My opinion?

Hell no. Won't do it.

"Also, I think plugins are far more desirable than editing core files because edits can be cause problems you don't expect -- it is a lot easier to remove plugins that may be causing issues than undoing core edits also core edits are a nightmare to keep track of during upgrades."

So you'd rather sacrifice performance, and load a ton more code. If you're an anti-core-hack zealot, fine. However, with responsible tracking, it isn't such a drastic thing to do. Unless of course one walks among the clueless.

"Core edits may also be why some things don't work properly for people who come to this forums with unusual errors."

And the same (or worse) code in a plugin makes it better how? And editing live files without testing is good, how?

You make an edit, if needed, and if it mucks up, you cmd+z (ctrl+z for the poor folks on windoze, or the folks on linux), and then try again. If there's no responsibility to have a test site, to try things out on first, that is poor management all around.

"I am yet to find anything I need to use a core edit for that I can't do with a plugin.

Plugins when done properly - use separate include(s) with the plugin logic code from the filters/action code using a single if statement means that 99% is not parsed unless needed. I would not call this bloat."

Parsed? Who cares about parsing and executing. To read the plugin file it still has to be read into memory. That alone is enough of a hit if it isn't needed, and a lot of times the plugin is going to be 10 times the code weight of an edit. Not always, but a lot more than not. The OP's problem for example. Changing just a couple characters corrects the problem and produces the desired result. So how is adding in all those additional lines and reading it in with a plugin better?

And, as a note, while Donncha is busting his tail to provide as many hooks as possible, there a still lots and lots of places where it's necessary to edit the core if you desire to change those areas. Then again, lets read in even more files that have to have hundreds of lines of code to do what might take a 1/10th that many with an edit. Of course, reading in that plugin with every load, while the edit may only be called on certain loads.

So yeah it's bloat, with a side of A1, any way you slice it.

I won't even quote the XML_RPC stuff. But as the recent XML_RPC "problem" has shown, it can lead to many, many nightmares on its own, without any additional crap running through it.

And vbscript and active directory? Wow. I can't even comment on that crap, which I wouldn't want within 1000ft of any box that I have, let alone trying to interact with it.

And again, with xml-rpc... that still isn't exactly "smart", IMHO.

Note in the previous post, and this one: IMHO.

Sorry Vimm, J, carry on. ;)

lunabyte,

I am very disappointed with your response. I will not enter into name calling, I will not engage in negative posting. Of course, if you ever make it down to Australia, look me up, I'll buy you a beer and give you heaps in person (when the written word won't be an obstacle to being clearly understood and my lightheartedness will be obvious) :)

I do not agree (or know enough about) with what happened to Dr Mike and I do not agree (or know enough about) with the way it was handled but I hoped that the regular posters here might decide to be more positive and less combative on these boards.

Again, my intention of this post is to ask all regular posters to think about the negativeness and put downs to consider being more positive and less combative.

Wordpress and wordpress mu is free open source software, I hope the boards reflect the same generous attitude.

Richard

PS. I reply to content about plugins and XML_RPC in a separate post.

Why I think plugins are preferable to core edits.

A high performing plugin comes in at least 2 files. Depending on the if statement length and the name of your files you're looking at about 50 characters (including spaces) a small price to pay for the benefits gained by using a plugin. The first one with an if statement and the others in a sub directory that is included only this

if (plugin_is_needed ) { include plugin_sub_directory/this_plugin_file_with_hooks_filters_functions.php;}

Of course, sometimes more code may be needed in the initial file.

If you need to remove it (obsolete or see if it is causing errors) then you remove that one file from the mu-plugins directory.

Plugins can also be shared with the wordpress community in a much easier way than core edits can. Continuing the open source ethic.
I

Richard

Flickr, delicious and the like, all heavily use their XML_RPC based APIs and make them available to the public. They are not anymore prone to security issues than any other code.

I won't even quote the XML_RPC stuff. But as the recent XML_RPC "problem" has shown, it can lead to many, many nightmares on its own, without any additional crap running through it.

Adding a method via a plugin would not change the security in any way shape or form, there would not be any change to the security at all. The code would work in exactly the same way as it does via http, any security holes caused by a plugin (or core edit) would be there regardless of whether XML_RPC or http was used.

What webservices do is extend the functionality of the website. There is no reason why webservices cannot be used to allow administrative tasks to be performed It opens up an administrative interface to those who do not know php or do not have root access to upload files.

And vbscript and active directory? Wow. I can't even comment on that crap, which I wouldn't want within 1000ft of any box that I have, let alone trying to interact with it.

Using XML_RPC means the scripts do not have to be on "your box", you're just providing an API. That is the whole point.

I only mentioned XML_RPC because it is something I was thinking about looking into for myself. I'll post code when I do (don't hold your breath)

Richard

If you read what I posted, I said using in my opinion wasn't smart. Nothing more. Never called a name or anything. So, I stick with my opinion. Which is just that. My opinion. I wasn't negative to begin with, rarely am I ever intially, but I can be and have no guff if need be.

Other than that, I got better things to do.

I still stick to my original comment, and that modifying the role created at the time of creation is a more viable option, and is less weight.

No worries, happy to leave it at that.

Still interested to hear if Vimm is getting the right $blog_id or not?

Richard

> modifying the role created at the time of creation is a more viable option, and is less weight [than using a plugin to change modify it at run time].

From a CPU utilization point of view I agree this is better than using a plugin to change it at run time.

From a maintenance point of view it is suboptimal.

Would you both be happy if there was a hook to modify it at the time of creation?

Martin.

Well shit, let's just put a hook after every single line, and call it a day.

Making a modification is not "sub-optimal", unless you aren't bright enough to keep track of what you're doing.

It does not take a decade of experience coding to realise that if there are common patterns of edits to core code then these are locations for hooks.

Some of us prefer to keep the workload to a minimum, and don't make any assumptions about how bright other people are.

Whatever, dude.

Take it personal if you want, other than that, next topic.

Would you both be happy if there was a hook to modify it at the time of creation?

I haven't looked into what hooks are available but I'm think you'd be able to what Vimm is fter without any additional hooks.

Given the way this all works, I don't see any reason not to add any suggested hook requests to the trac, as long as you can justify your reasons.

But, many things that are currently done with core edits by many (for example, global categories) can be achieved with existing hooks and filters.

Richard

Just came back from a week's vacation.

Yes, the correct blog_id is being used. It is returned from wpmu_create_blog() and the blog does get created successfully. I also echoed out the blog_id and user_id for debugging purposes. The problem that I have is I want for my script to function as an API, not as a plugin attached to a specific blog. I also want to have the flexibility to choose what role the blog owner will have based on my conditions, so a core hack is not an optimal solution for me. I've already created a plugin which bypasses the built-in blog creation and uses my own, and it works flawlessly with no core hacks. My goal is to be able to create multiple blogs with multiple users in multiple roles, all via the command line so that I can integrate it into another application. What I don't understand is why my code functions correctly when used inside a plugin, but when placed outside a plugin I have to manually hit the database.

I just made a new thread on the API subject before I noticed these replies.