Categories
Weblogging

WordPress 1.2 release

The long awaited WordPress 1.2 has just been released. You can download the source directly at the Source Forge page if the WordPress site is slow.

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?

Stuff.

Upgrade Updates:

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.

Categories
Technology

Splitting LAMP from the weblogs

Recovered from the Wayback Machine.

I’m going to continue the LAMP series later, but won’t be focusing them on the changes I’m making to WordPress. The two discussions aren’t compatible.

I’ll wait for the released WordPress 1.2 product and then just post my modifications with instructions about how to incorporate the changes for those interested. But I’m not going to leave the Movable Type ‘fan club’ just to jump into a WordPress ‘fan club’, and join in what is now becoming an emotional tug of war.

They’re just tools. My appreciations to the people who built them; I donated for MT, and when I can spare the money I’ll throw the same amount in as donation to WordPress. But they’re just tools. I prefer WordPress because I can legally tweak it, it uses my preferred technologies, and I can afford it.

But it’s just a tool.

Clay Shirky writes about emotional attachment to social software and people ‘freaking’ out, and Anil Dash uses it as a blueprint. Phil Ringnalda writes about how he’s standing by his Movable Type friends in one post, and then does a line by line dissection of his friends’ software license in the next.

Aside from the fact that we use the word ‘friend’ far too easily in this environment, I left my cheerleader skirt folded up on a porch when I was 13 and moved to Seattle a long time ago; so I’m not going to drop green-gold and black pom poms, just to pick up ones colored gray and blue.

Categories
Technology Weblogging

Survival guide to LAMP: Unlimited weblogs

Recovered from the Wayback Machine.

L is for Linux, A is for Apache, M is for MySQL, and P is for PHP

At this time, being able to create multiple instances of WordPress weblogs isn’t built into the tool interface, and some folks have been turned off of the product because of this. After all, if people are looking to move from Movable Type, it’s most likely because the new licensing system restricts the number of weblogs created. It would make sense they would, then, be interested in moving to a system that provides multiple weblog support.

While WordPress doesn’t yet have push button support for it, implementing multiple weblogs is actually quite easy if you’re willing to go beyond the button stage. And since I know you’re all closet hackers, I feel comfortable that the button was left behind, long ago.

In this LAMP essay, I’m going to cover the steps you can take to implement multiple weblogs. In addition, I’m going to cover my own little ‘multi weblog management’ hack hinted about in an earlier writing. However, I’m going to cover a couple of different options when creating new weblogs: 1 for those who aren’t quite comfortable with the Linux command line; another for those on the hacker track. All total, I’ll be creating, oh, 4 or 5 weblogs. We’ll see how I feel by the time I finish writing this.

(And I’m thinking of doing them all the same design, but in different rainbow colors: bright violet and purple with maybe a touch of yellow; deep pinks and roses, with a hint of olive; oceans of blue; the obiquitous bittersweet and orange; and of course, where would I be without Missouri green, with just a hint of lime to show that I can still salsa with the best of them. I’ll call the latter blog, the “Margarita Blog”.)

Creating each Weblog

First step is to download WordPress and create your first weblog, the mold if you will, for all the other weblogs. To do this, I created the subdirectory, following the steps detailed in The Command Line is Fine, Come on In. The database has already been created, and then it’s a matter of installing the weblog tables and software as described in Installing the Weblogging Tools. At this point in these essays, there is one working weblog, at http://wordpress.burningbird.net.

Before creating a second weblog, now would be the time to implement any changes to that you want reflected across all the weblogs, regardless of look and use. If your changes aren’t to the primary index.php file, or any of the other files that are going to be modified at each site, you can wait and copy the changed file at a later time. Or you might be able to get away without any copying, with a few tricks, discussed at the end of this writing.

Now is also the time to clean up the installation. For instance, if you’re not importing any data from another weblogging tool, you don’t need any of the import-*.php files contained in the wp-admin directory. In addition, what looks like legacy files from previous implementations of the software–b2rdf.php, b2rss.php, b2rss2.php–shouldn’t be needed; or the wp-comments-popup.php file if you’re not supporting pop-up comments, and so on. It’s worth the time now to go through the files in the primary directory of the tool, the root directory if you will, and make sure it’s as clean as possible.

Don’t delete the files you don’t want. Create a second subdirectory somewhere off your web path, and put the files there. Just in case. You can use your FTP program to examine and clean these files up, or use vi (remember vi?) to see what the files are doing, and the Unix move command, mv to move the files:

mkdir /home/shelley/tmp

$mv b2rdf.php /home/shelley/tmp

In this case, I created a directory for the files, and then moved the b2rdf.php file to it.

Once you’re satisfied that you have a good, clean, working install, now you’re ready to create your second weblog–and to install the Weblog Switcher. The first approach we’ll look at to create a another weblog is the simplest from a Linux perspective, but also the hardest to maintain over time.

Creating a Second Weblog by Copying Files

Create a new directory to hold your new weblog, following previously given directions. Once finished, you’re going to copy all of the files from the first weblog directory over to the second. My second WordPress weblog is at http://wordpress2.burningbird.net, and I’m going to copy the files from the original wordpress directory to the wordpress2 directory:

cd /home/shelley/www/wordpress

cp -r * /home/shelley/www/wordpress2/.

The first command takes me to my original weblog’s directory; the second copies everything, including directories (recursively followed using the ‘r’ option), to wordpress2. If you’re not on the hacker track, then use your FTP application to just copy the files from the first directory to the second.

After the files are copied, you need to create the second set of WordPress tables to support this new weblog. To be forward compatible with multi-weblog support in WordPress, it’s important that the tables are created in the same database as your first weblog’s tables. To do this, open the wp-config.php file that you created for the first weblog, but copied over to the second, and leave everything the same except the following line. You need to change the table prefix to something different in order to create the second set of tables. You can use whatever you want, but the example shows that the tables are prefixed with “wp2_”:

$table_prefix = ‘wp2_’; // example: ‘wp_’ or ‘b2′ or ‘mylogin_’

Again, you can use the vi text editor to make this change in Linux; or use your text editor on your home computer, using FTP to bring the file down, make the change, and then upload it again.

After you make the edit and save the file, run the wp-admin/install.php application in the new weblog location to create the tables. As with the first weblog, it’s just a matter of opening the page in your browser and clicking the Let’s Go link.

Once finished, congratulations: you’ve just created your second WordPress weblog. Not quite pushbutton–but close. Close.

(Of course you still have all that design stuff, but we all know how easy this is. )

To work with each weblog, you have to load each weblog’s admin page. It would be nice to be able to switch back and forth between the weblogs without having to hand type in the URL for the WordPress administration page, or the weblog page. That’s where the next change comes in, customizing WordPress to install a new administration page to handle this for you.

Adding in Switcher

Switcher is a page that’s dropped into the WordPress administrative interface, which allows you to record edit and view URLs for all weblogs you create, and then use this to switch between the weblogs. It doesn’t create a weblog, and you can’t use it to delete a weblog–yet. All it does is help you track and navigate between weblogs.

I’ll install Switcher into the original weblog’s administrative pages. The first step to install Switcher is to copy the zipped file containing the software. It can be found here, though note that downloading in Firefox requires saving the file and then opening it separately in Winzip, if you’re getting the file from your Windows machine. However, if you have access to the command line, a quicker approach is to use ‘wget’:

$wget http://wordpress2.burningbird.net/multiweblog.tar.gz

tar -xzvf multiweblog.tar.gz

mv menu.php /home/shelley/www/wordpress/wp-admin/.
mv install-multi.php /home/shelley/www/wordpress/wp-admin/.
mv switch.php /home/shelley/www/wordpress/wp-admin/.

These commands downloaded the software, unzipped the compressed file and extracted the files from the tar file (a tar file is a Unix archive file, a way of grouping files together for easier handling). Then the files were moved to the wp-admin directory of the primary weblog. If you unzipped them on your home computer, FTP them to your server.

When you copied the menu.php file into wp-admin, you overrode the existing one. Switcher is an independent application, but it does need to be installed into the WordPress menu to be accessible. Luckily, menu.php is easily modified to add a new option. All that’s required is to find the code where the array of menu items is being created:

$menu = array(
array(__(’Write’), 1, ‘post.php’),
array(__(’Edit’), 1, ‘edit.php’),
array(__(’Categories’), 3, ‘categories.php’),
array(__(’Links’), 5, ‘link-manager.php’),
array(__(’Users’), 3, ‘users.php’),
array(__(’Options’), 6, ‘options-general.php’),
array(__(’Plugins’), 8, ‘plugins.php’),
array(__(’Templates’), 4, ‘templates.php’),
array(__(’Upload’), get_settings(’fileupload_minlevel’), ‘upload.php’),
array(__(’Profile’), 0, ‘profile.php’)
);

Then, add Switcher as the last option:

$menu = array(
array(__(’Write’), 1, ‘post.php’),
array(__(’Edit’), 1, ‘edit.php’),
array(__(’Categories’), 3, ‘categories.php’),
array(__(’Links’), 5, ‘link-manager.php’),
array(__(’Users’), 3, ‘users.php’),
array(__(’Options’), 6, ‘options-general.php’),
array(__(’Plugins’), 8, ‘plugins.php’),
array(__(’Templates’), 4, ‘templates.php’),
array(__(’Upload’), get_settings(’fileupload_minlevel’), ‘upload.php’),
array(__(’Profile’), 0, ‘profile.php’),
array(__(’Switch Blogs’),0,’switch.php’)
);

Though this change is simple, unfortunately if you install a new version of WordPress, this menu.php file will be overriden unless you choose not to install the new menu.php; or do so, and then re-add this small notification.

(Note: As long as I’m an active weblogger, I’ll provide updates to this code. Hopefully when full multi-weblogs is implemented, it won’t be needed.)

What this edit does is add a new menu item labeled “Switch Blogs”, pointed to an application page called “switch.php”. This page is provided as is, and requires no modification of existing code – just drop the file into wp-admin.

Before you open the page in your browser, you have to do one more thing – create the multi-weblog management database table, wp_multi_blogs. You could try accessing MySQL at the command line and create the table…but an easier approach would be to load the page “install-multi.php” into your browser, which creates the table for you.

At this point, you’ve installed Switcher and if you open WordPress, you’ll see the new option in the menu. Clicking on it will open a page with a form with fields for a weblog’s name, the URL for the Weblog’s WordPress administration page, and the URL for the weblog itself. The image below shows both WordPress test weblogs and Burningbird.

Switcher screen shot

Of course, as you’ve probably realized, Switcher is only available in the original weblog’s WordPress administration pages. To add to each additional weblog, you’ll have to copy the menu.php and switch.php pages to the wp-admin directories for each. You don’t have to install the database table again, or add the weblogs, either. Adding a weblog in one administration page, adds it for all.

Of course, a better approach to all of this would be to have one installation of WordPress shared by all weblogs. Well, I can say that I gave this my best effort, but was defeated by a little thing called a symbolic link. And that leads to a second approach to creating another weblog in WordPress.

Symbolic Links and WordPress

Now, this solution I’m about to detail is a Unix-based solution, and takes us down to the iron of Unix, so to speak. Instead of copying all files, what you’ll do instead is copy the files that are unique to each weblog–the PHP and CSS files located in the root directory. But instead of copying the other WordPress directories, such as wp-includes and wp-images, what you’ll do is create a link from your new weblog to the directories associated with the original weblog.

To follow this approach, again create a third WordPress subdirectory; mine is located at http://wordpress3.burningbird.net. Copy the files located in the root directory of the original weblog installation, and make an edit to the wp-config.php file to change the prefix to ‘wp3_’ to create a third set of tables.

Unlike the previous approach, the only other copies you’ll make are the wp-admin and wp-includes directories to the new site. For the other directories, what you’re going to do is create what is known as a symbolic link between the directories at the old location and the new location.

A symbolic link in Unix is a way of accessing the same files in a given directory in two different places. For all intents and purposes, when WordPress accesses a library function in wp-includes, or a plugin in wp-content in the new weblog directory, it behaves no differently than if the directory was actually, physically duplicated. However, and this is a big however, if you make a change in wp-content, let’s say add a new plugin, in either WordPress weblog, the change is reflected across both.

As you can imagine, this is a simplified approach to maintaining the weblog. Instead of having to updated one version, and then the other– you upgrade one, and you’ve automatically upgraded the other.

To create a symbolic link, you’ll use the Unix link command, ‘ln’, with the ’s’ for symbolic option. You specify the source of the link, and then the target. For this example, linking to the wp-content directory in the old directory is accomplished with the following:

$ ln -s /home/shelley/www/wordpress/wp-content wp-content

Unfortunately, this is one command you have to give at the command line; your FTP program will be no help. At least, that I know of.

Use the same approach to link the wp-images directory, and any other that can be shared between the installation. When finished, if you list out the contents of the directory using the long listing format (with ‘l’ option), you’ll see something like the following:

rw-r–r– 1 shelley shelley 1061 May 19 18:35 wp-config-local.php
-rw-r–r– 1 shelley shelley 992 May 19 18:35 wp-config-sample.php
-rw-r–r– 1 shelley shelley 1001 May 19 19:26 wp-config.php
lrwxrwxrwx 1 shelley shelley 38 May 19 20:36 wp-content -> /home/shelley/www/wordpress/wp-content
-rw-r–r– 1 shelley shelley 585 May 19 18:35 wp-feed.php
lrwxrwxrwx 1 shelley shelley 37 May 19 18:35 wp-images -> /home/shelley/www/wordpress/wp-images
-rw-r–r– 1 shelley shelley 4656 May 19 18:35 wp-layout.css
-rw-r–r– 1 shelley shelley 2182 May 19 18:35 wp-links-opml.php

You might be asking yourself about now, why didn’t I link wp-admin and wp-includes? Well, it wasn’t for lack of trying.

One major dependency in the whole system is the wp-config.php file, located in the root directory of the WordPress installation. Not only does it provide database access, but it also defines the location of the installation, in a variable called ABSPATH, set like so in the code:

define(’ABSPATH’, dirname(__FILE__).’/’);

This variable and the data connection information is used all throughout the system. It’s incorporated by including the wp-config.php file within other PHP files. The code used in the files is the same as the following, found in the admin-header.php file:

require_once(’../wp-config.php’);

Unfortunately, that little reference to a relative location, ‘../’ in the code defeats the symbolic link within PHP code. No matter how you try and trick it. So, the wp-admin and wp-includes files don’t access the specific version of wp-config.php in each weblog directory– they access the one in the initial WordPress installation, every time.

Not too handy if you’re trying to access wordpress2 or wordpress3, or wordpress(n).

Until I find a workaround, you’ll have to just copy wp-admin and wp-includes. And to be honest, if you’re not comfortable with the Unix system, you’re going to just want to copy all of the files. It is easier that way. You just have to remember when upgrading to make copies across all the installations.

Where to next

This is all a workaround, and a hack. It definitely works, and you shouldn’t have problems – but it exposes way more of the Unix environment than a lot of people are comfortable with. Heck, even I got lost a time or two. Or three. And you don’t even want to know what I was saying about symbolic links, relative directory references, and PHP.

The next step is to take this into full multiple weblog management, and this doesn’t have to be complicated, but will require more coding. Specifically:

  1. First, the concept of the table with metadata for each of the weblogs is good, but it needs to be extended to include the table prefix for each weblog installation. In addition, a second table to record users per weblog should be added to restrict access to the weblog to authorized folks.
  2. Once this is done, then the wp-config.php file should be altered to point to the database, not a specific implementation. This means we would have one wp-config.php file for the entire installation.
  3. Instead of running an installation program, an introductory page would provide access to functions to create a new weblog. The subdirectory would still need to be created, but the administration page would not only create the set of tables for each weblog, it would record information about the weblog so that the next time the page is accessed, the weblog shows in a list.
  4. The administration page would allow you to select any one of the active weblogs, and when you proceed to the WordPress pages you see now, they would be activated for this particular weblog. This will require some, but not excessive amounts of edits to the current admin pages. The WordPress folk have followed some good, clean coding techniques separating the data from the process as much as possible, which makes this task far easier.
  5. For a little frosting on the cake, when we create the weblog, we could also copy the individual weblog pages into the new account, except for one thing: write permissions. That thing I wrote about in the last LAMP essay. The only way we can copy files into the new directory would be to set the write permissions to global in that directory. To be honest, I think a better approach would be to create a separate subdirectory in the WordPress install with files that need to be copied for each new weblog, and just let the folks handle the copy. Sometimes, less is more.
  6. Finally, a set of cross-weblog functions should be created to allow one to access posts across weblogs, in addition to comments, and maybe even categories. This can be managed in SQL, as long as the database is a certain vesion. Yeah, for SQL.

I won’t take on this hack. Why? Because open source is not chaotic source.

The WordPress development team has multiple weblog support planned for a near-term upgrade, and I can’t see why both of us would be coding at cross purposes. In addition, my design idea may not be compatible with the existing development team’s idea of how to implement this beastie. Why introduce contradictory implementations?

As it stands now, my little emulation system is forward compatible with multiple weblog support because the plan has always been to support different tables for each weblog. When this happens, just drop my table, and my menu.php, and we’re ready to rock and roll.

I hope no one is disappointed that I don’t have something more sophisticated. If you see errors with the implementation, please let me know. If you see a better approach, then please, either add a comment, or even write it up at your site. This is a lot of typing, and I need a break from the LAMP series, and I’m tired – so please excuse what are, I’m sure, many typos.

Categories
Places Weather

Don’t visit in the summer

I love my new adopted home, I really do. I’d love to share it with all of you, except that I have to honestly say, whatever you do, don’t visit this summer.

It’s only the middle of may and we’re heading to 90F, and 85% or better humidity. I went to the library and the store, both of which were cooled (and the library had some kind of band playing, go figure), but by the time I came home, I was dying. And it smells like something crawled into the attic and died.

With the rains we’re having and these 20 degree above normal temperature days, and the mild winter, the Missouri Green will have progressed from beautiful and mysterious and richly emerald to forests black as night because the foliage is so heavy. Not to mention the ticks and all the other insects out this year.

But let’s face it: bugs aside, you can’t do much when it gets over 100F and close to 90% humidity. Well, maybe you can. I can’t.

Fall. Fall is a nice time to visit St. Louis. Not September, I’m heading to Alaska in September. October. Octoberfest in St. Louis.

Categories
People

I’m out of control

At wood s lot a reference to an old online interview with W.G. Sebald. What an unexpected treat this was.

The entire interview was classic, wonderful Sebald, but I particularly liked what he had to say at the end of the interview:

Certainly, my own life experience is that when I thought I had things sorted and I was in control, something happened that completely undid everything I had wanted to do. And so it goes on. The illusion that I had some control over my life went up to about my thirty-fifth birthday. Then it stopped. Now I’m out of control.

Sebald died in a car accident not longer after that. I can’t help thinking he would laugh at the coincidence between what he said and his own death. Yes, he would laugh.

I deeply regret that Sebald died so young. I selfishly wish he had lived to 100, writing every single day. I cannot pick up one of his books without finding myself caught up, again, in the ribbon of words he pulls gently behind him. I guess this makes him one of the lucky ones: those who manage to create something of such unique and enduring beauty that it lasts five minutes beyond his death.