Updated Website Recommendations

A short time ago, I wrote about my experiences with website security and what I learned from them, as well as my experiences with privacy considerations. Those areas alone kept me in frenzied motion for the better part of two months–but I wasn’t yet done. The WordPress landscape has changed radically enough that I needed to take a look at some of my basic practices, including page design. What I discovered made me rethink some of my earlier recommendations.

A (Not So) Brief Rant about the New Block Editor

Most of you are probably familiar with the block editor (Gutenberg), first introduced as a plugin, then made part of the WordPress core with version 5.0. I usually applaud exciting new developments–but this is one about which I had a much more tentative reaction.

Editing Window Size

I can’t see the benefit of having a claustrophobically small editing screen. It doesn’t seem like an improvement on the classic editor, which feels much roomier. I suppose it might be better for editing on a cell phone–but how many people do that? At the very least, the size should be more adjustable.

Problems with Blocks

​More importantly, it’s not clear to me why the block metaphor is an improvement on the integrated approach in the classic editor. For instance, in the classic editor, adding an image could have been as simple as clicking add media, clicking on the image, changing alignment if needed, and clicking to insert. By contrast, in Gutenberg, you click the plus sign to add block, select image (which fortunately is pretty near the top), and go through the last three steps above. That’s already one click more (unless you’ve added images recently, in which case you can skip the extra click). But wait! You’re not done yet. The image is sitting in its own block below your text. That’s fine if you wanted to do that, but if you wanted to incorporate the text into your paragraph, you need to make sure the image is above the text rather than below and then align it right or left, at which point it will pop into the right place in the paragraph–assuming you want it right at the top. I haven’t yet figured out how to get it inserted somewhere in the middle of a long paragraph except by splitting the paragraph into two blocks.

Even though this process becomes faster as you get used to it, it’s clearly not as simple as the comparable process was in the classic editor. That’s because the classic editor sees your work as an integrated document. Gutenberg sees it as a group of blocks. For some things that typically take the whole width of the content area, like embedded PDFs, seeing the embedded content as a separate block isn’t a big deal. However, for elements like images that you often want to incorporate with the text, the block editor is clumsier than its classic sibling.

Restricting TinyMCE

Another side effect of the block metaphor is the disappearance of the TinyMCE toolbar from the top of the editor. TinyMCE is still under the hood, and you do get a (very limited) selection of Tiny MCE controls in the upper left corner of the screen when you’re editing text in Gutenberg. To me, neither moving the controls nor reducing their number is a usability improvement. It also creates problems for the numerous third-party plugins that incorporate their buttons into the TinyMCE toolbar. Many of these plugins have already been updated to include Gutenberg blocks. But now, instead of being able to click directly above the are where you’re editing, you have to scroll through the possible Gutenberg blocks to find the right one. Again, this doesn’t seem like a usability improvement.

JavaScript Pitfalls

Unlike its classic cousin, Gutenberg relies on certain JavaScript functions that could conflict with the potentially numerous plugin scripts on your website. If you search for the error, “The editor has encountered an unexpected error,” you will find that this issue pops up a lot over a period of several months for a variety of different reasons, and it’s still happening. I started having that problem yesterday and today. I solved it temporarily by switching from Chrome to Firefox. The same JavaScript errors occurred in both, but Firefox managed to get the page opened.

I probably should have taken the time to troubleshoot the problem, but you know what a joy that process can be on a live site. You know, disable all the plugins, then re-enable one at a time until you find the culprit. Then you either have to junk the plugin and/or notify the developers, who may not get a fix out right away. Oh, and let’s not forget about changing to another theme to see if the theme is the problem. None of those processes are in any way off-putting to your site visitors, right?

Interestingly, the old, reliable classic editor never had this kind of problem. Enough said.

Possible Block Editor Advantages

All of that said, yes, the block editor does add features the classic editor doesn’t have. The ability to have multi-column layouts is especially important. However, anyone who needed features like that would long since have found a decent page builder and used that. And yes, any decent page builder is likely to do columns faster and easier than Gutenberg does. Still, the idea of expanding the editor to include page builder features is a good one. It could theoretically reduce the number of plugins needed. However, in the short terms, it’s actually increased my reliance on plugins–go figure!

Why Not Just Ignore Gutenberg?

After all, the WordPress team has provided a classic editor plugin that enables us to continue using it as an alternative to Gutenberg–for the moment. Support for this feature is only guaranteed through 2022. From that standpoint, it makes sense to find ways to get Gutenberg to work the way you need it to work. The classic editor may not be an alternative forever. Besides, for all my misgivings about Gutenberg as it is now, the development team is constantly working on it. Based on how good WordPress is, I have faith that Gutenberg could eventually evolve into a much better editor.

Ways To Improve Gutenberg

TinyMCE Advanced Plugin

I actually ran across this plugin when I was trying to find a replacement for an abandoned plugin that made it easy to create image borders. As it turns it, the plugin does far more than just that.

Among other things, TMA creates a classic paragraph block that can be set as the default block in Gutenberg. Even better, TMA can change the settings for the TinyMCE toolbar, adding functions or even a top-menu that gives you easy access to everything TinyMCE can do. (It similarly expands TinyMCE in the classic editor.) I never knew TinyMCE could do far more even than what the classic editor allows.

This approach doesn’t resolve issues like the small editing window, but it does at least bring the Gutenberg experience closer to that of the classic editor.

Elementor Page Builder

For years, I’ve been a fan of WPBakery Page Builder, so you might wonder why I’m now recommending a different one. What it boils down to is that Elementor is currently more future-proof.

WPB claims to be compatible with Gutenberg, but in this case, compatibility is defined as begin able to coexist on the same website without problems. WPB works only with the classic editor. I think it can open the classic editor even without the classic editor plugin being installed, and it blocks Gutenberg from opening if there are any WPB elements in a page or post. This approach works for the time being, but the day may come when Gutenberg actually offers some features you want to take advantage of, and there’s no easy way to convert a WPB page or post, which uses shortcodes Gutenberg can’t work with to insert its elements into a document. Alternatively, some new change in WordPress might make it more difficult or even impossible to use the classic editor. Sure WPB may evolve with the times, but it hasn’t yet.

That said, it could do pretty much everything I needed in a page builder, so I decided not to adopt a different one right away unless I could find one that was at least as good or better.

Did I find one? Elementor, my dear Watson!

WPB in its current form only creates content usable in the class editor. By contrast, Elementor creates content that can be used in the classic editor (through shortcodes) or in Gutenberg (through a Gutenberg block). That means you’re covered almost no matter what happens. In the unlikely event that Gutenberg gets abandoned, you’re covered. If both editors remain available, you’re covered. If Gutenberg becomes the only choice, you’re covered. (Swapping from a page or post with Elementor shortcodes in a classic document to the Gutenberg equivalent would be far faster than the equivalent process of swapping from a WPB document to a Gutenberg one.)

But is Elementor better than WPB in other respects? Both are widely used and will be updated for the foreseeable future. Both are supported by an active community of third-party developers. Both have the basic features you want in a page builder plugin. All of that said, despite being used to WPB, I found Elementor easier to use.

WPB lets you use a backend editor or a frontend one.  In Elementor, you have both experiences at once. There is an editor window on the left (that can be expanded more easily than the one in WPB) and a more or less live preview on the right. There is also a full live preview option available. Neither one is 100% the way the page will actually look because they lack sidebars, but you can get a pretty good idea.

The issues mentioned above are relatively small. I’m more influenced by the subjective reaction that Elementor is easier to use. It feels more modern and faster. Considering how long I’ve used WPB, it’s interesting that Elementor would feel faster right out of the box. Of course, others might react differently.

Undeniably, Elementor is smoother in the way it allows individual pieces of content to be saved as templates that can be inserted into any page. WPB has no comparable ability. (You can format only part of a classic editor document with WPB, but the WPB editor will treat the entire document as if it were created in WPB.) And Elementor, because it can function as a Gutenberg block, can be part of a Gutenberg editor document instead of being the whole thing. You can mix and match if Gutenberg does some things better for your purposes than Elementor does. As mentioned above, WPB doesn’t work with Gutenberg at all.

What about price? WPBakery Page Builder is currently $46 (which includes unlimited updates but only six months of support). Additional support can be purchased for $15.38 when you buy initially and is available for $35.38 later. It also comes bundled with a number of CodeCanyon themes.

Elementor has a free version, so you may want to check and see if that will do the job for you. If not, the pro version is cheaper for the first year than WPB but more expensive in the long run–$49 per year for one site. Of course, that depends upon whether or not you have A WPB support question after your initial term runs out. If you wanted constant support, WPB would actually cost you $70.76 per year. You probably won’t need that, but compatibility problems can arise long after your initial support runs out–I had that very issue. Also Elementor Pro includes features you may or may not need, like the ability to build your own theme, a much larger selection of widgets, a popup builder, a form builder, and a large collection of professionally designed templates. Depending on your specific needs, Elementor Pro could be a good value.

Astra Theme

For many years, I’ve been a fan of BeTheme, like WPB an Envato marketplace  item. It currently sells for $59, has a special offer for an extra six months support with purchase and then $40.63 for every six months of support thereafter. (As with WPB, updates are free for life.)

In many ways, switching themes was a tougher call, and one I almost didn’t make. BeTheme updates regularly–it’s a rare week when that doesn’t happen at least once. That kind of rapid update cycle makes compatibility issues much less likely. It is also extremely flexible, with more menu options than most themes, potentially unlimited different sidebars, and a host of other possible customizations. In several years of using it on two websites, I never had a problem with it.

Why then would I switch? Part of the answer lies in the number of features I wasn’t using. One of BeTheme’s strengths is the large number of prebuilt websites you can use as is or customize. There are now more 450 of them, and the collection grows every month. That’s why BeTheme is sometimes called the world’s largest theme. However, if you’re building your own site, that isn’t going to matter. (One of the prebuilt sites is for a writer, but I didn’t use it.)

One of the features that attracted me originally is that BeTheme was bundled with three premium plugins: Revolution Slider, Layer Slider, and WPBakery Page Builder. For performance reasons, I’m not using sliders anymore, and I have already discussed my reasons for leaving WPB. BeTheme also has its own built-in Muffin Builder. I found it a little less user-friendly than WPB, though in fairness, I think the developers have improved it since. However, like WPB, it doesn’t interact with at all with Gutenberg and is largely an either/or choice with the classic editor. You can use one standard WP section in a Muffin Builder layout, and the Muffin Builder text editor inherits the classic editor’s TinyMCE toolbar, but otherwise MB is basically a replacement for the classic editor, not a complement to it. Elementor again wins for its greater flexibility.

Discounting the advantages BeTheme had that were not relevant to my situation, I looked for a theme that would be at least as good or better. In the end, Astra narrowly edged out BeTheme for the following reasons:

• Lighter weight–the same home page became almost 200K smaller just by switching to Astra.
• Recent–a theme that’s only a little over two years old has a more modern feel than an older theme like BeTheme, even though BeTheme is constantly updated.
• Plays well with any page builder–Elementor compatibility was critical, but Astra was designed with every popular page builder in mind.
• Even more control of site format, most of it built right into the WordPress customizer–in the pro version, the level of exact control is unbelievable.
• No obvious drawbacks.

This last point requires some explanation. The adoption of Astra increased the number of separate plugins I needed. The pro features require a plugin. The ability to create and use multiple sidebars requires a plugin. The portfolio feature (which I don’t use) requires a plugin. An attractive recent posts widget requires a non-Astra plugin. There are other examples of functions that are part of BeTheme’s theme files being relegated to separate plugins in the Astra ecosystem. We’re all trained to think that more plugins equals a slower site. However, in my tests, site speed was not reduced by the adoption of Astra. Number of plugins by itself may not be that useful a metric. What the plugins are doing and how they are coded may be far more important than their sheer number. Anyway, though the change in this area was surprising, it was not in the end a real drawback.

As with Elementor, there is a free version of Astra. You’ll probably want the pro version if you want a wider range of customization options. That version is $59 a year, or $249 for life. Whether or not that’s a good deal relative to BeTheme depends on how much support you’ll need past the first six months and how many websites you’ll be using Astra with. Each BeTheme license covers one website. An Astra Pro license is good for as many as you want to use it on. For most authors, that would be only one, but someone with multiple websites might save big.

When I installed Astra, my website remained functional. I had to redo some features, such as alternative sidebars and footers, and I had to do some customizing with the header to get it looking the way I wanted it, but a little work like that is inevitable with any theme change.

Astra and Elementor worked together as if they were part of the same ecosystem. I did experience a minor issue with fonts. Even with Georgia selected for both, the Elementor output was not coming out in Georgia. I solved that problem by setting up Elementor to inherit the theme font choices, and now everything matches perfectly.

Thanks to the plugin and theme choices I’ve mentioned, I’m now less worried about the block editor. Even if it stays as it is, I’m confident I can make it work for me.

(The featured image was copyrighted by Rawpixel.com and licensed from www.shutterstock.com)