13 CMS horror stories

Once, I was challenged to solve a project in which the content modeling had gone completely wrong…

It was obvious that the schema and the editor UI had been mixed up. New content was created in the schema, and the schema inputs were used as fields. As a result, there was a collection of content entries in the editor UI as page models.

To fix this, I had to start over and recreate the whole project basically. The good news was that we succeeded despite a lengthy and painful reworking process.

My biggest gotcha in the past months turned out to be quite a trivial rule: "Never assume, always check." There are tons of CMS on the market right now. Many of them use similar approaches and best practices for structuring content, which you may sometimes repeat automatically.

But this could crash your project if you don't double-check whether a "best practice" adopted for one CMS (or even for most of them) is compatible with your particular choice.

At WeFuse, we love a challenge. One of the world's leading automotive brands needed 13 sites in each country of operation. A traditional CMS was too limited for this thirteen-country, multilingual brand project, like cramming a city hatchback, a heavy-duty pickup truck, and a luxurious limousine into a rusty mini-cooper with square wheels.

A headless CMS was exactly what the client needed—it could be customized for every region, offered end-to-end performance and seamless integrations, and allowed the release of new websites within a few weeks when the engine was hot. Now that's a road trip we can all enjoy!

My story involves the evergreen battle between the developers and marketing teams and the SEO attempts to get them aligned.

While working at Toggl, and when we decided to move all products under one brand, I was in charge of making sure all domain migrations ran smoothly and because Toggl had its blog on a subdomain and as any well-behaved SEO, this was my chance to get the combined blogs under a subfolder. The good side of it was that all 3 blogs ran on WordPress which made the content migration easy; the bad side was that the new public website was supposed to run on Gatsby (cool, new SSG at the time).

The dev side, rather unhappy to work with the marketing project to begin with didn’t want to hear about WordPress (mainly for the fact that no one was a PHP developer) and the marketing side who wanted WordPress in its full form together with using all the plugins we were using, meaning no headless WP was an option. This left me with the final solution, which was to set up a reverse proxy. In summary, here’s a small insight into the issues we have ran across:

• The WorePress instance was being served from a root domain, and the actual blog from Toggl’s domain was supposed to be shown from a blog subfolder and to solve this we tried probably 10 different things that ended up in redirect loops that caused us headaches for a week at least.
• Given that we would practically have the blog shown on two different domains, we had to hide one from the search engines. Our WP hosting partner told us we needed to set up redirects which again ended up in a redirect loop so we settled in on x-robots header which kept randomly appearing where it shouldn’t be on the production blog until we found a way to permanently strip it on the proxy instance.
• The original setup had pages loading in 500ms - 1s, the new reverse proxy set up brought that to 3-5s
• To fix that, we had to set up a cache for up to 2h which made the marketing team rather unhappy because for updates on the website they may need to wait up to 2h for them to be reflected on the website
• We oversaw the fact that we had a robots.txt file accessible on the domain where our actual blog was hosted and proxied from which caused us to scratch our heads 2 months later when the pages still weren’t being indexed.

The upside was that it eventually worked, and the traffic had doubled (combined blog vs sum of all parts), but at what cost.

If you’ve read our previous series on how we use Hygraph for our daily project, you may already know that we use markdown to format our blog, and we defined a series of markdown components to display different elements in our blog visually. The in-line elements are stored in a shared Notion document as code blocks, which I can copy and paste whenever needed. However, we are only human, so sometimes I choose the wrong component and realize it after previewing the post.

For example, we created our own code for embedding YouTube videos instead of using YouTube's embed code directly, so the video would appear differently. We also have note blocks for different kinds of messages: questions, tips, reading recommendations, etc. However, sometimes, I just used my all-time favorite: the editor's note, instead of choosing the most appropriate components.

I’ve got a light-hearted confession to make about a little CMS incident during our rebrand. Everything was running smoothly as we prepped for launch—until we accidentally hit "publish" on the staging site instead of the production test site.

For a brief (but glorious) moment, the entire world had access to our "Top Secret Page of Meat and Food Jargon", complete with all the delightful captions.

It quickly reverted the changes—but not before our CEO got a notification about the unexpected "food mystery." Thankfully, it was taken with good humor!

Let this be a gentle reminder to double-check your staging content before hitting that publish button. Even the most serious CMS work can sometimes come with unexpected flavors!