Single File (WordPress) Components

Every developer loves to hate WordPress, and they have good reason to! It’s built on PHP which has its many flaws and does not follow any modern software architectures.

However, there’s no denying the popularity of the “platform”, it powers 20% of the internet and as such there is a HUGE market for developers that can develop on the WordPress platform. It’s cost effective and probably the best content editing experience for clients. Clients being the key word here.

As such, I’m torn between the market and using modern software techniques. So, I’ve tried to combine the two :)

What I’ve developed is an extremely flexible component based WordPress content editing experience, built on a “single file” architecture inspired by Vue.

So, let’s jump straight in to see what this WordPress component looks like:S

As you can see, the single file component covers 6 different areas required by a content managed component on the web:

  • ACF — Defines the content available to be managed via Advanced Custom Fields
  • PHP — After the raw content is received from the database, run some custom logic to transform the data for display
  • Mustache — Output content server side using Mustache templating (purely for SEO purposes)
  • Script — Define any interactive parts of the component with JS
  • Template — The final HTML that should be rendered for the user
  • Style — The CSS associated with the component

The single file approach allows everything related to the component to be contained in one file. Achieving the principle that “code that changes together, should stay together” mentality.

Once these components are defined it’s just a matter of parsing these files and feeding them into Advanced Custom Fields and WordPress templates appropriately.

This approach removes the idea of “custom templates” within WordPress. There is essentially only one template where you can add 1 or more components. Content editors (read: clients) can now create unlimited templates within their website by creating pages of the various components available, no developer required. Wait, maybe this isn’t such a good thing?!

I will share more details on how to do this once I develop this approach over my next few projects (of which there are a lot in the WordPress market)

Solutions Architect. Technical Lead. Full-stack Developer.

Solutions Architect. Technical Lead. Full-stack Developer. http://craigmorris.io