Digging into the Website

Sometimes my website goes through fallow periods, and when I say “fallow” I mean that in two ways.  On the one hand, I don’t feel like creating content.  On the other hand, I don’t feel like looking at my PHP and CSS code.  I used to post to the blog every single day.  Now I feel lucky if I write a blog post a week.  I used to dig into my PHP code at least every other weekend, and I’d stay on top of the WordPress support forum looking for new and interesting pieces of code or plugins.  Now I have a blog theme that is all sketched out and all I need to do is to sit down and finish the last code push, and it’s been that way since autumn.

Then there’s a week like this week, where I’ve made three posts, one of them a significant piece on a college baseball game, I tinkered with my theme’s CSS code, I wrote a little routine to replace the dates on my blog posts with Hobbit dates, I installed a plugin to enable front-end editing (and that required some tinkering because it hasn’t been updated in a while and triggered four PHP Fatal Errors), and I’m writing this post using the new Gutenberg interface (the future editor in WordPress) to see whether I like it or not.

Do I like Gutenberg?  Not particularly.  The Blade Runner post was written, at least in part, with Gutenberg, and since it represents the future of WordPress I want to build my experience and comfort with it.  I’ve become accustomed to writing my WordPress posts in HTML markup — WordPress has a visual editor, but I like the feeling of control and cleanliness I get from composing directly in code, and fifteen years of writing blog posts in code is so familiar to me that when I work with the CMS at work I write in code, not the WYSIWIG editor — that writing in Gutenberg’s WYSIWIG composition screen feels strange to me.  With the Blade Runner post, I wanted to embed videos from YouTube, but Gutenberg wouldn’t let me do it.  And, as a purely aesthetic matter, Gutenberg produces garbage code.  It turns my stomach and, for a project like WordPress that has the motto “Code is poetry,” the code Gutenberg produces for the user’s content is anything but poetry.

Still, familiarity with Gutenberg breeds comfort, and I’ve come to feel comfortable working with Gutenberg purely as a visual editor.  That’s the thing.  It’s useful as an editor.  I can see my words through the HTML tags.  I can see how my sentences hang together.  I can see my typos, I can see where I’ve left ideas out, I can jump in and fix my mistakes.  It’s very easy to add hyperlinks.  Gutenberg feels like a basic, distraction-light WYSIWIG editor.  I doubt it would suit all of my needs, but if I want to prototype text and then dig down into the guts of the code and fine-tune the post in the standard WordPress editor that would work.

Which leads me to the Front-End Editor.  I’m not sure how I stumbled across this plugin this week, but I did, and I’m glad I did.  It’s a plugin that was being developed for the WordPress core that was, for whatever reason, abandoned about two years ago.  One of the worst things about writing in WordPress is finding mistakes and typos after hitting publish.  Fixing these mistakes becomes cumbersome; you need two tabs open in your browser, one showing the post live on the blog, the other showing the editing screen, and then you need to flip back and forth between the two.  It’s not an ideal way to fix mistakes.  “Did I fix that comma?  Did I add in the verb I completely missed?  Did I catch everything?”  With the Front-End Editor, I can hit publish, then fix my mistakes live on the blog.  “This is genius!” I exclaimed (once I fixed the PHP Fatal Errors), and I can’t imagine how I ever lived without it.  It matches my workflow and, more importantly, it streamlines that workflow.

In my view, that would be the ideal direction for WordPress to take Gutenberg.  Instead of creating a brand-new editor experience, put the resources into bringing the Front-End Editor up-to-date.  The Front-End Editor won’t have all of the bells and whistles of the main editor in the WordPress admin, but it doesn’t need the bells and whistles.  It just needs to be able to create a post, add images, add tags and categories, and publish.  Ideally without the code garbage that Gutenberg produces.

If plugins like Gutenberg and Front-End Editor simplify content creation, why haven’t I been creating content as I once did?  There are two reasons, and they’re somewhat interrelated.  First, I could write to my blog every day when there weren’t other outlets for communicating with people online; either Facebook and Twitter didn’t exist then, or they weren’t the platforms that they’ve since become.  The kind of ephemeral, insignificant material I might post to my blog is the kind of ephemeral, insignificant material that modern social media is made for.  On Facebook and Twitter, material like that disappears down the memory hole (unless you’re someone like my Twitter follower Anthony Scaramucci, who has had his entire Twitter history dredged up in the last forty-eight hours).  On the blog, it’s important.  And the second reason, WordPress increasingly needs images with posts for thumbnails and headers depending on the theme in use, especially if the posts are going to be shared on Facebook and Twitter where those images are used as thumbnails and Twitter cards.  Sometimes, I don’t have an image.  Or sometimes, what I’m thinking about writing about doesn’t feel important enough for an image.  In a weird way, design decisions of the website itself drive whether or not something is worth publishing, let alone writing.

The goal, ultimately, of the blog design that I keep tinkering with is to get around those two problems, to have room for the important posts that justify the time and the illustration on the one hand and room for the ephemeral, random stuff on the other.  Ironically, that part of the blog’s design is done.  It required custom functions and the shortcode processor.  It’s been tested.  It’s worked for months.  It’s the other key component of the design, the one that requires a responsive slider and custom menus and a custom Walker that’s posed difficulty.  It’s not an insoluble problem, merely a tricky one.

All things considered, writing this post in Gutenberg wasn’t a bad experience.  It’s becoming comfortable and familiar.  At its worst, it feels like I’m writing in some open source attempt at mimicking Microsoft Word.  I’m not sure that it’s the right solution for every WordPress user, especially for those who use WordPress as a CMS rather than as a blogging platform.  If Gutenberg really is the future of WordPress, then I hope that the current editing screen remains as a fallback option for users.

And, as for my own blog theme, I’m getting close.  It’s almost there.  Almost.

Leave a Reply

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