How to Set Up a LAMP Stack for WordPress

Follow “How To Install WordPress on Ubuntu 20.04 with a LAMP Stack.”

Log into MySQL:
sudo mysql -u root

Update the root user’s password (replace new_password with a strong password):
ALTER USER 'root'@'localhost' IDENTIFIED WITH mysql_native_password BY 'new_password';

Create database:
CREATE DATABASE visualguiblog DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci;

Create user with strong password:
CREATE USER 'donnytruong'@'%' IDENTIFIED WITH mysql_native_password BY 'donnytruong_mysql_password';

Grant permissions to user:
GRANT ALL ON visualguiblog.* TO 'donnytruong'@'%';

Creating a Virtual Host for your Website

Follow “How To Install Linux, Apache, MySQL, PHP (LAMP) stack on Ubuntu 20.04.” Continue with step 4 to create a virtual host.

Create the directory for your_domain:
sudo mkdir /var/www/

Assign ownership:
sudo chown -R $USER:$USER /var/www/

Open a new configuration file in Apache’s sites-available directory using nano (command-line editor):
sudo nano /etc/apache2/sites-available/

Paste in the following configuration:
<VirtualHost *:80>
ServerAdmin [email protected]
DocumentRoot /var/www/
ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined

Change owner (chown) recursively (-R):
sudo chown -R www-data:www-data /var/www/

Change user (usermod), append (-a), group (-G):
sudo usermod -a -G www-data donnytruong

Change group ownership (chgrp) recursively (-R):
sudo chgrp -R www-data /var/www/

Change permissions with chmod command recursively (-R) with write permission for group (g+w)
sudo chmod -R g+w /var/www/

Change owner www:date to donnytruong:
sudo chown -R donnytruong /var/www/

Change permission for directory:
sudo find /var/www/ -type d -exec chmod 755 {} \;

Change permission for files:
sudo find /var/www/ -type f -exec chmod 644 {} \;

Edit WordPress config file:
sudo nano /var/www/

How to Set Up Virtual Hosts

If you are setting up your Droplet for the first time, follow “How To Install the Apache Web Server on Ubuntu 20.04” to install Apache. Step 5 is where you set up virtual hosts.

Create the directory for your_domain:
sudo mkdir -p /var/www/

Assign ownership of the directory:
sudo chown -R $USER:$USER /var/www/

Set up permissions:
sudo chmod -R 755 /var/www

Copy an existing virtual host file:
sudo cp /etc/apache2/sites-available/000-default.conf /etc/apache2/sites-available/

Make updates for the new directory and domain name:
sudo nano /etc/apache2/sites-available/

Edit thee following lines in :
DocumentRoot /var/www/

Enable the file with the a2ensite tool:
sudo a2ensite

Disable the default site defined in 000-default.conf:
sudo a2dissite 000-default.conf

Restart Apache
sudo systemctl restart apache2

Let’s Encrypt

To set up SSL certificate using Let’s Encrypt, follow “How To Secure Apache with Let’s Encrypt on Ubuntu 20.04.” Let’s Encrypt will generate the follow file, you can take a look:
sudo nano /etc/apache2/sites-available/

What is Cision?

Is Cision even a CMS? I have no clue. Its website is filled with marketing materials. I can’t even find the technologies behind the platform. Cision is a potential CMS for the Law School to replace MODX. The decision is above my level. I am curious and concerned how a change in CMS will unfold.

Our current website has about 2,000 pages. About half of these pages are dynamically generated. The faculty directory alone is large and complicated. Each faculty page has tons of template variables (fields) including courses taught, expertise, alma maters, and resume. In the publication section, faculty working papers go all the way back to 1999. All of the authors are tied into the faculty directory as well as a huge directory of authors who aren’t teaching at the Law School. Then the courses are dynamically generated as well. They includes fields like descriptions, prerequisites, and offered semesters.

Over 15 years, the system has increased many moving parts to accommodate new changes and requests. When I asked a Cascade rep how they would migrate the site over and his answer was to use an automated tool or hire interns to move the content manually. I don’t know how an automated tool could migrate the pages over if the technologies aren’t the same. Trying to replicate all the variables that we currently have would be a nightmare. Hiring interns is also laughable. If we paid $75,000 for the CMS and we still have to hire interns to do the laborious work? How ridiculous is that?

I don’t think the folks in charge understand how complicate it is to migrate from one system to a completely different system. I just have to wait and see how it will play out. Since I have no say on this matter, I’ll just roll along. I can use any system they want to have in place.

Replacing CMS

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.

Why We Don’t Need a Visual Editor

I haven’t found an ideal visual editor for MODX. The main issue is that we want to maintain the integrity of our codes and a visual editor would destroy it. Our method, as well as the reason we use MODX, is only to write the codes that are required for our website. With a visual editor, WordPress’s Gutenberg for example, the codes were already baked into the editor. As a result, the website with a visual editor is much heavier and the HTML markups would tie into inline CSS and other scripts. To illustrate my point, let me give you an example of how MODX renders a paragraph (<p>) versus a visual editor.


<p>Lawyers who can understand both sides of an issue and argue persuasively and civilly have an advantage in today’s polarized society. At Scalia Law, we believe in exposing you to all viewpoints along the legal and political spectrum and encouraging you to join the debate in a civilized and respectful way. You’ll learn to do this in a small and collegial community at our campus in the heart of Arlington, Virginia, a vibrant yet relaxed town that’s just a short Metro ride away from our nation’s capital.</p>

A visual editor:

<p class=MsoNormal style='margin-top:12.0pt;margin-right:0in;margin-bottom:12.0pt;marginleft:0in;background:white'><span style='font-size:14.5pt;font-family:"Pelago",sans-serif;fareast-font-family:"Times New Roman";bidi-font-family:"Times New Roman";color:#101010'>Lawyers who can understand both sides of an issue and argue persuasively and civilly have an advantage in today’s polarized society. At </span><span style='font-size:14.5pt;
font-family:"Times New Roman",serif;fareast-font-family:"Times New Roman";color:#101010'>Scalia Law</span><span style='font-size:14.5pt;font-family:"Pelago",sans-serif;fareast-font-family:"Times New Roman";bidi-font-family:"Times New Roman";
color:#101010'>, we believe in exposing you to all viewpoints along the legal and political spectrum and encouraging you to </span><span style='font-size:14.5pt;font-family:Helvetica;fareast-font-family:"Times New Roman";bidi-font-family:"Times New Roman";color:#101010'>join the debate</span><span style='font-size:14.5pt;font-family:"Pelago",sans-serif;fareast-font-family:"Times New Roman";bidi-font-family:"Times New Roman";color:#101010'> in a civilized and respectful way. You’ll learn to do this in a small and collegial community at our campus in the heart of </span><span style='font-size:14.5pt;
font-family:"Pelago",sans-serif;fareast-font-family:"Times New Roman"; bidi-font-family:"Times New Roman";color:black;themecolor:text1'>Arlington, Virginia</span><span style='font-size:14.5pt;font-family:"Pelago",sans-serif;fareast-font-family:"Times New Roman";bidi-font-family:"Times New Roman";color:#101010'>, a vibrant yet relaxed town that’s just a short Metro ride away from our nation’s capital.<o:p></o:p></span></p>

As you can see the difference between the two paragraphs. The first one, you can still read the text without interruption. The second one, lots of unnecessary styles were added by the visual editor. They are not only weighing down the page, but also making it tedious to make global changes across our entire site. For our WordPress sites, we have to deactivate Gutenberg because the block editor isn’t working too well. Even our users requested that we deactivated the visual editor. Until we can find a visual editor that spits out clean, well-structured markups, the compromise is not worth pursuing, especially in the long run.

I don’t recommend anyone experimenting on the live site. Even though I know MODX quite well, I don’t mess around with the live site to avoid accidentally breaking the codes. I only play around outside of MODX and make a backup first (just in case things would go wrong) before implementing on the live site. I totally understand it is easier for you to try things out than to explain them to someone else. A framework is helpful, but not always a true representation of the live site. I can offer you a much better solution. Since you are very good with Photoshop, I put together a mock-up of our website for you to experiment. Once you try things out and come up with what you want, send us your mock-up and we will implement it on the live site. This is a much safer approach to experimenting on the live site.

If you take a look at the PSD file, I have layers to help guide you through the layout. Our site layout is based on CSS Grid. The header and the navigation stay constant for consistency, but everything else can be changed by showing or hiding the layers. You can have a full-browser banner or a max-width banner that matches the layout. You can have a layout with or without a sidebar. You can have 1, 2, 3, 4, or 5 columns. You can combine different columns or no columns at all. You can have images flow within texts. You can have lots of options. In fact, you can turn off all the layers in Photoshop and have a blank canvas to work with. When you have time, play around with it. I am more than happy to walk you through the demo as well.

Upgraded to MODX 3.0.2

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!

Let’s Us Do Our Jobs

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.

CMS Comparison: MODX vs. Cascade

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:


  • 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.

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.

Full-Screen Banner

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.”