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