Ghost CMS Adventure

As of September 2024, WordPress is the clear winner by market share, at 62.2%. Despite its popularity and thousands of plug-ins, it has many flaws. In my case, the biggest one is the Page/Post editor. I used it for many months, but every time I had to deal with content updates, I suffered mentally. It affected productivity, so I decided to replace it with a more user-friendly CMS for blogging. I tried dozens of self-hosted and managed solutions - Drupal, Joomla, Wix, Squarespace, Payless CMS, HubSpot, dotCMS, etc.

The requirements were:

1) Cost - ideally free

2) Simple and modern UX

3) Self-hosted instances to have complete control over the content

4) Integration with Content Marketing Tools

After a week-long search, the choice was made—the self-hosted Ghost CMS (https://ghost.org/). Despite its 0.1% market share, it was a winner. Why? The answer is beyond the scope of this topic. I offer you the opportunity to research independently and see if it fits your needs.

Attempt 1

Before I picked Ghost, I utilized a custom-built static landing page.

The WordPress paid template I used could not offer strong performance or best practices, affecting SEO ranking.

The plan was to handle all requests by AWS CloudFront, keep the existing landing page on the AWS S3 static website, and delegate other requests to the Ghost CMS. It was easy to do since CloudFront supports multiple origins.

First, I installed Bitmani for Ghost using AWS Lightsail to speed up the CMS configuration. I had a great time with Bitmani earlier with various installations and hoped to have the same experience again.

Not this time...

Problem 1: The site must have a different domain when the DNS record points to CloudFront because it does not support an IP address as the origin.

For instance, if example.com is a CloudFront alias, then the CMS site should be <subdomain>.example.com or have a completely new domain name.

I configured the Ghost App Domain to cf.<site>.com/blog. It worked when the site was accessed via CloudFront, but all links were pointing to cf.<site>.com/blog instead of the desired <site>.com/blog.

When I changed the Ghost App Domain to <site>.com/blog, the site had a mixed content issue. Some links were generated as HTTP, while most were HTTPS.

I had to enable HTTPS.

Problem 2: Bitmani default configuration uses an Apache web server, while Ghost CLI works with Nginx. As a result, you have to use Bitnami tools or configure manually.

I ran the tool, but Ghost declined to work with SSL. I experimented with Apache and Ghost configurations for the next few hours without success.

After a short break, it became clear that this solution must manage two TLS certificates: one by AWS Certificate Manager for CloudFront and the second by Let's Encrypt for Ghost CMS. It seemed like overengineering.

Problem 3: Ghost has a weird behavior on menu configuration. If the App Domain has a path, you cannot reference it in a menu.

For example, if the App Domain is <site>.com/blog, you can't add a menu item that goes to it. Ghost constantly reset it to be just <site>.com

I had to return to the original problem and think it over because this problem was a blocker.

Attempt 2

The next day, I realized I had never tested Ghost's performance. I ran the test after reverting configuration changes and creating a content-heavy page. The results exceeded my expectations, meaning the static page is no longer needed, and I could use the full benefits of a dynamic site.

Considering all findings—Apache and SSL config, multiple certificates, performance, and menu bug (which was possible to fix with Apache redirect)—it made sense to drop S3 and CloudFront from the solution and stick to a pure Ghost CMS installation. This also meant avoiding the middleman and dropping the Bitnami dependency.

Attempt 3

I started with a fresh installation of Amazon Linux 2 using the official https://ghost.org/docs/install/ubuntu/ manual, and soon, I ran into the next problem.

Problem 4: Ghost CLI does not see the Nginx process on Amazon Linux 2.

Attempt 4

This time, I picked the recommended version of Ubuntu and followed the same manual. No issues were found.

So far, so good, but the next problem showed up during the home page configuration.

Problem 5:  Ghost does not support home/landing page updates from the admin console.

You have to download a theme and modify the code directly to update the landing page:

1) create a home.hbs file
2) add required HTML/CSS
3) archive the theme and upload it back via Admin Console

Well, it is too much work to get the new page's look and feel consistent with the rest of the site. Most importantly, coding loses the benefits of CMS itself.

I tried to play with Ghost's native redirects and routes functionality, but they did not work for the home page. I ended up with a simple JavaScript redirect to a CMS-managed page, allowing me to leverage the advantage of CMS with almost zero coding.

window.location.replace("https://example.com/home");

Problem 6:  Existing index.hbs page does not work when handling non home page requests.

Ghost was not automatically pulling data, so I had to update the page and add a Ghost directive to get the data.

Problem 7: The Admin Console offers a MailGun setup, but it is insufficient to send registration emails.

Ghost uses MailGun to send bulk emails. Additional email configuration from the Linux console is required.

"mail": {
  "Transport": "SMTP",
  "options": {
    "service": "Mailgun",
    "host": "smtp.mailgun.org",
    "port": 465,
    "secure": true,
    "auth": {
      "user": "postmaster@<your_mailgun_domain>,
      "pass": "<password>"
    }
  }
}

After all configuration issues were solved, the experience was only enjoyable. Ghost has good potential, but so far, it is somewhat unfriendly with customizations and very opinionated about being a newsletter/blog solution instead of a website builder.