 |
 |
My current institution, the University of North Dakota, adopted OmniUpdate as a campus-wide CMS four years ago. On balance, I have not been happy with it. It has not been something to work with, but something to work around. In particular, it has made it impossible for me to have a proper testing/development set up. Although OmniUpdate does have a built-in split between a staging and a production server, it suffers from a crucial flaw in that PHP is not executed on the staging server. If you are working with PHP, as I primarily do, then the only way to find out whether your PHP is functioning correctly is to publish it to the production server. This is bad practice. Testing things without potentially breaking the live site requires making duplicate copies of the files to be edited, and yields a workflow like this: 1) Make the change to the testing file on the staging server. 2) Publish the testing file to the production server. 3) Refresh the page to find out if it worked as expected. 4) Correct any errors and repeat steps 1-3 until satisfied. 5) Copy the code from the testing file on the staging server to the real file on the staging server. 6) Publish the real file from staging to production. 7) Go double check to make sure it's working. As workflows go, I find it annoyingly cumbersome. At one point it was taking me something like 9 clicks to publish a file, every time I wanted to test something. That has improved with the most recent version, but the fundamental problem of PHP not executing on the staging server is still there. OmniUpdate's assumption that "content = files" also annoys me. In most CMSs, if you are a content producer, you go to the page you're working on, edit it, save it, and publish it when done. You never have to think about how the information is stored, because all of that is handled by the CMS, which tucks it away in a database. In OmniUpdate, a large portion of the interface is devoted to creating, editing, and managing files and folders. You can't avoid dealing with them. Compared to the editing experience in most other CMSs, it seems a strained and pointless attempt to extend the conventions of desktop word processors onto the web. I do not have top level access to OmniUpdate, and I can't tell you much about how it works from a system management perspective. For example, I've never had to edit the XSL transforms that are used to combine the content (stored in XML files) with templates to produce a finished page. If you would like, I can refer you to colleagues from the university web team who work more closely with OmniUpdate at those levels. If you would like to do so, please email me off-list. Will Martin > Colleagues, > I am on a campus-wide team charged with evaluating and selecting a new > CMS system to replace our centralized Apache/PHP/Includes-based web > server infrastructure. > > Our Libraries and University Archives have relied on the existing > centralized system and would like to contribute to the selection of a > new CMS-based platform that will position our library well into the future. > > Currently the list is down to four vendors: > > Hippo > OmniUpdate > Terminal 4 > Jahia > > If any of you have experience with any of these systems you wouldn't > mind sharing please contact me off list. > > Your feedback would be appreciated. > > Best regards, > > Ed > > Edward Sanchez > Head, Library Information Technology > Marquette University > 1355 West Wisconsin Avenue > Milwaukee, WI 53201 > [log in to unmask] > W: 414-288-6043 > M: 414-839-9569