Okay, so this question pops up all the time. I’ve responded before on the High Ed Cascade mailing list, but figured I’d put it in a more permanent place I could always reference. What set this off as a question on the uwebd network here
For those of you wondering what product I am talking about because you have probably never heard of it (seems to be mostly a higher ed thing, and it’s not really good), you can go here.
Now onto my response to the question.
So what are my thoughts on going with Cascade Server by Hannon Hill?
For me I wouldn’t choose them again. I’m coming from the developer side (backend, not frontend) but I believe that both the designers and users would agree with what I am saying. As well I would like to point out that we started on version 4, our current live server is 5.5.1 and have a test server with the newest 6 on it that is currently being tested. So some of my issues may have been addressed with that but as you will see that doesn’t mean more will crop up later.
It all seemed really cool when they pitched it to us. The idea of reducing a failure point (Database server going down) with our website seemed great. You had increased performance as well because there would be no database calls in generating the page. In the sales pitch we had a bunch of questions like does it support this and that (iCal was the big question at the time) and they said it did. They also said they supported our current environment of Solaris and Oracle. It came off way better then the other products, but really the other 2 that I was shown were complete garbage so it didn’t take much to wow us. I would have preferred a more open system (I’m a PHP/Mysql guy mainly) so I could fix issues but at the time there wasn’t a valid (to the main people making this decision) option that had that.
The major general complaints
1. Everything stored in DB. Images, video files, EVERYTHING. So as you can imagine things get quite large and when you add revisions to the mix with those huge files, it multiplies quickly. This makes backups a pain because you have to dump the whole DB (ours is 9 GB right now.) It hurts things like rsync when it comes to having efficient backups so it then hurts/costs you more on that end as well.
Someone said that this was our fault for uploading Videos and 5 Meg TIFFs to the CMS. To clarify, we don’t do that. We could tell real quick that it would become an issue if we did put everything in the CMS once we saw that it was storing everything in the DB. We manually upload the videos where we need them and we only put images in the system that in there “ready to be used” form. It gets back to my point though of this being a poor CMS. Now I have to manually upload content that’s outside the CMS that it is not aware of or in control of. So now you have to remember all the exceptions for things manually put up for later if you want to delete and do a full republish on a directory. The point of a CMS is to Manage not be worked around.
2. Overall pretty slow. For users the interface is pretty slow (version 6 hasn’t seemed to help on the test server) in response and generating a page is pretty slow. As well counting on the page or folder, publish times can be gigantic. This is especially annoying because, even though they are told to do this before calling, they will see that there file isn’t publishing and think there is a problem. In reality they are just 15th in like between a file thats taking forever to publish and that same thing again because the person cued it up again. ALSO, on occasion I had to go in and add indexes on the tables to help some performance that was really sluggish and greatly helped some things.
3. Upgrading is a pain. It takes way longer then it should mostly because of the all in the DB issue. As well you need to keep up on the mailing lists to see what issues are being reported because there could be something that would effect you that you might not expect/know about otherwise.
4. Not very smart. Similar to above, the system isn’t very smart. Like mentioned above, someone will cue up something to publish twice and the system will do it both times even though no file has changed. As well someone can change a file in one place but when you publish it out it doesn’t update everywhere like a DB related one would. Publish sets are suppose to be the solution to this but then you have to constantly maintain things in it and the user might not know that something is linked elsewhere and know to add it.
5. We are still doing PHP for things we expected the CMS to handle. You expect your CMS get a change and update everywhere. What makes this worst is when you would have to republish the entire site to show that change (navigation.) We ended up using PHP to handle a lot of this functionality for us by putting some things int XML files from the system or in other ways to make up for these issues.
6. There use of the word “supported” was wrong. Did it “support” iCals, well kind of you could write your own xslt to bring in or create one but was their out of the box real support for it, no. They supported it by not stopping you from doing these things but overall they didn’t allow you to just plug and play it like they made it seem in the sales pitch. As well there is an image resize plugin that you can install but it is completely useless.
7. A pain to get data out. The Web services are clunky and accessing the DB directly is not fun because it’s a bit of a mess.
More Specific problems that we ran into
So we get the system in Dec and had training scheduled for Jan. It took a couple weeks for the whole concept to really click as it’s way different then the database driven type of affairs. I had a pretty good grasp by the time training came in which allowed me to get a lot of my XSLT related questions answered. They showed us what the “ideal” way to develop a site was. Made sense and we used that to start working on ours.
We started off running the system on Solaris and Oracle. The system was running really buggy and little things would cause it to completely lock up, so you would have to go in and restart it (couple minute process at that time on version 4.) Errors that were coming out were pointing to the DB so I looked at the Oracle DB they had and realized they weren’t really using any of the Oracle specific features, it was like they just took a dump from Mysql and forced it into Oracle. So we quickly moved it over to MySQL and almost all of the problems went away. But unfortunately one MAJOR one was still left, there was always a possibility when someone would delete something that the entire server would lock up and need to be restarted. After a month of getting nowhere with it I was told that HH couldn’t reproduce the issue on their OS-X version test setup they had with my data. I was floored when they told me they weren’t testing it on Solaris. It then hit me, even though they said they supported Solaris they actually didn’t and never tested with it. We then moved to Linux and the issue went away.
Part of our initial package was to have 1 site done by Hannon Hill in our system. Because of our own internal issues this didn’t happen until almost a year later. I went in to see what they had done for the site, so I could see if there was anything we could use elsewhere. What I found was they did the site completely differently then what we were taught in our training, and really not for the better. So it seems that even inside of the company their wasn’t a “best practice” for creating sites in the CMS.
Next we moved from version 4 up to 5.2 (we waited because we kept hearing of tons of issues in the previous version.) Now the athletics site that we had created our first test case became almost unusable. The XML indexes of the news that we had generating for the sports were taking 10 minutes to generate per sport, compared to the minute it took for all 16 plus the all including feed on the previous version. The site was eventually taken to an outside company partially because of these issues.
As well I now had to go into the DB and add indexes to help speed up certain queries. Performance just started to get slower and slower over time as the DB grew (9 GB now.) We moved to 5.5.1, and were looking to go to 5.7.x when we got word through the HighEdCascade list that the Tiny MCE editor had been messed with and the ability to put PHP into pages was all out of whack. Being that almost our entire site relied on this ability we had to hold off. There was also no talk of fixing this issue in the 5 series as they were working on version 6. We are now just getting around to trying version 6. Luckily because of the HighEdCascade list I got word that I should dump the Mail table before upgrading because this as well added a ton of time to the total upgrade process.
Overall never been impressed by product in any way.
Something else to look into
Overall if I had my choice, we would go to WordPress MU like some other Universities. WP and WP-MU codebases are coming together so you know the support will be there and with things like WP-Super-Cache you can get performance that’s just as good (maybe even better) as the straight HTML files. It’s an awesome platform to build on and has so many things already built for it that you can use that you can get things done quite quickly. As well you have a lot more options for hiring people or finding consultants and getting other support because it’s a much more widely supported system. With Cascade you need more specific knowledge for that system and the XSLT you can do with it. As well there is also a vast wealth of tutorials and information out here on WP compared to only having the mediocre stuff suppled by Hannon Hill.
Oh and to clarify, the Mu in the name of this blog has nothing to do with WordPress Mu, just a coincidence. That was in case someone thought I was a plant.
If you have any other specific questions please let me know.Comments: 8 Tags: