It seems as if the top has determined to migrate off MODX to a CMS that would provide a live editing capability. MODX has been great to work with for over a decade and has proven to be a solid content manage system. If I were to make the decision, I would not switch it to anything else. The decision, however, is not for me to make; therefore, I will let it go.

On the positive side, I will no longer have to maintain the system, which was part of my responsibilities carried over from when I was still a web developer. I won’t have to worry if the site needs upgrade, goes down, or gets hacked. Until we migrated over to MODX Cloud several years ago, I lost countless nights of sleep worrying about the website. I was stressed out because it was on my mind the whole time. I still bear the responsibility of the website, but I feel less stress because the site is now managed and secured on MODX Cloud.

When we move off MODX, I will focus my attention on being director of design and web services without having to be hands-on like I am doing now. So yes, let’s bring on a new CMS to replace MODX. I am all in.

When MODX 3.0 released in April this year, I couldn’t make the upgrade from 2.8.3 for the Law School site because Extras including getResource and Article weren’t compatible. I had to waited out. When MODX 3.0.2 came out yesterday, I ran another test upgrade this morning and I was able to upgrade from 2.8.4 to 3.0.2 successfully. I come across an issue with the log-in page, but it’s just the display. It looks like the CSS file is missing.The new MODX interface will need a bit of time to get used to, but I am so glad that we stay with this CMS. It rocks!

MODX has a WYSIWYG editor similar to WordPress and Drupal. You don’t need to know HTML to make updates. MODX doesn’t have a page view like Cascade, but you can click on the preview button to see exactly how it looks on the live site. It’s intuitive, but might take a bit of time to get used to. If you’re not comfortable using MODX, let us take care of the website updates so you can focus on more important strategic communications such as promoting our diversity, our centers, and our faculty as well as getting our rankings higher, which have always been a high priority on the Dean’s list.

Drupal was on the table for us about five or six years ago when the University went through a complete redesign. They made it mandatory to migrate to Drupal as well as to use their templates, but they backed away. We didn’t want to move into Drupal because we didn’t want to lose control of our site and to be stuck with their templates. We didn’t want to use Drupal because it is a developer-oriented CMS. In fact, the user interface in Drupal is even more complex than in MODX. In addition, Drupal renders tons of JavaScripts and HTML junks; therefore, the performance is slow. Even WordPress, now comes with its own block editors, is doing a horrible job of spitting out HTML markups. Out of the three content management systems, MODX is the only one that renders semantic, well-structured pages.

MODX does a decent job of accommodating non-technical users. The former Associate Dean for Library & Technology used to make changes on the site without knowing HTML. The library staff members are using MODX to make updates and they don’t know HTML. The current Associate Dean for Library & Technology used to make updates as well, but now she has higher priorities in her new role. I am sure the Associate Dean for Admissions can do it as well once she understands how MODX works, but she has more important priorities. She sends us updates so she can focus on recruiting students.

The Web Content Specialist and I work inside MODX everyday and we prefer using the blank editor to make sure the HTML markups are clean, organized, and readable by humans, browsers, and search engines. For us, the blank editor is much easier and quicker than the WYSIWYG editor. So please let us take care of the small updates so you can focus on marketing strategies such as improving our social media engagements, creating new videos to attract prospective students, and writing new featured stories.

I don’t have any concern about MODX security. As I pointed out in my comparison between MODX and Cascade, we have been using MODX for over 15 years and we have not run into any security issues. Like Cascade, MODX is hosted on the cloud and is protected by WAF (Web Application Firewall). In addition, we use CAS Authentication to protect the manager’s side. With two layers of protection, I have no worry about our site getting hacked. In fact, security is what sets MODX apart from WordPress and Drupal. When I first took on this job, I didn’t like MODX and wanted to switch to either WordPress or Drupal. The more I worked with MODX, however, the more I appreciated its flexibility and reliability. MODX is not as popular as WordPress and MODX, but its security is top-notch.

Our website has about 2,500 pages, which included approximately 1,900 public pages. Most pages are straightforward, but a handful of pages are dynamic, including the directories for faculty, staff, and administrators. The faculty working papers are also managed dynamically with the ability to filter by authors and dates. The course descriptions are dynamically generated.

Here are the breakdown costs between the two platforms:

MODX CMS

• Cloud subscription: $1,595
• Custom domains (up to 25): $55
• Uptime+: $900
• CDN & WAF: $240

Annual cost: $2,790

Cascade CMS

• Cloud subscription: $20,000
• Optional cloud development instance: $6,600
• Annual maintenance fee: $1,750
• Public server: $5,400

Annual cost: $33,750

Initial costs for Cascade CMS

• Quickstart implementation package: $21,000
  • 120 hours of professional services
  • Homepage
  • 2 internal page types
  • Newsroom implementation (individual news page, monthly and yearly index pages, syndication on the homepage)
  • Emergency alert banner implementation
• On-site training: $10,000
• Professional services (40 hours at $200 per hour): $8,000

Initial costs: $42,000

Total cost to get started (not complete migration): $75,750

Cascade CMS claims that many schools had switched from WordPress and Drupal to its platform because of its security features. Fortunately, MODX CMS has a solid record on security. Our site has been powered by MODX CMS since 2006 and we have not run into any security issues.

Clearly, I don’t see any advantage, benefit, or reason to switch from MODX to Cascade unless we have $72,960 and laborious time to waste.

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.

As I am working on the redesign for Scalia Law website, I am doing some research on the top-ranking law schools to see what they are up to these days. I checked out Yale, Stanford, University of Chicago, Columbia as well as our peers including Wake Forest, OSU, and Georgetown. The trend I am seeing is that every site uses a full-screen banner on the homepage.

We were not using full-screen banners because they required large images. We had three or more rotating banners, which tripled up our homepage loading time. If we wanted to take the full-screen route, I suggested that we only load one banner at a time, which is what I am seeing on these sites. They are moving away from the slider. I proposed that we load a different banner each time someone visits our homepage.

To perform a random load, I searched up MODX and I could not find anything simple like a PHP random function. Then I came across the &sortby=`RAND()` parameter from the getResources extra. Here’s the code for that:

[[!getResources? &parents=`12345`  &tpl=`RandomHomepageBanner` &limit=`1` &showHidden=`0`    &includeTVs=`1` &tvPrefix=``  &sortby=`RAND()`]]

I showed the mockup and it was approved. I implemented it on our homepage. Somehow a full-screen banner made our site more “modern.”

Here are my concerns about embedding Twitter:

1. Because we embed Twitter into our homepage, we carry an extra load, which slows down our homepage performance.
2. Twitter design doesn’t blend well with our design. We don’t have any control of how it looks. The typefaces and colors are different. Twitter’s blue doesn’t go with our brand colors. Although we both use sans serif typefaces, our sans has a friendly, humanist quality to it. Twitter’s sans is geometric and corporate.
3. Privacy worries me the most. By embedding Twitter on our site, we give Twitter permission to track our users.

Here’s Twitter’s policy on privacy:

When you view Twitter content such as embedded Tweets, buttons, or timelines integrated into other websites using Twitter for Websites, Twitter may receive information, including the web page you visited, your IP address, browser type, operating system, and cookie information.

Instead of embedding Twitter, why don’t we do it like the podcasts? We list all of the Twitter accounts, including the centers so they can also get exposure on our homepage. Here’s the implementation.

MODX still remains one of the underappreciated content management systems in the game. If I have to choose WordPress, Drupal, Joomla (is it still relevant?) or MODX for a medium- to large-scale website, I would go with MODX without hesitation. The only downside to MODX is the tiny community. MODX still struggles to grow. Comparing to WordPress, MODX’s development is much slower because it doesn’t have contributions and resources like WordPress. Nevertheless, its platform and power take no backseat to WordPress, especially MODX Cloud.

The Law School migrated to MODX Cloud for over a year ago and the experience and the service had been exceptional. One of the best features on MODX Cloud is the ability to spin up a development cloud exactly like the production cloud in a couple of minutes. When MODX released version 3.0.0 back in April, I needed to spin up a development cloud to test first before making the upgrade to the live site. I am glad I did because I could have been screwed if I went ahead and upgrade from version 2.8.3 to 3.0.0 on the production cloud.

To create new cloud in MODX, I logged into the dashboard, hit the “Add New Cloud” button, gave it a name, changed the version to match the version of the production cloud, then hit the “Complete Cloud Creation” button. Once the new cloud was created, I went to the backup archive, chose the latest backup from the production site, then selected “Restore Backup Into” the new cloud. That was it. When the new test server up and running, I upgraded MODX from version 2.8.3 to 3.0.0.

Although the upgrade passed, the site didn’t work 100 percent. Third-party extras, such as getResource and Article, hadn’t yet compatible with the new MODX. This is where MODX falling behind WordPress. One of the best features of WordPress is the upgrade compatibility. In addition to MODX, the Law School also uses WordPress Multisite, which is currently powering 46 sites, and we never ran into any upgrading issue. We even set automatic upgrades for the core and all the plugins.

The Law School main website, which is powered by MODX, is much more complicated than the sites in WordPress, but a major upgrade shouldn’t break the site. I tried to fix the issues myself on the test site, but I haven’t had any success and MODX’s small community isn’t helping much either as I reached out for support. As a result, I have been holding off on making the upgrade to version 3.0.1 until the Extras get upgraded to MODX 3.0.1. So far I haven’t seen any progress on MODX to get the Extras work with the new MODX release. Though MODX continues to support version 2 with the release of 2.8.4 and I had made that upgrade.

In attempt to upgrade one of my Droplets from Ubuntu 20.04 to 22.04, I kept run into the usbmuxd errors. I reached out to DigitalOcean and they suggested migrating to a fresh Ubuntu 22.04 server rather than upgrading in-place (sudo do-release-upgrade). The process seemed quite time-consuming. As a result, I tried a different method.

To begin, I updated to the latest versions of all packages for the current release of my Droplet:

sudo apt update

sudo apt upgrade

sudo apt dist-upgrade

In DigitalOcean’s web interface, I powered off my current Droplet, took a snapshot, then created a new Droplet from the snapshot. Once the new Droplet was created, I ran sudo do-release-upgrade. To my relief, the upgrade succeeded without any error.

I have a handful of sites on this Droplet, but they all PHP files and no database. To check and see if my websites worked, I edited the Hosts file in Terminal:

sudo vi /private/etc/hosts

11.111.111.111 donnytruong.com

To edit the Hosts file, type i for insert, then :wq to write and quit. After using sFTP to make sure that the sites were indeed working correctly, I went into Cloudflare’s DNS interface to update my A records to point to the new Droplet.

I am pretty darn proud of myself for figuring this one out.

I was up late last night upgrading Ubuntu 20.04 to 22.04. I have two Droplets in DigitalOcean. One just for this WordPress blog and one for my other sites. The Droplet for my blog upgraded smoothly. Unfortunately the other one didn’t upgrade successfully. I restored and tried three times. I even tried to diagnose the issue, but I couldn’t get through usbmuxd. Here’s the error:

Errors were encountered while processing:
 usbmuxd
Exception during pm.DoInstall():  E:Sub-process /usr/bin/dpkg returned an error code (1)

*** Send problem report to the developers?

After the problem report has been sent, please fill out the form in the automatically opened web browser.

What would you like to do? Your options are:
  S: Send report (434.0 KB)
  V: View report
  K: Keep report file for sending later or copying to somewhere else
  I: Cancel and ignore future crashes of this program version
  C: Cancel
Please choose (S/V/K/I/C): c

Could not install the upgrades

The upgrade has aborted. Your system could be in an unusable state. A recovery will run now (dpkg --configure -a).

Setting up usbmuxd (1.1.1-2build2) ...
usbmuxd.service is a disabled or a static unit, not starting it.

Upgrade complete

The upgrade has completed but there were errors during the upgrade process. 

Even though the upgraded seemed to fail, my sites loaded fine and everything seemed to work, but I revert back to Ubuntu 20.04 just to be safe. If anyone has any experience with this sort of thing, please help.