Dale wrote a pretty informative post over on BraveNewCode, so check it out. In short, we’ll be releasing a very reasonably priced paid version that includes support first, then will eventually roll out another free version using the new codebase. The major addition to WPtouch 2.0 is a new theme framework for creating mobile themes. WPtouch 2.0 will also ship with more than one theme, so that should be an exciting addition for people who use WPtouch.

For more information, check out Dale’s post above, or following along at wptouch.com, or on BraveNewCode’s Twitter feed.

In the past, I’ve helped put together a few small WordCamp Vancouver events, but the one we’re planning is going to be a fairly large one I imagine. Right now we’re exploring venues in the downtown area near the water, so hopefully people coming from out of town can be treated to some picturesque views of downtown. Right now the tentative date is June 12th, 2010.

I won’t say anymore, since we still have lots to plan and discuss. You can follow along via email by subscribing from the main site at wordcampvancouver.com, or follow WordCampYVR on Twitter. If you can help get the word out by Tweeting or blogging about this event, that would be great — thanks!

So while I make no promises, perhaps there will be a late 2010 version or and early 2011 version of WordCamp Whistler again if there’s interest. If you would be interested in that, then drop a line here. If there’s enough interest, I’ll try to rally the crew and see if we can pull something off. To keep up with future WordCamp Whistler updates, please follow the official feed on Twitter.

Back in September I wrote a post about switching to Server Beach. For the most part, it’s been pretty rock solid. We have a dual core server there with cPanel on it, and it’s been relatively pain-free. One of the reasons we opted for a dedicated server was to make our lives a lot easier. Prior to setting it up, Dale and I realized we had about four or five hosting accounts combined, many of which had old sites on them. Unfortunately, keeping everything running smoothly in that scenario is a challenge, especially when you’re also trying to develop (and backup) sites for clients. So, we decided to migrate everything onto one server.

We’re about 80% of the way now, and have shut down a few hosting accounts already (including my old Rimu hosting VPS). I’m about to finally pull the plug on my Media Temple account as well, which I’ve been trying to do for about six months now.

One of the two tools Dale and I use fairly religiously is DropBox. DropBox allows Dale and I to share a virtual hard drive up in the cloud. Whenever either of us updates a file, it automatically synchronizes the other person’s machine. Last night I also found a Linux based client for it, so I set that up on our server and tied it into Apache. That means Dale and I can basically modify live sites just by dragging files into folders on our local machines. Conversely, I configured some of our backup scripts to store various files (such as MySQL backups) in DropBox as well, which means Dale and I both automatically get server backups on our local machines every night. I think it works pretty slick actually, and I think we’ll be able to do a few more cool things with that setup.

My personal goal is to make it so that developing a site on my local machine is nearly identical to developing a site on a remote machine. Having everything on one server facilitates that quite nicely. For example, the Server Beach MySQL server is configured as a master, and my personal laptop machine is configured as as MySQL slave. So whenever I do a posting to duanestorey.com (which resides on Server Beach), the database is automatically synchronized with my laptop. The next step will be to synchronize the files (through some combination of SVN and DropBox), at which point I’ll have pretty much an exact replica of the live sites on my laptop (and so will Dale hopefully), which means I can develop without an internet connection, and simply synchronize everything to the live server whenever I’m plugged in.

So, hopefully by the end of this week we’ll have shut down all our other hosting accounts. If anyone is considering moving to Server Beach, feel free to use our referral code: SXHH4BQ82M. I believe you’ll save $100 on your first month’s bill, and we’ll also get a kickback to help us out as well.

Today Dale and I woke up and starting seeing some press about the new mobile versions on WordPress.com. WordPress.com is the free, hosted version of the WordPress platform, and currently has around 5 million blogs or so on it I believe. As of today, the iPhone plugin for WordPress that Dale and I created, WPtouch, is now live on WordPress.com, and is the default theme for all users viewing the site on an iPhone. That means roughly 60 million page views a month on WordPress.com will feature WPtouch.

That’s obviously super cool, and we’re pretty excited about it. Thanks to everyone for supporting WPtouch and BraveNewCode! Dale and I have a lot of really exciting things on the go right now, so stay tuned for some more excitement. If you want to follow along, follow us on Twitter, or sign up for our newsletter.

I gotta say, WordCamp Portland was a really amazing event, so major kudos to everyone involved in pulling it off. In fact, with each WordCamp I attend, I think that bar is getting progressively pushed higher and higher. For example, prior to my talk someone came and fitted me with a wireless microphone in addition to a normal microphone, the former being for the live stream. In addition, they exported all my slides to JPG/PDF such that the people watching on the internet could go through my slides while I was talking. Apparently the live stream was nearly flawless as well, which is great.

One thing that still bothers me about conferences in general though is sort of the lack of tact on Twitter sometimes after the fact. Everyone is entitled to their opinion, but I hate seeing people dish out insults or negative opinions and then add the conference hash tag to the tweet so that everyone sees it. I didn’t see much of this in Portland thankfully (way to go Portland!), but I’ve been to a few conferences where that’s the case. It must be hard as a speaker spending all that prep work (or traveling) only to be greeted with a pile of negative comments on your presentation or your content after it’s all done. I think some things are better said offline or in an email, but that’s just me.

But anyways, Portland was great, and everyone I met was super nice. The conference went awesome, and I learned a lot of cool things. But, as I pointed out before, I’m happy to be past it, since now I can focus on taking a bit of a breather at home. Dale’s flying in on Thursday and hanging out at my place for the weekend, so we’ll probably just take it easy, grab a movie or two, and maybe hit a restaurant or two. I also have to write an article this week for a Europe magazine (I’ve been putting it off), but hopefully that won’t take me too long.

There was a dinner last night for the speakers and sponsors, and it was good to finally meet everyone involved in the event. The restaurant was Ethiopian, which you don’t see too many of back in BC, so it was a great treat. Thanks to the dinner sponsor who picked up the food and drinks last night.

I was originally going to come back to my hotel room last night and work on my slides, but truthfully, was pretty beat. I decided to take the rugby game approach to my slides and take the day off before the game. So while I’ll tweak them a bit over the next seven hours or so, I’m probably just going to present what I already have prepared, which I think will be fine.

I also have to thank the Coast Hotels for giving me their friends and family rate in Portland’s Benson Hotel. The room is basically a small suite with a big, soft king-sized bed, and it’s super comfy.

I have a little surprise in store for my presentation, and I’m hoping there’s audio available up front. If not, I may try to run out and get a little speaker system such that I can play something.

If you’re just passing by here from WordCamp Portland, feel free to drop a comment and say hi! I hope to meet as many people as I can over the course of the next 48 hours, and hopefully see a few people later at a bar. Also check over at BraveNewCode where I’ll probably put a few blog entries up later.

[poll id="16"]

[poll id="17"]

[poll id="18"]

[poll id="19"]

[poll id="20"]

Based on the results from this, I might ask a few more questions. Thanks everyone.

I’ll be speaking on mobile blogging, with an emphasis on our WPtouch plugin. I’ll probably also talk a bit about mobile blogging in general, similarly to what I talked about at the Network Hub a few years ago. If I have time, I’ll probably also touch on the WordPress iPhone application a bit, and whatever else in the mobile sphere I can find. Matt Mullenweg will also be holding a town-hall type of event where the audience can ask a bunch of WordPress questions, so that should be fun.

I’ll be flying out of Bellingham on the 18th of September, and returning late at night on the 20th. I’m not sure where I’ll be staying yet, but a few people pinged me on Twitter with some possible options, so we’ll see where those lead. I believe I’m currently slotted to speak on Sunday sometime, so Saturday will probably be the day I start putting my slides together. I imagine there will be some type of social on Saturday as well, so that should be fun.

If you’d like to read more about it, visit the official WordCamp Portland website.

While the event was really successful in my mind (the speakers were great, the staff at the Fairmont were helpful, and everyone I talked to felt that they got good value from the event), in retrospect I might have organized something a bit more local. The costs associated with the event kept ballooning over time, and it was extremely stressful near the end when we were operating the event in the red, especially since I was basically bankrolling the event myself. We were forced to raise ticket prices at the end higher than I had wanted, simply to recoup some of the costs, and also reached out to a few of our sponsors, several of which helped shore up the difference. Initially tickets started at $35 (we had assumed most of the costs of the event could be handled with sponsorships), but eventually went up to around $75 as the deficit grew (since sponsorship ended up being low).

We had originally budgeted for only two drinks per person at the social, and assumed only about 75% of the people would come. I’d guess only about 40% of the people showed up, and of them, only about half were serious about drinking. That combination basically made it so we could open the bar up, which we were happy to do. Ultimately we had about $1,000 put aside for the social, but only spent around $800 or so.

In the end, I think we ended up about $100 short with the event, which was no big deal, especially considering we were about $2,000 short about 10 days before.

Here’s a quick run down of the associated costs with the event:

• 120 person conference room – $840
• Internet access during the event – $210 (the venue actually wanted $15/head, but I managed to convince them to simply give us an internet drop, and mostly Dale took care of the wireless at the event)
• Insurance – $210
• WordCamp Whistler Toques – $910
• Social at the Longhorn Saloon – $800
• Rooms + Travel – $620
• Catered lunch – $2,506
• Audio/visual/power for the event – $1,191
• Coffee – $1,240

The grand total for the event was close to $9,000. In terms of revenue, we received $4,150 in sponsorship, and $4,478 in ticket sales. As you can see, coffee and food took up a sizable portion of the budget, something I tried very hard to reduce with the venue.

So if you’re organizing a WordCamp in a prime location such as Whistler, this might be a fairly good guide for how it works under the hood. A simple way to reduce costs is to ask everyone to be responsible for their own drinks and lunch, as they amounted to nearly 50% of the cost.

First, here’s a definition of a permalink:

A permalink, or permanent link, is a URL that points to a specific blog or forum entry after it has passed from the front page to the archives. Because a permalink remains unchanged indefinitely, it is less susceptible to link rot.

An example of a WordPress permalink is this link, http://www.duanestorey.com/blog/2009/wheres-duanedo/, which points to my Where’s Duanedo post.

Why it’s not really permanent is that I can go into the WordPress back-end administration panel and change the structure of that link after the fact, adding the month and/or the day of the week. For example, in about 15 seconds I can change it to http://www.duanestorey.com/blog/2009/08/01/wheres-duanedo/, which depending on how you feel, might be a bit cooler. Those changes are retroactive, and will change all the links on the site.

Unfortunately, since I’ve given out the old permalink to people, it’s possible that those links may not work anymore (I believe WordPress will do a search under the hood to see if it can find the post, but I’m not entirely certain how well that works).

Anyone who has moved a site knows that you can still make the old permalinks work by doing some .htaccess 301 trickery, but depending on how you involved the changes are you did, that can sometimes be a bit gimmicky.

Really, the only true WordPress links that are permanent are the default links involving the ?p= URL parameters. For example, the true permalink for my Where’s Duanedo post is http://www.duanestorey.com/?p=4943, which involves the post ID.

I was thinking last night of the consequences of always using the true permalink under the hood, even if friendly permalinks were enabled in WordPress. Truthfully, I think it would work just fine, since WordPress automatically does a 301 redirect from the true permalink to the friendly permalink, the former of which is not susceptible at all to link-rot (as long as the blog address doesn’t change). It adds some header traffic for the 301 redirects, but should always work, even if the URL structure is changed at a later time.

Anyways, some food for thought.

I have a few basic goals for the new theme:

• The theme should put more focus on aspects of my life such as photography, and less on my other content
• The theme will focus more on my life, and some of my passions (such as blogging and WordPress development), and less on random blog entries about nothing
• The theme will basically update itself from third party services

I’m debating deleting a really large chunk of content from my current site. Some people will say that’s stupid from a search engine or SEO perspective, but I really think some of those entries (and the traffic they generate) don’t really lead to any useful traffic. For example, if someone gets to my site looking for a JPG of the Kool Aid jug, it’s not really that likely they’re going to want to read about WordPress or current events.

I’d like to only have four or five main categories on my site — currently I have about 20 I think. Unfortunately too, I think I installed a version of WordPress a year or so ago where the taxonomy system wasn’t completely cooked, and a lot of my tags are messed (lots have hyphens instead of spaces for example). So part of me wants to kind of start over and fix all of that. I haven’t thought it through very far yet, so I need to think about it a bit longer.

I’d really like to spend more time taking photos in the future, and I think if my blog were more photo-centric I’d be inspired to post more photos. I’ve actually sat down a few times to do a photo-centric site, but I’ve always had problems making it work. For one, photos are usually either landscape or portrait. From a design perspective, that gets a bit clunky, especially since several portrait oriented photos can have completely different aspect ratios. I might end up writing some PHP code to letter box photos such that they’re all the same size, but I haven’t made it that far yet. Since photos look brighter and more colourful when shown on a black background (the same way a stereo sounds “better” when it’s louder), I’ve made the new version have a dark background instead of the white I’ve used a few times in a row.

I started working on version two of my Crossroads plugin a few months ago. Crossroads was a pretty popular plugin for people wanting to put Flickr photos on their websites. Unfortunately, I never spent a lot of time improving it, so it’s kind of rotted on the sidelines. So version two was meant to be a pretty substantial improvement, especially since I’m also adding support for SmugMug. The good news is that Crossroads 2.0 already interfaces quite well with Flickr, so I’ve been extending it to do most of the heavy lifting on my site.

I’ve created a photography section of my site that basically shows all the photos and sets from a Flickr collection. It looks sort of like the following image:

If you want to see a live demo, head over to the demo site and check it out.

With this setup, I can basically just upload photos to Flickr, but them in the appropriate sets with the proper descriptions, and my site will automatically update itself. I’ve also created a special page for viewing each individual image (where in the past I would have just redirected people to Flickr). This method actually has several advantages. First, the verbiage and those images will essentially reside on my site, and not on Flickr. Given that my website has more Google juice than my Flickr stream, in theory I should start getting a lot more traffic based on my photos. I’ve also made the theme CC license aware, such that the proper form of attribution along with a link to the associated license is displayed under each photo. I’ve always liked EXIF information, so that’s included as well. If you want to see an example, head on over here.

Lots of designers use Photoshop. Unfortunately, I’m sort of Photoshoptarded, so I don’t really use it that often. So when I design a theme, I usually just start hacking out ideas using PHP and CSS, and slowly refine them with each iteration. So undoubtedly what I’m working on will end up being different than what I’ve started putting together, but at this point I’m just trying to flesh out the functionality.

I’m really not sure the best way to integrate Twitter at this point. Given the amount of Tweets I do in a typical day, it’s really not very useful to have them in a list anywhere. I might figure out a way to do something with the Twitter favourite system and have only those Tweets shown somewhere. I’m also probably going to put some type of FriendFeed or LifeStream on my main page, such that it represents a snapshot of everything I’ve been doing. I’d also like to find a way to merge Flickr and SmugMug, such that someone viewing a Flickr photo would be presented with a “Buy Photo” which would redirect them to the same photo on SmugMug. I’m pretty sure I can come up with some clever tagging system to make that work.

Anyways, that’s my little project for July.

Several fairly exciting things happened during Matt Mullenweg’s State of the Word Presentation. First, Matt showed a slide which displayed some of the new profile information that is going to be coming to WordPress.org — BraveNewCode has actually been helping with that effort, so it was great to finally have some of it shown to everyone. Second, Matt displayed a list of the coolest three WordPress plugins, as voted by people on his Twitter stream. The first plugin that was shown, the third coolest plugin, was actually WordTwit. Dale and I were both pretty floored seeing it up there in all it’s glory on Matt’s slide in front of about 700 people. The second coolest plugin was a related posts plugin. And then, Matt flipped to the number one coolest WordPress plugin, none other than Dale and my WPtouch iPhone plugin. So, BraveNewCode walked away with the #3 and the #1 spots for the coolest WordPress plugins — a pretty exciting event for us to be sure. So thanks to everyone who voted for us.

Later that night we attended the social down at Automattic’s new offices at Pier 38. I had the chance to meet a lot of great people in person, many of which I had only talked to online before. The bar was completely open, so most people did fairly well in the liquor department. Afterwards all of us found a little hole-in-the-wall diner and had a nice greasy meal to close out the evening. I’ve been really enjoying guacomole lately, and I managed to find a hamburger that had a healthy dose of the stuff on it.

Tomorrow I’m going to be making the long journey back home. I’ll save the details of that for my next post.

There are a lot of other reasons why you might want a single WordPress install for multiple blogs. First, if you make backups of each blog’s data from time to time, you might end up with a complete WordPress package for each website you host, even though ultimately 90% of those files are identical (basically only themes, plugins and custom content vary). Second, if you run a hosting server with a PHP caching engine (which most do), it’s likely that the cache keeps track of data using the complete path to the file, which ultimately means the cache effectiveness will decrease proportional to the number of sites (aka WordPress installations). If all the installations on a server shared one common WordPress install, you’d only have to cache that one set of PHP files — effectively you could keep WordPress in a compiled state in memory for all of your sites.

The first thing I did was install a fresh WordPress into a directory on my server called wp_install. Normally an end user would go through the installation process and configure that one installation, and then they’d have one blog. We’re trying to make one installation work for many blogs.

Next, I created a wp_domains directory at the same level as wp_install. Inside wp_install, I then created a symbolic link called “domains” which points to the wp_domains directory (you could also just put everything in the wp_install/domains directory, but I want to keep them separated slightly). So we have wp_install/domains symbolically linking to wp_domains.

In order to make one installation work for many sites, you basically need to have a dynamic wp-config.php file that can change depending on which site is being accessed. So I started messing with wp-config.php to try and come up with something that would work. The end goal was to change the parameters in the wp-config.php ssuch that we can use site-specific content in the wp_domains directory.

I ended up with something like this:

$website = strtolower( str_replace( "www.", "", $_SERVER["SERVER_NAME"] ) );
$website = preg_replace('[^a-z0-9\.-]', '', $website );

if ( file_exists( dirname(__FILE__) . "/../wp_domains/$website/db.config" ) ) {
require_once( dirname(__FILE__) . "/../wp_domains/$website/db.config" );
} else {
echo "Sorry, no configuration defined."
die;
}

Several things happen in the code, so let me try to explain. First, the destination website is determined using the HTTP server name which is passed in the address. For this website, that becomes www.duanestorey.com. I strip off the www just so that there’s a bit of consistency between sites. Next, I tell WordPress to change its default wp-content directory to the domains/WEBSITE_NAME/wp-content directory, which in my case is domains/duanestorey.com/wp-content.

In the next section of code, I check for domains/WEBSITE_NAME/db.config, which is a site-specific file that will set the database information on a per-site basis. If it exists, we load it up such that the username, password, hostname, and database name for that particular site.

An example of db.config for my site is:

<?php
define( 'DB_NAME', 'duanestorey-com' );
define( 'DB_HOST', 'localhost' );
define( 'DB_PASSWORD', 'user' );
define( 'DB_USER', 'password' );
?>

At this point, everything worked fine, and I had a base WordPress installation where the wp-content directory and database information could be split out dynamically. From a hosting perspective, you could conceivably only grant access to that one directory (i.e. wp_domains/duanestorey.com), which would allow the user to modify their plugins and themes for their site only (even though the core WordPress files are being shared).

It’s at this point I actually decided to do a Google search to see if anyone else had tried this approach before. I found this article on Virtual Multiblogs which is based on a similar approach. It looks like he used a bunch of different directories all mapped to one WordPress directory. In the approach I’ve taken, I point everything to the same directory (in the HTTP virtualhost section), and simply rely on the HTTP_HOST/SERVER_NAME that’s sent with each request. In addition, I’m doing the wp-content remapping, which I don’t think was done with the Virtual Multiblogs approach. I also did a bit more, as you’ll see next.

You might be asking why I didn’t just do away with the wp-content directory although, and simply remap it to wp_domains/duanestorey.com — it’s a good question.

There are a few problems with the current approach. First, remapping the wp-content directory often breaks plugins because many plugin developers hardcode the URLs as /wp-content in the code (it’s sloppy, but I’ve done it previously as well). So as soon as you move your wp-content directory, all those plugins start showing errors. Second, some javascript libraries and statistics programs (the popular Mint program, for example) must be installed in the root of the website. With this model, you really wouldn’t want users to mess with any core WordPress files or directories, so they really shouldn’t have access to the root installation. So what do we do?

Well, I came up with a little .htaccess hack such that anything that isn’t found in the core WordPress path is automatically redirected to the domains/WEBSITE_NAME directory. That means if http://duanestorey.com/test.html isn’t found on disk in wp_install/test.html (which is the base WordPress installation, so it definitely won’t be there), the .htaccess redirect will send it to wp_domains/WEBSITE_NAME/test.html (or in my case, wp_domains/duanestorey.com/test.html). The redirect is internal, which means that from the user’s perspective they are really looking at http://duanestorey.com/test.html (but on disk they are actually viewing the file in wp_domains/duanestorey.com/test.html).

This approach should fix most of the plugin problems since it uses URL remapping to trick the website into thinking everything actually is in the http://somedomain.com/wp-content directory, even though there’s nothing really there. It also should allow users to install whatever they want in their directory (mint, javascript, whatever), since anything not actually found in wp_install will redirect to their site-specific domain files in wp_domains.

In fact, once you do the .htaccess change, there’s no need to define WP_CONTENT_URL in wp-config.php anymore, since the htaccess will take care of all of that automagically. So, feel free to remove:

define( 'WP_CONTENT_URL', 'http://' . $_SERVER["SERVER_NAME"] . '/domains/' . $website . '/wp-content' );

Internally, http://www.duanestorey.com/wp-content/themes/duane-apr09/style.css is actually mapping to http://www.duanestorey.com/domains/duanestorey.com/wp-content/themes/duane-apr09/style.css, but since .htaccess is hiding all of that, plugins with hardcoded elements should work normally.

I’ve currently moved this website over to this new approach, and will probably move a few more tomorrow and test it out further. Ultimately I can stop backing up whole directories with WordPress installations, and simply backup my wp_domains directory nightly. So far, things appear to be working quite smoothly (even old images that were inserted into posts using relative /wp-content/ URLs work properly thanks to the .htaccess trick).

The current structure of my wp_domains directory is:

• /duanestorey.com
• /duanestorey.com/mint/*
• /duanestorey.com/wp-content/*
• /duanestorey.com/db.config

The .htaccess hack I came up with is below:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /

# END WordPress

I’m by no means a .htaccess expert, so if you see anything wrong with it, please let me know. It seems to be working though (I have Mint working).

Since I haven’t touched any C++ in about two months, I thought I’d try my hand at writing a quick web server to see if I can better understand some of problems. For now, I’m leveraging boost for all the threading, and just using simple select now for all the socket communication (I understand the limitations of select, and will probably move things to boost::asio when it’s all done).

I originally wrote it using a half-async pattern, but found that I was having problems getting the threading the way I wanted without having lock contention going on between threads. So I’ve pretty much abandoned that in favor of a fully asynchronous architecture, which is trickier to handle but ultimately gets rid of nearly all of the locks. I still haven’t really figured out the best way to handle memory, but obviously some type of pool is going to be required for high efficiency. One of the areas I spent a lot of time with at my last job was optimizing code for speed, so I’m hoping I can bring some of that to the web space problem as well.

In terms of the actual server, right now there’s a main thread handling all the dispatching and communications, and a pool of worker threads handling the actual web traffic. It’s a typical web traffic architecture, and I plan to pick it apart when I’m done to see if it actually makes sense.

In about four hours in front of the TV yesterday I managed to get the web server (affectionately called Webby right now) to serve static content. I’m using four threads right now for the worker pool, but it’s completely configurable (I’m guessing around four threads per core is probably ideal). Once I had that working, I decided to take a stab at getting PHP code to work. I did some basic stress testing at this point (no point in continuing if I can’t blow Apache away). I did 10,000 requests for static content using Apache, and 10,000 requests for the same content using Webby. Apache took 42.5 seconds to serve a static HTML file over the LAN, which amounts to around 235 individual requests per second. Webby did it in about 3.28 seconds.

Apache has an distinct advantage because PHP can be built as a module for it, basically loading PHP into Apache. Given that this is just something I’m doing for fun, I don’t really want to spend the time doing that at this point. So my only options at this point are to drop to the OS and execute PHP, or execute it as a CGI. I tried the former, and it was painfully slow. So that basically meant going the CGI route.

The best way to do CGI is using Fast CGI, which is something I’ve never done before. Basically you open a local socket to a server running PHP, and send it requests to process scripts. I ended up writing a mini Fast CGI library, since I couldn’t find one that was usable. It took me a few hours, but it seems to be working now with PHP.

I still have a few major optimizations to do before I can test out the PHP part properly (you have to initialize PHP with various variables before WordPress will work properly), but maybe next weekend I can set aside an afternoon and finish it off.

Apache’s major detriment is that it’s such a memory hog. Without a doubt, one of the major advantages to Webby in a low memory environment is that it won’t start trashing into swap space as soon as Apache will. I also will be able to adjust the stack size per thread (something that I haven’t done yet), so conceivably I could get the memory foot print even lower (although right now Webby is using around 1.5 MB of memory, whereas Apache is using around 120 MB I believe).

A few days ago I sat down and started working on version 2.0. It’s a 100% complete rewrite, which given the state of the old code is definitely something that’s going to improve it. I’m writing it with both Flickr and SmugMug in mind, so it will most definitely support both out of the box. I’m also ditching all the old prototype concepts and switching it entirely to jQuery.

I’m still prototyping several concepts, and still don’t have that warm, fuzzy feeling with the direction it’s going. Part of the problem is having it integrate with WordPress without forcing the user have to make any adjustments to their theme. That’s a big constraint, and given the market I’m trying to cater to, I’m not sure that’s the best option to be honest.

At least personally, I’ve never found an image plugin that makes showcasing my photos very easy. I use Flickr RSS fairly religiously, but that only showcases recent photos, so it doesn’t help for general blogging. I’ve always felt like there needs to be a better way to have photos tell stories in addition to the text of a blog entry, and that’s something I’m hoping Crossroads will ultimately help with.

One of the shortcomings with the first version was that you had to post photo and set IDs into the post content to have images show up. I’m going to fix that this time and put some kind of administrative interface for selecting photos or albums to be included. So hopefully when it’s done it’ll be far better than the old version.

Here are a few photos from last year’s Northern Voice displayed using Crossroads 2.0. As I mentioned, this is just one of many rough implementations I’m going to do to test things out.

[crossroads type="flickr" set="72157606640072832"]

Another complaint I used to get is that you could only have one line of Crossroad photos per post in the old version. Since I have rewritten it, I managed to get that functionality in right from the get-go this time. Here’s another group of photos to demonstrate.

[crossroads type="flickr" set="72157600042953096"]

For all you photographers out there, drop a comment and let me know what features or functionality you’d like to have on your blog, or any problems you’ve hit that you’d like solved.