Blog

One of the criterion I use to know I’m working with a good team is the technical support. Recently I posted a follow-up question to the support forums to see how the documentation for the current version of WordPress was coming – there being very little at present. Here’s how that went.

This support volunteer has had two opportunities to provide useful and helpful responses but each time failed to do that simple thing. His final response was equivalent to “do it yourself”. We are not better off for his contribution.

I just have the feeling from this that they’ve stopped being responsive and helpful. I’m less inclined than ever to recommend WordPress to my customers and have actually suggested they consider the forked version that is continuing the non-block editor path.

My reason for posting this is that I’m quite certain they will delete my post because they’re getting just a little bit pissy about the negative reaction to the direction they’ve taken with WordPress.

I tried – I really really tried. But Gutenberg is simply unready. I didn’t lose and it didn’t win. We were never in the same ring. Gutenberg is unfit for duty and I can’t waste any more time putting lipstick on this pig.

Under Gutenberg my Events Calendar is usesless. Existing events are fine but adding or editing events can’t happen. Overlapping blocks is a serious and unbeatable problem. Actually, this is such a steaming pile of dung that I can’t even compile in meaningful terms what the problems are and how they manifest themselves.

There is no obvious path to whipping this thing except to follow the advice of the WOPR – the only way to win is to not play the game. Time to start looking at B2Evolution again.

Here is a hard line analysis – the WordPress.org management and developers and the salute smartly and carry on plugin experts have to know this release is a brick and that it has no path to success and adoption. It was a nice try and a good effort but like a lot of people I have work to do, and it cannot be done in WordPress with Gutenberg. Hard reality. So I’ll try using the Classic Editor and I’ve disabled the block editor in The Events Calendar. If things work well this is where my sites will remain until I find a replacement for WordPress or WordPress puts Gutenberg back into alpha development.

UPDATE: After enabling the classic editor and disabling the block editor in the Events Calendar settings I find the only reason I bought Events Calendar Pro, recurring events, is disabled without the block editor and will remain so until a miracle occurs from the EC developers.

Second update: The recurring events problem in The Events Calendar has been corrected with an update. Version 4.7.3 and version 4.5.2.1 (pro) work better though recurring events that begin and end at different times (weekday vs weekend schedules) does not work correctly.

This was the last straw for me. On my production site I tried to create an event in The Event Calendar. I have purchased the Pro version. In WP 4.9.9 before blocks this would have taken less than 3 minutes. Type in the date/time, select the pre-defined venue, drop in a Featured Image, publish. No more – after twenty minutes of fighting badly, no, impossibly rendered screens in the event block editor I was able to post this event. Then I realized it was not showing the featured image in the event single-view, so I opened it in the editor and inserted the same image into the event body text. For reasons I cannot fathom, the event time changed, so I opened it again and selected the date block and this is what I got. The calendar and image share the same screen space.

So done with this.

Anecdotally, the world has chimed in and offered its collective opinion on Gutenberg. Here are two plugins offered by WordPress.org along with ratings and implementation. Bebo is dead, Jim.

Every complex tool has multiple ways of doing things. A table saw, for example. Out of the box it is a big machine that may have come with a single saw blade to help you get started. The table saw industry has a number of add-on providers that offer a very wide variety of blades, some for general purposes, some for specialty purposes. None of these add-ons are intended to fill in missing core functionality – they enhance the experience. With the current version of the Gutenberg block editor this is not the case. It was shipped missing core functionality – equivalent to shipping a table saw without a core feature such as a power cord, or a wrench for attaching and holding blades on the shaft.

An example of Gutenberg’s missing core capability that has been back-filled with an add-on (plugin in the vernacular) is adding color to individual text contents e.g., words, letters, and numbers. As shipped the block editor will let you paint the entire contents of a block any color you want. But not individual characters or words. So naturally, someone has created a plugin that will do this and that is all very fine.

I anticipate (and am aware that an early attempt has been made available in a block suite plugin) that plugin developers will create a very useful block that allows nesting and arranging other blocks within it, and that each nested block will allow the author to place the blocks into an ad hoc arrangement that would allow the creation of a live object as illustrated below and which was possible to do in the 1980’s. Every element was a letter or white space block border (currently possible with CSS) made within the tool and fully editable (no images were required to produce this and it could be made into a re-usable and shareable template). And each plugin author working independently will plop such a block into a plugin that is a suite of blocks unaware that dozens of other authors are working at the same task, and that there will be endless functional replications of blocks littering the block selection tool – this is an applied form of chaos.

It is early in the Gutenberg experience and many people with the capability are rushing out various block plugins. But do we want to depend on good will over the lifetime of our pages and posts on a Samaritan’s hard work to create and maintain these plugins? And is it fair for these plugin authors to make these available and to generate a bit of income by accepting donations for what they do only to later see WordPress add the functionality to core?

And ignoring what is or isn’t fair, is it best practice for our businesses that depend upon these plugin authors because the essential components are missing from the WordPress CMS? I for one submit it is bad practice to depend upon volunteers from outside the WordPress organization for core (essential) features and I will not be caught up in installing endless plugins to bring essential features into my tool kit. And that is why the words “bad practice” above are not bold and red. I’ve decided to not install a plugin that will let me do that. Gutenberg himself would do the same.

Another best practice for any dynamic tool is to watch the trajectory the developers have made public. This is necessary if that trajectory does not match our individual future needs and which might necessitate changing tool vendors. So to that end, here is what WordPress.org says about the future:

“I’m not saying it always has to be me, but what I want is a strong, opinionated, thoughtful leader setting a bold direction, taking experiments and being willing to fail, comfortable with failure, is I think what you need to create great software”

— Matt Mullenweg

We are now at version 5.0.3 with no improvement.

Aside from the universal problem of figuring out how to work with blocks (the documentation is abysmal), there were some plugin and user interface problems revealed.

The plugin WordPress Contact Forms by Cimatti gives these errors in the WP Health Check plugin report. I am not concerned about this plugin as Cimatti appears to have abandoned it and I will too.

REST API Availability
The REST API request failed due to an error.
Error encountered: (0) cURL error 28: Operation timed out after 10001 milliseconds with 0 out of -1 bytes received

Background Updates
A plugin has prevented updates by disabling wp_version_check()

Loopback Request
The loopback request to your site failed, this may prevent WP_Cron from working, along with theme and plugin editors.
Error encountered: (0) cURL error 28: Operation timed out after 10001 milliseconds with 0 out of -1 bytes received

Next issue: There are two plugins that if both activated create a problem with scrolling while in the editor. The affected plugins are MetaSlider and Slider by 10Web.

Neither slider is a problem unless both are activated so I really don’t know which to blame. Somehow, the main edit panel and the sidebar panel become interconnected in a way that prevents scrolling from the top to the bottom of the main panel. Scrolling stops before the lower or upper text of the document appears, depending where in the document you begin the scroll. This while using the main panel scroll. To get the rest of the way to the top or bottom it is necessary to scroll the sidebar window which also affects the main panel scroll bar.

This is difficult to explain so I’ve made a screen recording video of the problem and placed it in this post. The remedy is to deactivate one or the other of the plugins that create the problem.

In this video I have opened a lengthy document (more than one screen of information) in the block editor. The mouse pointer is in the editor panel. I begin to scroll the panel contents with the mouse wheel. The scrolling stops before I reach the bottom of the document. At that point I move the mouse pointer to the sidebar and begin scrolling there. Notice what happens to the scroll bar thumb in the sidebar – two appear and they overlap. I scroll up again in the sidebar and the main window scrolls but does not reach the top of the document. But it should not have been scrolling anyway. When I have run out of motion there I place the mouse pointer back in the editor panel and can finish scrolling to the top of the document. This same problem exists with or without the sidebar showing, and even if the scrollbar thumbs are dragged directly with the mouse.

This next problem is a UI issue. I don’t know if it is by design or a bug. The following images show how selecting any block editor view option prevents the mouse hover from drawing a frame around the hovered block. Deselecting the view options restores this frame. I would prefer to use the Top Toolbar option but not if it means losing the hover highlight of the blocks.

Next problem is while editing a document, using the Preview button produces a preview screen but new material is not seen. It will not show up in preview until after an Update is performed which kind of defeats the purpose of the preview. A related issues updates following a click on the Update button will frequently hang requiring abandoning the current screed. Symptoms are the Saving message blinks on and off endlessly. Sometimes it happens that the updates are seen when the document is visited, sometimes not, and there will very likely be a notice of a previous edit being found. I’m now going to update this document so I can see if it presents as I intended.

Jan 9 – updated to 5.0.3 and the Editor Preview option is still showing the page or post but not showing changes after editing a page or post. It is necessary to commit changes with the Update button then go look at the page or post to see if you got what you wanted. You probably realize that defeats the purpose of the Preview process.

Jan 5, 2018

The built-in text widget at WP 4.9.9 offered a Visual tab that allowed wysiwyg previewing of the widget contents. That is missing in 5.0.2 using the classic editor. I’m using the TwentySeventeen theme. Here is an example screen shot.

Second update and resolution found.

Continuing the analysis, I opened the widget page using the Customize menu rather than the Appearance->widget meny and discovered the Visual tab can be seen there.  Having discovered this unexpected on/off situation I removed moved groups of plugins from the plugins directory and found that by deleting the Advanced Rich Text Tools for Gutenberg plugin this Visual tab is restored regardless of which menu is selected. This is the first time I’ve run into a plugin problem that required removal vs disabling. So this issue is resolved.

Final note: Still not happy with the diagnosis, I re-installed the plugin and enabled it and the text widget Visual Tab disappeared again. I then disabled it and the tab was restored, so there is this remaining issue of deleting vs disabling the offending plugin, but since I’m not using the block editor it doesn’t need to be enabled or installed. I’ll leave it for now installed but disabled and keep this as an example of new experiences I’ve had since Bebo came knocking.

Here is the widget menu with the previously missing Visual tab.

This site is used for testing themes, plugins, and block editor features and functionality. Content is nonsense grabbed at random from here and there. The following is a YouTube embed block. It doesn’t have much in the way of features – just paste in the URL Gutenberg takes care of the rest.