A Verbal Middle Finger to WordPress

I just lost a fair bit of work from WordPress “helping” me, so I need to vent.

Think for a moment. What is the #1 thing that should define a good text editing experience… something so fundamental that you take it for granted… I’ll give you a hint. Autocorrect screw-ups are a weaker form of it failing.

Give up? It shouldn’t #$%*ing lose or corrupt your work!

WordPress deserves an award for how flagrantly it violates this principle and, if I can ever find the time to satisfy my obsessive dedication to preventing dead links, I’m going to switch to a static generator. (Partly because I blog infrequently enough that it feels like all I ever do is apply updates. Static HTML can’t have exploits in it.)

Let’s start simple. You might have noticed that I like to use all the semantic elements HTML gives me for making my posts as readable as possible, including tables and especially definition lists.

Have you ever tried to edit a table or definition list in WordPress? …especially with the legacy TinyMCE editor? There’s no option for them, so you have to switch into the raw HTML view and edit by hand.

That wouldn’t be so bad, except that there’s no “preview without publishing” option in raw HTML mode when you’re editing an existing post, except for switching back to WYSIWYG mode… and WYSIWYG mode normalizes your work into gibberish with no Undo option if you don’t get your HTML tags just right.

Better hope you made a backup of your HTML in an external text editor before previewing it.

…and that was before the new Blocks-based editor. If you’re using Blocks, you get a helpful little “Invaid HTML. What do you want to do?” popup with two buttons… they’re kinda cryptic and one of them basically means “convert from legacy TinyMCE block to custom HTML block without any apparent option to Undo”.

Better make a backup of that HTML, hit Reload to “undo”, and then paste the HTML into the TinyMCE/legacy block’s HTML mode to restore your work.

OK, so maybe I’m just too much of a technical writer and I should try using Blocks the way it was intended… I think you can guess by now that it’s no picnic either.

Want to edit stuff naturally in the new Blocks editor? Good luck. The interaction between cursor motion and selection means that trying to select a paragraph of scratch text without reaching for the mouse will snap the selection to the entire block, including text outside your intended span.

(Admittedly, this is something I dread having to do right in my own project, which also has editable text spanning multiple contenteditable elements… but at least I’m diligent enough to be aware of the problem and dedicated enough to try to figure out some kind of solution.)

…and that’s not even counting the idiocy that is how the Up arrow likes to jump from the second line of a paragraph block to the end of the previous block when you’re trying to position the cursor at the beginning of a paragraph. The Blocks editor is so braindead that it boggles my mind that nobody else noticed this.

(Nor the more minor annoyance that the heuristics for determining when to finalize one Undo action and start another are inferior to the desktop text editors I use, so I wind up undoing too much.)

…but I saved the worst for last. The piece de resistance that inspired this whole rant. I just lost a big edit to an old list post because, for reasons I can’t even fathom, switching from TinyMCE to raw HTML reverted it to the saved version. No “Are you sure?”. I just did what I always do to switch to HTML to fix up my markup and… that’s odd. Where are my changes?

OK. Maybe I should have un-published the post into a draft for a moment, even though I despise 404ing links even temporarily… the “Save Draft” button is unreliable. Wait too long with a WordPress tab open and clicking “Save Draft” will leave you stuck on “[Icon] Saving”.

Now, admittedly, I do, on rare occasions, have HTTP requests get stuck on setting up the connection. I’m assuming it’s some kind of packet loss during the initial handshake and TCP has to wait for it to time out and resend the packet. Maybe it’s that WordPress is much more prone to that somehow.

…but the usual solution is to click the Submit button again… a button that WordPress hides. …and there’s no “click Stop and then reload”, because WordPress has no analogue to the Stop button!

Wanna use the preview function but have your browser set to only allow new windows/tabs to be opened by an explicit middle-click or context-menu choice? Too bad. The Preview button can’t be middle-clicked.

I’m on WordPress because I’ve been on WordPress since December of 2004, and my workaround, when I don’t get lulled into using the UI the intended way, is to just copy my post into gVim, edit it there, and then copy it back.

Given that the “can’t trust WordPress to protect your text” aspect of this seems fundamental to how the authors of WordPress approach the interaction between author, text, and tool, I think you can see why, as soon as I have time, I want to translate all my posts into Markdown, switch the site to something like Pelican, and say good riddance to bad rubbish.

UPDATE: Apparently it’s also prone to forcing a “convert to visual and resolve broken HTML” when losing focus so I can copy-paste text from another tab. Ffffff……

A Verbal Middle Finger to WordPress by Stephan Sokolow is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.