I still have and keep updated the Guttened version of WeirdPress. I don’t actually use it anymore except on one site where I keep the Events Calendar current. And each time I do that the weirdness follows like a crank-addled ghost.
If you visit the home page of this site you will see I discovered a technically acceptable but illiterate way to use the Quotes block. At least all the quotes are balanced but are single quotes rather than the preferred double quotes.
For calendaring on my production site I use The Events Calendar with The Events Calendar Pro plugin by Modern Tribes. A reliable failure which exists at every update of events is times and dates will mysteriously change. This is especially nasty when using repeating or multi-day events. It takes several iterations of edit/preview/publish to get the dates and times right for new events and I’m constantly reviewing existing events to ensure the times have not shifted. For reasons nobody is talking about, the multi-day feature will randomly add several days to an event. It also becomes terribly confused about events that span midnight even though I’ve selected 2:00am as close of day for events in the settings.
Another grand anoyance of the Events Calendar is after creating or editing an event and publishing it, I am asked if I am sure I want to leave the block editor page I’ve been working on, suggesting there is unsaved work there. There never is but it is still unnerving to wonder how much of a job it will be if it thinks there are still unsaved changes. It also produces alerts about the existance of a previous draft version. It is no wonder I’ve largely lost interest in this mess and long for a return to a Guten-free web experience.
The Dashboard Updates page tells me I’m up to date on everything which is sad because the WordPress Contact Forms by Cimatti pluginis still being reported by the Health check plugin as failing. If I disable the Cimatti plugin these warnings disappear.
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
Installed Contact Form Plugin:
WordPress Contact Forms by Cimatti Deactivate | Troubleshoot Quickly create and publish forms in your WordPress powered website. Version 1.4.8 | By Cimatti Consulting | View detail
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”
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.