http://www.simplethemes.net/

—————-

CREATE A NEW BLOG

Creating a new blog in MU is a super easy process, just click <site Admin>  then the <Blog> button. Fill out the form and away you go.

Take special note of the ID that WPMU gives your new blog. The ID is in the left most column of the blogs list.

————–

MIGRATE YOUR DATA – THIS TIME FOR REAL!

Fire up phpMyAdmin, and take a look at your old blog’s database. You’ll want to export the following tables to a .sql file:

• wp_comments
• wp_links
• wp_postmeta

• wp_posts
• wp_terms
• wp_term_relationships
• wp_term_taxonomy

Remember that ID from step 3? Open up the .sql in your text editor of choice, and globally replace “wp_” with “wp_{ID}_” (where {ID} is your blog’s ID).

————

And in wordpress mu this corresponds to: ~/wordpress-mu/wp-content/blogs.dir/{Blog ID}/files

I copied everything under ~/wordpress/wp-content/uploads to ~/wordpress-mu/wp-content/blogs.dir/1/files

I also used the following SQL command to update the post contents in the database: update WP_1_POSTS set POST_CONTENT = replace(POST_CONTENT, ‘wordpress/wp-content/uploads’, ‘wordpress-mu/wp-content/blogs.dir/1/files’)

—————-

replace the old url with the new

—————-

Now point your phpMyAdmin at your WPMU’s database. You’ll notice in this database that you’ll already have tables with names like “wp_1_posts”, etc, so prefix all the tables with your blog ID in them with “old_”. The only table you’ll skip is “wp_1_options”.

Now that you’ve renamed those 7 tables, upload your .sql file into your WPMU database. You should now have a table list that looks something like the image to the right.

5. FIX AUTHOR OF POSTS

Last step! For every author in your old blog (probably just you), create a user in WPMU (if it’s you, it’ll be the MU admin). To assign all the posts to the admin MU user, run the following command in your MU database (substitute {ID} for the blog ID):

UPDATE wp_{ID}_posts SET post_author = 1

———

That’s it! You’ll probably want to log into the admin console and re-enable any plugins you need, and tweak your settings again. We omitted the wp_options table, so this process doesn’t import any blog settings at all. I tried importing settings as well, but hit a wall and was plenty happy to manually fix those.

At this very moment I am enjoying 1 admin panel, 1 click install for new blogs, 1 database, and 1 codebase. Simple. Upgradable. Trustable.

Enjoy your WordPress MU powered blog!

————

• What about the wp_usermeta table?
  
  @eddihughes, I didn’t try moving the usersmeta since it wasn’t important in my case and I didn’t want to risk it. I’d try moving everything over except users+meta, then backup, then move users and meta and see how it works out. and better yet, report back here so we all know!
• —————–

Step 2: Open Up the Exported SQL file in a Text Editor (save a back up)

Step 3: Editing the SQL database file

(The WPMu Tutorials site has two posts about the basic structure of the WPMu database. It is a useful overview that explains how the deafult blog in a WPMu database has the table prefix wp_1_ as logic would have it the next blog you create on a WPMu installation will be wp_2_ etc. This is a different from a single WP installation in that the single installation only has the wp_ prefix without the numbers (which connote a blog id in WPMu). For example, whne importing my single installation in WPMu, I already had several blogs within that environment, so when I mapped the new domain for bavatuesdays, the database table structure was already up to 30:

wp_30_options is the table name on WPMu vs. the wp_options that is in my single installation. So, in short, just about every database table you have in a single Wordpress installation (which will not include plugin databases only you have already set them up on the new WPMu blog you are importing to) will have a corresponding table in WPMu with an appropriately number table prefix, in my case wp_30_

Before we go in and change the table names, one thing you might consider is cleaning out some on the kipple in your database.

So, the quick and easy way to do this replacement is to use the text editor to find `wp_ and replace all instances with `wp_30_

Step 4: Deleting existing tables

The sixth step may seem counter-intuitive (and there may be a better way), but in my limited experience I found I had to go into the WPMu database and delete all the tables for the blog I created and want to import the single-install database to. For example, the new blog on WPMu for bavatuesdays has the database prefix wp_30 (your may very well be different depending on how many blogs you have created and what the corresponding number is). So, I go into my WPMu database, find all the tables that have the prefix wp_30 and drop them (scary I know, but trust me, I’m an amateur).

Please note: You will need to dump all of the tables associated with the blog you want to import. Try not to be confused by my example here because I have already done this and some tables are related to plugins. for a list of the tables you should be deleting with only the wp_# prefix, for example:

wp_#_categories
wp_#_comments
wp_#_link2cat
wp_#_links
wp_#_options
wp_#_post2cat
wp_#_postmeta
wp_#_posts
wp_#_terms
wp_#_term_relationships
wp_#_term_taxonomy

Where the # is the number of the blog you have created to which you will be importing the SQL file. Am I being clear here?
As another note, wp_#_terms, wp_#_term_relationships, wp_#_term_taxonomy are all specific to WP version 2.3, so be sure your blog is updated to the lastest version before you try this!

Step 5: Importing the new SQL blog database
Once you have dropped all the relevant tables, you will then go to the import tab in phpMyAdmin and upload the modified SQL file we have been working through. This should be relatively painless, return to the root of the wpmu database, make sure you are not within a specific table, and then click on the import button, find the saved SQL file we have been modifying and import it.

And that should be it, but let me say two things before I end this post:
a) I’m a hack and this worked for me, but may prove unsuccessful for you, so if you try it please backup your stuff
b) I hope far smarter than me who have done this before and know the intricacies better will chime in and correct any flagrant errors or misleading passages that could mislead or somehow screw someone’s attempts up.

With that said, go to it and let me knwo if you have an issues that I can try and help out with.

Het moet ook met Custom Fields kunnen?

—-

Plugins:

wp-security scan (dicht gaten en geeft advies)

login lockdown (voorkomt frute force)

wp-dbmanager (backup vd database)

askApache Passwordprotect (werkt bij niet altijd) (beschermt admin forder)

WP-scanner

]]> http://maartenvanderglas.com/mu/webdev/2009/06/29/wordpress-security/feed/ 0