A major architectural update in 1.2 is the tool now makes about 25% less calls to the database, which should make significant improvements in performance. I’ve noticed this improvement in my working versions of the product–as long as I don’t use automated trackback and pingback of URLs within each post. My recommendations is: do not do automated trackbacks, manually grab and add trackbacks and pingbacks as appropriate. Remember that a trackback isn’t necessarily a link to another post.
There’s all sorts of new goodies in this release, including support for internationalization (and yes, I realize that I need work in this area for supporting trackbacks from Japanese sites), category hierarchies, built-in blacklisting, thumbnail image generation, and the new plugin architecture. The plugin architecture is particularly nice, and I’m porting as many of my hacks to it as I can.
There was one change mentioned that I’m interested in but unclear about; according to the change log:
Directory flexbility: Now you can have all the WordPress files in one directory and the weblog in a higher level directory.
I wouldn’t mind a cleaner directory for my weblog, but I’m not sure the mechanics of this, and can’t find any documentation about this change. Speaking of which, I also wouldn’t mind more documentation on the plugin architecture. However, now that 1.2 has been released, I’m sure we’ll see an increase in the overall documentation for the tool.
Unfortunately, I’m right in the middle of something else and can’t work with WP 1.2 as much as I would like right now. I hope to start making the move towards the end of the week. As I do, and create plugins, I’ll add them to the WordPress Plugin list, in addition to documenting their use here. (That is, after first checking to see that a plugin to do the work hasn’t been written already.)
As for those hacks that can’t be done with a plugin, I’ll also document how-tos here, which the WordPress folks are more than welcome to copy for inclusion in the wiki in they wish. I won’t document these directly at the wiki, though; I don’t want these hacks to seem as if they’re officially sanctioned by the WP team. Well, unless they do get officially sanctioned by the WP team.
When the hacks and plugins are working in my test weblogs, then I’ll port this weblog. I also want to do a re-design first, so that’s another chunk of time. There are existing styles designed for WordPress I could copy and then modify–but I can’t find the list. If I find this, I’ll post a link to it. (Here’s the link, thanks to Tubedogg.)
This is a major new release, with numerous new features, so for those new to WordPress, all I can say is, patience. If you run into a bug, report it, don’t just drop the tool. If it doesn’t have something you want, check to see if the feature is planned for the future, add a feature request, or see if it does do what you want, but you need to make some modifications first.
All in all, I’m pleased with the move to this tool, and look forward to when I’ve migrated the rest of my old MT weblogs over, and have upgraded everything to the newest release.
Then I can go back to writing about…well, what exactly is it that I write about? Stuff?
Note I checked the support forum on this flexible directory modification, and found that a) this is an .htaccess redirect hack, and b) there are two fields in Options that control this. You enter the Blog URL, the WordPress URL, update, and then go to the permalinks option and generate .htaccess entries…but it sure didn’t work for me.
Looks to me like there’s a missing redirect to the index.php file in the .htaccess file to work. When I manually added this, and altered any other reference to index.php to point to the WP directory, it did work, then. But was that what I was supposed to do? Or leave some of the files in the weblog directory?
update on this item A documentation page for this option was pointed out to me at the forum. I’m so used to checking the documentation wiki, didn’t check the documentation at the site itself.
Modifying the file worked, and removed the redirect to index.php. It sounds like rewrite is only needed if rewrite is being used for managing archives anyway.
This works nicely. It’s more secure than having your weblog in the midst of your WP files, not to mention easier to work with from a design perspective. The application could generate the change itself, but that means setting index.php to global write – per previous LAMP essay.
One upgrade question down.
Update on Japanese trackback
Another support forum entry discussed the problems with getting trackbacks from Japanese language weblogs–but it looks like the solution is partially in Japanese. However, the code is in English, so looks like it could be used to make mods to the code. I hope because I don’t like deleting the Japanese trackbacks. Unless, I’m doing something else wrong with the trackbacks.
Too much tweaking.