Changing Meta Types in iTunes Files
So I'm off on a road trip next week, and I've downloaded a number of "spoken word" MP3s to listen to while I drive (it's an 8 hour trip). The only problem is that now they're mixed into my iTunes library, and when I hit shuffle on my iPod, every 3rd or 4th song will be a chapter of a book. It would be useful if iTunes would let you identify any MP3 as an "Audiobook" but they'd rather you buy your books through them, so they don't expose that functionality directly. Here's instructions on how to re-type your MP3s as Audiobooks for iTunes...
Also, if you want to re-type video, or other MP4 files -- say to turn a downloaded video into a "TV Show" check out Lostify for Mac. It won't work with AVIs though.
Enabling WebDAV on OS X
I won't re-write the article, but this weekend I wanted to turn on WebDAV on my Mac mini, and this article pretty much covered it for me. The article talks about using iCal, but do the steps and see the FAQ for additional tips on regular file sharing.
The only note I'd add is that Digest authentication didn't work for me in OS X 10.4.10 -- I had to use Basic authentication.
WordPress Hacking: Multiple Blogs On One Set of Tables
Note: This post was written for WordPress 2.1. Please see the comments for discussion on how to apply to newer versions!
I recently rolled out a new theme for my website. Normally when I do this, I do it against the live site, so there's about an hour where the site is either broken, or looks really weird while I'm working on it. This time I wanted to be a little smarter.
The goal was to build another blog -- a "test" blog where I can try out new themes and other experiments -- that pointed to the same data as the main site. This way I could get a realistic picture of what the site would actually look like before I publish an updated theme.
The more I thought about that, the more useful the concept seemed. What if I wanted an iPhone-friendly version of the site? I wouldn't want to write the same post in two places. Now eXpression could do this very easily -- since every "page" was actually a query, you could just specify a different theme file (XSL) in the query. WordPress, not so much.
What WordPress can do is allow you to specify a table prefix for each installation on a given server. That means you can have 3 blogs, each with their own set of tables. When you build your wp-config file, you tell it what prefix to use. Since this is the case, it should be fairly easy to install another instance of WordPress and point it back to the original blog tables, right? Here's how you do it...
Step 1 - Install a new instance of WordPress
- Make sure it has a unique folder name so it doesn't over-write your original blog
- Run the install pages, and give the new blog a unique table prefix
- IE: If your original blog got the default prefix: wp_ then give the new blog newwp_
- Get the blog up and running with an admin account, but don't bother posting anything
Step 2 - Point the new blog to the original blog's tables
- Modify wp-settings.php as per the instructions found here
- Modify all the table pointers EXCEPT for Options
- This means that only the Options (including Theme and Plugins) will be specific to your new site. Everything else (including Posts and Comments) will come from the original site
- So anywhere you see: $wpdb->users = $wpdb->prefix .
Change it to: $wpdb->users = 'wp_' . 'users';- where 'wp_' is the table prefix for your original blog
Step 3 - Grant the admin user from your original blog the same permissions on your new blog, by inserting two records into your wp_usermeta table:
- Where wp_ is the table prefix of your original blog and newwp_ is the table prefix of your new blog...
INSERT INTO wp_usermeta (user_id, meta_key, meta_value) VALUES (1, 'newwp_user_level, 10')INSERT INTO wp_usermeta (user_id, meta_key, meta_value) VALUES (1, 'newwp_capabilities', 'a:1:{s:13:"administrator";b:1;}')
That's it! You now have two uniquely styled blogs with the same data in them! The only thing that sucks is if you have Sidebar widgets configured, you'll need to re-configure them in your new blog as well and manually keep them in sync. That's the case for all options, and that's why this is useful.
A couple other notes:
If you want, you can delete the superfluous "new blog" tables -- just make sure you leave the Options table intact.
I have no idea how this will work during a WordPress upgrade. My current plan is to run the upgrade on the original, or base, blog, then manually change the Options table structure, if necessary, for the secondary, or derived, blogs.