Building WPDecoupled: Adding Content! ✍

I’ve launched the site! Folks have even sent me their emails. Thank you for your confidence, each email makes me want to work harder and faster on this! Publishing a blog is a lot easier when you’re relying on established platforms, things such as classic WordPress. As I’m not, and I didn’t even choose Faust.js, which would have assisted in making this front end…I’m left building it all. I hope to make my code available in the future to folks as packages, this way others don’t have to repeat my work…but we will see how reality works out.

What I need to do…

• GraphQL client integration
• Lots of theme/design work (I’m terrible at this)
• Nav menu
• Articles(posts) archive templates
• Category & Series archive templates
• Article(post) templates
• RSS/Atom/JSON feeds for at least articles…possibly sub feeds for Series & Categories
• SEO of some amount
• SvelteKit components for each and every Core WP Gutenberg Block…or at least those I’m using
• Accessibility testing

What I want to do…

• Recent/featured articles on the homepage
• Light/Dark theme switch
• Search
• Social media preview images/meta
• Logging for debugging issues
• Analytics

What I am doing…

I’m trying to remember that things don’t have to be perfect to launch. I’d rather get content out there and have some important things missing than not launch anything for the next several months as I try to get it all “just right”. With that as my guiding principle, I can shorten this list significantly. To get content in your hands I can limit this to 3 features. I have to integrate my GraphQL client to fetch data, then I can implement the post-archive template and post template, and finally, a navigation menu so you can find the post-archive page. That gets the content to you all. Everything else is important, but not to that singular goal.

How I will be implementing these…

Let’s talk about the implementation decisions made. Most important is the WPGraphQL integration. This integration will define my data fetching for all templates, menus, feeds, SEO, content, search, etc. I have to do this before anything else can be done. I could have also chosen to use the native REST API, but generally prefer GraphQL. Though this is mostly a personal preference and one I don’t always follow. As you may have read in the Launch! 🚀 article, I used REST for forms to expedite and simplify the process. At the end of the day, use what you know and you’ll be alright. Because I chose GraphQL, for the best development experience, I wanted type integrations and some other fancy things. Houdini GraphQL is one of the only options in the SvelteKit space at the moment, but it offers a great experience and should handle all my needs.

Once I get data flowing I’ll need to render post content in the templates. There are many options, some new, some old, and some just plain weird. This space is quickly improving and I expect to generate a lot of content around this topic. The short story is I needed to choose between styling HTML rendered from Gutenberg blocks by WP and rendering HTML in SvelteKit using data sourced from those same Gutenberg blocks. Long term I’d like the latter, it means more control and more power in the hands of content creators. But I am the content creator for now, and styling might be as simple as doing nothing. So far my first 2 posts have only used `heading and paragraph blocks. I’m using Open Props for styles, and its defaults should do just fine for now. That will change in the future but for now, this works.

Finally, menus. Menus are a strong feature of WordPress and there’s no reason not to use them here. I create the WP Menu, wire up the GraphQL queries, and spit out some basic menus. Once again, there’s more I can and will need to do here in the future. For now, this meets my needs. I can worry about more complex nested menu items in the future when I decide to implement them.

Two last things…

Finally, I did two relatively quick and easy tasks. I added analytics tracking via Google Analytics and error reporting via sentry.io. These were quick easy tasks that will help me monitor usage and fix errors. Maybe not super important, but because they were quick and easy it was worth it.

Conclusion

Basically, I’m putting off as much as I can in the name of shipping fast to you all. I will let my availability and need drive building specific features in the future. Also, I’d love to open-source much of the code I’m writing for these features. At a basic level, things like menus and Gutenberg blocks should be sharable and easy targets for open sourcing. On the other hand, if WordPress’s full-site editing and other Gutenberg-related features pan out, I might be able to build things that “Kinda Just Work”™️. The future is bright for decoupled WordPress. I hope you come along for the ride!