Scroll down to the bottom of this page (or any page in this site if this page is too long). You will find two logos added in the footer section: UCSD and SIO.

I just added these. Up until now, we had no logos on this site, except for the OI logo embedded into the header graphic.

Big deal, right?

Well yeah, it is.

Go to Google and search for ‘Ocean Informatics’ (with or without quotes). We are currently the 4th site returned in the results. Not as impressive as being in the top 3, I know… but at least we are now on the first page! For a while, we were sitting buried under layers of irrelevant results.

So what does this have to do with the logos? Well, I remember learning at point (from Wayne I think) that any publicly accessable page in the ucsd domain should sport a ucsd logo somewhere. Our site has failed to do that since August when I first set up the blog. That is, until now.

I first noticed the missing logos as a concern yesterday. I was searching for info on Subversion use with web-related projects, and I stumbled upon my recent blog entry from late last year. Treating myself as an ‘outside visitor’, I noticed that I learned very little about Ocean Informatics, particularly the Who, Where, and Why. The only hint came from the ucsd.edu domain, which would lead me to guess this was a university-related site.

Thus, in putting the logos on the site, we help to clarify the Who (somewhat) and the Where. Now, maybe we should revise the site (the content, not the theme!) to give a bit friendlier welcome to outside visitors, especially if our blog posts are showing up in Google searches.

Maybe the next step is a visitor logger…..

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.

Last night I upgraded this blog to WordPress 2.0, which was released at the end of last year. Though it contains some nice improvements, particularly in the user/admin interface, the performance was less than spectacular. The pages took much longer to load; I suspected that some of the plugins may be at fault. Sure enough, upon disabling all plugins, the site ran faster. However, since we rely on some of the plugin functionality, I decided to downgrade the site back to version 1.5.2.

It may be best to wait a few months before attempting to upgrade again. This will allow time for other developers to create plugins that work better with WordPress 2.0.

The main plugin at fault was “Extended Live Archives”, which provides the cool AJAX viewer for browsing through posts on the Archives page.

A question now looms whether we should upgrade the CCE site to WordPress 2.0. I figure that since it’s primary use is as a CMS and not a blog, it uses less plugins and thus performance may not be hindered. Additionally, I have been porting the Palmer site into WordPress 2.0, and the site seems to run OK… no worse than the CCE site runs on WordPress 1.5.2.

Read this article more about what’s new in WordPress 2.0.

A few notes from my experiences already:

• The admin interface is more colorful and uses AJAX in some places for ease of usability, most notably when Deleting an item, and also receiving a Confirmation Flash Notice at the top of the page after having successfully completed some action.
• It is much easier to upload images and files to a post. The Write Post page contains an embedded file uploaded/browser for inserting images and files directly into your posts. All uploaded files (by default) are stored and organized in /wp-content/uploads/(year)/(month)/ where year and month reflect the current date of the upload.
• In FIREFOX and IE (I assume), there is a Rich Text Editor available when writing posts. This is particularly useful for those with little or no html knowledge, yet are comfortable with a WYSIWYG (What you see is what you get… e.g. Microsoft Word). editing environment. SAFARI on the Mac still lacks some Javascript functionality, and thus does not have the Rich Text Editor available. This however is not all that bad…
• …Using the Rich Text Editor screws up Relative Links. The Rich Text Editor detects relative links (if you edit directly in html mode) and will convert them to absolute links… incorrectly (it converts the link using the wrong query path). Safari is advantageous because it allows you to save posts with relative links intact. This is extremely noteworthy, particularly for the CCE and Palmer sites which have a lot of static pages that may link to each other. If we ever move a site to a new location or domain, relative links will keep working while absolute links will break….
• Thus, as I have been working on porting the Palmer site, I’ve been using a hybrid approach. I use Firefox to do the bulk of the admin work since it contains the Rich Text Editor. However, I use Safari whenever I need to create a relative link as part of a Page’s content. It’s kind of a pain, but it gives the best of both worlds. Hopefully the guys at WordPress will fix this Rich Text Editor (bug, feature, etc… which is it?) on a later version.

I hope this wasn’t too confusing.

Overall I think WordPress 2.0 is a nice improvement and is fairly intuitive, but it definitely has its kinks. Knowing and discovering the tricks like those above will help. Since the OI site is primarily used as a blog and relies on some cool plugins, I thnk keeping it at version 1.5.2 is okay for now. However, the Palmer site runs fine on WordPress 2.0, so there is no reason to revert it back. The CCE site should probably be upgraded to 2.0 as well.

FYI, the link to the CCE and Palmer WordPress development sites:
http://ccelter-dev.ucsd.edu/wordpress
http://pallter-dev.ucsd.edu/wordpress

Quick note: All the sites are using the same theme, each one tweaked differently. I added a dark-blueish background to this site to help the pages stand out better.

Ever since I’ve opened commenting to the public (anonymous users) last November, we’ve been getting some spam comments at random posts. Lately, the number of spam comments has been increasing. Fortunately, pretty much all have them had been placed in the Moderation Queue because they contained at least one common comment spam word. I’ve been getting emails each morning for the last couple weeks telling me there are comments awaiting moderation. (WordPress provides a nice interface for moderating comments and marking them as spam).

To prevent the noise in my email and in WordPress, I have decided to once again close public commenting, so that only registered users can post comments. Note that anyone can still register if they want to.

If our blog starts seeing higher usage again and attracting more anonymous users, then we can re-open public commenting. However, since this is mainly an internal blog, used primarily by our small group, there is little need to open our doors when nobody is appearing, and at the expense of combating spam every day.

It’s time to recap some of the major changes made to the Ocean Informatics Site this week. Beware, this post is hefty. Let’s get started!

New Theme

As mentioned in the previous post, the Ocean Informatics blog now employs a new theme. For those not in the know, this Ocean Informatics blog is powered by WordPress, an open-source php/mysql application. WordPress is a very popular and widely used blogging platform. Additionaly, it benefits from having excellent documentation and strong community support, resulting in a on-growing collection of plugins (functionality) and templates/themes (presentation).

The original theme we used for this blog was a modification of the default WordPress theme. It was pretty bland. This new theme comes from a 3rd-party designer, and is also found on WordPress’s page of featured themes.

This theme is entitled Connections. I changed the hues of all the images and styles from green to blue to fit better with our original Ocean Informatics header image. I also moved the search bar to the top right of the page, and changed the nav links and the sidebar blocks to better fit our needs.

Development/Modification of a WordPress theme is fairly simple yet time-consuming. Fortunately, the bulk of the layout and structure work had already been accomplished, so my main focus was in changing the colors.

Oceaninformatics.ucsd.edu and the old OI Site

Up until 2 days ago, going to oceaninformatics.ucsd.edu would redirect you to Ocean Informatics Portal. This portal site was virtually a scaffolding site, resulting from a rapid development that wasnt given much thought. To be honest, I’m not sure what its purpose ever was, and I know for sure that no one has ever been using it.

I’ve read that WordPress can be used as a simple CMS tool in addition to a blog. Afterall, WordPress allows for the creation of static pages in addition to blog posts. Also, with the armada of external plugins available, it should be no problem to find (or develop) WordPress plugins to bolster our specific needs. Thus, I decided that the dormant OI Portal site can be integrated with WordPress. Given the power and simplicity of WordPress, we can update extra pages/data in addition to blog posts, creating a multi-functional Ocean Informatics web space.

Our WordPress installation resided in oceaninformatics.ucsd.edu/wordpress. I moved the installation source up one level to oceaninformatics.ucsd.edu. Now, instead of redirecting to the OI Portal Site, the domain points to this blog’s home page (which has the same content as the portal’s home page). The link to the OI blog remains the same.

Technical Notes on the Installation Migration

• Before the move: The original WordPress location resided in a directory called “wordpress”. A symbolic link named “blog” pointed to the wordpress directory. This is how the oceaninformatics.ucsd.edu/blog link worked. The oceaninformatics.ucsd.edu/wordpress link also worked, though we always used “blog” instead. (Both links are still active at the time of this writing… try them out).
• The move: I didn’t actually “move” the source code. Instead, I copied it up on level. Thus, the source code is duplicated at 2 places: The oceaninformatics.ucsd.edu root, and the oceaninfomatics.ucsd.edu/wordpress directory. Since changes (hacks, plugins, themes) are only being made to the source code at the root level, the oceaninformatics.ucsd.edu/wordpress is now obsolete.
• After the move: Originally, oceaninformatics.ucsd.edu pointed not to a home page, but to the blog page. I installed a plugin that enables a WordPress site to have a static front page. To maintain the blog url, I added apache mod_rewrite rules to the .htaccess file so that oceaninformatics.ucsd.edu/blog really points to oceaninformatics.ucsd.edu/category/blog. (This is how the blog url stays the same). More on categories in the next section….

Categories

Our list of blogging categories continues to evolve. WordPress supports hierarchal categories, and thus, our categories have become hierarchal. You’ll notice this next time you write a new post. The current state of categories looks like:

- Blog
– Announcements
– Community
– Data/Metadata
– Environment
– Hints
– Questions
– Tools
– Visualization
- Page
- Private
– … (not typed here to protect cat. name)
– … (not typed here to protect cat. name)
- Public
– Reading Group

The only categories this blog is concerned with are those that fall within the parent Blog category. Hence, the blog category page becomes our blog. You do not need to explicity categorize a blog post with “Blog”. As long as any one of the child categories are used, the Blog category is inferred. By default, all new posts are categorized under Blog.

The Page category used to be called “Uncategorized”. By default, WordPress categorized all pages under Uncategorized. I simply changed its name to Page. There is no interface in the admin panel to change a Page’s category.

The Private category (and its children) may be used to store information that only registered users should access. Likewise, the Public categories may contain information that anyone can access. This information can be stored in posts and also the custom meta fields. At this time, I am not sure if or how I would implement this functionality. My reasoning for private vs. public stems from the fact the the OI Portal site contained extra “private” information that was only accessible once you were logged in. The addition of these categories is currently serving as an experiment, and they may not ever be used.

Plugins

Plugins are a way to add extra functionality to WordPress. We’ve had some plugins installed since day one. Here’s a run-down of plugins we are currently using.

Active Plugins

• Extended Live Archive - This recently installed plugin provides an AJAX-based interface for browsing through our entry archives. It rocks.
• Email Notify Comment Authors - This plugin emails all authors in a thread anytime a new comment appears in that thread.
• Search Everything - This plugin extends the WordPress search capabilites to look in comments and pages in addition to just posts.
• Static Front Page - This plugin allows the front page of your WordPress site to be a static page instead of the blog. (To display the blog page, we point to the Blog Category Page).
• Subscribe2 - This plugin sends email notifications to users anything there is a new post in the blog.
• Time Zone - This must-have plugin tells WordPress to justify time changes related to Daylight Savings Time

Additionally, I am also considering a plugin entitled Private Categories 2 which allows you to mark a category as “private” so to hide any posts under that category from unregistered users. As of now, I am not impressed with the robustness of the plugin, and may search for alternative solutions. (Hence, I may not use those Private/Public categories at all).

Hacks

Jerry discovered that WordPress lacks the ability for registered users to edit their own comments. What a surprise… honestly! I figured that implementing this functionality would be somewhat trivial, and that surely someone had already developed a plugin to add this feature. Apparently, it’s a tough plugin to write.

Fortunately, for me it was an easy hack. As an aid to group blogging, users can now edit any of their own comments. (See the previous thread for the back-and-forth conversation between Jerry and myself regarding this issue).

Pages

I am in the process of porting over some of the “static” pages from the portal site to WordPress. The Pages links can be seen on the home page in the Pages block in the sidebar. One example of a ported page is Reading Groups.
» New Reading Groups page
» Old Reading Groups page

Concluding Notes and Thoughts

• I’m partially convinced that the old OI portal site never got use because it wasn’t well supported, especially as a CMS tool (for common users to edit content). I’m not sure if migrating it to WordPress will resurrect any usage, but I feel that providing some simple means for collaboration may help.
• I turned on the permalinks function for WordPress, which uses mod_rewrite. Basically, what this means is we now have “pretty” urls. So we see http://oceaninformatics.ucsd.edu/2005/11/15/testing-new-theme/ instead of http://oceaninformatics.ucsd.edu/blog/?p=76, even though they both point to the exact same place.
• Regarding email notifications: No offense, but email notifications are sooooooo 1997. The real method now is RSS. We have 2 plugins used for email notifications, but WordPress offers 2 RSS feeds as part of its core functionality: One for new posts, the other for new comments. For those who like to evolve with technology, consider using these instead.
• Regarding editing comments and posts: I mentioned this in the previous thread, but any edits to comments and posts should be done with care. It’s one thing to fix a small typo, or to rephrase a sentence. However, it’s bad practice to edit a bulk of content, or remove it completely. If you need to update any information mentioned in a previous comment or post, the best way to do it is to append the new information at the top (or bottom) of the post, headlined with “UPDATE”. This gives the users a clear visual clue that something has changed.

This is a new blog theme, a modified version of Connections. I changed the header image, and pretty much every other image and stylesheet (changed the hue from greenish to blue-ish).

In addition, the blog root now rests at http://oceaninformatics.ucsd.edu. The main blog link remains the same.

Check out the Live Archives plugin on the Archives page (the top nav bar). It’s pretty sweet and uses AJAX and stuff….

More to come about the new blog/appearance/migration/etc. This post is acting as a quick FYI.

Geoffrey Bowker appeared in a “top story” on CNN.com this morning in an article about wireless technology: Wireless technology changing work and play

The article discusses advances in wireless technologies and how it impacts social ettiquette and security.

Congratulations Geoff for having your name in a worldwide news story!

If you are an avid reader of this blog, then all 2 or 3 of you may have noticed a few recent changes. In particular, these changes are the header/logo, horizontal navigation tabs, and the sidebar navigation.

You can view “before” and “after” snapshots of this blog here.

The categories page shows a listing of all posts sorted by category and ordered by date.
The posts page shows a listing of all posts ordered by date.
The pages page shows a listing of all static pages embedded into our (dynamic) blog. We only have one such page thus far, that being the Screenshots page linked above.

The tabs may be useful in helping keep track of your location. As an example, the posts tab becomes active when viewing a single post (with or without comments). Before this feature, it was sometimes difficult to determine what type of page you were on, requiring you to scroll down and see.

The sidebar navigation has an addition of links titled “Active Threads”. This list shows the 6 most recently commented posts, with the most-recent on top. This should help us keep track of where the latest commenting activity is.

Happy blogging!

I removed the Xoops CMS from underneath the interoperability site. The url remains the same:
http://interoperability.ucsd.edu

These pages are purely static, written in php but with no database back-end, meaning that all content is hard-coded in the html (including the old wiki pages). There is no longer an authenticated user-base, so all pages and content are readable by the public. Future plans include the addition of a blog (another instance of WordPress), and a file upload/download manager (similar to the CCE iForum).

The old Xoops site is still online, with the new location:
http://oceaninfo-dev.ucsd.edu/interoperability

Development work for the static site will continue at:
http://interoperability-dev.ucsd.edu

Future development plans include adding a breadcrumb trail on the pages, and versioning the source code using Subversion.

EDIT - srhaber 8/19
I added the breadcrumb trail to the new site. I had trouble adding this the other day, thinking it was a php include path problem. Turns out I was just missing a helper function in the code for the breadcrumb function.