HEALTHY WORDPRESS

It’s a CMS!

First of all, WordPress is a CMS.
In this context, it’s capable of doing everything a CMS needs to be able of.
And if done right, it can be a reliable, easy-to-use, and powerful system.

WordPress – due to its huge ecosystem with all the marketing-bloated plugins and themes – tends to quickly get messy, slow, and hard to maintain. We have seen too many such WordPress Systems. Things get worse when you start to use WordPress as – let’s say as shopping system. Then you will soon start to install plugins supporting other plugins. Chaos guaranteed!

Let us try to break down what we mean by ‘healthy WordPress’ to the following:

• 1. easy-to-use: a graspable set of options
• 2. No Page-Builders – stick with standards and prevent lock-in effects
• 3 use fewer plugins
• 4. keep the system secure with auto-updates
• 5. Stay GDPR-safe
• 6. do not use meta-fields for layout

1. Easy-To-Use: A graspable set of options

Multi-Purpose Themes and Plugins tend to have just too many options. One simple example of this is the implementation of Right-To-Left text flowing, which is a very rare case, at least in the Western world. When you start using a plugin to provide some basic features you will end up with a slow and messy WordPress.

This is also the case with the newer “Add 30 new amazing blocks” – kind of plugins. Many things they offer will never be used and only will add complexity and ballast to your system.

I’ve seen WordPress Systems, even such made by professional agencies – which are such a mess and complicated as hell to update and maintain. Even experienced editors have difficulties finding an option somewhere hidden in a 3rd-level-tab.

Often also paid plugins or such with a “premium” or “pro” plan
are just overloaded with options (even for very rare use cases) and this leads to confusion and endless clicking and scrolling through an endless list of options.

In many cases, the subscription to a single WordPress hook that triggers a function call and makes use of some data – let’s say from the wp_options table is enough.

Even if this is not always simple, we can help to reduce the complexity of your backend.

2. No Page-Builders – stick with standards and prevent lock-in effects

Some page-builders (like elementor or similar) offer a great range of layout options and features. But there is one thing why I never would use them. It’s a very strong vendor lock-in effect. Having page-builders in mind – that means that you are forced to use this proprietary software forever since your content can not be displayed properly without that peace of software.
By the way: It’s the same thing with Page-Building-Services (like webflow.com or similar).

Gutenberg has a lock-in effect too. But here we are in a safe(r) area since the Gutenberg-standard post-content format will probably be not a marginal one, given that WordPress runs around 30% of all websites.

There is a strong desire to fight lock-in, which is not new but is pervasive in a world of proprietary software and software-as-a-service.

https://lamda.blog/2018/04/22/the-language-of-gutenberg/

Without being able to give a complete assessment on this – the way Gutenberg saves its data seems to be well-thought-out (see this, this, or this).

When you stick with the official WordPress standards, your system stays healthy, portable, open, and free.

3. Use Fewer Plugins

Since we are very aware of what WordPress offers out of the box and what not, we can decide quickly when a plugin is required or not. In many cases, a single WordPress hook triggering a function that makes use of some data from the wp_options table is enough.

With Gutenberg at hand, you can now build template parts and compose the elements without using postmeta table for any layout properties at all.

Larslo’s WordPress Systems usually come with a master-must-use-plugin which defines all the necessary building blocks of a typical WordPress backend, like:

• Content-Types
• Meta-Boxes
• Shortcodes
• Admin-Settings (Columns in listings, option pages, etc)
• Endpoints for Rest-API-Calls
• Taxonomy Definitions

That way we keep the number of plugins in use very small.
By implementing our own plugins for we can ensure that plugins just do what they are made for.

4. Security through auto-updates

Since WordPress is running around 1/3 of all websites it is attractive to hackers and SEO-Spammers. As ZDnet states:

Sucuri experts blamed most of the hacks on vulnerabilities in plugins and themes, misconfiguration issues, and a lack of maintenance by webmasters, who often forgot to update their CMS, themes, and plugins.

Most of the time, poorly coded plugins (there are many in the WordPress ecosystem) are prone to hackers.

Our WordPress systems are set up so that:

• the core is updating itself (minor and security updates)
• the few and reliable plugins in use also get updated automatically
• a security plugin (succuri, wordfence) monitors file integrity, login attempts, and post updates.
• the theme in use is not public. So there is less attacking space here.

 In fact, according to data from WPScan, approximately 97% of vulnerabilities in their database are plugins and themes and only 4% are core software.

Jamie Juviler at HubSPOT

5. Stay GDPR – safe

Many WordPress sites out there still include many third-party services, even for such simple things as a Google Font.
larslo’s systems don’t do that. As long as possible we try to serve everything from one web host.
We prefer to ask for user consent just before consent is required. For example, A page with an embedded youtube video asks the user for its consent to load that video (and transmit her data to youtube) exactly where the video is supposed to be shown.

This way we can dismiss (except the tracking cookies) the annoying general cookie-consent banner you see everywhere nowadays. For portfolio sites, business or institutional websites, so to say not advertisement-driven sites, we guess this is the best solution.

6. Themes should not use meta fields for layout reasons

Besides PageBuilders there is another way to build more advanced page layouts with Worpdress. Plugins like Advanced Custom Fields (ACF) make heavy usage of custom or meta fields.

The more content you add to a site, the more entries you get in wp_postmeta database table. So wp_postmeta gets huge quickly, given that multiple entries are made for a single post. And this is often the reason for performance issues.

With Gutenberg, we can reduce the number of meta-fields, since all layout is backed into the post_content main field (and handled by the quick parser (see above).

So when you start using postmeta data for layout reasons, or even worse implement something like “repeatable groups” inside ACF, sooner or later you will get into trouble (or have to implement a complicated and costly caching mechanism). Some good background info about that is found here.

One more thing about that: Meta Fields have no Revision Mechanism built in. So when you want to roll back such a page to a former version you are lost.