Headless CMS Newsletter Support

Developer help Routing
1

When I first found Ghost and found out about its ability to be used as a headless CMS with many popular JAMstack frameworks I got excited. But as I’ve tested, built and shipped many client projects using Ghost I have ultimately come to the same ending point, which is not using Ghost in headless and unfortunately running two sites; domain.com (NextJS) & blog.domain.com (Ghost).

The decision point ultimately comes down to two major downfalls to using Ghost as a headless CMS that makes it not worth it.

  1. Newsletter email template links
  2. Unsubscribe functions

I’ve created many sites and for any clients that didn’t want to send out blogs as emails I’ve been able to use the content/admin API to display all posts on a NextJS site.

But for me, the real game-changing feature and the thing that my clients rave about is the ability for blog posts to become a newsletter with 0 extra clicks. Trust me, when I tell you that my client’s eyes light up when I tell them they can cancel their $50+ a month email marketing tool. This killer feature in a headless setup feels all but gatekept to the Ghost native stack.

In a headless setup, the email newsletter function becomes useless and you are left to re-engineer the entire newsletter function from scratch which feels so wasteful when the Ghost team has spent a lot of time and resources figuring out how to make the email newsletter work smoothly.

Of course, you can use no code automation to send an email upon new blog posts or the Admin API with some sort of SMTP client to send an email. But again, why all this work for something that is inches away from just working right out of Ghost…

The Issue:
Email newsletters have hardcoded $siteUrl values that live within their template files. Secondly, the template file lives within the Node Modules of the Ghost repo which means if you do change any of these, they will get overwritten upon each upgrade. This means email newsletters in a headless CMS setup become completely useless.

I have tried:

  • Editing the template (issue noted above)
  • Using redirects:
    sending blog.domain.com/* to domain.com/blog/*, this works for very simple cases but quickly becomes a mess of routing and is not ideal. As well I would guess is not the intended use case of the redirects function
  • Using a separate Admin URL and then hardcoding the Ghost main URL to the same URL as my NextJS site. This breaks the front end but since I would be setting to private anyways I thought it didn’t matter, but then little things like the site preview, post previews and even image previews in drafts no longer work. I could live with this myself, but looks super unprofessional to client. Furthermore, is not great for vetting content before it gets posted and then parsed through the content API to my front end.
    -Further to the issues with email links, the unsubscribe function is also broken, even when you have the basic redirect to 3rd party site working for blog post links.

I could see a mix of the above things I’ve tried maybe working but also proving the point of this being way to many config steps to get to a state of working

From searching through this forum and other blog posts on the topic I am only left with one option it seems, which is to rebuild the a lot of the Ghost stack/functions in my NextJS app…

I can’t be the only person who feels this is just a huge run around for no reason?

With a few small tweaks to features/settings you can, at the very least, allow for some basic headless/newsletter inter-connection to occur without the need to completely code every aspect of the Ghost feature stack over again.

  1. Have a true toggle for headless mode, this would:
  • shut off the front end except for content and admin API endpoints + sign up / unsubscribe functions. Additionally, would keep the pages dedicated for signup and unsubscribe like a landing page, its sole purpose is to perform each of these actions.
  1. A function to set various URLs / redirects values for the purpose of supporting routing to an externally hosted fontend site. Again, I aware there is a redirects function but I would like this feature request as more a a Ghost specific env with some logic behind that is purpose-built to handle route to a frontend JAMstack site.
  2. allow for the editing of email templates, namely to configure the URLs so that they route to a fontend site

Again, I am not doubting that the above isn’t possible through countless hours of coding, refactoring, API calls, etc but feels like with a few tweaks to the core email/routing functions could be enabled for headless. This feels like something Ghost would be motivated to do seeing as the more people who chose Ghost for their project, the more chance they use the Ghost Pro hosting for their headless sites.

I would be very curious if someone has made this all work in the JAMstack world or if there are still options I am missing for self-hosting to achieve the above challenges.

2 Likes
2

There is a FAQ about all the known issues with Ghost(Pro) when it’s used to power a headless site and a number of them apply to self-hosted Ghost as well:

I doubt there is much market for this niche, which is why Ghost has addressed it with a FAQ of a list of about 10 things that don’t work well when using Ghost(Pro) for headless sites.

3

Yes, I’ve read this and many other posts from others citing these “limitations”.

I’m afraid I have to disagree with the statement “I doubt there is much market for this”.

If so then why would there be so many CMS platforms that have a page on their sites on how to create a blog using their CMS:
DatoCMS
HyGraph
Strapi

etc…

All of these though still have no features in the realm of newsletters or members management. Imagine being the first to offer that without needing a CS degree!?!

Believe me when I tell you every client I work with raves about Ghost’s newsletter function.

From my technical understanding, the headless feature “limitations” in Ghost Pro have nothing to do with the Ghost Pro hosting but rather an unwillingness to handle the few technical edge cases that will allow those headless limitations to work.

Again,

  • Allow for editing of the newsletter template, or even just allow for an extra URL setting (headlessUrl) which can be toggled on to replace the hardcoded “view in browser” link.
  • While in “Private” site mode, allow the subscription management pages (newsletter subscriptions) to still be visual, maybe with a more barebones page template to allow the handling of email users wanting to update their newsletter subscriptions.

I am totally fine with the draft preview being just a default casper theme post view while in private mode as well. Just so that things don’t look broken.

Like they noted in their own post, performing DNS or Ghost routes/redirects is messy and not meant for true headless production.

I currently self-host all my client’s ghost sites, mostly due to having the flexibility that isn’t offered in Ghost Pro. But if they were to make Ghost Pro more flexible in this manner I would happily point my clients there (maybe for a referral :thinking:) cause I am paying 80% of the Ghost Pro cost on my end, then marking it up anyway.

4

I love the security and performance benefits of headless blogs.

You are right that Ghost already has pretty good support for use as a headless CMS and a few targeted changes could go a good deal further to improving that.

5

The core team isn’t focused on headless setups at the moment, because there’s much more traction and demand in other areas - but the codebase is open source, so if you’d like to see that area of the product advance you can always contribute, hire someone else to contribute, or gather a group of people with the same desires as you to work together and make it happen:

6

Hey John,

I appreciate your reply, and I agree with you, currently the demand would be for the normal use of Ghost in a non-headless setup.

But to play devil’s advocate, I do find that statement a bit of a chicken or egg scenario as the Ghost team has built a product from front to back that is meant to do exactly that. At the same time, the headless features have always felt like an afterthought. But if you were to push some more headless focused features, especially those which make headless features available without needing mass amounts of rebuilding via, API’s and Code you might find those scales tipping.

It’s the classic “build it and they will come” vs “build for an existing demand”.

For sure, someone could fork the repo, as you mentioned it’s open source, however, the suggestions I had made would be relatively small adjustments that would benefit all frameworks.

Of course, there’s no expectation from my end, but I hoped to bring awareness to the fact that people are looking for these features. Sometimes the demand opportunity is hidden behind individuals like myself with 10’s/100s/1000s of clients who each would want Ghost Pro hosting for their headless Ghost blog + front end we’ve built for them.

7

Not quite :)

The entire marketing cycle of Ghost 3.0 was all about headless / jamstack usecases. We put lots of effort into docs, development starters, fleshing out APIs, and building workflows around integrations.

Then we did the 4.0 release cycle around memberships/newsletters, and the demand exploded (largely from a group of users who have no idea or interest in what headless/static sites are)

No judgement either way, but we’ve put plenty of effort into each. The core team can’t focus on everything, so we focus on the cases that seem to be resonating most strongly.

There’s still plenty of room for the community to get involved and support other use cases they care about most, though, that tends to be how open source projects grow and expand. I wasn’t suggesting forking, to be clear, I was suggesting Pull Requests!

8

Sorry, looking back on my last post (and maybe the ones prior), I definitely didn’t frame my thoughts to acknowledge the amazing work that the ghost team has done thus far on the API, CMS-focused work and others. I wasn’t aware of Ghost when these CMS/API features didn’t exist, but I have come across my fair share of posts, forums and articles dating back to 2018 about feature releases that seemed to me as standard today.

I still will say though, that I find the current stopping point from a CMS feature standpoint to be odd. This is again because of Ghost’s position in the market being one that is so closely tied to its core ability to turn any blog post into a newsletter.

Not to try to compare a for-profit company to an OS project but… lol

Hashnode recently released their headless blog platform which includes many features and documentation items on how to handle forwarding/redirects and has post-to-newsletter built-in. For my clients, I still prefer Ghost’s offering for many other reasons but to me this along with many other CMS companies starting up recently proves there is a huge appetite in this space.

I fully recognize it’s probably a hard line to walk with OS between pushing features core features with a team and letting or allowing the community to fill in the gaps. I would say from my standpoint though this gap is one that falls in the former slot.

P.S
I’ve been enjoying watching your build-in public journey with your new hiring app. I probably don’t have a current need to use something like that but it’s looking great!

1 Like