Starting last week, we’ve implemented many changes and features to the Palmer LTER development website. Though we have not yet completed our on-growing list of items, we are comfortable enough with the site that we aim to publish it at the public domain by the end of this week.

Our list of changes and features spans many areas. While some changes are architectural and “behind-the-scenes”, others are up front and purely visual. Some of the features are mainly used as development aids, making it easier to modify the site without breaking it.

A breakdown of some of the recent changes and features:

Normalizing the CSS
This is an architectural change. Our CSS files were decentralized and fragmented, making it virtually impossible to apply trivial style changes. By restructuring and modularizing the css code into one centralized file, we have a much stronger base to modify and add new styles for html elements.

Polishing the Theme
This is a visualization change. Using Photoshop, I changed the header and background images to spice up the site. I updated the css code (which was easy after the normalization) to reflect the new theme, particularly the two columns. The left column with the yellowish background is slightly bigger, and the right column with the blue gradient is smaller. I added more style to the sub-navigation lists in the right column. Checkout the snapshots page showing the previous theme and the new theme.

Using Cookies to Test the New Theme
I added this feature as a workaround while testing and developing the new theme. Using a bit of php logic, I enabled the use of web-browser cookies to locally change the stylesheet. By setting a cookie named “newcss” with a value of “1″, the new stylesheet would only be applied to my current web browser on my computer. Everywhere else in the world would still recieve the current stylesheet. This allowed me to test any visual changes to the site without breaking it (in case there are bugs).

This feature was needed because we have been treating our development site as a working site, relying on it for presentations and demos. This extra usage makes it less of a development site, especially when users expect it to always be stable. Thus, a workaround was needed to be able to develop the site without the worry of breaking it for everyone else’s use. One option would have been to move it into another local development area. However, I felt that not only would that require too much overhead (with code versioning and merging), but that it would also be a redundant effort since this site was already in a development area. The second option of using cookies to apply local settings was easier to implement (at the cost of a few lines of php), and it prevents source code and content from getting out of sync.

Converting Absolute Paths to Relative Paths
Almost every single php page used absolute paths when including other php files. This is an extremely bad practice and would break the site when porting the code over to a new physical location on the server. I went thru every page I could find, and changed all absoulte paths to relative paths. This is a good example of an architectural change that is “behind-the-scenes”.

Cleaning the HTML Markup
Some of the html pages have sloppy or invalid code. A common example is the lack of a closing tag. For instance, <p> is never followed by </p>. When testing the new theme and css, I cleaned up sloppy html wherever I found it.

Here’s a list of some of the To-Dos:

Develop a Best Practices
We need a best practices document for site development and content placement. Having a best-practices helps achieve consistency throughout the site, and it also provides a starting point when developing new site apps or modules.
A rough best-practices:
- Use the right column for sub-navigation links.
- Use the left column for header title and main content.
- Use the bottom column for application output.

Revisit Relative Paths
We may want to create an infrastructure for relative paths, so that it is easier to move files around freely without the need to edit them to reflect their new path. There are a few ways to do this. One option is to set a local php config variable that points to a specified include path. Another option is to create a root.inc.php file inside each directory that stores that directory’s relative path to the site root in a global variable, and have all other php files in any given directory include that directory’s root.inc.php file.

Searching Capability
One future idea for the site is to add a search bar, probably at the top of the right column, for all pages.