Writing WordPress Content in HTML

There are a lot of myths and opinions about developers and their reliance on- or aversion to- software that has been built by others.

On one side of the spectrum, there’s the camp that believes that everything with your name on it should be build from scratch in HTML and vanilla CSS. These purists like to forgo any modern convenience, any framework or library that appears too easy or too user-friendly. On the opposite side, there are the stereotypical web designers who prefer to rely solely on drag-and-drop page builders and free PDF templates, working quickly, but limited by the constraints of their knowledge and their resources.

Ignore those two vocal minorities. The reality is that most developers work somewhere in the middle, a decent amount of customization, but built on a strong and ubiquitous foundation. Libraries, content management systems, and frameworks when appropriate, custom coding when needed.

When you work for clients, you need to strike a balance. You need to be have the skills to create anything they ask for, but you need to make sure you’re able to offer a user-friendly back-end for them. I enjoy transferring control of a site to a client, if they’re interested and have the time, and training them to take ownership of their online identity.



Recently, I’ve been managing some websites where I’d really like to be able to blend custom HTML with WordPress. I want to be able to write some truly hand-crafted pages in my preferred text editor on my computer, but have the HTML stored within the database as the post content. However, I did not want to spend time copy/pasting between my local editor and the WYSIWYG editor.

Before I continue, I should state that I am aware that there are arguments against all this custom HTML inside of WordPress. For posts, specifically, I think that writing syntax-free, or in some simple, universal Markdown, is the way to go.

Pages, however, are different. They’re meant to be unique expressions that stretch the user experience and can afford a little custom attention. I could use a custom page builder, but that’s not ideal when I’m really just interested in quickly writing and maintaining them myself, or using some advanced techniques that will require some custom styles and scripts.


Current Problems

Previously, I’ve relied on custom page templates as a hacky solution to this problem, assigning a page it’s own template, editing it locally, and using something like WP Pusher to sync updates with the website’s theme. This works well enough, especially when I’m using a local WordPress to develop anyway. Changes render pretty quickly with no database calls, so I can write these pages rather quickly.

The problem with storing what is essentially page content inside of the theme files (instead of the database) is all of the WordPress features I was missing out on:

  • Non-dev colleagues can’t use Yoast plugin to see some basic SEO assessments of pages
  • Page content isn’t accessible via integrations, such as the WP REST API
  • Page content not indexed in site search (using a search plugin like Relevannsi), meaning pages that might be helpful to site visitors aren’t showing up in on-site search results

These were just a few that crossed my mind, but I can bet that there are a ton more benefits to keeping content inside your content management system.


Possible Solutions

I’ve been searching around for an alternative workflow that could involve stored HTML on my computer for editing pages locally. Then I could use the command line, preferably with some version control such as Git, to upload them to the site.

One clear forerunner is the WP-CLI. It looks like it has the potential, along with WP REST API, to revolutionize how we interact with WordPress. I still have questions about it before I go through setting it up, so I’ve put testing it on hold for now.

Instead, a plugin by the name of WordPress Github Sync seems to be a great out-of-the-box solution. This plugin grabs all of your page/post content and stores it as MD files in a github repository. I can write pages in HTML (even though it stores them as MD) and sync them with my site via git. WordPress then stores the HTML in my page content field where it should be.

I should mention that this doesn’t seem to be the primary purpose of this plugin, but it works and also makes collaboration with other devs a little more controlled.


Potential Pitfalls

There are a lot of caveats to this method of using the post content for storing actual code. While this method is working well for updating custom HTML, it doesn’t work as well for other languages.

Executing PHP

The function to display content, the_content(), will not execute PHP, for security reasons. If your custom page template includes any PHP, such as a WP_Query for some posts, get_template_part(), or some other custom call to the database for some additional data, it will not execute.

One way to get around that is to wrap those sections in functions and call them via the shortcode api. Here’s an example of a basic shortcode that calls a file from my /templates folder, but that could still keeping a lot of content in the theme files.

Storing CSS/JS

Another issue is storing my CSS/JS. These still need to exist within my theme, and there’s no easy way to link script files to individual pages without simply using conditional tags in my functions.php. Could there be a way of storing modular CSS or JS files as page meta? Would that even be ideal? Something to look into.



I’m interested in what other ways developers have of combining custom, local coding with WordPress. It seems like wrapping everything in shortcodes or using page builders are OK, but sometimes a little too broad of a strategy.

I can also understand that maybe WordPress isn’t the best solution for this type of development, but apart from designing these custom pages, the rest of the CMS is extremely useful for running our blog, processing contact forms, integrating with third-parties, and so on. How do you approach this problem?


Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.