Lately I’ve been producing a series of posts on using WP-CLI, the command-line interface to WordPress. Along the way I’ve started to accumulate a pretty good toolbox of scripts to throw at larger-scale administrative tasks.
A little background on the one that blew up. We run individual blogs (the industry jargon for higher ed is “ePortfolios”) for students. They’re launched when they’re freshmen, and part of their first semester is filling in some assignments. We’ve been running this long enough so that a substantial numbers of users have graduated and no longer have access to editing their sites. So, we are cleaning house.
Pulling out the graduating students was easy enough. I simply ran the user list generated by WP-CLI against our authentication system. Any that came up with no result could safely (for the most part*) be removed. Then I’ll take that same list, which corresponds to the blog slug, and delete the blog. What could possibly go wrong? This.
Just to be, duh, safe, I decided to look at these 10 rows at a time, printing them out and copy-pasting one example to the command line just to be sure.
Perl mavens, see the error? Spoiler ahead.
It’s the “chop” function. Just used by itself:
It takes off the last trailing whitespace character. But when you get its return value, as in
The return value is “success!”, or, in binary, “1.”
So what I pasted into the command line without really looking closely was
What I was hoping to get was something like
This is bad. I deleted the root blog. Later on I realized the error when I tried to go to the root site and got a “not found” error. To make matters worse, http://my.blogs.edu/wp-admin/network also threw a 404 at me.
Ultimately it’s fixable. The good news is, your posts and media files are not stored the same way as the sub-blogs are. They have directories in wp-content/blogs.dir/123/files; but the root blog’s files are stored in wp-content/uploads, just as they would be in a single installation. And your post and page content are not in anything like something like wp_1_posts, they are just in wp_posts. These are out of reach of the wp delete site command when a blog ID is fed into it.
First of all, you can get into the administrative back end by logging on to any of the other blogs on the multisite installation: http://my.blogs.edu/someotherblog/wp-admin/.
And from there, you can slot on over to the network admin screens using the bar across the top of the browser window. Then, go to the Sites::All Sites screen and edit the #1 blog. Un-check “Deleted,” and save your changes. That might well be enough.
If not, there are a couple of places where the site URL and root blog info are stored. Go into phpmyadmin (or your database tool of choice). The table wp_site has a field for the #1 blog’s domain. In wp_options, make sure that home and site_url are set properly. And make sure that in wp_blogs, the root blog has just a slash for its path.
And hopefully that will be enough.
* just don’t delete any super-administrator accounts, because they won’t show up in your Active Directory or LDAP databases.