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
edward.sanc...@mu.edu
W: 414-288-6043
M: 414-839-9569
