Last week I began moving the current Palmer LTER site into WordPress, mainly as an experiment to see how well WordPress works as a CMS-lite solution. I had already moved the CCE LTER site into WordPress successfully (being a much much smaller site compared to Palmer). The CCE site performed smoothly under WordPress 1.5. For the Palmer site, I downloaded and installed the newly released WordPress 2.0.

The result was not impressive.

After migrating a dozen pages, I noticed that WordPress 2.0 performs awfully slow, even compared to version 1.5. There were a lot of lag time (wait) between page navigations. Though WordPress 2.0 contains some improved features in the administrative area, the cons of the sluggish performance outweigh the pros of the beefed-up admin interface.

At this point I had 3 options:

1. Continue with the migration to WordPress 2.0. Maybe the slow performance is a transient issue that may go away (a future release of WP 2.1?, or a server-related issue, etc.)…. this however is a fat chance.
2. Downgrade back to WordPress 1.5. Afterall, the CCE site runs fine using it, where performance is much faster.
3. Throw out WordPress completely. I considered this briefly, and it quickly made sense. The Palmer site will be easier to maintain if we go back to the good ol’ file structure, and ignore a CMS-type solution completely. I’ll explain why a little later…

First, my reasons for originally choosing WordPress:

• Success with Ocean Informatics site - We’ve been using WordPress for our Ocean Informatics blog/home site since August, and it is undoubtely a success. We’ve already established a grounding of understanding and learned the intricacies of WordPress including plugins, hacks, and themes.
• CMS-Lite Solution - We’ve spent the last year and a half (though not recently) exploring various open-source CMS applications, including PostNuke, Mambo, and Xoops. Though each of these programs excel in providing various features for building a community portal, they required too much overhead for our simple Ocean Informatics group. We needed something lighter. Thus, I played around with the idea that WordPress could function as a CMS-lite solution: ability to post static pages in addition to blog posts, hierarchical ordering of categories, etc. (I still believe that WordPress is a great CMS-lite platform.)
• Pretty Themes - The most superficial reason of them all, but maybe also the most important?
  Once I downloaded and tweaked (changed colors, graphics, etc.) the Connections theme for WordPress, I felt a lot more comfortable. Building the navigation and sidebar menus became fun. The pages became colorful but not too distracting. The page title was pronounced, and it was enjoyable to read the page content…. basically it was a really well-designed theme. And I didnt have to do any design work! (Except the tweaking of course). Because all the visualization work is done for me, it relieves me of the burden of having to design the website, so I can focus more on coding applications and re-structuring the file system.

Why the Palmer site works better with a file structure:

• What to do with files? The Palmer site contains many non-php, non-html files, like docs, pdfs, images, and text files. All of these need a place to be stored and be accessable with an associated URI (web link). Using a file structure, we can logically place such files in the semantically meaningful folders, nested appropiately according to the site’s navigation scheme. This method works much better than in WordPress, where the basic solution is to throw all of these files into a centralized folder, thus flattening the semantic layout and the URI construction of the file’s path.
• The Connections theme can work outside of WordPress. It’s basically just a stylesheet, a few images, and a few php files (header, footer, etc). Even though the site no longer lives in WordPress, it can look exactly the same.
• Performance is much much faster… even faster than WordPress 1.5. Navigation between pages is lightning fast compared to within WordPress, where it stores all page content in the database. Thus, whereas WordPress takes some time to process the code and query the DB, the file structure solution simply retrieves the php file which has all the contented embedded inside.

What we lose when we move away from WordPress:

• No Web Editor - All editing takes place in the file, usually using a unix editor like vi or emacs. This means that anyone who wishes to edit a file must contain some knowledge of html. This also limits the users who can edit files to those who have server accounts or another means of access (ftp). The advantage of WordPress was its built-in web editor which generates some html for you, making it easier for non-html users to add and update content.
• Blog, RSS, etc. - WordPress is mainly a blogging platform, with rss publishing and aggragation. If we ever decide to setup a Palmer web blog, we can still use WordPress. The rest of the site, however, would stay outside.

Just why does the Palmer site need to be moved anyway?

The Palmer site doesn’t just need to be moved… it needs to be completely re-organized. The file-structure behind the Palmer site is ridiculously out-0f-sync with the web site’s navigation scheme. This is confusing because the path you would take to navigate to an item on the web site differs from the path you would take to find the same item on the hard drive. A web site with a good navigation system is one that mimics its directory structure. The Palmer site is suffering from 10+ years of data build-up and low maintenance, creating a messy file system with lots of noise and little logic.

The experiment to move the Palmer site into WordPress was a first attempt at rebuilding the file structure. Because we have abandoned that attempt, we are simply rebuilding the directory structure from the ground-up, creating a much cleaner file system and navigation scheme.

What about the CCE site?

The CCE site is being moved out from WordPress as well. Although it worked a lot better with WordPress 1.5 than Palmer did with version 2.0, it is in our best interests to keep these 2 LTER sites as related to each other as we can, for ease of development and maintenance. Additionally, the CCE site also performs faster outside of WordPress.

When will these sites be ready?

The CCE site is basically done. Mason may still be working on fine-tuning some specific applications (IForum, etc.). You can compare the 3 sites using the links below. CCE new is the newest revision of the site (using the file system). Compare it the WordPress site. It’s the same theme (with a revamped nav-bar).

CCE site: http://cce.lternet.edu
CCE wordpress: http://ccelter-dev.ucsd.edu/wordpress
CCE new: http://ccelter-dev.ucsd.edu/new

The Palmer site, being much larger, will need more time. Hopefully by the end of this month, but depending on what other projects come up, it could be even later. I spent the last two days alone migrating the entire Datacat app from the Palmer dev site to the Palmer new site.

Pal site: http://pal.lternet.edu
Pal dev: http://pallter-dev.ucsd.edu
Pal wordpress: http://pallter-dev.ucsd.edu/wordpress
Pal new: http://pallter-dev.ucsd.edu/new

Future plans I’d like to implement is to throw these sites into Subversion, using a ‘2-way door’ method. The dev area and the production area would contain a checkout of the repository. Anytime someone makes an update (in either the dev or the production area), they should simply commit that change to the repository. Likewise, to update either area, you simply update from the repository. Nothing else fancy here… no other users or working-spaces, and definitely no trunks or branches! I feel this may be the simplest way to incorporate subversion into our workflow.

We may also want to merge (normalize) some of the code shared betweem the Palmer and CCE files, notably the templating files, and a common library of php functions. Both files are using the exact same template, differed only by the stylesheet. Any differences like these (stylesheet, site title, etc.) can be stored in the site-specific config file. Using a shared library helps ensure the sites are in sync with each other, mainly from the developer’s point-of-view. Mason and I have already noted that slight additions we make to the Palmer code-base are not in CCE, and vice versa. While this is typically a minor (if yet insignificant) impact, it requires extra manual labor to ensure that both sites are kept up-to-date with the latest additions of new functions, etc.