It appears I had some bad timing. Or maybe it was good timing? I am still trying to decide.
A few weeks back, I was fiddling with one of my new tags (1977, if you care) and I opened up the Sidebar Editor in WordPress to work that year into my complicated sidebar schema. Said editor has always been pretty funky for me, probably mostly due to the fact that I created my sidebar widgets before the switchover to the block editor, at the time called Gutenberg. These older features still remain functional, but not really supported.
This time around, the mere act of viewing the existing data with the editor seems to have wiped out all my prior configurations for a particular class of WordPress widget. Specifically, I had been making use of the “links” function within WordPress to regale you with my organization of my posts into timelines. The same function is what I employ so as to comply with the FTC requirements regarding affiliate links.
All of that disappearing is a serious problem for me. It is also obvious why it happened.
Much of WordPress is organized in a database -type format. All that I have ever typed to you is stored and stored separately from the configurations which tell the machines how you should see it. This separation allows me to, for example, swap out “themes” and give you an entirely new look and feel while not changing a word in my 1000s upon 1000s that are already there. It also means that, as with any good database, I can roll back any changes to return to any previous state. For example, if I come home drunk some night and rewrite an old political post to enhance it with inflammatory references – upon regaining my sobriety and good sense, I can retrieve and restore the more appropriate version.
In some cases, though, WordPress doesn’t work like that at all. For example, you might recall how I found myself frustrated with the way footnotes were apt to up and disappear. It didn’t matter if I had an older, published version of the post saved wherein that content was intact. In the case of footnotes, as well as the tags/links/blogroll function, the stored data is simply in a file somewhere, not in a database. If it gets updated for any reason, whatever was there before is gone forever.
Most critically, if the editor opens a file and realizes it doesn’t know how to “rewrite” the content that it just read in, it may be forgive if it writes out a new version of that file with nothing in it. And that’s where I was – having opened the 1977 tag in the editor, even without saving anything, it caused all my existing, stored information about tags, categories, and external links to vanish as if it never existed. There was no undo button, as there was no record of what I had before and all the tags were effected, because WordPress couldn’t make sense of my any of my tags (not just 1977). To really make it frustrating for me, had I not used the editor as a viewer, all that information would still be there and still be working today.
At the end of the whole process, though, I have to admit it wasn’t all that bad. It did take me a while to get back to the point of acceptance and serenity but get there I did.
I’ve ended up replacing these two widget categories with their equivalent within the block editor. The biggest hurdle, both for upgrading and for fixing my problem, is that there is not a one-for-one mapping between the old and the new. As far as I can tell, support was dropped for what I was doing. That “links” function used to automatically integrated with the “blogroll” widget, allowing you to configure-up groups of external links1 and then control their display upon your own blog. Within the new system, that “blogroll” function is restricted to blogs (and maybe even WordPress blogs). Overall, there is a focus on the specific social media that you wish to reference. No longer do you have a “link” widget, but you do have widgets for Facebook, and Twitter, and Reddit, etc., etc., etc.
On the other hand, the block editor has exposed the underlying functionality at a finer grain. As far as I can tell, I am able to exactly reproduce what I had before, even if it might take me a couple of extra configurational clicks to do so. Furthermore, having put in that work, my control over the final product is that much better. Not to mention I do it all with an editor that actually works reliably via a sensible set of interfaces.
I do wish the WordPress people would be a little more careful about how they deprecate their features. In this case, I suffered no more than 3-4 days of distraction as I tried to figure out what would happen – plus a few more days spent on reconstructing the old settings. I can imagine much worse just as I can also imagine development approaches to avoid it all.
While I have your ear, let me throw in one more complaint. I ran into another case of the “classic” editor being phased out, and this one almost did just what I described above.
One of the better compatibility features that followed redesign is a “classic” block within the block editor itself. For the old dogs, if one couldn’t figure out how to make something happen with the current methods, one could just fall back on the old editor and set to work. It can be as little as a paragraph or a table or it could encompass an entire post. Indeed, when an old post has been created with the old editor, opening it for further revision uses the “new” block editor, but within it that classic block.
The same improvement project that ganked my old “blogrolls” seemed to be messing with this function as well.
As of a few days ago, opening an old post to edit automatically converted to block style. What’s wrong is that these conversions are less than reliable. For example, captions. If an image created in the classic editor had a caption, that caption text got deleted. This is exactly the scenario that I suffered with the footnotes bug. It is just what I said I feared when WordPress plunges forward with “upgrades” insensitive to the fanout.
I almost captions in a couple of posts. Almost.
Why this problem got relegated to an afterthought is – and unlike with my first issue – everything about the old post remains saved in the database and the destruction can be entirely backed out. Furthermore, there remains an older method of opening posts with the classic editor interface (rather than just the classic editor block) and that provided me a workaround to this auto-conversion and its attendant destruction.
Best of all, it appeared that the developers realized the error of their ways and fixed this before I accidentally messed anything up. I was (sort of) hoping that they didn’t fix it before I hit publish, as their prompt attention has made the tail-end of this post obsolete before any of you got to see it.
- A key point here is that the “links” (and this feature is still in there) is open-ended. It could be any link, internal or external, which then could be grouped and/or sorted by a number of user-definable features. Built in, was a category “blogroll” which could be easily included in ones website design. There is nothing, however, that said the links had to be to blogs, WordPress or otherwise. ↩︎