MySQL Trauma.
When Wordpress 1.2 was released I decided to give it a try, just to see what it is like, how it compares to B2, etc. It now has all of the features that I’d been adding to my B2 install for the last, errm… I guess it’s been a very long time since I’d done eMotif, hasn’t it?
I installed it, took a look around after copying my ‘real’ database into it, then I sort of let it sit there abandoned. Most of the stuff I’d added to my B2 install was with the help of Michel, making slight changes to the core code so that all the stuff like private entries, password protected entries, etc, would actually work. I didn’t know if the WP dev team would follow with those or take different and possibly better directions, so I needed to find out just how difficult or easy it would be to actually transfer over to it.
Sam asked me what WP can do that my modified B2 can’t. Realistically, it doesn’t do much more extra, it just does things differently. It adds a thousand layers of complication though, which in a way is nice because it brings a lot more flexibility, but it also, I’m not sure, the interface lacks the simplicity that I’ve always liked about B2. I like WP though, it would just take some time, as one would expect, to really embrace it.
I used to know B2 like the palm of my hand, as they say. Since it has been so very long since tinkering around with the code I’ve forgotten quite a lot of how it works. This poses a problem because that also means I’ve forgotten how a lot of ‘my’ code works too.
This installation uses category zero to keep posts from being published. It never was the most elegant way to go about things, but it is very effective at the task regardless. Wordpress uses the much more elegant and flexible way of allowing a tag to represent the post status, be it private, draft, or published… this allows for many more possibilities in the future too. So, that’s one ‘conversion issue’ that would need to be tackled, easy enough with a line of MySQL:
UPDATE wp_posts SET post_status = “private” WHERE post_category = “0″
Formerly “unpublished” posts are now private, score. Of course, another similar line of code would be needed to move those posts back into a ‘real’ category:
UPDATE wp_posts SET post_category = “24″ WHERE post_category = “0″
This installation uses a “private filter” to password protect posts. I used to keep a little box mostly hidden on the page somewhere, those in the know could easily type in the password, it would set a cookie and “decrypt” private entries. The filter worked on a very basic premise, when rendering the page if it caught the particular ‘tag’ writtin in the entry the filter would then engage and ‘encrypt’ it. The password was kept in the actual code of the filter, so one password would work for all entries, any change to it would apply to all entries. Wordpress follows similarly to private entries with having a field indicating the post’s password, if there is one it prevents the entry from being seen, without a password it behaves as normal. Again, a similar MySQL command fixed this ‘conversion issue’ by inserting a password into the column necessary whenever the filter tag appeared in the post’s content:
UPDATE wp_posts SET post_password = “–password–” WHERE `post_content` LIKE “–filter-tag–%”
I considered those to be the most important issues, it at least keeps everything that is supposed to be private actually private. Four more ‘conversion issues’ present themselves though, making eMotif work, making my ‘post moods’ work, making my brainfeed work, and keeping permalinks permanent.
The permalinks ended up being a lot easier than I originally thought. WP uses mod_rewrite to make the urls ‘pretty’ unlike the way I’ve been doing it. There weren’t really any options in WP to do the urls exactly like I’ve been doing them, but I couldn’t just switch to the ‘new’ way otherwise those permalinks wouldn’t work anymore… defeating the whole idea. For the sake of convenience I used the WP mod_rewrite generator to cook up the code to make the ‘old’ permalinks work while also using it to make nice new ones for the future. This solved the problem while also giving me the ability to use the newer, nicer, urls. :)
I’ve not tackled eMotif, which will function standalone if I can’t figure out how to get it to use WP code, so I consider that fairly low priority. Brainfeed is just another B2 install that I publish to via the command line, it’s that little line at the top next to my mood (eMotif) and age, etc. Because two installs of B2 don’t ‘play well’ with each other I wrote a little function to grab the data and display it. I figure that function should work fairly well in WP too, but now I’m not sure.
WP has this ‘meta data’ function, where one can add custom fields to their posts. I don’t like it much, but it is flexible, so I’ve given thought to converting all of my mood data over to it. Since I wrote ‘b2moods’ before eMotif, they use basically the same type of database structure. Whenever a mood is posted it saves an ID number for that mood, instead of the actual mood itself. This saves database space because the actual mood is only stored in the ‘match’ table. In reality it doesn’t save much space, so ultimately it was kind of a dumb way to do it I think, because it means that anytime you want to show the mood it needs to do extra work to match up the ID to the text. One reason I don’t like the meta data way of doing it in WP is that I really like having the mood dropdown box, I tend to choose something more appropriate when I have options, otherwise I’d probably write in rather ordinary things. With those considerations I wanted to see if I could get the mood code to work with WP directly.
Unfortunately I can’t seem to get it to work, there are no errors, it just doesn’t do anything either, lol. It’s clear that the functions pulling up post data have changed just enough to prevent my little ‘addon’ from working properly. I tinkered with this for a while, but never did get it to work. I just haven’t examined the WP code enough yet.
Since I couldn’t get it to work I tried to transfer my mood data into the WP way of recording meta data. Unfortunately this didn’t work either, but I’m so close! Since the process is rather complicated using single MySQL lines wouldn’t work, so I started writing a mood conversion script in PHP. I actually have it working too, it grabs a post ID and its matching mood ID, looks that mood ID up in the mood table and bingo, inserts the post ID, and the mood into the meta table, along with other required bits of meta data. The problem is I’ve screwed up somewhere, it only does one and then stops! Instead of… say, doing all six hundred plus entries. I definitely have a loop or the actual mysql_fetch commands written incorrectly.
Oh well, I’ll get it eventually, I just need to remember how to do all the things I’ve forgotten over the last year or two. If only I can get the little conversion script to repeat through all the rows it’ll work, bugger for not being able to remember how to do it!