The Spirit of WordPress

This year, WordPress celebrates its 20th anniversary since it was launched to the web community. I remember this well. It was a couple of years after I had started building websites, and it was like a breath of fresh air compared to the various half-baked web publishing solutions (side note: Moveable Type was great, too). For its time, WordPress raised the bar by providing an excellent experience for developers and editors.

In fact, WordPress plays a role in my journey to where I am today. I learned PHP by making themes. I got business by empowering my giving my clients the means of publishing on the web themselves. This might be a similar story for many of you reading this now. We all should recognize the immense impact this blogging software has had on the web community and how it democratized web publishing for so many people.

I also remember how, over these past two decades, my job as a web developer gradually evolved from making posts and page templates look nice to try to make WordPress work as a serious content management system, e-commerce platform, artist database, academic journal publishing software, podcast system, and much more. During that time, our expectations of the web changed. A website wasn’t just for marketing and news; it embodied the experience; it was the product. If you think about it, what CMSes did, was to give us software in the browser that let us be productive without having to install anything on the computer.

With increased expectations and more complex problems, my frustrations with WordPress grew. Sure, I could make “it”?do all these additional things, but I was essentially working against its design, writing a bunch of extra code, and trying to make plugins of varying quality play nicely together. I remember the stress of being responsible for WordPress sites running well and getting late-night phone calls whenever the site fell down due to an unintended plugin upgrade or bugs (self-inflicted by my client or not).

The legacy of WordPress is also why I decided to move on: It has not significantly changed its foundational architecture since it was launched (if we look away from Gutenberg, the block editor, for a minute): The database schema is pretty much the same (your content lives in the wp_post table), and it’s still essentially a PHP app that intended to run on a live server environment (a.k.a a LAMP stack ). Sure, you can get WordPress content from an API, but what you get in the GraphQL payload is still HTML markup over the wire, with all the cruft and stuff that can get in there, from plugins to arbitrary HTML embeds. It felt clunky and against the grain to put that content into modern web frameworks via their dangerouslySetInnerHTML properties and whatnot.

Recently, I asked several members of the community and our customers why they decided to move away from WordPress. They said:

• It’s hard to structure content. Even with Advanced Custom Fields, it’s easy to mess it up.
• It’s tricky to scale WordPress for performance.
• A lot of security, reliability, and maintenance worries
• Gutenberg, the block editor, is too opinionated and with too many options that mess up design systems.
• Fever devs want to work on a LAMP stack –?it feels very dated.
• It’s hard to make advanced permissions and localization work great.

I know many of you come from WordPress development and chose Sanity because you shared these frustrations. And I know that many of you have to convince customers and clients that might ask for WordPress that a different tech stack is better for them. But they wonder: why should they ditch their familiar platform just because their developer isn't satisfied with WordPress?

I think it starts with understanding why folks reach for WordPress. My impression is that it has a long history of empowering content creators.

Fortunately, we built Sanity with the same ethos: We wanted to make it easy for developers to say “yes,” and make the accommodations their content teams wanted, making them more independent. Over the past 5 years, we’ve seen that successful teams who move from WordPress to Sanity:

• include content teams in the process of building out the Studio and its schema
• manage expectations that the experience is different from what they’re used to
• make it clear that requests for customizations are not just possible but reasonable
• prioritize making accommodations like great field descriptions, helpful validation, custom desk structures, icons for document types, field tabs, conditional fields, and plugins for media management, localization, and SEO
• set up webhooks to trigger builds or revalidation and have their content creators understand how an update gets published
• Provide ways to preview content before it gets published

From a business perspective, it can be a hard sell to go from seemingly “free”?software to a paid model of composable technologies like Sanity and hosting like Vercel, Netlify, Cloudflare, and similar. But then again, it’s not free to host WordPress either, and even though the core product is free, plugins are very often commercialized for professional use. And then there is the hidden opportunity cost and what the team spends their time on. For a lot of customers, especially in larger companies, we see that they ship significantly faster (while having fun doing so), and they’re spending less time on scaffolding and maintenance and more time on stuff that brings immediate value. The motivation from working with and not against technology is also valuable.

WordPress is still out there, dominating the web. For those who’ve moved on, it’s tempting to look down on it and those who choose to use it. But that’s an overly simplistic point of view. We should acknowledge its limitations while respecting the legacy of WordPress and how it has paved the way for developers and content creators to feel comfortable publishing content on the web. I hope the spirit of WordPress can live on while we move to technologies built for the challenges and opportunities of today—and tomorrow.

Do you have a story about the role of WordPress in your journey and why you decided to build with Sanity instead? I’d like to hear from you in the comments!

Community Highlights

Every week, the community shares insights, inspirational projects, and useful tools and plugins. We have collected some of the highlights here:

• There is a new update to the Icon Picker plugin that reduces bundle size when consuming its data
• The Draft Review plugin now supports Sanity Studio v3, with support for previews, user presence, and live updates
• The new Simpler Color Input plugin makes it… simpler to select among predefined colors
• Roboto Studio has published guides on using GitHub Actions with Sanity and image handling with Next.js
• If you’re into TypeScript, then the @sanity-typed/types?project might be interesting

Thanks to all of you who make and share with the community!

Recent news and updates from Sanity HQ

Make sure that you sign up for our upcoming virtual Summer Product Event (August 2nd), where we will be demoing Sanity AI Assist, as well as upcoming feature releases.

• We released Studio updates, including bug fixes, a new document pane search, and improvements to the Portable Text Editor customization API. See our changelog for more .
• You can now initiate a Studio (and project) in a Next.js application with a single command
• Sanity AI Assist is launched in beta for enterprise customers
• Simen Skogsrud (CTO, Co-founder) wrote about how he views the impact of AI
• There is a new guide for making templates with Sanity , as well as clean templates for Angular and Nuxt
• We have updated our guide on how to use structured content for page building for Studio v3
• We have published the recordings from our meetup with Vercel on Visual Editing , e-commerce demo , the State of Headless CMS panel , and the Remix Bay Area meetup that we hosted in our SF office
• And, of course, we’re hiring !

I hope you enjoyed this newsletter, and as always, we’re grateful to have you as part of the community!

Cheers,

Knut