For many web developers, the idea of transitioning to a content management system (CMS) is both appealing and frightening. It’s appealing because of how easy it would be to manage once everything is converted. It’s frightening because when you have a large, mostly static site, transitioning to a database-driven CMS requires a lot of work, specifically doing data migration.
Here’s a quick tip on making the transition easier: build a web form that parses static files and allows users to manage content online.
Let me explain. Let’s say you have a static files that call a simple header and footer, so that the source of your typical page looks like this:
Here’s the title</h1>
<p>Here’s the content. Blah, blah, blah.</p>
<?php include(“_templates/footer.php”); ?>
From this code, it’s very obvious what the user would have access to manage. If your pages follow some sort of pattern (the above one is just an example), you can easily parse the content out of that page. Once you have the content, you can drop that content into a form that allows a user to edit it.
But why do this? For (at least) two reasons:
- Once you have users accustomed to the idea of managing content using an online form, it’s much easier to get them using a standard CMS, such as WordPress, Drupal or Joomla.
- It’s a relatively simply process to tie a parsing script into an existing CMS. The idea would be to make the parser check to see if the requested page content is already in the database. If it is, then it edits the database content. If it’s not, then it parses the page and updates the database. This effectively transfers the work of migrating data to the current content managers.
We’re currently implementing something like this at the business school. If anyone is interested, I’ll post some code and examples.
The UA Business School is currently in the process of migrating all our email and calendaring from Microsoft Exchange to Google Apps. This has been done by other schools and organizations, but as far as I know, no other subset of the UA has done this yet (please correct me on this if I’m wrong).
What this means is that our faculty, staff and students will view their mail in the Gmail interface and their calendar(s) in the Google Calendar interface. For the most part, this change has been very positive. However, it’s not without its setbacks.
One such setback involves the student services department, which handles all the student advising and as a result has a lot of calendaring issues. Calendars can be shared with the Google Apps just like in Outlook, so permissions were not an issue. However, a third party resources schedular that integrated with Exchange had in the past given the student services department a particularly useful multiple calendar view. This view showed everyone’s calendar for a given day with each person represented by a column, similar to this:
In the Google Calendar interface, a similar view just doesn’t exist (yet). This was a problem given how accustomed those who actually scheduled appointments had become to this multiple calendar view, to the point where it was a necessity.
Enter the Google Calendar API.
As with all of Google’s API’s, the Google Calendar API allows one to extend the current functionality of Google’s services to encompass any special needs. Our necessary functionality was pretty cut and dry: to view multiple calendars at the same time in a specific manner.
I won’t go into the nitty gritty of how the code works here, but suffice it to say it’s much simpler that you’d think.
Sample of finished product
This may go without saying to most of you, but an end user probably has no idea what “Error 404″ means. An easy way to help a user along when he hits a bad link is to customize your error pages, the most common of which is the “Page Not Found”, error 404 page.
All web servers are capable of doing this, but it’s different for each one. We’re using Apache in our office, and the setup for the custom error handler couldn’t be simpler. It’s just a single line in your virtual host container:
ErrorDocument 404 /errors/404.php
For our Error 404 page, we chose to give the user three options:
- Perform a search.
- Choose from a list of quick links.
- Start over at the home page.
Here’s the result:
Hey everybody, as we’re all admiring the great tool Andy and his team have provided, let’s start this thing off with a community question:
What topics would you most like to see discussed here?
Leave your answers in the comments of this post.