After hitting the CPU limit on the shared server at HostPapa, I knew I needed to make the move for the long run. I am so glad that Thủy Nguyễn, a long-time reader of this blog, recommended DigitalOcean. I hesitated at first because DigitalOcean is a cloud-hosting service and I do not have much experience with cloud servers. Fortunately DigitalOcean has tons of tutorials to help me make the move. From setting up the LAMP stack to virtual hosts to SSH keys to Let’s Encrypt, I was able to follow along. I had to destroy several deployments and started over. I hadn’t worked with the command line in a while and it was like rediscovering an old love.

I created two Droplets: one exclusively for this blog and one for my static sites including Vietnamese Typography and Donnytruong.com. I don’t know for sure, but I suspect Vietnamese Typography is the cause for the CPU shortage. The site hosts tons of web-font files. I was thinking of limiting the number of fonts being served on the site, but it would ruin the purpose of the book. I wanted to showcase as many Vietnamese typefaces as possible. Now that the web book is on the cloud, I hope the traffic won’t blow up my budget.

Migrating this blog was a huge challenge. Transferring the database over was time consuming. I tried SQL dump, but it didn’t work too well. I finally just use the export and import tools provided by WordPress. I can’t believe it worked great. I still have a handful of things to take care, but I need to get some sleep. I hope to get back to regular blogging schedule soon.

From 2003 to 2019, all of my websites were share-hosted by Lunarpages for eight bucks a month. I was happy with its service for 16 years. I even recommended my clients to host with them. In 2019, HostPapa acquired Lunarpages and I was concerned.

An acquisition is never good for the customer, but I stayed on. I just don’t have the time and the resources to research and to migrate my sites. Because I am running multiple sites, which was fine with Lunarpages, I am paying $15 a month.

The new business plan was already double what I paid before, but they are constantly trying to up-sale me to the business pro plan for $25 a month. That’s more than what I am willing to pay for my personal sites. I might need to start looking for a new home for my digital properties if HostPapa keeps trying to rope me into their higher plans.

After the disastrous failure of trying to upgrade MODX, which brought down the Scalia Law website for almost an entire day, I needed to make a move. It was an embarrassment and my reputation was on the line.

I looked into the possibility of moving the site to WordPress or Drupal. The development would be expensive and the migrating process would be long, but we needed to get off MODX or move off a dedicated server I managed.

I presented the options and explained the pros and cons to my supervisor, but she had another idea in mind. She was neither impressed with WordPress or Drupal. Moving almost 1,200 pages to another platform seemed scary and daunting. She suggested that we should look into MODX Cloud. My worries turned into excitement when she made that suggestion. I didn’t think it would be an option because I strongly advised that we move to MODX Cloud a few years ago, but it didn’t work out.

I immediately reached out to the MODX Cloud team and they offered to take care of the migration for us at no charge. In the past few weeks, they worked closely with me to make sure the migration went smoothly. They explained everything I needed to know. They moved and tested our site on their Cloud platform. They made suggestions to improve our site. I was amazed with the level of support they had provided us at no cost. We were more than happy to pay for the business package and a few extra options they offered.

For the first time in almost 10 years at Scalia Law, I feel so good about handing over this part of my job. A huge rock has been lifted off my chest. Server administration was never my strong suit. I rather have the experts taking care of the server and I take care of the design and the development parts of the site. The most stressful part of my job has migrated. I now can enjoy and focus on what I do best for the law school.

The Scalia Law website is now in a good home. Who can take better care of MODX than the creators themselves? The team was a pleasure to work with. Special thanks to Jay Gilmore and Veljko Mirkovic for their patience and expertise. I am so glad that we’ve made the move. Although MODX is small and its adoption is not as popular as WordPress or Drupal, it is still a powerful and flexible content management system. The people behind it are just phenomenal.

After watching the final U.S. presidential debate on Thursday, I checked my RSS reader instead of going straight to bed. I saw a notification from MODX releasing 2.8.1. I was a bit surprised because I just upgraded to 2.8.0 only a few weeks ago. MODX usually takes at least 6 months to put out a minor release. It must be some security issue that they needed to patch.

MODX is the content management system that powered the Scalia Law website. Since it was midnight so no one would be logging into the CMS to make any updates; therefore, it was a good time to do the upgrade. It would only take me about 15 minutes to complete. I followed the procedure like I had always done in the past. Something didn’t go right when the files which were supposed to be merged had prompted me to replace. When I allowed the files to be replaced, the website went down. The files that used to take 15 minutes to merge were now estimated about 55 minutes.

I started to panic, stopped the upload, and tried to figure out what went wrong. I went into our daily backups and re-uploaded the directories I had made the upgrade. The process alone took about half an hour. The website was still down. At this point, I re-upload the entire site as well as the database from two days before. This process took a couple of hours. It was already three in the morning and nothing worked. I called GoDaddy, our hosting provider, to see if there’s anything they could do. The first time I called, the technician recommended that I try to re-upload the site from a week old. If that would also fail, I could request a disaster recovery.

I went on Twitter and tweeted for help from the MODX community. I received no response. Its community is way too small. Around six in the morning I started to get messages from colleagues telling me that the site had been down. I explained the situation to my supervisor and her supervisor. They completely understood. Since I could not get any help the last resort was to ask GoDaddy to perform a disaster recovery. The site remained down until around 4:45 pm on Friday. The site went down for 16 hours and I feel horrible. It was all my responsibility alone to bear. I did not sleep that night and kept checking my phone for a miracle to happen.

Although the website is now backed up working, we are set back 3 weeks. GoDaddy only keeps a snapshot every two to three weeks. Now I have to restore what was missing and it is a pain. I am also causing other people to redo some of their work as well.

After this incident, I now determine that we will need to get off MODX. This CMS is dying. It could never get beyond a couple of thousand enthusiasts. I should have called the shot a long time ago, but I held on the hope for it. Now it has become cleared that I need to make an exit strategy. It’s time to migrate to WordPress.

Nowadays I write more in Vietnamese than English. To spare my English readers from receiving my Vietnamese posts in their RSS reader, I decided to make two separate feeds.

I had thought about this for quite a while, but hadn’t come up with a simple, streamline solution until this morning. It just occurred to me that the simplest solution is using tags, which built into WordPress and RSS. I just need to tag my Vietnamese posts with “vi” and English posts with “en.” To subscribe to my RSS feed, you can now choose English only or Vietnamese only. If you can read both languages and want to get everything, you don’t need to do anything. The default feed still works.

I wish I can go back and tag every post with either English or Vietnamese, but sorting through 7,267 (as of this writing) is just not a good use of time. Fortunately, I can filter out my Vietnamese posts by searching for letters with diacritics such as “ô” or “đ,” which narrowed down to 690 posts. Using bulk actions, I can quickly tags my Vietnamese posts. Now that I have most of my Vietnamese posts tagged, I can add a CSS class and design something specifically for Vietnamese and English in the future. That should be fun.

If you want to find the quick tutorial, scroll down to the bottom of the article. Here’s some background of the issue I faced.

Last night before going to bed around 10:30 pm, I made a tiny mistake that kept me up until three something in the morning. I logged into iLoveNgocLan.com’s WordPress Admin to post an article. Instead of doing what I intended to do, I changed the encoding for pages and feeds from iso-8859-1 to utf-8. I also set the template header to <meta charset="utf-8">. Vietnamese text still rendered fine until I made a new post. Every word contained question marks. When I edited an existing article, it also turned into question marks.

I freaked out a bit and went back to change back the encoding for pages and feeds. I freaked out a bit more when the option had disappeared in the Settings Reading Screen. It turned out that WordPress has removed that option in version 3.5.0. I suspect that the option was still there because it was set to iso-8859-1 instead of the default utf-8. I edited wp-config.php to change the encoding back to define('DB_CHARSET', 'latin1');. To my dismay, all the Vietnamese texts displayed black diamonds with question marks. It appeared that going back was not possible; therefore, I googled to find out how to convert latin1 to utf8, something I should have done a long time ago.

In my search, I came across Varun Shrivastava’s “How to Fix Weird Characters Seen on WordPress Blog?”, which seems to be straightforward. I follow his instructions using phpMyAdmin. I exported the existing database into UTF-8 encoding. I created a new database with UTF-8 Collation. Then I imported the data back into the new database. Unfortunately, that didn’t solve the issue. The question marks still showed up on new posts, edited articles, and new comments.

Then I followed WordPress’s documentation on “Converting Database Character Sets” using the new database I just created. I ran the following SQL command in phpMyAdmin to change the default charset of the database:

ALTER DATABASE MyDatabaseName CHARACTER SET utf8;

It worked, so I ran the following SQL command to change the default charset of individual tables:

ALTER TABLE wp_posts CHARACTER SET utf8; 

Then I ran the following SQL command to run individual columns:

alter table wp_posts change post_content post_content LONGTEXT CHARACTER SET utf8;

Unfortunately, I have to run TEXT, LONGTEXT, TINYTEXT, VARCHAR, ENUM for each individual column for each individual table. It would be a lot of work to do manually and when I got to TINYTEXT, it wiped out all the body text from the article. I gave up and went to bed around 3 something in the morning.

I woke up again around 7 am and tried to figured out what I else I could do. I opened up the SQL file I exported a few hours earlier and performed a find-and-replace to convert latin1 into utf8. 19 instances were found and replaced. I created a new database in phpMyAdmin and imported the new search-and-replaced file. To my surprise, it worked as expected. Take a look at iLoveNgocLan.com. I created new posts, edited old posts, added new comments, and the text came up normal, no more question marks and no more black diamonds.

Essentially, to convert latin1 to utf8, this is all you need to do in phpMyAdmin:

1. Export your existing database to your local machine
2. Find latin1 and replace with utf8 on your local machine
3. Create a new database in phpMyAdmin with UTF-8 Collation
4. Import the SQL file from your local machine to the new database in phpMyAdmin
5. Run this SQL command in phpMyAdmin: ALTER DATABASE MyDatabaseName CHARACTER SET utf8;
6. Edit your wp-config.php to point to the new database and edit define('DB_CHARSET', 'utf8');
7. Update the meta tag in your theme’s header: <meta charset="utf-8">

That’s it. I don’t know why this method isn’t available already. I wonder if there’s any drawback of using this method, but it seems to work for me. I am not a MySQL expert. In fact, I don’t have much confidence in messing around with it. I lost several hours of sleep, but the learning experience is worth it.

On my iPhone, I continue to use Safari without JavaScript to browse the web. In addition to hamburger menus not working, I have come across a bigger issue. Some of the sites I visited are completely blank with JavaScript turned off. What even more shocking is that sites with typography are completely empty.

I started off with Frere-Jones Type and it is completely blank. Then I headed over to Kilotype, which designed by the same company that created Frere-Jones Type, and it is also completely blank. H&Co is completely blank. Future Fonts is completely blank. Even Google Fonts is completely blank.

I don’t have the courage to go on. As CSS fonts continue to advance and mature, I wonder why these sites rely solely on JavaScript to deliver their content. I will continue to use Safari on my iPhone to browse sites and read news. I won’t turn on JavaScript unless I absolutely have to.

A couple of weeks ago, I came across a tweet encouraging users to turn off JavaScript on iOS Safari to browse the web on mobile devices. Until I read that tweet, I didn’t know that I could disable JavaScript on my iPhone. I didn’t use Safari much on my phone unless I tapped on a link in email, which would bring up Apple’s default browser. I used mostly Chrome for my own convenience. My bookmarks, histories, and passwords were all synced and managed by Chrome. I tried to deactivate JavaScript on Chrome on my iPhone as well, but I couldn’t find a way to do it.

In the past few weeks, I have been browsing the web using Safari on my phone with JavaScript turned off and it has been such a pleasurable experience. Sites, particularly news, loaded much faster and without annoying ads popping up. On some photo-heavy sites, images didn’t even load without JavaScript. I actually preferred more white space than images. Hero sliders didn’t work. I just saw all the slides stacking on top of each other.

The biggest issue I ran into was the hamburger menus. Without JavaScript, these menus simply didn’t work and I could not go beyond the homepage. Everything hidden under the three horizon lines was inaccessible. We should move away from using JavaScript for hamburger menus or avoid sweeping everything under hamburger menus for the sake of convenience. I have seen sites that used the hamburger menu for just one or two items like “about” and “contact.” For longer navigation, we can use CSS grids, flex boxes, and variable fonts to control the items. A variable font with the width axis can be useful for menu items. Its narrow width can save some space on small mobile devices. It can get wider for larger screens.

For sites with tons of menu items, I don’t know what the solution is. I implemented the anchor-link technique for the Scalia Law School website years ago. Basically, I placed the menu items in the footer for mobile devices and positioned it to the top with CSS for larger screens. It still works fine without JavaScript.

Over the weekend, our Senior Associate Dean asked me to come up with a message board for the Scalia Law School’s class of 2020. Since the graduates won’t get to have a formal graduation ceremony in May, she would like us to create a special page to let faculty, staff, and administrative members post messages to the graduates. My immediate solution was to create a WordPress page with comment section enabled.

On Monday, I spun up a new site from our WordPress multisite and activated the Scalia Law 2019 theme, which is based off WordPress’s Twenty Nineteen official theme. When Twenty Nineteen first released, I created a child theme to have our own brand, which includes typography, colors, and our logo. For everything else, I depended on the parent theme. Twenty Nineteen is beautiful out of the box and it uses the new Gutenberg block editor.

Within a few hours, I created a page addressing our graduates, “Congratulations Class of 2020! An Extraordinary Class in Extraordinary Times.” I used a big cover image and made the text huge. We launched the site on Tuesday and the messages have been rolling in. I love reading them even though I am not a graduate. The messages are wonderful.

WordPress has been a great asset to my professional career. It has helped me provide many solutions to the needs of the school. Now that the entire network of over 30 sites is hosted on WP Engine, courtesy of the University, I don’t have to worry about the backend. I still have full control the themes, plugins, and full SFTP access. Some IT members at the Law School had criticized me for giving up hosting the server part of the sites, but there’s no way I can run the server as reliable as WP Engine. It would be a huge undertaking and I am not a server administration. If the University offers this huge service at no cost, why not taking advantage of it?

WordPress is great at solving problems that do not required original design. I could get pretty far with some changes to make the templated design suits my brand. Of course, I could create the entire WordPress theme from scratch, but that would required tremendous time and technical investments. For my own personal use, WordPress is far too complex. This blog, for instance, probably uses about five percent of WordPress’s powerful features. This blog has been powered by WordPress since 2003 and it hasn’t changed much over the years. I am still using the classic editor. I still code the theme using HTML and CSS and with only a minimum amount of PHP. I have control of every code I input. Developing a new theme, even from a starter theme, isn’t as simple anymore; therefore, I no longer offer WordPress for freelance clients. The amount of customization is just too much. Of course, I can still do it if I get big projects, but not for my typical clients.

I still love WordPress, but my development has changed. I am now happier to use WordPress as a tool to solve technological solutions instead of trying to offer WordPress as design solutions for client projects. It is a change in perspective that I have to come to term with if I continue to use WordPress. There are other choices out there, but WordPress remains a tough contender in the web space.

My choice is either WordPress or hand code HTML and CSS with some PHP to keep the pages manageable. I am missing the entire trend of static site generators. When web designers and developers moved their sites or blogs to Jekyll, Hugo, or Eleventy, I still keep my blog on WordPress. When they spent countless of hours moving from one static site generator to another or back to WordPress, I am still on WordPress.

This blog still runs on WordPress. It’s a theme I have designed and developed years ago in B2, which was the father of WordPress. I coded the theme from scratch using only PHP hooks specifically for my blog. Even to this day, my theme has three files: index.php, style.css, screenshot.png.

These days WordPress has become way too complex to start from scratch. I can still take a starter theme like Gutenberg and go from there, but it already packed too many things I don’t need. I prefer to have control of WordPress instead of the other way around. I want to know exactly how my HTML ended up in the browser. I tried not to sweat it and just lived with whatever an existing theme spits out, but it just feels wrong.

I would love to learn how to make a WordPress theme from scratch using the Gutenberg’s blocks. I have not found any tutorial like that. If you do, please let me know.

Because WordPress has lost me, I can no longer develop clients’ website with it. I turn to Kirky instead. Kirby is not free, but it is worthwhile paying for. Kirby allows me to stand up a site quickly and doesn’t get into the way I design the website. Every piece of HTML is rendered exactly the way I have coded. The best part is that the panel knows which piece can be updated by content editors. As a result, Kirby is an ideal CMS for a small websites.