DEV Community: Tim Nash

Five languages for WordPress Developers to learn in 2020

Tim Nash — Fri, 28 Feb 2020 14:08:00 +0000

This post was originally posted on TimNash.co.uk on 16th Jan 2020. Hi, I'm Tim, tend to talk about WordPress and Security on my site, I hope you enjoy this repost.

Folks often ask me questions, and recently there has been a little bit of interest in the fact that while I work in the WordPress space I’m not a traditional “WordPress Developer” and I don’t tend to work day to day with WordPress.

For those who don’t know me, my day to day programming is that of a backend and security engineer supporting WordPress developers and site owners. I work on infrastructure projects so I’m as likely to be playing with Linux kernels as WordPress code. This means I need a broad range of language familiarity and extensive knowledge of how to use Google.

However, if you are a WordPress Developer and you are looking for more backend languages to maybe play with then I present to you my choice of 5 languages you might consider focusing on in 2020.

Even if you have no real interest in other languages or learning a new language they have projects that are interesting and it’s worth at least understanding what some of the pros and cons of languages are.

Deep dive into PHP 7

Might seem an odd choice as someone thinking of themselves as a WordPress Developer probably knows PHP and its true. However with WordPress backwards compatibility has meant a great deal of stability that has made it the choice of 33% of the web it has also meant it’s codebase has stayed largely the same over the last few years. PHP has not, a once derided language is probably one of the most mature, community-orientated languages its development and growth along with careful (though some might disagree) cherry-picking features of other languages means the modern PHP developer has access to a language capable of a lot. It also provides an excellent gateway language for other languages in part because it is something of a hybrid language with features and broad concepts from other languages.

Pros

One of the best package managers in the form of Composer
Ubiquitous, getting up and running with PHP7.4 is easy and quick
As a WordPress developer you know PHP it’s about taking advantage of it’s features

Cons

Slower than many other languages, though massive improvements in PHP7+
Tutorials often written for older versions
Ubiquitous means much more variable packages

How do I use PHP?

Well outside of WordPress I primarily use the framework Laravel and it’s smaller Lumen framework to build API interfaces. While I don’t make extensive work with Laravel I have used it to build Chatbots for Facebook and Slack.

In addition I use CodeCeption as my Integration and acceptance test suite, often even if I’m using other languages.

I still reach for PHP if I’m interacting with the web or WordPress, this is made easier by WP-CLI.

Good Projects to follow

Outside of WordPress, PHP the right way is still considered one of the best resources out there to get going.

For frameworks, I would recommend looking at Laravel and if you are getting started with Laravel the excellent Laracasts is a great resource. Actually it’s a great resource for Javascript, React, Vue and dozens of other things too.

Getting into testing, for WordPress, PHP or any setup where you want acceptance testing, then check out CodeCeption.

And for some cool things, you might not think of PHP for such as ReactPHP for event-driven programming or Bref to run PHP on AWS Lambdas.

There are so many good projects, tools and libraries take a look through Awesome PHP I suspect you will be surprised just what you can do.

Best way for WordPress Developer to get started.

Carry on with your day to day jobs, but maybe start to look at Composer if you haven’t already this will lead you into a lot more modern side of PHP from their maybe consider Laravel my friend Ross has a freeWordPress to Laravel course.

Javascript and NodeJS

Again another but this is a language we already know Tim, and for many WordPress Developers you probably know more Javascript then I do especially if you do front end development. Javascript has come on a long way from making things appear and disappear in a browser. If your experience with Javascript is JQuery then you are in for a shock. As a backend developer, Javascript has become a backend language through NodeJS and while we can argue all day as to should it have it exists. Because NodeJS crosses the lines between frontend and backend through package managers like NPM it has built a very isolationist eco-system. If you are going to build and supporting frontend developers or building real-time services then Javascript is important to learn and understand as well as its eco-system. Also, Javascript or rather Ecmascript (complex eco-system remember) turns up in very unexpected places, for example, you can use Nginxscript inside Nginx config files.

Javascript also provides a good starting opportunity for desktop applications in the form Electron. Which powers tools like Atom, Slack and many other desktop applications.

Pros

Large eco-system
Existing Familiarity
Built in out of the box support for things like Async

Cons

Package management is a mess, meet NPM and cry
Packages even more variable then PHP developers
Javascript is a frontend language being shoehorned into doing something else

How do I use Javascript

I will be honest I’m not the greatest Javascript fan and while I maintain NodeJS instances it’s mainly to be able to use web projects that rely on webpack, grunt or another builder that could have been make.

However I have recently gotten into working with Electron to build Desktop Applications and started building more web interfaces using React, which also works well with Electron.

I also started to use Nginxscript where Lua is not available within Nginx for example when not using OpenResty.

Good Projects to follow

Coming from WordPress a bunch of Libraries are in use within WordPress but the new and interesting one probably is React if you are put of by Facebook there is also Preact which is a lightweight alternative. For mobile development, there is also React Native project.

Normally when discussing React, Vue.js is referenced as a great alternative and is especially popular amongst the Laravel community. For a totally different style of Framework consider looking at Svelte.

Not touched on in the above description of Javascript but Typescript compiled to Javascript but bring typed support as well as some extras. If you working with Typescript and looking for a build tool then check out Fusebox.

Finally going for Desktop Apps then the defacto project is Electron alternatives do exist within the Javscript eco-system to a certain extent React Native but also things like NW.JS.

There are so many good projects, tools and libraries take a look through Awesome Javascript & Awesome NodeJS I suspect you will be surprised just what you can do.

Getting started for WordPress Developers.

Again keep doing what you are doing, but Gutenberg block development will lead you down some interesting paths and probably will take you into React in the end. While it is possible to write vanilla javascript blocks the reality is so much of the tooling is for React. Joining and getting involved in front end development tasks will paradoxically provide the quickest route into backend Javascript as so much of frontend development relies on NodeJS for build steps.

Python a glue language for all your needs

If your only real experience with development in PHP/JS, Python is going to drive you mad… initially. However, once you get over it’s weird (to you) syntax and you stop putting semicolons everywhere you will realise Python is actually pretty quick to pick up. Indeed if I was asked for a language that someone new to computer programming should learn Python would be my language of choice. Python standard library is both good and standard, writing programs in Python rely on far fewer lines of code then comparable to other languages and hopefully without the need to rely on too many external libraries. If you are a WordPress developer reaching for a language for the web reach for PHP, not Python, PHP7 is going to be faster.

So why is Python on this list? Well once you step back from the web having a general-purpose language that allows you to develop small applications with rapid development is going to be on your list and while it’s possible to build similar applications in PHP to what you can do in Python you will find that Python development will be quicker and have more library support for non-web based tasks. If you start getting interests in things like Machine Learning then Python is the default tool for many.

Pros

Deep system integrations and large standard library.
Simple to learn and clean code
Defacto choice in many industries
Lot’s of applications you have heard of and use depend on Python for example Fail2ban is written in Python.

Cons

Slow
Un-training your brain to put semicolons everywhere is not as easy as you think, and whitespace suddenly becomes important.
Eco system is fragmented between versions and compatibility between versions is complex.

How I use Python?

At 34SP.com most of our codebase is Python so a lot of my day to day work is working with Python. Outside of work I use Python for most of my basic scripting needs, replacing a lot of the bash/PHP scripts of old. It is now the tool I start with not end up with for such scripts.

In addition, I have been working on some machine learning projects that heavily rely on Python and my houses home automation is managed via Home Assistant which is based on Python.

Good Projects to follow

A good starting points for diving into Python and what it can do is PyVideo a sort of WordPress.tv for Python and Python Programming community portal.

How to use Python to expose Politicians from PyCon UK 2019

For web development, almost the defacto choice in Python is Django a web framework similar to PHP frameworks like CakePHP.

If you have an interest in home automation, check out Home Assistant (which I use at home) and for game development Python has quite a few libraries including RenPy for a sort of choose your own adventure style games and Pygame for more general game programming.

For Machine Learning possibly the biggest name you might have heard of is Tensorflow or Pytorch but Python is used extensively and in emerging fields for good or ill including DeepFakes.

There are so many tools, libraries and frameworks for Python that I suggest just diving through the Awesome Python list to get a feel.

Getting started for WordPress Developers

Unlike Javascript and PHP there isn’t an obvious path to Python in your normal day to day jobs, probably the most likely place to encounter python is a side project (such as home automation) or a supporting project to your work like Fail2ban. If you work with shell scripts, then this perhaps provides a better route and consider your next shell script should it be a python script?

Rust, for those who were terrified of C++

Up to now, we have been talking about Dynamic scripting languages, that you will be familiar with and are quite similar in philosophy and features. Python vs PHP is almost a matter of personal preference in terms of what they can do. Rust, on the other hand, is a compiled language. So whereas with PHP we might do something like:

Php my-file.php to run a file or python my-file.py and it will run the program and include assorted files rust code needs to be compiled and the result is a binary application.

So Rust is more like C or C++, Rust is a fully-fledged language, you can build Kernel modules, complex games and anything you could do with C++. You can build PHP Extensions, and generate libraries which are binaries that can be called by other languages. On the Web, it can be compiled to Web Assembly.

And for PHP Developers good news it has curly brackets… Bad news that’s almost exactly where the similarity ends.

Rust is both a static and strongly typed language, meaning that before you use a variable it types must be declared and variables are tried to that data type. Both PHP and Python are dynamic typed and while there are options to enforce typed properties in PHP7.4 this is wishy-washy.

Pros

It’s fast, I mean really fast
It’s portable, while Binaries need to be compiled to given architecture the result is a binary application
It can do work with true low level aspects of OS, including things like eBPF

Cons

It needs to be compiled
It’s not as quick to get started and developing
Huge learning curve if coming from Dynamic Languages

How I use Rust

To give a little bit of the difference I rebuilt a PHP based tool to hash and compare password strings, to check for weak passwords based on an already salted password set. The initial application took several minutes to process through 100k passwords. The version written in Rust took several seconds and that was in part because of a logic bug. The ultimate performance difference with logic fixed over the original was nearly a 1000x faster.

I have also recently been working on a couple of PHP Extensions written in Rust, to allow a PHP application to make use of Rust performance under the hood.

I have also been building a couple of libraries for an Electron app, that once again moves heavy performance tasks to a binary and away from Electron.

Good Projects to Follow

Rust main package manager is Cargo while Rust development without cargo is possible it acts as a build tool as well as package manager making it a semi-critical piece. Individual packages are called Crates. For getting started Tensor Programming have an introduction to Rust series.

Being a competitor to C++ the breath of Rust projects is well everything from Embedded systems to Interacting with just about every language through FFI.

On the web, Rust can be the webserver to full frameworks with things like Rocket and building dynamic modules for Nginx with Nginx Rust Bindings.

Of course, you could also write a new Operating System in Rust… but should you?

While Rust is a younger language then any of the others mentioned there are still lots of resources, tools and libraries to be interested in so I suggest diving through Awesome Rustcollection.

How Should a WordPress Developer Start

Like Python the route to Rust is not obvious from WordPress for me the gateway was through the fact I could make PHP extensions that provided the route, I had however had some experience making PHP extensions with C++ so it was not an entirely cold start. A good potential place is isolated PHP programs such as the password tool above, something where performance is important but it’s not reliant on the WordPress stack.

.cls-1{fill:#fff}.cls-2{fill:#2f3a3e}.cls-3{fill:#3ab14a}Asset 1

Bash/Shell Scripting

You might have heard of bash as a shell for a unix the environment you login when you SSH into servers but it’s also a command language like all shells are (Someone going to correct me on that I’m sure). As such Bash can be a powerful tool and pretty much every unix system administrator dabbles with Bash scripts. Bash is a very simple language with none of the fancy features that come with the other languages mentioned, you won’t be doing object oriented, I mean would you?

I have included Bash but this is probably better seen as a more broader learning your shell including scripting and doing the quick jobs. It is the polar opposite of Rust but also the broadest spectrum. Good working knowledge of shell scripting means a good working knowledge of the fundamentals of your operating system.

How I use Bash

For me shell scripting is automation, if I’m repeatedly typing multiple commands, then it’s probably something I should be chaining, and if it goes beyond a one-liner then it should be scripted. I try where possible to think ahead will this need to interact with other things, am I concerned about performance etc. The reality things start as a shell script, when they become to complex they move to a Python script, with grumbling this is what I should have done in the first place. However really while I may grumble and have that mindset there is nothing wrong with using shell scripting for most typical sysadmin tasks and not everything you do needs to be a python script, nor do you have to reach for tools like Ansible.

Examples of some scripts I use every day, Simple stats gathering across multiple servers, checking mail queues, managing WP-CLI tasks, keeping my ZSH shell preferences in sync.

Good Projects to Follow

This list is probably harder than the others, while certainly should check out awesome Bash & Awesome shell and really get into customising terminals. When it comes to cool projects well Bash doesn’t lend itself to fancy stuff, even the how-to learn Bashresource is a hefty tome that feels from the 90s.

A really good resource is Julia Evans Zines which I particularly recommend Linux Debugging tools you’ll love. Julia also regularly posts on twitter, short extracts

file locking pic.twitter.com/tq1VRct5Hk

— 🔎Julia Evans🔍 (@b0rk) January 8, 2020

Some tools you will find really useful when working with Bash JQ for manipulating JSON, FZF for well-finding anything. If you are like me and a typo machine then a combination of auto-complete and Fuck might be wise.

Ultimately bash and shell scripting might not be sexy but it’s a valuable tool to know.

How Should a WordPress Developer Start

If you are finding yourself writing “reports” or processes that run via cron jobs anything like that, these are good opportunities for Shell Scripting, if you have just started using WP-CLI then combine that learning with shell scripting to unlock some powerful options.

Special mentions

Ok so these didn’t make it on the main list but I still think they deserve a mention they are each a powerful language in their own right but have lots of similarities to many of the above mentioned.

Lua

A true scripting language if you have heard of Lua it’s probably in relation to computer game modding? Mods for games like Civ series use Lua. For the WordPress Developer, the reason you might be interested in Lua is because of OpenResty which is an Nginx HTTP server with Lua scripting built-in. This makes OpenResty very flexible and powerful with big companies like the BBC and Cloudflare using it.

Lua is perhaps not a language you go out to learn, rather it’s a language to understand you will come across and it helps to get a little familiar with it. Lua is the ultimate tinker language.

To get a feel how about going through Awesome Lua

Elixir

Is the exception to the rule, when it comes to similarities, Elixir is a language that uses Erlang a different languages virtual machine. It’s a dynamic functional language and its use is mainly when you are working with high levels of concurrency. Elixir is a bit like Ruby on Rails in that it feels like a very different language to Erlang (though rails technically is not its own language just a framework but go with me) it’s built on all the benefits of Erlang or in Rails case Ruby. WordPress and PHP Developers are probably not naturally going to go to Elixir and I have included it here because it challenges a lot of how “we” program as someone who has worked heavily with Erlang in the past Elixir feels like a much-needed way into the eco-system and for that reason alone is worth checking out.

To get a feel how about going through Awesome Elixir

Go

Go is a badly named language managed by Google and wins the runner up award for bad name choices beaten by Hack by Facebook for dumb things to call your language for anyone who wants to Google you. Consequently its often called GoLang, it’s technically not a scripting language and compiles at runtime. Its roots is in C++. It’s statically typed but functional not object-orientated and fast. Not Rust level of fast but runs laps around Python. It’s use case is where performance matters but you want a simpler development time. I really like Go and it’s a solid choice as a second language for PHP developers.

To get a feel how about going through Awesome Go

Summary

So, first off I’m going to head off a few questions I expect/have already been asked.

Where is Ruby/Java/Kotlin/C#/F#/Q/R/Swift/Dart/Scala/Haskell/Crystal/The other Crystal language/Modula2/Delphi/Basic?

Or indeed plenty of other languages, right at the start I said this would be opinionated and based on experience. In 2020 these are languages I’m actively using that I think would suit WordPress Developers one way or another. I would love to have put Erlang on the list (ok so I sort of did sneaky sort of way) and plenty of other languages. Also if you are in certain fields Mobile development for example then Kotlin and Swift might be more appropriate, I have little experience with either.

Why did you choose Rust/Python over Go?

Two people who proofread the article, one said I’m surprised you put Rust instead of Go and the second said I’m surprised to see Python not Go on there. Obviously Go gets the honourable mention. It sits in between the space between Python and Rust but the reason I didn’t pick it for the main article was primarily that Python and Rust do great jobs. If you are looking for a multi-purpose language then Go is a great choice. If you are already using Python there are fewer reasons to move to Go and the same if you using Rust then Go doesn’t make much sense. PHP/Go is a fantastic combination so don’t discount it.

Do you really need to learn more than one language?

You don’t have to but if you’re a WordPress Developer you will end up learning PHP and Javascript. You can for the rest of your career rely on those skills and you have made a good solid choice. Learning a new language adds complexity and often brings new fundamentals if it’s not something you enjoy don’t do it. However, even if you never learn Rust or Python I really do recommend you take a look at some of the examples just to be familiar with what they are. You never know something might just click.

So finally If I had some recommendations for developers based on skill level as to where to head off first I would say:

Junior WordPress developer

If you are a junior WordPress developer maybe just started writing your first plugin then I suggest concentrating on Javascript and Bash/Shell Scripting these two will more then anything push you forward in your career and get you going quickly.

Senior WordPress developer

For more senior folks and those looking to get into the more DevOps side then at least look at how Python/Go works and consider really diving deep into PHP internals and foundations looking out of the WordPress ecosystem.

There will come a point where performance, stability really matter and then I suggest it’s time to look at Rust.

So there you have it, I’m sure some folk are going to tell me I’m wrong, you are of course right because this was my list and recommendations which are based mainly and totally biased on my own journey.

I would love to hear your journeys through in the comments below.

Illustrations used in the article by Undraw

Source

macOS restarting/logging out when screen locked

Tim Nash — Thu, 27 Feb 2020 14:11:05 +0000

I’ve noticed for a while now, and I mean a long time (as in this affects both macOS Catalina and Mohave ), that if I locked my screen and went away for any length of time that I would come back to it midway through a restart. Normally iTerm2 had prevented shutdown, but half my applications would be closed. Today I figured I would work out why.

TLDR If you’re looking for a solution you can jump to the fix.

My first assumption – this is related to power settings, involved with Sleep/Hibernation. My working theory that the machine tries to sleep while locked and this upsets it, so my first thought was to confirm those settings.

pmset -g

This lists the system-wide power settings if ran in a terminal as an administrator (it doesn’t need root privileges). I was sort-of expecting autopoweroff to be set to 1 but nope, in this case that doesn’t seem to be the case. So it seems my settings are correct and nothing obvious looks like it will cause a power-off or restart while locked.

Maybe the issue, therefore, is an issue with the machine. While restarting, it’s not shown the typical Kernel panic style messages, and the reboot has been quick, but after some googling found George Garside blog which has a handy one-liner for looking at your logs for what the last shutdown cause was and more importantly what the error code are.

log show --predicate 'eventMessage contains "Previous shutdown cause"' --last 24h

A few interesting things to note from the image, number 1 the timestamps are off by a couple of hours. The second that the shutdown cause was 5… Which is, it was correctly shutdown.

We shall skip over states 1, 2 & 4 and simply take the good news the machine is not crashing, it’s doing this on purpose. So something is sending /sbin/shutdown command. Yet the timestamp is bothering me; what if it’s not trying to shut down at all?

Sleep
Lock Screen
Log Out
Shutdown/Restart

Both Sleep and Lock screen leave the user’s apps and space intact while Log Out and shutdown close apps. I had made the assumption the machine was trying to shutdown and restart; what if it was just logging out?

Working out how to identify in the logs when a Log Out occurred was a little bit of trial and error, but eventually settled on searching for sessionlogoutd within messages.

log show --predicate 'eventMessage contains "sessionlogoutd"' --last 6h

Now that is the right timestamp, so the machine isn’t doing a full reboot, rather it’s logging my user out.

This also now totally smells like macOS itself not an application doing this, it seems far less likely an application would attempt to log out the user than restart it, so it’s looking more like there is something in macOS forcing a log out.

How to fix macOS automatically logging out

Once you know the problem, googling the answer is easy and it quickly becomes clear that you are not the first to have this issue.

But to summarise, macOS added a setting which logs you out even when the screen is locked as it is still counting this as inactivity. Applications like iTerm often prevent this and it tends to look like the machine is constantly restarting.

To fix you need to have administrator access then:

System Preferences -> Security and Privacy (unlock via padlock) -> Advanced

Then untick the Log Out after, checkbox, followed by OK.

It would appear this feature appeared in High Sierra, so now I have to wonder how long have I been putting up with it?

Anyway, mystery solved, and I learnt a few bits about macOS system logs along the way.

Source

Making TimNash.co.uk – Part 2, The developer strikes back

Tim Nash — Thu, 20 Feb 2020 12:00:00 +0000

In part 1 of my “how did I make this site” series, which, in case you are using an RSS reader or are on a site that scraped mine, is https://timnash.co.uk, I went through my choice to focus on a writing experience of the site being a developer playground. The article focused on my choice of plugins and theme as well as the idea that I wanted a site that made it easy for me to write.

Those who know me well may well have stared at that article with suspicion; Tim using off-the-shelf components and nothing else, I simply don’t believe it!

So ok, you got me, I couldn’t entirely leave the developer side alone so in this article I’m going to look at the custom side of the site. I do recommend reading Part 1, Making TimNash.co.uk – Plugins and Theme first, if you haven’t done so, we have plenty of time and can wait.

Onwards!

Code Management

Before we get to the custom code let’s roll it back a bit and talk about how I manage the site.

My site sits on Managed WordPress hosting that comes with built-in Git integration. The way we set up Git at 34SP.com Managed Hosting is that the host sets up a Git repository with a master and staging branch. If you push to master it copies the contents to your live site, if you push to staging it copies to your staging site.

So you can set-up the Git repo as an origin, clone it and off you go, or you can add it as a remote and push to it. Both ways work. The big advantage of doing it this way, over adding the “server” as a user to your existing repo, is that the server controls what it will accept in push requests. For example, by default it lints PHP code, it will also run things in your tests folder, allowing you to specify tests for deployment. If things fail, then it rejects the push and lets you know directly in the Git client feedback.

There is nothing wrong with just using this Git repo, and for lots of projects this is what I do, however for my own site I also keep my custom code within a separate Git repository on CodebaseHQ.

CodebaseHQ

CodebaseHQ is a code hosting service similar to GitHub/GitLab/BitBucket. Built by aTech media I have used Codebase on and off for over 10 years as my code storage solution alongside other aTech products.

There are many reasons to use Codebase over the larger competitors. It has some fantastic features, some of which the bigger companies have never replicated, but the main reason is they are a local UK company and, unless they are going to DM me, have literally no evil clients.

A few reasons you might want to check them out:

Really good issuing tracking, that effectively allows you to run projects directly from within Codebase
Wiki features in the form of notebooks
Time tracking
Exception and error handling (see below)
Really simple yet flexible API and Webhook system

I sound like a shill for them, but I really do think for a lot of smaller companies they are the ideal choice, especially over GitHub private repositories.

If I was smart I would totally have an affiliate link… I don’t, carry on.

I keep timnash.co.uk in a single project, and I organise most of the site tasks within Codebase. For example, right now I have a pair of Milestones:

Project Speed – A general milestone for exploring and experimenting with speed/performance improvements
V2 2020 Overhaul – A milestone to collect any big-ticket items I’m looking to change in the second half of the year

Outside of these two big milestones I have my general tickets, these are either raised within CodebaseHQ itself or more likely me sending an email.

Whenever a ticket is created it also adds a Todo within Todoist via some horrifying spaghetti code which will never see the light of day. Likewise, if the issue is closed, either through email/the site or through a Git commit, the Todo is removed. In theory, closing the Todo in Todoist should also close the issue but the reality is that’s never worked reliably.

So my usual workflow for a bug I don’t have time to fix immediately is, send an email to Codebase, that generates a ticket and a Todo. Work on ticket, close it and it removes it from the Todo. Prompting to work on the ticket/escalation is all done in Todoist.

Pushing to Multiple origins

Pushing to two places at once in Git turns out to be remarkably, for Git, easy. To get it setup:

Clone your original repo, in my case that’s the 34SP.com one
Add the second as a “git remote” git remote add codebase git@codebasehq.com:/pathtorepo.git
Set the two repo to both listen to origin for push and add git remote set-url –add –push origin git@codebasehq.com/pathtorepo.git git remote set-url –add –push origin git@timnash.co.uk/pathtorepo.git

If you then run a git remote show origin both are now showing and when you push, they both are pushed too.

IMPORTANT – The second repo you add as a remote needs to be blank or matching otherwise this is going to become fun.

It’s worth noting that only “add” and “push” are mirroring so other commands that call origin, for example pull, will still only be occurring from your primary repo, which in my case is the one I cloned from.

This way I can keep my code neatly in two separate repositories. Now I’m aware I have basically broken Git and this only works realistically if one person is working on a project. I also have turned a decentralised system into a centralised system in two places.

One of the bigger issues is making sure they keep in sync, at least for me is testing. The 34SP.com Managed Hosting Git integration provides a way to run tests against your deployed code and rejects the deployment if, for example, it fails a code lint.

This is great and stops code that will kill your site from being deployed, however, it can mean that one of our origin servers has rejected the commit. Normally this isn’t an issue as you just fix and push again and they resync.

I tend to work with 3 branches, the 34SP.com Git integration specifies two branches:

Master & Staging, new commits pushed to the origin on either of these branches will be deployed. So I tend to work on a dev branch and merge into Master or staging depending on what I’m doing.

What goes into the repo?

I have kept saying custom code, I don’t commit any code that is available via the auto-updater system so this is code from wp.org and sources which hook into the WordPress auto-update system.

So my git repo looks like:

wp-content/
plugins/
theme-fiddles
security-headers
my-config.php
composer.json

So there is a composer file in the root of my site but no vendor folder.

Where is the vendor folder…?

Not in Git, I’m not here to start a flamewar but the point of package managers is that they manage your packages. The moment you hunt something in Git, the manager is no longer in control, you are. Which might be ok in certain scenarios, but for me, I would rather let Composer do its thing.

Also that Composer file, it has nothing to do with WordPress…

Well, that’s not exactly true, it’s for handling code that is currently outside of the WordPress plugin/theme eco-system. Specifically, I use Composer to manage a pair of packages I use for environment variables and exception tracking. Both of these need setting up prior to somewhere in the WordPress loading sequence where there is a suitable hook.

Consequently, they are set up in the my-config.php file, which is a file provided on the 34SP.com hosting that is “required” in the non-writable wp-config.php file for additional directives. Normally it’s used for adding things like WP_DEBUG defines or similar, but I use it as an early-stage location to add some code.

So why don’t I put all the plugins and theme into Composer and let Composer manage everything?

It’s a good question, and the simple answer is that would require me to write a package management update system or use a third-party, and the hosting already has a plugin update system that works well.

If you have read my Back to Basics – Updating WordPress Strategies you will hopefully get the impression I am very pro full automation as much as possible, when it comes to keeping things up to date. Therefore one of the criteria for the site is that it should manage itself if I stop looking after it for prolonged periods.

At the moment, all my plugins on the live/staging site auto-update daily. My dev site, my plugins update when I open my IDE Atom and open the project files in addition I have a pre-commit hook in git that runs auto-update and fails the commit if a plugin has been updated allowing me to retest if needs be, or simply commit again.

Yes, in theory, I could do all of this with packagist and wp-packagist and some cron jobs but the current setup has thousands of sites using it, is robust and has decent feedback systems. Why reinvent the wheel?

So what are the two packages?

Keeping things organised with .env

The first package in my Composer is https://github.com/vlucas/phpdotenv though if I was to recommend one I would lean more towards https://github.com/josegonzalez/php-dotenv

This reads in from a .env file a bunch of variables and allows me to quickly insert them wherever I like within my code. Why might I do this?

I have in-effect 3 environments – my local machine, staging and live, each of these at times need different variables. So each has its own .env file. So within the my-config.php file I load in the env at the start

use Dotenv\Dotenv;
$dotenv = Dotenv::createImmutable( __DIR__.'/../');
$dotenv->load();

And then I can use them at any time for calling:

getenv('SECRET');

This means any of my custom code can make use of .env file but I also have a simple mu_plugin that looks at variables called OPTION_* and then applies a pre_option_{$option} filter allowing me to serve any option normally in wp_options table via the env file instead. This allows me to set separate API keys etc on plugins on local/dev/live.

Exception Tracking

The second package is Airbrake. Airbrake is a language-agnostic exception tracking service and open-source standard. The idea, instead of reporting your error or thrown exception to your local logs, you throw it to an exception tracking service. There are lots of these services, and most have their own API for handling data sent to them. Airbrake opened up their API and this means multiple services can act as Airbrake endpoints including Codeception.

What does this mean? Well with Airbrake setup and configured on the server and Codebase, whenever my site throws an exception or triggers a warning/fatal error, it sends an HTTP notification to Codeception which generates an exception report. This contains a stack trace and other useful information. It then groups them together so if you have the same error over and over it just includes them in the same report.

This means you can go into Codeception and into Exceptions tab, see all the errors, raise tickets and notes and ultimately close/delete them directly from the interface.

To get it going I just install the ‘phpbrake’ package from Airbrake then:

/*
 * Setup Airbrake for exception tracking to Codebase
 */
if(getenv('AIRBRAKE_ID')){
// Create new Notifier instance, pointing to Codebase
$notifier = new Airbrake\Notifier(array(
    'projectId' => getenv('AIRBRAKE_ID'),
    'projectKey' => getenv('AIRBRAKE_KEY'),
    'host' => 'https://exceptions.codebasehq.com'
  )
);
// Set global notifier instance.
Airbrake\Instance::set($notifier);

// Register error and exception handlers.
$handler = new Airbrake\ErrorHandler($notifier);
$handler->register();
}

Within the my-config.php file.

That’s it, I can now explicitly throw an exception and it will appear, or any errors will show up, naturally. This makes debugging quicker and easier and because of notifications in CodebaseHQ I get notified about errors quickly, not when I happen to look in my PHP error log.

Custom Plugins

I have a few custom plugins and mu-plugins. I have already talked about my options_to_env plugin above. In addition, the two of most interest to people will be my security headers and theme_fiddles plugin, and both will disappoint.

I really try to keep things small and single-purpose. Indeed the entire code in my tn-security-headers plugin is:

function tn_security_headers() {
    header( 'strict-transport-security: max-age=31536000; includeSubDomains; preload' );
    header( 'X-Frame-Options: SAMEORIGIN' );
    header( 'X-Xss-Protection: 1; mode=block' );
    header( 'X-Content-Type-Options: nosniff' );
    header( 'Referrer-Policy: strict-origin-when-cross-origin' );
}
add_action( 'send_headers', 'tn_security_headers' );

Likewise, my tn-theme-fiddles is similarly lightweight:

remove_action( 'wp_head', 'wp_generator' );
remove_action( 'wp_head', 'wlwmanifest_link' );
remove_action( 'wp_head', 'rsd_link' );
remove_action( 'wp_head', 'wp_shortlink_wp_head' );
remove_action( 'wp_head', 'adjacent_posts_rel_link_wp_head', 10 );
add_filter( 'the_generator', '__return_false' );
remove_action( 'wp_head', 'print_emoji_detection_script', 7 );
remove_action( 'wp_print_styles', 'print_emoji_styles' );
remove_action( 'wp_head', 'rest_output_link_wp_head' );
remove_action( 'wp_head', 'wp_resource_hints', 2 );
add_filter( 'the_seo_framework_indicator', '__return_false', 10 );
        //Make sure all images come from cdn
        add_filter(
            'wp_calculate_image_srcset',
            function( $sources ) {
                $return = array();
                foreach ( $sources as $source ) {
                    $source['url'] = str_replace( 'https://timnash.co.uk/', 'https://cdn.timnash.co.uk/', $source['url'] );
                    $return[] = $source;
                }
                return $return;
            }
        );
add_action(
        'wp_head',
        function() {
            ob_start(
                function( $o ) {
                    return preg_replace( '/^\n?<!--.*?[S]tream.*?-->\n?$/mi', '', $o );
                }
            );
        },
        ~PHP_INT_MAX
    );

The security header just applies header on every page. Really this could be done with Nginx, but at one point some headers changed depending on page, it has been simplified over time.

The theme fiddles is very much the “functions.php” file of the site but in plugin form, so I can keep some control over it. It’s mostly removing things in the head I am uninterested in, though it does include a fix (for posts using classic editor block) where the ‘subscr’ would point to the wrong URL.

That’s it, how dull and boring, but that’s the point I’m trying to be dull and boring just a few very small custom plugins and everything else using existing plugins was the goal. Many of the plugins I use I could make myself, especially if I’m looking for total performance and sacrifice settings pages for configs etc.

Other code that is running?

Backups

The hosting takes backups daily in the morning just after any updates are done and stores them for 28 days. I also use a free service called CodeGuard that backs up all the code on the site daily as well, excluding .env file and the wp/ folder itself as I don’t manage that, the hosting does.

In addition, I have a small script that logs on and runs ‘wp db export’ and stores it on my home NAS. When I start developing locally (by opening the project in Atom and on my home network, or connected to the VPN) it will grab the latest backup and apply it to my local environment. This way I am always testing my backup.

So my backups are:

The hosts own daily backup
All custom code is in 2 repos
I back up the code to CodeGuard
I back up the MySQL DB to a local NAS as well as use it as the basis for local development.

I’m totally not paranoid, and have lost years of posts in the past and had to rely on archive.org to get them back, oh no.

WP-CLI commands

I have a few maintenance commands, that I hold in a package separately and just require them as and when I need them. Mostly these are old test commands, exporting options and a few quick commands for clearing the cache when I need them. These are the dirty bash scripts of the WordPress admin, you wouldn’t share them but they quickly allow you to test things. My test for finding Gutenberg blocks is an example of the sort of script that is in my wp-cli commands folder.

While typing this I realised how unproud I am of this collection so I have raised a ticket in Codebase to clean them out and organise things a little more logically.

So is part 3 return of the writer?

So there you have it in, part 1 we looked at how I was trying to simplify and make sure my over-engineering self wouldn’t dominate my site so I could get on with writing. In this 2nd part, we can see that’s not exactly how it’s gone and I clearly have more work to do.

So what of part 3? This is an ongoing project, after all. Since I wrote part 1 things have changed, plugins have gone, and a new plugin has arrived. But I think I will save things that changed since I started writing these posts to part 4. Instead part 3 will be How I write posts and my Gutenberg workflow!

Want to learn more?

This post is from a series called Making TimNash.co.uk, here is the series so far:

Help others find this post:

This post was written by Me, Tim Nash I write and talk about WordPress, Security & Performance.

If you enjoyed it, please do share it!

Source

Part 1, Making TimNash.co.uk – Plugins and Theme

Tim Nash — Thu, 06 Feb 2020 07:30:00 +0000

This site has gone through so many changes, I have had a personal website for nearly 25 years! While I have talked in the past about choices and how I do certain things the site in the last 6 months has had a major change in philosophy and I would like to talk about that and also the question I get asked all the time, what plugins do you use!

This site around 2018

The last big iteration before this (2018) was all about performance, I did everything I could to load the homepage in under 200ms for all users and threw out aesthetics. The goal of that site was to showcase performance. At the time I wasn’t writing as much and the site was really just a testing playground. Analytics who needs that, it’s a waste of bytes! Markup, styling totally optional.

Do you know what I am still proud of that site, I built the template with my terrible design skills and it worked. It looked horrible but it worked.

Well, when I say worked, I mean from the users point of view, behind the scenes it was a pain. For example hard coding the menu saved on database calls but meant changing a menu involved code changes. This was fine, it’s not like there is a content team, it’s just me but each little barrier meant I was less likely to do something. Everytime I had to hard code something it meant opening up Atom to make the changes, commit the changes, check the changes, push the changes, clear the cache. Then I did the thing, you know the thing you should never do…

I bypassed my own version control, I can’t even remember what it was but something “needed” doing quickly and I just edited it on the live site. I can already hear the tuting, I would tut too because that moment meant everything started to fall apart. But not in a catastrophic way simply enough that it became hard to maintain so I stopped. The site is sitting on 34SP.com Managed WordPress Hosting so the plugins just auto-updated as did WordPress everything was fine but my tinkering stopped and I lost interest.

Back in July I wanted to write up my thoughts on a Steelcon talk, I did with my friend Glenn I had already started to think I should also learn more about Gutenberg so it was time to start afresh and consider the site.

New Site new thoughts

I am not a web developer

I am not a web designer

Tim Nash 2020

There I have said it, I know a lot about both subjects but knowing and doing are two very different principles and my strengths lie more to the backend then the front. I like pretty things but I cannot draw, that doesn’t mean I shouldn’t draw, just that perhaps I shouldn’t try to demonstrate it as a strength unless it’s to demonstrate perseverance.

So step one, delete git repo (backing it up first) but all old assumptions were to be left at the door, this was to be a fresh site with fresh ideas. I still want it to be performant, but as much emphasis to be placed on functionality and to make things as easy for me. So the first starting point was a theme.

There are lots of great themes by hugely talented designers, and the base theme of WordPress today Twenty Twenty is one of my favourite themes right now. However Twentytwenty wasn’t available when I was looking so I did what millions of others do I looked for a theme.

My theme criteria was:

Look good – this is in the eye of the beholder but I wanted a clean minimal theme
Reputable Company/Individual – I’m putting a lot of trust into the theme designer I want to feel confident in updates. While reputation isn’t always a guarantee Hi Pipdig! It’s a good start.
Gutenberg ready – The theme should not just work with Gutenberg but the theme designers are on board and interested in Gutenberg.
Simple code base – I want to be able to follow the code and review things if needed change things.
Do things the WordPress Way – Similar to keeping the codebase simple, I don’t want a theme that implements its own things, this did rule out things based on Roots with blade templating and Twig based themes using timber etc.

I didn’t mind paying for a theme, if it was the right one, after all, I want to know the author is going to be there for potentially years to come and give back to them.

In the end, I chose Neve from Themeisle as theme companies go Themeisle is one of the larger companies and as such have had press good and bad but on balance the press has generally been good. They show a real willingness to not just create products but be part of the wider community. Neve itself is a functional theme, that was easy to customise, didn’t come with anything that put me off and allowed me to build something quickly. It perhaps had a few too many settings and skirted the doing things the WordPress way and Simple codebase requirements both of which were borderline.

My intention was to spin up a child theme, for the inevitable changes I would need to make to templates but the reality is I haven’t needed to yet. Their release cycles have been good and I have been updating the theme regularly and without issue.

Overall I’m pleased with my choice, my theme is not unique but it’s customised enough that it’s mine. Over the last few months, things have been added changed for example, the footer recently made an appearance on most posts.

Plugins Galore!

So a site is the sum of the theme and its plugins and while a few plugins have always been on the site, the amount of plugins I use has changed dramatically escalated however I have been trying to keep to the keep it simple philosophy and choose:

Single Purpose – Smaller plugins with a specific use case
Simple Choices – Simple or no configuration plugins where I don’t have a bunch of configuration changes each time.
Gutenberg Ready – Blocks, not shortcodes where this is important
Simple code base – If the plugin codebase is greater then WordPress core that is an issue.

So here are the plugins I have installed on my site currently, this list does change so might not be as is when you read it.

Security

Most of the security is handled at the host level (By the totally excellent 34PS.com Managed WordPress Hosting… …at least according to their WordPress platform lead. That would be me) so I don’t make use of traditional security plugins however I still have a few plugins that enhance security on the site, all of these I would install on any site by default.

Two-Factor

This is my default 2FA (two-factor authentication) solution. It’s a feature plugin so the goal is it will become part of WordPress core, in the meantime I use it across all sites I manage. It’s simple to install/setup and works with my hardware keys.

Should you use it: Yes, if you have an existing 2FA solution then this might be a “Maybe” but if you do not use Two Factor or a Multi-Factor Authentication on your site, then this is the perfect plugin for you.

Stream

Default logging solution, it logs all user actions and records them in the DB, it also sends me notifications on certain actions, for example, it reports successful logins. There is plenty of auditing and application logging plugins but I like Stream as an activity monitor.

Should you use it: Maybe, You should have a plugin that does application monitoring, I like Stream but others do exist. Try to look for a plugin that doesn’t just hold its information in the database.

Tip: If using Steam, you can set up notifications, one example is I have a notification that emails me every time a new user session is created for my admin user. If someone logs in to that account that’s not me, I get an email.

Application Passwords

Application passwords, allows the generating of special passwords for users, to be used through the REST API/XML-RPC endpoints, I use it to make requests to the REST API for my custom dashboard.

Should you use it: If you need to use the REST API outside of your site, but do not need a comprehensive solution like Oauth then maybe. It also can be useful for legacy applications using XML-RPC

WP Fingerprint

File Integrity Monitor compares file hashes of individual plugin files on my server with those on wordpress.org and also attempts to crowdsource those not hosted on wp.org.

Should you use it: If you are on 34SP.com Managed Hosting it comes preinstalled, there are other plugins that also do file integrity checking, if you already have one then no, otherwise all of its checks are done by crons in the background so it’s worth having on.

Content and presentation

Making things look pretty is perhaps a little beyond my remit, making things look presentable and not so bad as to upset anyone is the goal. Posts and pages should be laid out with the block editor and when introducing new content types my goal is to make it work easily with the site. I also want to make things more finable, while I was heavily involved in SEO a long long time ago, the world has changed so much, so rely on good choices by others.

Gutenberg

While the block editor is now in core Gutenberg project lives on and continues to improve the block editor and site editor projects. With the Gutenberg project, I’m getting access to those improvements in between WordPress core releases. The WordPress core team doesn’t recommend running Gutenberg in production but for my purposes, I’m happy to run it on my live site and so far it’s caused no issues.

Should you use it: I think so, while there is always a chance of breaking changes if you are all in on the block editor, then it makes sense to run with the latest and greatest. Just a word of caution, it does have experimental features, that can wipe settings and replace themes at a click of a button so if you or a client are the just click things type one to avoid.

Atomic Blocks

Atomic Blocks is a collection of blocks, one of the first out there and it extends the blocks that already exist with new features. While I certainly don’t use every block within the library more then one is being used on this page.

Should you use it: Well this very much depends, there are lots of block libraries, so look through the feature list, do those blocks look like the ones you might use. Finding a library which has the most synergy with your use case. If a library only has a single block of use to you may be worth avoiding unless you can’t find a similar block elsewhere. I’m looking forward to the block directory arrival.

Gutenberg blocks and template library by Otter

While this plugin has many similar blocks to Atomic Blocks the main reason to use this alongside Atomic blocks is it brings both CSS transitions and Custom CSS to every block, now Otter (Really ThemeIsle who also make my theme) do provide these as separate plugins and I suspect when the “block directory” comes I will move to these plugins. For now, while it breaks the single-use rule it seems that Themeisle primarily is maintaining this single plugin and not the separate ones.

Should you use this: Pretty much the same comment as Atomic Blocks, if it has the blocks you need. Though this library does come with the additional features in that it adds custom CSS option to any block and CSS animations. If you don’t need any of the blocks and just custom CSS option, maybe worth looking at their Custom CSS plugin instead.

Contact Form Block

My contact page for years just had my email address but after a few folks complained they couldn’t find the contact details I have re-added a contact form. I didn’t want anything fancy or complicated and the contact form block fitted the bill. No data is stored on the server, and integrates with RECAPTCHA.

Should you use this: It’s simple, it’s uncustomisable and has virtually no flexibility but if its fields are the ones you want, and you just want to send an email then this might be the right plugin for you otherwise there are thousands of mail and form plugins out there.

The SEO Framework

When it comes to SEO normal recommendation is Yoast and the SEO Framework comes up as choice number two. I’m not going to bash Yoast many folks there are my friends and I am in awe of the company and how it’s grown. However Yoast SEO plugin isn’t for me and I find it gets in my way, I wanted something a little lighter that focused on just the things I cared about.

Should you use this: Chances are you use Yoast, happy with Yoast? Stick with Yoast. Not happy with Yoast worth looking at. I imagine most of the reasons you don’t like Yoast will be why you don’t like the SEO Framework either though.

Schema & Structured Data for WP & AMP

A very recent install, but most of my posts are exceedingly long and suit the article schema markup. Schema is not about improving search results themselves but improving discoverability and understanding we all need a helping hand even Google. This is a bit of an experiment, historically I have written microformat directly into the template, this way I can play around with things and worse case remove it and wait 6 months for Google to stop being upset.

Should you use this: Want schema markup this is a relatively easy way to add it, there are a few alternatives I haven’t tried them all and went off a recommendation and it’s early days so I will let you know.

Update: Before this post was released, I disabled it due to a PHP Warning being generated that I haven’t had time to look at properly.

Performance

Make things go fast, I’m under no illusions this is the section most people come here for, but I’m going to tell you a secret, most performance is good hosting including a CDN (I use KeyCDN), sensible plugin choice and being considerate of download sizes. However, I do use a few plugins that could be considered “performance” plugins.

Classic Smilies

In part as a security cover-up, WordPress introduced emoji support which came with added markup and javascript. This removes those and returns the original emojis back. I’m not really an emoji sort of person ¯_(ツ)_/¯

Should you use it: Do you like emojis and can’t live without them? Then this plugin is not for you if you don’t care you will save yourself a couple of JS includes. This could easily be done in your own theme tweaks.

EWWW Image Optimizer

I need to look at alternatives, and KeyCDN does a lot of image optimisation tweaks if I let it, but currently, I use EWWW I have configured it to do light changes but it could do a lot more. Images and Media optimisation is one of my big areas of improvements in 2020 for the site, so expect this to change, even if it’s just changed for a bash script.

Should you use it: I personally do not like EWWW, it’s there because it was the thing I knew and it was quick to set up with the limited presets I know work the way I want. I suspect there are much better alternatives and it’s just a matter of me spending the time researching.

Fast Velocity Minify

Concatenates and minified files and stores them in a cache, while HTTP/2 having multiple files is not as much of a performance issue, and indeed in some circumstances, lots of smaller files would be quicker over HTTP/2 there are specific speed improvements. I am significantly underselling it as this plugin does far more then I use it for.

Should you use it: There are dozens of minification and concatenation plugins out there, and over the years my recommendation for which to use has changed. If you are using one and it works then stick with it. Otherwise, Fast Velocity Minify is simple(ish) and works.

Remove Query Strings from static assets

This plugin has been in my toolbox for years, it simply removes the “?version” off static assets, meaning they actually get cached as most things won’t cache something with a query string.

Should you use it: Do you like your assets to be cached? On a production site, I wholeheartedly recommend this plugin. On a development or staging site, you probably don’t want this enabled as you will actually want your assets to not be cached assuming you are making changes to them.

WP Lazy Loading

A fairly new plugin, though again is a feature plugin, and hopefully will be in WordPress core fairly soon. It simply modifies image tags to include the lazyload attribute, browsers that support (aka Chrome) lazy loading will then lazy load the images. Quick and easy performance win, with no complicated javascript.

Should you use it: I don’t believe this brings anything but positives, the only reason not to use it is in a couple of months it will be in core and then it will be superfluous.

WP Stack CDN

Again another tiny plugin that I love, written by Mark Jaquith years ago and I suspect I might be its sole user. Allows me to swap all static asset URLs to be cdn.timnash.co.uk which points at KeyCDN.

Should you use it: No, almost certainly there is a better solution out there sorry Mark, mind you, I’m not sure Mark uses it anymore. Find a better alternative, which has at least some support and possibly even a GUI.

Analytics

For the last few years I haven’t been using any analytics on the site at all and I’m not sure I have missed it too much. Google Analytics was always too much for the site and slowed the previous versions of the site enough that I was proxying the script. I wanted something in between something lightweight, privacy-conscious that gave me some basic metrics, which I could use alongside Google Webmaster Tools.

Koko Analytics

I selected Koko Analytics for a couple of reasons it’s incredibly lightweight in just showing referrer data and pages visited. It can and is set to not track via cookies, all the data stays on the server and not sent to a third party and I can control the data retention. For bonus points it’s really well written, makes use of the REST API so I can also make direct calls to the data and just generally ticks the box across the board. I have only been using it for a short time but I love it. My only fear is that as a young product, Danny the developer is under pressure to add features.

Should you use it: If you are a Google Analytics user, this will be a massive change in philosophy. If however you currently use Jetpack Stats or no analytics at all then Koko is worth looking at, it will outperform Jetpack and comes with huge benefits in privacy.

Others

There are a few miscellaneous plugins that don’t fit into categories that I use, a couple of these are not always active, but are always within reach.

Query Monitor

Query Monitor is one of those plugins that once you use you become addicted to. It provides debugging and performance information at the PHP/Server level for every page on the site, shows scripts loaded, the action performed and loads more. More then once Query Monitor has found that slow running weird bug and its a tool I always have available but not always active.

Should you use it: Yes, yes you should, this should be your go-to plugin the moment you hit a performance bottleneck. It’s so good I put it as my choice for the Plugins we love series on the 34SP.com blog.

Anti-spam

As the same suggests, add a “invisible” captcha to comments pages in the form of an extra field. Simple and effective.

Should you use it: ~~It’s not as effective as a tool like Akismet, but it’s simple adds no overhead and doesn’t send comments to a third party. For most people, this is a good alternative to the default choice.~~

Unfortunately, this plugin has recently been taken over by a new developer, in addition to somewhat obtrusive advertising for a premium version, it looks like the direction they are aiming to go in is more like Akismet with comments, being validated on their servers. So I will be looking for a new option before that happens.

Public Post Preview

This plugin creates a unique link, to allow you to share unpublished content with selected non-logged in users. It’s great for sharing previews with people and getting opinions on content choices.

Should you use: If you share drafts, this is the defacto solution so the answer is probably and when not in use you can always deactivate.

Wappu Dashboard Pet

A plugin made by my colleague Kayleigh Wappu Dashboard pet adds a Wappu to your dashboard, but if you don’t keep things up to date it gets sick. Thankfully with my site running on Managed Hosting my Wapuu spends most of his time healthy and happy!

Should you use it: I love a cute Wappu and if you are sort of person that will do something just to make a sad Wappu happy this is the plugin for you.

Custom Plugins

I do have a few custom plugins:

Security Headers
Some theme tweaks
Some error tracking

These are little more than one-liners, and I do have a few other tweaks but do you know what I’m going to save till part 2, yes it’s a two-part series, who knew!

The site itself

The site itself is running on 34SP.com Managed WordPress Hosting just the standard £9.95 with no fiddling by me it’s a bog-standard container. If I was good at marketing I would offer you some sort of 3 month discount with a crazy code like TIMNASHWP.

I use KeyCDN to serve static resources. My DNS is managed via DNSMadeEasy and my newsletter is provided by TinyLetter.

I’m still tweaking things and some pages like my talks page are still on the list of updating, but I’m happier with the site then I have been for years. The big difference baring the occasional grumble as Gutenberg inevitably doesn’t do the thing I want I’m enjoying writing again.

Yet having a more normal site, comes with other issues, even writing this post I was reviewing plugins and for example, discovered Anti-spam had been taken over and heading in a direction I wouldn’t want. By using more plugins I’m giving up a certain amount of control and the time saved up front doesn’t mean its time saved overall.

My site is a tool and repository, it’s enabling me to do things and that’s great, that’s the way it should be. I’m happy and capable to invest the time, now it’s in smaller manageable chunks.

Do I care about performance? Sure I do, my front page has increased from 200ms load times to around 400ms. That’s 100% increase but still far less than most peoples and I’m ok with that, I’m slowly bringing that time down again as well.

So in part 2 of Making TimNash.co.uk I’m going to look at what custom code is running, how I deploy the site and why composer fans are going to hate me.

Want to learn more?

This post is from a series called Making TimNash.co.uk, here is the series so far:

Help others find this post:

This post was written by Me, Tim Nash I write and talk about WordPress, Security & Performance.

If you enjoyed it, please do share it!

Source

Back to Basics – User Management Strategies

Tim Nash — Wed, 29 Jan 2020 19:29:08 +0000

Sometimes it’s too easy as our hacker sits in her darkened room, waiting… His target was on the site and was typing in characters P…A…S…S…W…O…R…D…1…2…3

Excellent! Now on the actual site, our bad actor logs in – yes – admin password123 and in! The phishing attack worked just as he had imagined and now total access to the WordPress site was hers; what would she do.

With the start of the new decade I thought I would take a look at some of the basics of WordPress security that we often take for granted and consider how in 2020 we can achieve a minimum level of security that aims to remove 99% of automated attacks.

This article is less a “how to”, rather a look at user management strategies for agencies and sites. With the right strategy in place you can rest assured your users only have access to things they need and are keeping their and your secrets safe.

User Management

What is a user?

For the purposes of this article a WordPress user is someone who has a row in the WordPress users table in the database. As such a WP_User object can be generated and they have a set of capabilities within WordPress core. That might sound a bit technical, but this means a user is someone who under normal circumstances can access and login to wp-admin and perform some sort of action.

A user normally has a login username, a password, and email address. In addition they might have one or more roles. They have additional profile information which is stored in the usermeta table.

Users probably represent squishy humans in the system, most WordPress users will be active through the WordPress admin areas, though not always.

So with users defined, let’s look at how we stop them running amok and changing everything.

Understanding WordPress Roles and Capabilities

WordPress Access Control System is based around “capabilities”. A capability is assigned to a user and then that can be tested against, by the code. By default WordPress has a bunch of different capabilities from editing plugins to publishing posts. Most actions within the WordPress Dashboard have a capability check making sure you are allowed to take the action you are doing.

Capabilities can also be added by plugins, so for example if a plugin has a shop interface then the plugin can define a capability view_orders and then test against that capability when viewing the orders page; only a person with that capability can see the page.

It’s important to understand, if a plugin or feature is not checking for the capability then it’s capable of being run by anyone; a lot of poorly coded plugins assume because you have access to the admin area you must be an admin.

Every user has dozens of capabilities. So why do people not see all these “capabilities”? Well to simplify everything WordPress has “Roles”, roles are just a collection of capabilities collected together. When a role is applied to a user, that user gains the capabilities associated with the role.

By default WordPress comes with the following roles:

Subscriber
Contributor
Author
Editor
Administrator
SuperAdmin

While these progressively gain more capabilities, they do not build on top of each other so it’s not a case that the editor role is the author role + extra capabilities, even though it does have the author role default capabilities plus additional ones.

Additional roles can be added and removed, and even the default roles can be removed, though admin and superadmin have specific checks that they return when WordPress gets updated.

Speaking of superadmin, it’s the role you are least likely to have heard of, of the default WordPress roles, as it only appears when the site is defined as a Multisite. Users with the superadmin role have the ability to access and manage the network aspects of multi sites.

So, a role is simply a holding bag of capabilities which can be applied to a user. Individual users can still have additional capabilities added or removed on a per user basis. Also, while the default UI only shows one role per user, a user can in fact have multiple roles.

To summarise

A user can have any capabilities and multiple roles, but those roles might not reflect the capabilities the user actually possesses. If you run a WooCommerce site or a large membership site, or just have lots of subscribers, you might have just nervously twitched.

The good news, we have a list of roles, we know the capabilities they should be giving to a user and therefore auditing users is as simple as looking at their capabilities and comparing.

Of course if I really wanted to hide a user’s capabilities rather than then modifying the actual user, you would use the

function innocent_function($allcaps, $cap = false, $args = false)
{
    $allcaps['edit_posts'] = true;
    return $allcaps;
}
add_filter('user_has_cap', 'innocent_function');
user_can(3, 'edit_posts');

user_has_cap filter, to simply return “the user has those capabilities”. So we need:

To list all our users and what capabilities they have, along with what roles they should have
To compare it to the capabilities a role should have
As well as making sure within our codebase nothing is filtering the user_has_cap filter.

Up to this point we have been making an assumption that actually people are using different roles so while auditing your users’ capabilities is a useful exercise and one to do for the basics, we need to:

Check “should that user exist”?
What role should they be?

Should the user exist

Philosophical issues aside, in this case we are concerned solely with “should the user exist” within the context of your website.

A few questions to ask yourself when evaluating the need for this user

Are they still employed by/work for or with us? Sounds like such a simple question, but you will be amazed how many companies have an onboarding policy including giving site credentials but don’t have a leaving policy that removes them. It’s also not just your company but those third party agencies; do you still work with that SEO agency? What about the web designer?
When was the last time they logged in? So there are some people who on paper should maybe have access but when was the last time they actually logged in? Setting a period at which if you haven’t been logged in over the last 6 months we remove/deactivate/contact your line manager probably makes sense. This review should be for everyone.
Does the role need a user? I mean does everyone in the company need a login to the site? Did you once upon a time have a grand plan where everyone in the company would blog? Yeah, you and every company, the reality is very few folks actually need a login or interact with the site. Even if they DO write blog posts, do they edit and publish them, or is that handled by someone else? If all they are doing is login, hitting Add New and copy and pasting from a Google Doc, do they need a login? Worse, are you giving them a login just to provide an author bio? If so, good news; there are plugins for this https://wordpress.org/plugins/guest-author/ https://wordpress.org/plugins/molongui-authorship/

In addition, if you run an e-commerce or membership site there is a good chance it creates users. Have they bought anything in a while? Could you set a policy if you don’t login every x months we remove your account? Especially for membership sites, you might very much want to remove expired accounts after a given period.

What role should they be?

So having decided the user should exist (how kind of you). Now you need to determine what level of access they need. In most websites there is one “default” user, and that is administrator. Sure the other roles exist, but most companies just make everyone an administrator and that’s it.

Needless to say almost no one needs to be an administrator day to day.

Let’s take a look at the different roles and their potential use case

Subscriber – This role gives you access to the admin area, to your user profile, the dashboard and any functions/tooling that is checking if someone has access to the backend but not specific capabilities. As a role it’s not meant to be able “to do” anything other than be a profile and access content. It’s often used as a role for members to a site. Other uses might be ex-employees where they don’t want to reassign posts or indeed, an account for Guest Authors, where they can create a profile, and then their post is assigned to them by the editor.

When might you use this role:

This is a horrible role; if you have lots of users in this role you have a massive amount of potential targets and while it feels like a role that can’t do much harm, it’s allowing a user, which you inherently don’t trust, onto the system and gets them at least part of the way to becoming a hostile actor. It also generally has little to no purpose as things like the “guest author” plugins above can easily replace most of its use cases.

Capabilities Assigned from this role:

Read – checked when trying to access the dashboard, user profile

Contributor – This role lets you login, access the posts option to write posts and delete posts that are in draft and owned by that user. Importantly, while they can edit their own posts they cannot edit others nor can they publish a post.

When might you use this role:

It is quite feasible that for most sites contributor is the default role, especially if the site has any sort of editorial process where posts are proofed, SEOified, etc. In a content generating role it doesn’t hugely affect the capabilities of the user and still lets them build things even with block editor. They can use reusable blocks, but they don’t have the ability to create new ones or delete them. One area they cannot access is other post types beyond “posts”, and that includes pages, unless explicitly declared. The biggest potential limitation is the inability to upload files via the media uploader.

Capabilities Assigned from this role:

All from Subscriber
Delete_posts – their own posts but not once published
Edit_posts – their own posts, including creating new posts, but they can’t publish or adjust the state of the post.
read_reusable_blocks – read blocks created from everyone

Author – This role lets you login, access post/pages option to write, delete and publish your posts. You can edit and control your own content; you are not able to edit other people’s content. Within the block editor you can also create, edit and delete reusable blocks. By default authors have access to both pages and posts.

When might you use this role

Like contributor this is quite feasible as the default role, and suitable when the user is going to manage their own editorial content. If they are not the person who will hit publish then contributor is a better choice.

Capabilities Assigned from this role:

All from Contributor & Subscriber
Delete_published_posts – delete posts they are marked as author of
Edit_published_posts – edit posts they are author of, once published
Publish_posts – publish a post
Upload_files – upload content via media library
Create_reusable_blocks – create reusable blocks
Edit_reusable_blocks – edit blocks they have created
delete_reusable_blocks – delete blocks they have created

Editor – This role is the last of the content roles and is the same as the author role, except they can make changes, create, and delete pages that are authored by someone else. They can also change the authorship of a page.

When might you use this role

The day-to-day manager of the site’s content creation and any editorial team probably want this role. While it’s unlikely to be the default role for all users on the site it’s not unfeasible that multiple individuals will have this role. This is the last of the low risk roles. The higher roles all come with a stark escalation of privilege. If a site used to historically just have admins, reducing those users to editors will not change how they use the site too much.

Capabilities Assigned from this role:

All from Author, Contributor, Subscriber
Delete_others_pages – delete any page
Delete_others_posts – delete any post
Edit_others_pages – edit any page
Edit_others_posts – edit post
Manage_categories – add/remove categories
Manage_links – blast from the past, but WordPress used to have links “postesque” type thing that’s no longer a thing, but might be depending how old your site is.
Moderate_comments – see/approve/delete any comment
Unfiltered_html – switch to HTML view, and be able to paste HTML into posts/pages and not have it filtered. By default, authors have limited options, so couldn’t add script tags for example.

Administrator – The admin role gives full access to managing the site, including access to edit settings and plugins on a non-multisite site. This is the “I have everything and can do everything” role! MUHHHHAAAAAA! As such it’s normally the role everyone ends up with. As this gives you access to do everything, including run arbitrary code via the code editor and plugins interface, it’s a high risk role that should be limited. The admin role also is the role that is allowed to create other users.

When might you use this role

You do need an admin (well you don’t but that’s a story for another day) to do all the things that admins are needed for however only people who are charged with maintaining the site should have access.

Capabilities assigned from this role:

All from previous roles discussed
Activate_plugins – activate a plugin from the plugins screen
Edit_dashboard – change the widgets shown on the dashboard
Edit_theme_options – edit theme options in customizer
Export – run the XML export under tools
Import – run the XML import tools NOTE both export/import the tools are now plugins, but the capability is still in WordPress core.
List_users – see all users, and click into their user profiles.
Manage_options – gain access to the WordPress settings page
Promote_users – change the role of a user note while it says promote, its to change a users role.
Remove_users – delete a user
Switch_themes – change the theme
Customize – see the customizer

In addition there are some extra permissions if on/or not on a Multisite

On a Multisite setup:

Delete_site – you can delete the single site, but not the multisite

On a Single site setup:

Update_core – update the WordPress core files
Update_plugins – update Plugins, and their language pack
Update_themes – update Themes, and their language pack
Install_plugins – install a plugin via the upload option and either searching wp.org or uploading the zip
Install_themes – install a theme via the upload option, either through wp.org or uploading the zip
Delete_themes – delete the files from the server
Delete_plugins – delete the files from the server
Edit_plugins – use the code editor to edit plugins
Edit_themes – use the code editor to edit themes
Edit_users – change user profile information for users
Create_users – create a new user with whatever the default role is within the WordPress settings.
Delete_users – delete a user
Setup_network – create a multisite network (if defined in wp-config) – note once done the first time, this is then mapped to superadmins.

SuperAdmin – Only available on a multisite, these admin users have the ability to add/remove sites along with the capabilities of a normal administrator. On a multisite install the admin role is a reduced role and so loses some capabilities which only the superadmins have.

When might you use this role

Well it’s only available for multisite, beyond that the criteria is that of the admin user.

Capabilities assigned from this role:

Create_sites – create a new site in the network
Manage_network – access the network tab
Manage_sites – change site settings in the network tab
Manage_network_users – manage which users can access which site
Manage_network_plugins – set a plugin to be globally active/installed
Manage_network_themes – set themes to be available or indeed installed
Manage_network_options – set sites’ settings that are global
Upgrade_network – access the upgrade network option

Ok, so what roles should you actually use?

For people writing content, the most obvious roles are contributors and authors, however for many the limitations in allowing uploads to contributors means that most sites, while starting with contributors, will end up giving their staff author roles.

For people editing content, then the editor role is the obvious choice, for one-man sites and smaller sites you may end up with the default role being an editor.

People needing admin level access should be restricted. If you are currently working with a site with lots of administrators then a simple test is to reduce everyone’s level to editor, and see who complains. When someone has an issue, ask them what they were doing and see if this task was appropriate. For a few people they will need to have the higher level of access and you might wish to bump them up.

If you have people who write/edit lots of content but also do site maintenance, for example you might be the solo person, then consider having two accounts and using the “fast user agent switching” plugin to move between them. Set one account as an editor and the other as the administrator. Then you login as your editor, and use that unless you have to use the admin account.

Tims Tip : If you do have two accounts, I like to make my administrator account admin colour scheme red, so I recognise this is the admin account and I’m less likely to use it for day to day tasks.

Creating your own roles

Roles are just a name and a collection of capabilities and adding your own is easy either through WP-CLI or with a plugin. Common roles I have set in the past:

Staff Contributor – The same capabilities as contributor but with the capability upload_files. This does significantly increase the danger posed by this role, but as is always the case the risk outweighs convenience. The alternative would be authors and while this role is less about outright security and more editorial workflow it seems a fair tradeoff.

Site Manager – Editors with the create_user capability giving them the ability to add default users, you probably also want them to be able to delete users. I have in the past written custom code that checks custom capabilities to make sure they can only delete /add/promote up to site manager level. I would also consider adding theme_options and customizer access to allow them to edit widget, and menu level content.

Super dooper boss – A standard editor role to give to anyone who complains they should be an admin, who clearly doesn’t need to be, but you can’t risk your job upsetting – aka your boss.

It’s also worth noting plugins add their own roles, for example WooCommerce has:

Customer Role – is the same as the subscriber role with only the read capability.

Shop Manager – has the same permissions as the default editor role in addition to two new capabilities manage_woocommerce and view_woocommerce_reports. It’s worth noting that, at time of writing, while the documentation for WooCommerce says it has the same capabilities as an editor, this role hasn’t been updated for Gutenberg, so a shop manager can’t, for example, use reusable blocks even though an editor or even a contributor can. So when creating your custom roles that replicate WordPress ones be mindful you will need to maintain them.

Other plugins also add their own roles, and some plugins often extend existing ones, again, for example, WooCommerce adds the manage_woocommerce and view_woocomerce_reports capabilities to the admin users.

So, users’ capabilities and roles

Access control is managed via capabilities, and specifically the has_cap function within the WordPress user object. Users gain capabilities by being given a role or by an individual capability being added to their user role. Even if they don’t have the capability of a theme or plugin, they may be able to override such checks for good or ill.

A role is simply a collection of capabilities, users normally have a single role, but that’s just because that’s how it’s set in the WordPress user interface and in reality users can have multiple roles. Indeed plugins like BBPress specifically set multiple roles.

When choosing roles, select the role based on what the user is going to be doing, not what they think they need. Every user thinks they need to be an administrator when rarely they do. Try to give the least amount of privileges.

If needs be, custom roles can be created to suit your setup but remember you must maintain such roles. Because roles are just a collection of capabilities, if a new release of WordPress came out with new capabilities your custom role will not have them.

Consider adding your custom role as a secondary role, so you’re just applying your additional capabilities. The downside to this is currently there is no real UI for this type of style, so would need custom code, or heavy use of WP-CLI.

Audit your users regularly; users that haven’t logged in or who no longer need access should have their accounts removed.

Consider creating second admin accounts, for users who need them, that they can switch into maybe using the “fast user switching” plugin. Try to avoid using the site as an administrator.

Protecting users

Up until now we have concentrated on users as a collective, and looking at how we restrict what they access. Now we are going to harden our users’ accounts to try and prevent those accounts themselves from being compromised.

Passwords

Most people start off life with one password, it’s normally fairly simple, we joke and snigger at password123 but even the most mighty of tech firms probably has a test server setup somewhere with something considered insignificant with that password. Regardless, the password is simple and memorable: a daughters name, favourite football team. Over time the password gets reused, and some sites have requirements, and so the password evolves a capital letter at the start, a number added to the end and pretty quickly we go from Bernard to @Bernard123. Let’s face it somewhere we all still have that password.

Then something happens, a scare, maybe it was a site got compromised or your tech friend came and muttered at you. You started to realise one password was a mistake, you start to add more @Bernard1234 …5 …6. This quickly becomes more complex so you come up with your first cunning system the site name+the year you signed up+if you stood on one leg. It’s foolproof but then you start forgetting things and oh my.

At some point, reset password becomes standard, indeed you might start thinking why have passwords at all, just get them to send me a reset every time.

If that sounds like you, don’t worry you are not alone, but for many of your users they might be part-way through that journey and that’s fine but we need to shortcut them to the end quickly.

With passwords there really are only two sensible approaches that I have come across – passphrases and password managers.

But before looking at either it’s important to understand the rules of a good password and they are:

Make them long
Don’t tell others
Make them unique

The longer your password is, the stronger it is. We have been trained to add capital letters, numbers, special characters and these are helpful but the key to a strong password is making it longer. If we take the following a£Dq2@ vs fqkoafyp – which is stronger? Clearly the first – nope that’s 6 characters vs 8 and even with the extra character sets the 8 character password is going to be harder to crack.

The second rule, “don’t tell others”, can be often misunderstood. Keeping your password secret means don’t print it to your screen, and don’t share your login with someone else. It’s yours, guard it as such.

Make them unique, every site should get its own password, so if it’s compromised your accounts on other sites are not compromised.

WordPress Password Strength meter and changing the password

When you click create new password in your, or another user’s, profile, you are not presented with an empty password field rather a pre-generated random password and a strength indicator (which with the generated password should always be green). You can overwrite this password with a password of your own, or accept it and proceed.

The password strength meter itself is based on the zxcvbn Library originally built by Github and Github blog [https://blogs.dropbox.com/tech/2012/04/zxcvbn-realistic-password-strength-estimation/] has a good explanation of how it works.

I have little to add to it, except to say only accept strong passwords. By default WordPress will allow you to still proceed albeit by making you tick a box with a weak password. So look to enforce password strategies; lots of WordPress security plugins come with some sort of password management features.

Passphrases

A passphrase is 4 or more randomly generated words strung together. The idea is to make a phrase, ultimately, instead of remembering a complex password. You simply need to remember 4 words, which is a lot simpler. If you add in special characters, all the better. Passphrases were popularised by the XKCD comic but have been a pretty standard practice for a while.

Passphrases still need to be unique so each site would need its own 4 random letters and those words should be random, though there are a plethora of generators out there including some WordPress plugins that will generate XKCD style passphrases. Don’t try to pick words yourself as humans are terrible at random.

Password Manager

Once upon a time password managers were frowned upon, these days even the most purist security professional will suggest using password managers. A password manager is simply a tool or service that stores passwords in a vault, which only you can access. The idea being that you generate a long password, which you never have to remember for the site, store it in the vault and when you need to login, you copy it from your password manager (or your password manager auto-fills) and you login.

With a password manager, you need one passphrase to access all your sites. So why were they once upon a time frowned upon? Well a password is something you know, while technically a password manager is something you own. If you have a weak or non existent password protecting your manager or the vault gets compromised then the whole thing breaks down.

What’s more, in the early days password management services had issues with themselves being hacked and I don’t think any major password management service hasn’t had some sort of breach. That’s not to say passwords were compromised, simply they are huge targets. When it comes to password managers pick one you like and run with it, I use BitWarden having used KeePass for many years, but there are plenty of services including 1Password and LastPass; both have good reputations.

Browsers, like Chrome, have also started offering password management services, though be careful that when picking a password manager you can get it on all the devices you are planning on using.

My Own Strategy for password management

I use BitWarden as my password manager and virtually all my passwords are kept in there, with the exception of one or two which are passphrases, specifically my primary email account and the place where a lot of my reset keys go. This means the number of passwords I need to manage is relatively low, just device specific logins, password manager login, SSH passphrase for my primary key, though for other keys I now store them in my password manager and email.

Setting sensible passwords and education

So as an admin you should, at minimum, be using long, unique and secret passwords and ideally be enforcing use of secure passwords across the board.

In the perfect world you would set the minimum character length of WordPress to 12 and make sure all passwords are strong. With plugins this is a few clicks away, however the reality is without an accompanying education programme this is just going to lead to massive negative user feedback resulting in the policy quickly being revoked.

Password management is not about setting the policy, it’s about educating users.

Educating users by leading by example and explaining needs without recriminations. A good option is to check and validate passwords, compare passwords with known password lists and automatically prompt, if the password is found, for it to be changed.

Consider language changes, the very term “password” can be changed to “passphrase”.

Maybe look at introducing company purchased accounts for password managers, this doesn’t mean buy a single account but as part of the onboarding process offer a password manager. Though be flexible, if people already use a password manager, don’t force them to use the company prefered option. Likewise if the company is purchasing password managers, consider how you will offboard people who might have stored non-work passwords in there.

If you make the process simple and reduce the fear aspects, passphrase or password management usage will shoot up. Ultimately leave your special characters, and changing passwords every 6 months, at the door and concentrate on “keep it long, keep it safe, keep it unique”.

Passwordless authentication

Rarely are passwordless systems actually passwordless rather simply relying on someone else’s passwords.

Single Sign On Systems

For larger enterprises and even smaller clients, perhaps using Google Suite for email will already have an authentication system and integrating such a single sign-on will reduce user friction. In such scenarios the site normally hands off the authentication to the sign on system, then if authenticated it passes them back and the user logs in. SSO systems either work by totally replacing the user management, or just providing a way for the “local”, in this case WordPress user, to login in addition to their normal login procedure.

The downside to a SSO is they are normally complex to setup and manage, so outside of enterprise clients where they might already have an LDAP or Active Directory setups, spending the time to build such a system is a pain. Worse, while plenty of services will integrate with your SSO setups, they nearly always do so only in their more expensive enterprise plans, so to make full use of such systems can prove costly.

Magic Links

There are multiple plugins that provide “passwordless” systems all that work on roughly the same principal. The user “logs” in and the system sends them a link to a communication system, normally email but some might send it to Telegram/Slack and the user either clicks the link or enters the code. The system then considers them to be authenticated and you can login. It’s similar to two factor authentication mechanisms but with what would normally be the second factor considered the primary.

The big advantage of Magic Links is they are simpler for the user – no passwords, no needing to remember things – but they break the paradigm of a password being something you know, and rely on your owning and being able to access something, be it Slack/email etc. Also, while unlikely, this method also risks the potential of being intercepted during transit. There are a few examples for WordPress and they all have their benefits and drawbacks and while I have yet to be persuaded that they provide an effective login mechanism they open up conversations we should be having about how to make things seamless.

Biometrics

Biometrics, especially on phones, has seen a popular rise, be it a fingerprint or face scan, and there has been some work to bring these tools to the web. This is a very young industry and tooling is still fairly immature, at least for the web, so in terms of securing my site I would be nervous about such usage. But if you are considering a biometric system I will leave you with this thought, if a site gets hacked, my password is compromised, I change my password; who pays to change my face?

Two-Factor Authentication

In many ways getting people to select good passwords is quite hard even with education, and indeed with “keep it secret” we can only do so much to judge the effectiveness of our education.

Likewise there are lots of social engineering tactics for clients to reveal their passwords, to the point we cannot simply rely on them alone to protect accounts. Enter two-factor authentication, sometimes called multi-factor authentication.

The concepts of multi-factor authentication (and there is a subtle difference between two- and multi- factor authentication) is that you have to pass multiple challenges before being allowed in. One factor is a password, or maybe a thumbprint or face scan, while another might be a code sent to your device. The combination of multiple factors means there is a high probability it is you.

Two-factor authentication normally refers to the very specific paradigm of password and second authentication method, normally a code generated on a device (such as a code generated by the Google Authenticator app) or a physical key.

There are few people who would say don’t use two-factor as standard where available, yet I suspect many people giving that advice might not be implementing it. Indeed I wonder if you, reader, have uttered those words. You might even have two-factor setup on your email, what about your Slack?

Two-Factor Authentication for WordPress

There are a range of options; I have long recommended just a single plugin – the “two-factor authentication” plugin. It’s written by the WordPress security team, offers support for TOPT (time-based one-time passwords), as well as support for U2F and other mechanisms.

How does this work in practice? You can install the plugin, then your users can choose to implement a 2fa option. If they choose the TOTP option, which will be the most popular, they will need a TOTP supporting client on their phone or machine. The most common is the Google Authenticator app but others do exist (including LastPass, Microsoft Authenticator, Authy).

With the Google Authenticator app installed on their phone, they will scan the barcode in their user profile and from then on be prompted on login to provide a second factor.

Other options include a hardware token. I have talked about my hardware token of choice before but again there are plenty of options.

Advice for Two Factor Authentication

Implement it, and make it a requirement for all members of staff, but at minimum anyone with admin roles.
If you have the budget consider hardware tokens for everyone over going down the app route.
Most two factor apps offer backup codes, make sure you are storing them somewhere safe, but ideally not in your password manager. After all the whole idea is to have a second factor.
Try to enforce 2FA across all apps within your systems, but stick, where possible, to a single approach; if you need multiple apps/devices then people start taking shortcuts.

With a secure passphrase and 2FA enabled it will be very difficult for a bad actor to get into the account without significant effort through the main login. Just remember there are multiple routes to authentication for a user including XML-RPC and REST API so just because the dashboard is setup requiring 2FA doesn’t mean other areas are as well.

General user hardening

Phishing and Spear Phishing

Increasingly WordPress sites and users are becoming targets for phishing attacks. A phishing attack is an email or other communication pretending to be genuine that is used to lure you to take an action on your site or a fake site pretending to be yours.

Example Phishing emails include:

Your site’s database needs updating, please click here
There has been a critical error please click here

In most cases they replicate common emails people see during site updates, or more recently with the introduction of recovery mode, fake recovery mode emails.

The goal is normally to present you with a login screen into which you will then proceed to enter your details, the bad actors then use the credentials you gave on your own site to gain access.

While phishing is just sending lots of emails, spear phishing is sending targeted emails to a specific individual, for example if you have identified an admin of the site, so can send a Dear Bob email where you can give a little more detail to Bob such that he believes the email is genuine.

Countering Phishing

Never click a link in an email, especially one you didn’t generate. No good workflow should have a way that you can’t do the action (even verifying emails).

Education education education, send staff automated emails, if they click the link send them education, repeat until no one dares to click links.

Consider watermarking or signing emails generated by your WordPress install to make sure people look for those within the emails.

Make sure your SPF/DKIM records are set and your server is not coming in as junk, so people are not used to seeing emails associated with the domain in junk folder.

Warn users if a phishing attempt is seen, and act quickly.

2FA doesn’t prevent phishing but it makes it a lot harder to do, so make sure it’s enabled.

Empower users to manage security

By default a user can be logged in on more than one device in more than one location, which is useful as it means you can be logged in on your phone and PC at the same time. However, it also means a bad actor can be as well.

Monitoring logins, their locations and number of sessions can give some early warning. While something can be monitored by admins for many things this is about users managing accounts themselves for example:

Consider emailing users on successful logins, with a click here if it wasn’t you style message
Clearly show the user the last time and location they logged in, with a “flag this login”
Maybe consider preventing logins from two distinctly different geolocations (though be aware IP might not be the best way to do this, more than once I have been on a train and the world has thought I was in Sweden, not Stevenage)
Provide a clear reporting mechanism.

Managing Users

User management doesn’t have to be complicated. It’s also one of the few places where actually plugins and security plugins in particular come in handy. Ultimately the simpler you make things, the easier. Give users the correct capabilities, and indeed make sure they should be there in the first place. Enforce a secure password policy and back it with education and two factor authentication. Finally, empower users to notice and report problems.

Education, Empowerment and Policy dictate user security as much as any tool, get those right and user management becomes less of a headache and our bad actors will have a hard time fooling our users.

Want to learn more?

This post is from a series called Back to Basics, here is the complete series so far:

This post was written by Me, Tim Nash I write and talk about WordPress, Security & Performance.

If you enjoyed it, please do share it!

Source

Back to Basics – Updating WordPress Strategies

Tim Nash — Fri, 24 Jan 2020 13:50:50 +0000

This post was originally posted on TimNash.co.uk on 24th Jan 2020. Hi, I'm Tim, tend to talk about WordPress and Security on my site, I hope you enjoy this repost.

In a darkened room the hacker is sitting, he has been trying to gain access to his target for hours, green writing on a black terminal flashes by as he crafts by hand the payload. This attack will be the one that lets him get in. Just at the moment, the pinnacle of success his Mum comes in with his cup of tea.

For most people, this is what they think a bad actor looks like, a solitary individual or group out to target them. The reality, of course, is most hacks are done entirely automated with no human ever typing a single command into your now rooted server.

With the start of the new decade, I thought I would take a look at some of the basics of WordPress security that we often take for granted and consider how in 2020 we can achieve a minimum level of security that aims to remove 99% of automated attacks.

This article is less of how-to, rather a look at updating strategies for agencies and sites even ones that consider mission-critical. With the right strategy in place and how to test updating is easy and something that shouldn’t be keeping you up at night. However, while not a how-to it includes tools and techniques that should hopefully be used.

Why Update?

It seems trivial, so obvious and yet actually can if you are not careful to turn out to be almost impossible to do but the number one way to keep software secure is to keep it patched and up to date.

Most bad actors (malicious attackers) are not using hugely clever tooling to attack your sites, instead, they rely on known vulnerabilities and code written by others to exploit your site and thousands of others in an automated fashion.

Let’s assume you have blue widgets plugin and it has a vulnerability that allows uploading of a file to the webserver with no checks. This is pretty bad and gold dust for our bad actors. However several things have to have happened, number one our bad actor needs to know about your site and number two they need to know about the vulnerability as well as how to exploit it.

So how do bad actors find your sites? Well, the first way is that your site is already known to them and perhaps is being specifically targeted, this is incredibly rare even larger hacks of well-known brands don’t start off as targeted hacks however your site might be the target of a bad actor either for political, economical, state reasons or just malice.

The second far more likely reason is that your site was found during an automated scan, looking for conditions that might make it exploitable, for example, your site might be the target because a scan has revealed you have the blue widgets plugin. In this scenario your site is not the goal, it is simply being used to gain access to the server. Automated attacks can be fairly specific trying just one vulnerability having checked such conditions exist, or a total scattergun approach, accepting your site is up, therefore trying as many exploits as it can till it’s blocked hoping one succeeds.

Sites are rarely specifically targeted and it’s sad but important to understand they are often simply collateral damage on the way through to the server resources behind them. There are exceptions, especially towards e-commerce sites where credit card skimmers are becoming an increasing threat but on the whole, if your site has not been specifically targeted its just a way to get on to the server

So how do vulnerabilities come to light? For our Blue Plugin Widget, someone needs to know there is a vulnerability and write the code to exploit it. A bad actor may identify a vulnerability, they might wander across it or be looking at a given plugin as a potential target. As likely a security researcher or the plugin authors themselves might identify the issue and patch it. When a vulnerability is found, by a bad actor or published as information by the plugin author/security researcher that information tends to get disseminated quickly. What starts off as a “this is a potential issue”, quickly changes to this is proof of concept on how to exploit it, to here is a “weaponised” version of the exploit, to it deployed to exploitation framework publicly available.

The good news if a vulnerability is discovered developers normally take steps to patch their code and fixing the bug that allows the vulnerability they then release this fix as a new version. So how do we stop most attacks?

We update.

Security Updates vs Fixing things

In the perfect world, WordPress core would have some sort of long term security release cycles where security fixes are released independently of anything else. Certainly some minor releases are referred to as security fix releases but quite often security patches get bundled up with general bug fixing.

WordPress core technically only supports the latest version of WordPress.

However the security team backports critical security bugs, so when there is a major issue the latest version of WordPress gets a minor release, but so does all/relevant branches all the way back to 3.7. At least currently as WordPress releases more and more this process is becoming more burdensome and this policy is under review so it’s not safe to assume anything but the latest version is considered patched.

All of this is just WordPress core, themes and plugins each have their own review life cycles but most do not backport security releases. Worst many plugins and themes do not declare security fixes leaving them as fixed a couple of bugs, line item in changelog. Consequently only the latest version of a plugin or theme is likely to be the one with the latest security patches.

It’s not that easy to update

Or maybe it is, WordPress has a very simple manual update procedure, you login in to your Admin Panel and under Dashboard, there is Updates clicking this lists all the updates needed to be done, for WordPress core itself as well as Plugins and Themes. Clicking update on an individual component or update all will connect to WordPress.org and download the appropriate Theme/Plugin or WordPress itself.

A few issues present itself with our default approach, the first and foremost is it relies on a human to do it and well we suck as a race at doing things like this. It’s like we have a built in phobia of update buttons, perhaps a traumatic past or just far to use to Windows failing has made us wary.

Another issue with this approach is someone needs to be in charge of doing it, a process of when and how it’s done is needed and ideally, it’s recorded when things get updated. This means for the solo site operators, no holiday for you without your laptop, and I hope you’re healthy. In a larger organisation, we have even more issues, with who pressed the update button and when. The meaning site can have issues and we don’t even know that it’s an update because Bob hit the update button for WooCommerce but failed to update anything else.

So letting humans willy nilly clicking buttons doesn’t sound good, what other approaches could we take?

Fully Automated

Route one, is to accept that we as humans are not going to update things and we should just let the system do the updates. By default WordPress already updates the core with “minor” updates so there are systems in place and by adding a few additional filters plugins/themes and major updates of WordPress can be enabled.

add_filter('allow_major_auto_core_updates', '__return_true'); // Updates all versions of WordPress Core
add_filter( 'auto_update_plugin', '__return_true' ); // Updates Plugins
add_filter( 'auto_update_theme', '__return_true' ); // Updates Themes
add_filter( 'auto_update_translation', '__return_true' ); // Updates Translations

It’s important to understand the automatic updater works using the default WordPress updater so only plugins that it can update, will work with the WordPress update solution. Likewise most third party automatic updaters, or WP-CLI still also rely on this system. If you have plugins or themes, that use their own updater and don’t hook into this system, then you may need to do additional steps to achieve full automation.

A fully automated process looks something like this:

Once every 12-24 hours, the site checks for updates using the standard WordPress checker.
If updates are found, the site updates.

Um that’s it.

Now, this is pretty simple but we all know that when we update something breaks, and this is going to be at 2 in morning. There is no benefit to us being secured from bad actors if the site isn’t operable. The reality is failures happen rarely even though they are perceived as a high risk, however a better process is:

Once every 12-24 hours, the site checks for updates using the standard WordPress checker.
If updates are found, we update the staging site with updates.
The staging site gets checked and if no one stops it the main site updates 24 hours later.

In our first scenario we could do that with 3 lines of code, now we have added a staging site and all its dependencies, we have to also built in a delay for our live site. Also it has the problem it’s reliant on those squishy humans to check things. A fully automated shouldn’t have humans involved.

So a more reliable process would be:

Once every 12-24 hours, the site checks for updates using the standard WordPress checker.
If updates are found, we update a test site with updates.
The test site is then “tested” against in some automated fashion.
If the tests pass then the main site gets updated.

So again our complexity has rapidly increased, we need a test site, ideally one that is pulling from the live site. Running a series of tests, meaning we need some sort of test suite and then pushing or re-running the update on the live site.

However once set up this fully automated approach should be incredibly robust as long as our test coverage is robust. Indeed for all of updating approaches a lot relies on testing (see testing strategies).

Updating and not panicking of failures

While our third option is the most, ideal what if we don’t have the technical capabilities to implement a multistage deployment should we just automate and be damned? The answer is almost certainly yes. Most people who have failures during update process fit into the infrequent updaters or the cautious update camps.

In both cases, they either don’t update or worse selectively update and consequently not everything gets updated at the same time, the result is a plugin which might have a compatibility fix with the latest version of WordPress doesn’t get updated while the core does. The results are an error and a fear to update. If everything gets updated the failure rate drops significantly enough that many managed hosts are willing to force clients into update cycles. In addition while it’s not ideal for a site to be down, few sites are so mission critical that once every few years they can’t afford to be down overnight. If your site is mission critical then it should be treated as such, if it’s your personal blog, or brochure site then we can update and if there is an issue we fix it in the morning.

Pros of Fully Automated

Never have to worry again about updates
Patch cycle time is immediate
No compliance issues, always up to date.

Cons of Automated

Needs a system to handle testing and deployment
Site may break and no one will be available to fi
Huge amount of complexity

Who is it best for

The fully automated solution is probably suited for the vast majority of sites with very few exceptions. It does however rely on good plugin and theme choices, the system falls down if there are “troublesome” plugins or large chunks of third party code that isn’t within the automated system. Building the system is a reasonable investment, and does require building out testing for the best results. Ironically agencies and development teams with CI (continuous integration) based deployments are often most resistant to fully automated approach yet are in the perfect place for building out such systems, as much of their tooling is already in place. If your a development shop not using fully automated updates then it’s an opportunity to massively improve your deployment strategies.

Patch Tuesday

Route 2 we just tried to convince everyone that full automation is the way to go and the response was something akin to: Don’t be silly.

The various arguments came forward all flawed but you my friend are not in a position to fight them, you try to convince them with failure rates below 1% automatic updates are safe, that testing will cover edge cases. You have tried to explain the investment in systems and processes will improve deployments across the board. It all falls on deaf ears then you need a different strategy and this is the time honoured “Patch Tuesdays” how does it work:

You keep a local or staging site, and you update it once a week

Test
Then deploy

This whole process is manual, BUT TIM SQUISHY HUMANS. Yes, but at least squishy humans are not randomly clicking buttons. Patch Tuesday strategy works because we update once a week regardless. If we fail to update then we no longer have a strategy so we are substituting automation for the process.

Patch Tuesday strategy means we turn off and disable automatic and indeed all automated updates our Patch Tuesday is our source of updating, this way they are tested in a single process.

Patch Tuesday approach has the advantage issues are in theory found before deployment, they have a chain where there is a person responsible for the deployment so they should find issues. However, just like any of the routes, Patch Tuesday is reliant on testing.

The biggest problem with Patch Tuesday is when it’s missed or worse something is not updated, the second this happens this becomes a failing system and as the gap between times to update increase more things are likely to break meaning Patch Tuesday becomes a burden worse it becomes an excuse.

One option is to automated Patch Tuesday

So that the initial commit or command run is automated, and then the human is just responsible for testing and deployment. In this way it’s not dissimilar to option 2 within the fully automated approach only by it happening just once a week or a specific period it reduces that burden down.

The name Patch Tuesday comes from Microsoft’s regular schedule for patches (you know the ones that just install on your machine, but in enterprises they manually update because)

Patch Tuesday route, also potentially limits the way your store code, for the site as almost certainly to do it reliably ALL code will need to be stored in version control including vendor folders etc. Where as fully automated only custom code would need to be in there, as the live site would be automatically getting latest version (or could do depending on strategy)

Pros of Patch Tuesday

Issues are picked up early and fixed prior to production
Built into existing deployment options

Cons of Patch Tuesday

Humans everywhere
It’s process not code heavy, the first time someone fails to patch the system breaks
It is much slower deployment time
Almost certainly always lagging behind a truly updated system.
Limits how you store code.

Who is it best for

Incredibly mission critical sites, where the entire business is based around the site and has enough of a team built around it that Patch Tuesday strategy can work. Teams already used to working in patch cycles, so attached to more traditional IT will have easier buy-ins for this style of deployment.

Approved Release

Route 3 is another messy release strategy, everyone agrees they love automated releases but they have WooCommerce installed and that can’t be trusted (it can but I know you won’t believe me) instead with approved release we pretty much follow option two of the Automated Release but with a few modifications:

Our staging/testing site is updated, and any automated testing is done.
A notification is sent to the human, who double checks and “approves”
The update then gets deployed on the live site.

Basically the staging site stays always up to date, but the final push is done by a human to live this gives it some advantages of Patch Tuesday and fully automated but with the disadvantages of both.

We still have squishy humans and indeed a squish human with a flexible process. One of the biggest benefits of Patch Tuesday is a rigid update structure means updates are expected at given points. Approved release is adhoc, and worst potentially in the hands of just one person.

Like Patch Tuesday, this strategy means all things go through staging/testing and so turning off all automatic updates and even removing update options from the user interface all together. This also works best in strategies where the site is entirely controlled through the staging/testing cycle with dedicated deployment processes. Indeed both Patch Tuesday and Approved Release only work if there is a single deployment pipeline, otherwise things will get missed (though Approved release, each update could pull from live first).

Pros of Approved Release

Issues are picked up early and fixed prior to production
Issues can be pushed live quickly

Cons of Approved Release

Humans everywhere
Still needs a deployment solution for automatic updates on staging, a way to deploy to live & a way to notify of updates
Yet still process reliant, if no one pushes the button.
Almost certainly always lagging behind a truly updated system.
Limits how you store code.

Who is it best for

Very few people, on first glance a lot of solo developers, and tiny agencies with maintenance contracts will look at this and think this is perfect we keep control but have a nearly entirely automated solution. For e-commerce sites Patch Tuesday or Fully Automated are better strategies. From a security and engineering perspective this strategy might not fit any one, however I can see certain business cases where an agency might wish to adopt this approach not least because it enforces a one deployment strategy.

Testing

In all 3 of our strategies they all fall down on testing, if we don’t test either manually or automatically then they are going to fail. For testing we have 3 rough categories of testing:

Error Monitoring
Acceptance
Visual Regression

Error Monitoring

In its most simple form is hitting end points and seeing if they have a PHP or Javascript error, in addition seeing if the amount of errors within your error log increases. This can easily be monitored, both by processing the error log and navigating around the site. Often Error Monitoring can be done alongside acceptance testing (acceptance testing does the clicking) so error monitoring can then look for differences.

In addition simple HTTP monitoring such as uptime tools can check the site is not generating 500 error on given pages. At minimum consider checking your Homepage, Login page and any mission critical pages (checkout for example).

While HTTP monitoring should be fairly instant, ultimately this a few curl requests made from multiple locations and could easily be done with your normal uptime tool (you are running uptime monitoring right?). Error monitoring which is looking at statistical increases in errors might take longer to be noticed. By combining with a baseline and acceptance tests we can speed up at least the initial analysis.

Recommended tools

Acceptance Testing

We alright integration and acceptance tests right? When you develop new features, well now is the opportunity to reuse them and not just for testing your backups. By running the acceptance tests against your live/test sites you should be able to identify if there has been any breaking changes. In addition you can use these along side error monitoring to see if your testing is generating additional errors in the logs (or if your logs are noisy, this could be a percentage increase, though in our perfect world your PHP error log would be empty).

The downside to acceptance testing is they can be slow, even on a very uninteresting site like this my acceptance test suite takes about a minute to run, however most acceptance/integration test software allows you to group tests, so you can run just high priority for example post builds, a good example for this site my acceptance tests:

Check my homepage loads, including looking at the footer text
My login page, loads, can login and prompted for two factor auth
My RSS feed loads and counts how many entries are on the feed

Now my full test suite does things like testing the contact form, some backend bits and a bunch of little tests.

Things to think about before running acceptance tests on live:

You might have security in place to prevent such automation
Your acceptance tests might be destructive in nature checking the delete all posts functionality works might not be a good test for live.
They might create DB entries, for example one of my acceptances tests creates a post and publishes it (actually it doesn’t because Gutenberg broke it, thats a post for another day)

Picking tests that have broad coverage ultimately for updates you want to know if things are working.

Recommended Tools

Codeception

Interested in Acceptance testing I spoke at WordCamp London 2015 on introduction to acceptance testing.

Visual Regression Testing

Visual Regression testing sounds very fancy, but it literally means comparing the output of your site with a previous version you took. This is normally done by screenshotting your site before and after and then comparing them, if there is a percentage difference between the two then it is flagged. A “poor mans” visual regression is not to use the rendered output (i.e screenshots) but simply to evaluate the DOM this has a higher level of false positives as even a slight element change, for example, a plugin updating its DOM to clean it up might result in every other element appearing to have changed.

Visual regression testing can be either very simple or very fiddly to set up depending on use cases, there are third-party services like VisualPing that will compare screenshots from previous days.

Recommended Tools

UPDATE ALL THE THINGS!!!

Everything needs an update from time to time, and your goal is to make it as easy as possible to update. For the vast majority of people and companies going fully automated is the answer even without a full test coverage the failure rate is so low as to be acceptable for all but the most absolute critical sites. For those mission-critical sites that can’t be fully automated then rolling out Patch Tuesday strategies minimises potential problems of Adhoc updating.

In all cases updating fails, when it’s not done consistently, keeping things up to date might feel daunting if you’re looking at a screen with a hundred plugins all needing updating but once you are on top of it, the process can be seamless and you will never have to think about it again.

It’s important to remember though WordPress is just one part of the stack, and so its not just updating WordPress, plugins, themes but everything underneath if you manage the hosting yourselves then you will need strategies for updating the operating system and all the other applications on it.

Regardless of which route you take, know this you need to update and keep on top of updates if something is stopping you from doing so it is the problem and should be considered a blocker.

Want to learn more?

This post is from a series called Back to Basics, here is the complete series so far:

Help others find this post:

This post was written by Me, Tim Nash I write and talk about WordPress, Security & Performance.

If you enjoyed it, please do share it!

Source

Finding all your sites Gutenberg Blocks

Tim Nash — Sat, 18 Jan 2020 10:25:54 +0000

This post was originally posted on TimNash.co.uk on 18th Jan 2020. Hi, I'm Tim, tend to talk about WordPress and Security on my site, I hope you enjoy this repost.

Want to know something? Sure you do, a secret only you and me know….

I use Gutenberg on this site! There I have said it, half the WordPress world gasped in horror and do you know what I don’t dislike it.

There are also lot’s of plugins now that support Gutenberg blocks, like Atomic Blocks and Otter Block and My Mates got a Block. A Block directory is coming it’s so well blocky.

However there is a problem with all these blocks, people they are going to use them!

For example on this site I had 4 separate block libraries mostly doing the same things and I don’t need all of them and surely can’t be using all of them but how to check.

Guttenberg Blocks

WordPress has a built-in Blocks Parser, which if you give it content (like post contents) it will return you blocks within it for example:

parse_blocks( $post->post_content );

returns an array container items something like:

array(5) {
    ["blockName"]=>
    string(14) "core/paragraph"
    ["attrs"]=>
    array(1) {
      ["fontSize"]=>
      string(5) "small"
    }
    ["innerBlocks"]=>
    array(0) {
    }
    ["innerHTML"]=>
    string(113) "
<p class="has-small-font-size">Illustrations used in the article by <a href="https://undraw.co/">Undraw</a></p>
"
    ["innerContent"]=>
    array(1) {
      [0]=>
      string(113) "
<p class="has-small-font-size">Illustrations used in the article by <a href="https://undraw.co/">Undraw</a></p>
"
    }

So to get the list of blocks for your site is easy it’s just something like:

$args = [
    'numberposts' => -1,
    'post_type' => ['post','page']
];
$postc = get_posts($args);
$site_blocks = [];
foreach($postc as $post){
  if ( has_blocks( $post->post_content ) ) {
    $blocks = parse_blocks( $post->post_content );
    foreach($blocks as $block)
    {
        if(!in_array($block['blockName'], $site_blocks)) $site_blocks[] = $block['blockName'];
    }
  }
}
var_dump($site_blocks);

If we run this on the CLI with:

% wp eval-file list_blocks.php ~/httpdocs
array(17) {
  [0]=>
  string(14) "core/paragraph"
  [1]=>
  NULL
  [2]=>
  string(14) "core/separator"
  [3]=>
  string(9) "core/html"
  [4]=>
  string(12) "core/heading"
  [5]=>
  string(10) "core/group"
  [6]=>
  string(12) "core/columns"
  [7]=>
  string(10) "core/image"
  [8]=>
  string(18) "core-embed/youtube"
  [9]=>
  string(18) "core-embed/twitter"
  [10]=>
  string(9) "core/list"
  [11]=>
  string(10) "core/block"
  [12]=>
  string(10) "core/cover"
  [13]=>
  string(24) "atomic-blocks/ab-sharing"
  [14]=>
  string(10) "core/quote"
  [15]=>
  string(9) "core/code"
  [16]=>
  string(17) "core/preformatted"
}

Happy days, sure we could clean up the output, and we could probably exclude core components etc. Likewise, we are just getting names, but we could store posts etc.

Happy with my success I shared it with the WPUK Slack, and Herb pointed out, to check wp_blocks.

Wait what now…

Ah yes, reusable blocks, turns out they are their own custom post type, which kind of makes sense, he also correctly pointed out to be sure to include other post types which I don’t need for me but is a good point so now our code looks more like:

$args = [
    'numberposts' => -1,
    'post_type' => ['page','wp_block','post','wp_area']
];

Ok so by now I hear the grating of teeth at the use of -1 for numberposts, don’t judge, this is a CLI running reporting tool thrown together in minutes.

Ok so we all done, happy days. No… I go and look on the list, and that block I know I used isn’t showing up. Why?

Nested blocks

So if we go look at the output of the parse_blocks we have the innerBlocks array, this is an array of blocks that might be inside our block we have just parsed. This happens for example in sections and columns and JUST ABOUT EVERY DAMN BLOCK IS IN ANOTHER BLOCK!!!!!!!!!!!

I mean that’s fine, we just go through and loop through those, happy… Recursion oh yeah so we extend out and make sure we are looping happily through.

My final very dodgy code looks like:


<?php
$args = [
    'numberposts' => -1,
    'post_type' => ['page','wp_block','post','wp_area']
];
$postc = get_posts($args);
$site_blocks = [];
foreach($postc as $post){
  if ( has_blocks( $post->post_content ) ) {
    $blocks = parse_blocks( $post->post_content );
    foreach($blocks as $block)
    {
        $blockNames = parse_block_names($block);
      $site_blocks = array_unique(array_merge($blockNames,$site_blocks));
    }
  }
}
var_dump($site_blocks);
function parse_block_names($blockObject) {
  $blockNames = [];
  if(!in_array($blockObject['blockName'], $blockNames)) $blockNames[] = $blockObject['blockName'];
  if(!empty($blockObject['innerBlocks'])){
    foreach($blockObject['innerBlocks'] as $innerBlock){
      $innerBlockNames = parse_block_names($innerBlock);
      $blockNames = array_unique(array_merge($blockNames,$innerBlockNames));
    }
  }
  return $blockNames;
}

Which happily generates a list like:

% wp eval-file list_blocks.php ~/httpdocs
array(27) {
  [0]=>
  string(14) "core/paragraph"
  [1]=>
  NULL
  [2]=>
  string(15) "core/media-text"
  [4]=>
  string(33) "themeisle-blocks/advanced-columns"
  [5]=>
  string(32) "themeisle-blocks/advanced-column"
  [6]=>
  string(12) "core/columns"
  [7]=>
  string(11) "core/column"
  [8]=>
  string(10) "core/image"
  [9]=>
  string(14) "core/separator"
  [10]=>
  string(26) "atomic-blocks/ab-container"
  [11]=>
  string(9) "core/list"
  [12]=>
  string(37) "contact-form-block/contact-form-block"
  [13]=>
  string(10) "core/block"
  [14]=>
  string(12) "core/heading"
  [15]=>
  string(27) "themeisle-blocks/posts-grid"
  [16]=>
  string(28) "atomic-blocks/ab-testimonial"
  [17]=>
  string(14) "core/shortcode"
  [18]=>
  string(9) "core/code"
  [19]=>
  string(17) "core/preformatted"
  [20]=>
  string(18) "core-embed/youtube"
  [21]=>
  string(10) "core/quote"
  [22]=>
  string(18) "core-embed/twitter"
  [23]=>
  string(9) "core/html"
  [24]=>
  string(24) "atomic-blocks/ab-sharing"
  [25]=>
  string(10) "core/cover"
  [26]=>
  string(33) "themeisle-blocks/advanced-heading"
  [27]=>
  string(10) "core/group"
}

Turned out I really wasn’t using that plugin after all and it’s safe to deactivate.

Future

Block Management is going to be an interesting challenge, I’m already seeing a potential idea for a plugin, that hooks into deactivate script, and says “These plugins blocks are used on these pages” please check before deactivating.

However this 5-minute detour into the world of blocks has been interesting, a couple of caveats I’m sure some blocks use the same names, replace core blocks, generate on the fly and do a myriad of things to avoid detection. To this end, the quick script will no doubt not pick up the edge cases but I leave it here as it might be useful. For me it lets me explore parse_blocks and I learnt about the wp_block and wp_area custom post types.

Source