Development

Questions About Cascade CMS

The Law School website is powered by MODX for over a decade, but we’re exploring the possibility of migrating over to Cascade CMS. I am tasked with looking into Cascade. I reached out to a formal colleague who used Cascade CMS in the past to get some technical assessments. Although he hadn’t used Cascade in two years and things might have changes, he gave me some invaluable insights. Here are his answers to my questions.

What was the experience working in Cascade?

Generally, not good.

What parts of Cascade worked well?

The fact that it’s a static CMS means when there were issues with the server it was on (assuming a separate server than the websites) or with the Cascade, sites were still up.

What parts didn’t work so well?

  1. Velocity scripting which I think overall is hard to work with, it was even worse since Cascade would only expose a subset of its full functionality.
  2. Because it’s static, when there were global changes requiring all pages to be published, Cascade could crash mid-publish or block other jobs in the publish queue. Not that you can’t set up global regions like headers, footers, nav etc., that can be published easily using server-side scripting (on you to do), but if you update templates you need to publish all pages with that template.
  3. Pages viewed inside Cascade are not forms (as you would find in WordPress/Drupal) but actual pages that needed styling. This was the only preview available and it was difficult match what was inside Cascade with the actual published pages.
  4. Unless content was generated internally it wasn’t available inside Cascade. You may have systems that cannot be incorporated into Cascade because it uses a scripting language instead of a fully-featured language like PHP that WordPress and Drupal use.

What did you wish they had?

  1. I wish they offered what I built. A headless version that allowed dynamic templating.
  2. Pre-built, plug-and-play modules for common needs of and EDU.

What made you switch to Drupal?

  1. Dissatisfaction with how non-standard Cascade is.
  2. We had to do a lot of custom scripting in Cascade and support was difficult to get because of that.
  3. We asked for new features but getting them implemented was at Cascade’s whim and on their timeline.
  4. The Drupal community/ecosystem is much larger.
  5. PHP is a standard, object-oriented programming language that many more people know (vs Velocity which is just scripting and no one knows)
  6. Drupal is open source
  7. You’re more likely to be able to hire people who are skilled in Drupal vs. Cascade (same for consultancies)

Anything else you would like to add?

I made Gamut for many reasons but Cascade’s shortcomings were a major factor. I’m not sure if Cascade has gotten better in the two years since I last used it but I would be cautious about needing too much customization and using a non-standard tool.

Follow-Up Question

The primary reason we’re looking into migrating to Cascade is the ability to edit the actual pages inside Cascade. What are your thoughts on that?

If that’s the only reason, I would reconsider. You’ll lose a lot to gain a little. Is triggering a preview button too much effort? Or, I know, inside the CMS looks pretty then? We never had a one-to-one correspondence to what was actually on a given page. There were sections/pages that couldn’t be represented in the CMS because the content came from external systems. We also intentionally hid content from almost every page (footer/sidebar/etc) because it was uneditable except by our office. And I know we had issues maintaining parity with CSS between the internal Cascade view and what published pages actually looked like.

Cascade’s Performance

In addition to what have said above, I found a few concerns on performance Cascade’s users have shared:

The one thing that can be challenging is the speed of Cascade. The more complicated you design your page, the longer it takes for cascade to load the page for display, and edit.

I dislike how much clicking is required to publish a change. The submit option is great when making big updates, but when making small changes to many pages on a site, it takes forever.

The downside to Cascade is the amount of resources needed for a fast implementation. It is resource-hungry, and if your websites get too large, you will definitely notice some speed and efficiency hits to your self-hosted solution.