So much for Wordpress

So much for Wordpress

As of today I am officially looking for a self-hosted replacement for WordPress that I can migrate all of my posts to. No, this change will not be soon, but it will happen, and here’s why.

They dun fucked up.

Oh, it’s still usable, and not broken yet, but the upcoming chaos is inevitable much like watching a train wreck in slow motion.

There’s a reason I used WordPress. Not because I couldn’t write my own CMS – Did that for “fun” back in 2002 with the default LAMP stack. I’m no great programmer but in that same time frame I also set up a site that downloaded property data, flushed and updated the relevant tables, and made them searchable, etc. by various filters to generate leads for a realtor. I even became reasonably familiar with more advanced CSS, including making drag and drop CMS interfaces.

By the time I was putting up my own blogs somewhat seriously, I was no longer working in web development, and I wanted to spend time on content, not maintaining a database / editor system. And WordPress fit the bill. Reflecting the man-hours put into development it was already more capable, but parsing through the php and theme files was still a straightforward task, and building a site template/theme from scratch based off of the barebones theme was still easy.

Somewhere along the line, that changed. I was helping a friend out, he’d found a theme that worked, and dipping my toes back in after a while I discovered that editing the base theme was strongly not recommended. Instead you created a child theme. The problem being that for any but the simplest changes you now had to go parse through a dozen files to find – and replicate – the items you needed so you could change and override those.

And it was now significantly more complicated to do so – to parse through the various php files.

I could still live with that. I needed self-hosted, I no longer trusted blogger/etc., and WP was still simple to set up and not terrible about getting posts back in.

Which brings us back to Gutenberg.

Gutenberg is the new editor. It’s intended to be more newbie-friendly, and help force content into manageable, parseable chunks by making you organize it into blocks that roughly map to HTML block types (paragraph, header, etc). If all you’re doing is writing out a bunch of stuff and then setting the header/subheader paragraphs, it’s very simple and straightforward.

The problem came when I needed to quote a forum excerpt that had an unordered bullet point list. It would NOT keep any nested formatting inside the block other than paragraphs (which it didn’t gracefully convert consecutive paragraphs into a single block either) and bold/italics. Lists? Forget about it. Last week’s Friday post I reverted to the “old” editor to quickly get all the images in.

But that isn’t the worst part.

Gutenberg is still in beta, but it will become the default. If any of you are reasonably familiar with HTML and WordPress you’re already tearing your hair out at all the plugins and customized themes that will break. Sure, you’ll still be able to run the “old” editor as a plugin, but why should that be needed?

So yes, it’s slick. It does that 80% pretty well, and enforces a bit of structure to your writing. The current editor is… flaky is being charitable. The problem is that other 20%.

And then I started doing some more digging.

From “Where Gutenberg Lost Me (Open Letter to Core)“:

So, WordPress has structured data needs for blocks that may be dynamic or static, and may have a large amount of meta-data attached, and it has flat output needs in various forms, such as excerpts, search fields, RSS feeds, and HTML.  It also has needs for several ways to modify the underlying structured data, in various apps, via API, or in visual editors. Clearly, the core data is structured, and should be stored as such, with all flattened views and editing interfaces being generated from that. At minimum, it could be a JSON object, or better yet, a series of database structures that could be manipulated and indexed independently.

NOPE. The team went with HTML with inserted comments.

Are you thinking WTF? well, the explanation is easy. This massive paradigm change to structured data for WordPress posts would change everything from how the API interfaces with content, to how the site renders the_content(). And that is hard. Plus, this is the #yearoftheeditor, not #yearofthedataparadigmshift, so making changes like that was written off as out of scope. They’d rather maintain a box of snakes for the next ten years, endlessly patching, then to consider a major structure change.

So, instead, we get a whole new set of problems bolted into the existing mess that is post_content. Search results will now parse through the myriad html comments in a post, as well as the shortcodes and html tags they already look at. All rendered HTML will need to be based in forms that work equally well as plain text, or auto-excerpts and feeds will look awful. Dynamic blocks will disappear, of course, so any text describing them will suddenly be orphaned in feeds and excerpts. Rendering blocks on the front end will now involve either an expensive DOM walker, to parse the WordPress comments, or an insanely complicated RegEx to parse comments, that is guaranteed to fail under certain circumstances (Regular Expressions are fundamentally not suited for parsing HTML, as HTML is not a regular language), or posts will need to be filled with opinionated HTML to support their display. (note: it appears i was incorrect about this point. Post content is parsed using PEG, which is theoretically a parser capable of handling HTML parsing… HOWEVER, the PEG parser for PHP is generated by a project called Peg.js, which is at version 0.1, and does not promise stability until version 1.0, and a project called phpegjs, which is at version 1.0.0beta7 and has only one contributor.. this does not inspire faith)

And then, from You called it Gutenberg for a Reason.. That Doesn’t Make it Revolutionary. (An open response to Matt Mullenweg):

This is a very interesting statement, beyond the overly rosy assumptions that are low on facts, because it highlights a common use case: writing elsewhere and pasting into WordPress. Many people go this route because they either don’t trust, or don’t like the WordPress editing experience. Many reviews of Gutenberg by writers have stated that their issues with the interface actually got worse, rather than better, due to the constantly changing controls and lack of consistent interface elements.  Given those facts, I find it somewhat telling that even Matt Mullenweg, champion of Gutenberg as the future of writing, chooses to do his writing elsewhere.

and to me, the real sign of trouble – scope creep:

Scope is a word we hear a lot, and there are a lot of problems with it. Gutenberg was originally a codeword for the new editor, which would add block support, and basically replace the existing editor block. From there, the scope has changed to first encompass the customizer, then metaboxes, and now full page-building and the entire “WordPress experience”.  The project began without a tight scope or definition of success and failure, and now is naturally suffering from scope creep.  But everything it moves to now encompass comes at the expense of further development and iterations on the core idea.

Finally, from this year, the article I originally dug up when I was trying to figure out why I was having issues with nested elements, Gutenberg Can’t Switch Semantics, and that’s a BIG Problem.

In short, scope creep, not paying attention to what all the users – vice just some that would otherwise be using Medium – want, and making the functionality worse, if anything.

About Last Redoubt

Ex nuke mechanic, jack of all trades.