Linux.com

The software that supported the site was old and inflexible. A mod_perl 1 plugin handled basic page templating and navigation, but it didn't easily allow interaction with other programs; thus, we could add no new features, such as discussion boards, weblogs, and photo galleries. To work with Apache 2 (and mod_perl 2), the plugin would require a complete rewrite.

In 2002, our team conducted a needs analysis to determine what we needed to take the site to the next level, including:

• Team needs: New software needed to be easy enough to use that anyone could submit content to the site. This meant removing the need for FTP and HTML training and going to a browser-based solution; however, the system still had to allow for more advanced page layouts and code, as needed.
• Site needs: The team spent a lot of time pulling old material, so a content management system (CMS) that scheduled when content was available would help streamline our process. We needed to have group- and user-based privileges to restrict who could edit and view content. Future ministry needs (such as discussion boards, weblogs, and calendars) then would require an integrated application framework.
• Technical constraints: Deciding to play to our strengths, the team wanted to go with an open source solution written in Perl. Our sole technical person had lots of open source experience with Linux and Perl, Portland has very active Linux and Perl user groups, and the price was right (i.e., a free solution was all that was budgeted). But we learned that not all open source or free software is created equal.

The first Perl-based CMS we found was Metadot Portal Server. We were in the process of learning how to use it when, in October 2002, Metadot pulled the free version of its software and closed its community support Web site. The community debated the project's future on forums at SourceForge and eventually forked the last GPL version into OpenMetadot; however, that project died a few months later. Metadot was eventually released as free software again and has been featured in recent NewsForge articles.

After this debacle, our team determined another absolute: Whichever software project we chose needed to have a strong community of developers and users -- people who could not only produce plugins or add-ons but would work on the core software itself and provide support for one another.

WebGUI

In the summer of 2003 we came across WebGUI, which is owned by Plain Black, LLC, and released under the GPL. Its Web site touted a commitment to open source, an active group of developers (volunteers, paid staff, and contractors), and community support from discussion boards. After a three-day email conversation with JT Smith, lead developer and owner of Plain Black, we were convinced that the project was actually as good as it looked, so we downloaded a copy.

WebGUI in action - click to enlarge

Creating a page is easy in WebGUI. From a drop-down menu, you select Add Page, fill out a form, and the page is created. Since pages are simply "containers," adding more content entails using the same drop-down menu to add Wobjects (article, discussion board, FAQ, etc.). Wobjects can be reordered on a page one position at a time via editing buttons. Editing a Wobject is done via another form, with a simple WYSIWIG editor available for entering HTML content.

We began our transition to WebGUI by creating a sandbox Web site both for learning WebGUI and to give us a place to translate our current material. We spent a lot of time going through the built-in help section, and decided to subscribe to Ruling WebGUI, an online WebGUI handbook, which has an installation guide, tutorial for adding pages and content, and covers basic management topics. In February of 2004 we held a two-hour team training session, where we created accounts for everyone and learned how to add pages and place content.

In July 2004, we duplicated our original site in WebGUI. We chose our battles, time-wise: with limited resources, we had to balance between neglecting the production site while creating the WebGUI site versus allowing the copying to take its time, thus maintaining two sites longer.

Our migration did not come off without a few hiccups. For instance, we used WebGUI's time-based viewing feature on our site's Weekly Update page, which holds church news and announcements and had occupied one volunteer's time for a week. It ended up having a lot of Article Wobjects on it, and what we gained in maintenance time we lost in reordering content, one place at a time.

Additionally, we found there wasn't a way to lock a page or Wobject while editing, so multiple workers could edit the same piece simultaneously. It took us a while to determine how to set up groups to limit access to different areas of the Web site. We eventually found the answer on the community discussion board.

Since everything in WebGUI is simply a database entry, page hierarchy and URLs can be completely disconnected. When we were first learning, we'd find pages in the strangest places. Yet having page hierarchy and URLs disconnected means we can build a Web site with short URLs while nesting pages.

For every unexpected glitch, we also found unforeseen benefits. While we knew upfront it would be easier on our team to add and manage content, we didn't realize how easy it would be to teach other church staff how to post material as well. For example, we taught two good Bible study leaders (but poor computer users) how to post lecture notes to the Web site into a File Manager Wobject.

Our old templating system would have required a complete rewrite to work with Apache/mod_perl 2, but WebGUI worked with it almost out of the box, requiring just a small change to one configuration file.

The final product

WebGUI is in the middle of a huge rewrite. Developers are adding a built-in commerce system, adding workflow and version control, and improving security and usability; see the roadmap for v7 and its current status.

The interim versions (6.x) have been released as either alpha, beta, or gamma. Several of the gamma releases are near production quality. We took the opportunity to upgrade to v6.2.11 to pick up a click-and-drag content interface to help with large pages, and we've been pleased with the performance to date.

Today, less than a year since it was officially launched, our WebGUI-based site has almost 350 pages. Most of our volunteers' time is spent updating existing content and creating new pages. As mentioned earlier, some content has been handed off to staff and ministry leaders, and our newest feature is weblogs for our missionaries. It's been months since we've had to crawl through the site looking for broken links, missing font tags, or misconfigured navigation files.

Share    Print    Comments