Focus on the Websites

One of the recurring themes from Computers in Libraries 2023 was the focus on the websites. Speakers talked about site design, user experience, and content strategy. They also discussed about quitting social media.

For Libraries, websites remain our homebase. Unlike social media networks, our library websites have no ads, no privacy issues, and definitely no misinformations. As a result, we should not send our users to social media, but the other way around. We have control of our sites, not social media. We provide accurate information on our site and we have no idea what type of information being pushed on social media.

I am glad to hear that librarians put their focus and effort into their websites instead of someone else’s. Library websites are still trustworthy online presence for institutions and organizations.

In my current role, I am no longer in charge of the Law School or Law Library social media. My focus is primarily on our websites. We are about to embark on a whole new direction for our main site. I don’t know how that will play out.

In my personal space, I focus only on my websites, particularly this blog. I haven’t posted anything on social media in a while. I have been tempted to deactivate them all. I also don’t have any desire to try another social media platform.

At least at the moment, my career in web design is still good. Social media networks come and go, but our sites will stay for a while. That’s my take from the conference.

Switching from em to rem

In addition to changing the wordmark, I made the switch from em to rem unit for my typographic control after a Slack discussion with my former colleagues at Vassar. I used em for scalability and inheritance, but em could cause compounding sizing. Using rem seems to avoid the headache; therefore, I might as well making the switch.

After reading Robin Rendle’s note, I added this new CSS element on all my headings:

h1, h2, h3, h4, h5, h6 {
text-wrap: balance;

I am not seeing the effect yet, but I hope it will just work in the future once browsers support it. It’s not a big deal. I still like to tinker around this site as often as I could.

I am in the middle of listening to John Gruber talking with Jason Kottke about web design, Movable Type, and web development. I have tremendous respect for them on how they could turn their blogs into full-time jobs. I am not sure about Jason, but John is doing pretty darn well with the sponsorships on both his site and podcast. I don’t subscribe to their RSS feeds. I just check their homepages every once in a while. I can’t keep up with John’s podcast either. I only check in once in while for something special, like the latest episode about turns 25. That is quite a milestone. Congrats, Jason.

First Impression of Cascade

The Cascade editor gets the job done, but it is limited and not intuitive. Every task requires filling out forms. Use form to add a title. Use form to upload an image. To update text, use the WYSIWYG editor, which can also change styles, fonts, font sizes, colors, and background colors to the body text with inline CSS. Editing a page in Cascade is not intuitive because the pop-up editor covers up the page. I had to close the pop-up editor several times to see which part of the homepage I was editing. That’s pretty much all you can edit in Cascade. You can’t add any dynamic contents. If you need new features or new design layouts, you will have to edit or create new templates. Cascade doesn’t offer the flexibility that MODX offers.

There’s a misconception that you need to know HTML or you have to be technical savvy to make edits in MODX. You can use the WYSIWYG editor in MODX to make changes without knowing any HTML at all. In this regard, MODX is very similar to Cascade, but MODX offers users beyond the WYSIWYG editor. If you know HTML, you can switch to HTML view to keep your page clean and free of messy markups. Furthermore, you have more flexibility to create different layouts without having to add additional templates. In addition, if you know the MODX scripting language, you can create much more complex pages with dynamic contents such as the directories, working papers, and course catalogs.

Cascade has a straightforward templating system. You can create an HTML page and add in Cascade’s snippets for parts that need to be updated. Unlike WordPress’s modern templating system, Cascade takes a traditional approach. Whereas WordPress is moving toward giving users more control of the full-site editing, Cascade is still relying heavily on templates to lock down the editing capabilities. If our goal is to limit users from doing too much editing to our website then Cascade is good for that.

Cascade vs. WordPress vs. MODX



  • Higher-education focused
  • Fast
  • Secured
  • Non-technical friendly
  • Good technical support
  • We already have connections to people we need
  • If we pay, should be able to have new site up quickly


  • Cost
  • Proprietary
  • No access to the backend
  • Not flexible editor
  • Limited plugins
  • Costs will continue to rise
  • Lacking dynamic content



  • Highly flexible
  • Full-site editor
  • University support
  • Easy to hire developers
  • May be able to get a CDN, like Cloudflare
  • High adoption rate means likely to persist for a while
  • Large community increases chances of quick access to new tech
  • Departments, student orgs, and centers are already on it


  • Not as secured (but University has it locked down with Firewall)
  • Might be slowed (database and bloated markups)
  • The markup can be messy
  • Might depend on plugins for dynamic contents
  • Would need to find support on our own
  • May be challenging to sort through all plugins



  • Secured
  • Fast 
  • Flexible 
  • Everything is in place
  • No need to migrate


  • Not friendly for non-technical users (There may be a solution)
  • Small community
  • Heavily dependent on the database
  • No plug and play. 

The Visual Editor

The only reason to switch CMS is coming down to one feature for one non-technical user: the visual editor. The choices are Cascade, MODX, and WordPress.

Cascade is the potential candidate because it allows users to preview the page. Editing contents still requires filling out the forms, but users can see the changes right on the page. For this feature alone, we will have to pay hundreds of thousands of dollars to migrate. Is it worth the investment?

Similar to Cascade, MODX is also a form-based system for content updates. The only difference is that MODX doesn’t have the live preview page. Users have to click on the preview button to launch the page. The user interface is not as intuitive as Cascade, but it is not hard to use. MODX has a product called Fred, which is “a friendly and intuitive visual content building and editing experience for MODX.” Fred might be the solution we are looking for to stay with MODX.

WordPress offers block and full-site editing. This is a game changer for non-technical users who want to edit the entire layout of the site. I am impressed with the ability to just copy and paste any pattern into your site. Do we want to give non-technical users that much power? How do we made sure the consistency of the branding if anything can be edited or created on the spot?

The decision has yet to be made.

Persistent Object Cache

WordPress’s Site Health suggests that I should be using persistent object cache for this blog. Last night I tried to install and secure Redis on Ubuntu 22.04 on my DigitalOcean Droplet, but I couldn’t get Redis to work. I restored my snapshot then tried to install and secure Memcached. That didn’t work either. I restored my snapshot again. I am not sure what I was doing wrong.

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.