This week I finished porting the Palmer site into the new theme/framework. From Mason’s advice, I ported most of the files over from the Production area since Mason had previously used a link checker to originally move only the necessary files into the Production area, trimming it down significantly from the Dev area.

I ported practically every page manually. This allowed me to address some usability issues on certain pages, clean up some html markup, and most importantly, detect broken links and missing files. We have a few missing files in the Production area because the link checker we used failed to follow symbolic links. In addition, some documents may not have been detected, partically if they were referenced by a different protocol (file:/// vs. http://). These issues have been fixed for the New site.

The New Palmer site has reached a somewhat stable point. We have succeeded in restructuring the file system so to be parallel with the navigation setup of the site. It is now time (particularly for Karen) to fine-tune the structuring. Some folders and files may be moved around as Karen continues to add more content. However, the framework of the new file structure should help guide us to place and locate documents in a semantically meaningful way.

I would eventually like to run a link checker on the New site as part of the fine-tuning process. Mason used a fairly good one, nice interface and all that… except it’s Windows only. Plus it’s limited to 500 links w/o a registered license. We can use that link checker as a Plan B. I may try to find a Mac link checker next week. Best bet is probably to check versiontracker.com.

We will ultimately throw this site into Subversion. However, we need to address some issues before hand, particularly concerning images and documents. The Palmer site is loaded with distributed docs, pdfs, txts, and other documents. Is it worth loading these into svn and having them eat up space? I still beleive they should not g0 in the repository. This leaves a couple options:

1. Create a central location to store images and documents, like pal.lternet.edu/images and pal.lternet.edu/docs
   This method requires an extra global variable in php to store the permanent URI of these locations. In this case, that would be pal.lternet.edu
   This method also implies that we could somewhat mirror the file structure inside these folders. For instance, a pdf referenced in the sci-research page could be located under /docs/sci-research
2. Store images and documents in the both Development and Production areas. I am against this idea, mainly because it requires double-maintenance of any changes made to these files. It also makes the site less extensible. Should someone else want to checkout a 3rd copy from the repository, they would also need to copy over these folders from one of the two areas.

A lot of these documents are embedded deep into the multiple tiers of the file system. To sweep thru the system and move them all to a central docs folder would be quite tedious. Not only does it involve the physicall moving of the object, it also requires to make changes in the html to all hyperlinks that refer to that document. However, a workaround for that may be to create symbolic links to the documents’ new resting place so we could leave the hrefs at peace. If we choose to leave the files where they sit now, this corresponds to Option #2. It makes it easier on us by removing the burden of extra work, but it results in duplicated files spread thinly throughout the site.

***

I’ve also worked on some datacat stuff this week. Yesterday, I recoded the html for the datasets details page, so it fits well with the new template, and today I recoded the html for the attributes form. In addition, I’ve also been working on the IOD Personnel page.