obsah

WP-CLI handbook

Today about WP-CLI. It is used in the Linux command line. Before you go, read on to see why you, as

Today about WP-CLI. It is used in the Linux command line. Before you go, read on to see why you, as an experienced administrator, should know and at least have some familiarity with this tool.

What is WP-CLI

It’s a text interface to WordPress that you run and control on a server that you log into using SSH. It can’t be accessed via ftp either, except in the settings via http protocol. It must be installed on the server by the server administrator, as a user you can at most ask or send a pointed request. (If you have a server, you can probably get by, installation instructions are on the front page of the site.) A large number of hosts have WP-CLI, sometimes it’s just not enabled.

The script is programmed in such a way that the individual functions are distributed as (mini)packages , actually mini-plugins, so that they can be installed, deleted, searched or even browsed through their list (WP-CLI package list).

How to use WP-CLI?

You use it to perform tasks in WordPress, but you don’t (actually, you can’t) log in. By being on the server in the WordPress directory and having sufficient permissions as a system user, you can control the application. You don’t log into WordPress, because most of the actions you perform are stored in the database, and that’s where the operating system’s user rights give you access. For example:

WP-CLI will make modifications in the database tables (like replacing strings or changing the user password) because it gets into the database – it reads the configuration stored in wp-config.php.
WP-CLI runs PHP to process the requested PHP script. It loads everything needed, so in effect it is the same request as over http. For example, analysing running hooks.
WP-CLI manages files on disk, installs and updates plugins, manipulates images, exports and imports data.

You can use all this in case of

rescue operations when you can’t get into WordPress because it won’t load at all or is not accessible via http,
time- and data-intensive tasks where the graphical environment is unnecessary and actually delays,
automation or scripting – you can perform many tasks with a script hanging on the system cron.

Main benefits

You can’t always get into the WordPress graphical environment. But that’s okay, you’ll be fine with the command line, even if you enter commands by manual instead of by rote.
It’s much faster. Really, the lack of graphics and pictures is not such a problem, you can only see the information you need.
You’ll find out things that you sometimes can’t find out at all, or not so easily and quickly, through a web app.
You can script and therefore chain tasks (e.g. create a backup script or import files).
Many plugins also add a module to WP-CLI, so you can control the functions from the command line as well. (Although I thought Wordfence had recently added their module as well, this is not the case, they use their own distribution package.)

I hope you’re still reading, because we’re just now going to show you some riveting examples that will get your heart rate up a bit.

A few words on installation and use

As I said before, you need to have sufficient rights to use it on a Linux system (because it is not a WordPress application, but access to the database and files on the system). Two concepts collide here, as they often do:

either you create (or is created) a role in the system that has necessary but not all rights (for example, it cannot create databases), or
you run everything as root, which means you put WordPress at risk of compromise.

The first time, WP-CLI still asks for your password and permissions, the second time you have everything readily available, which is risky. Life is a challenge.

The main command is called wp, followed by the section name, then the action name and other parameters. Example: wp core update or wp user list. The help section is ‚help‘, then the name of the action, then the topic you want help on, or you can add a command. So wp help core will list the commands for managing WordPress core, wp help user will list the commands for managing users, wp help user list will list the help for listing users (hence the list). All sections are in single number as far as I noticed (theme, plugin, user).

The plugin names correspond to the slug they have on WordPress.org, so there are no spaces in the name, but hyphens. This name is the identifier of the plugin/template for use in commands.

I don’t want to list all the sections here, that’s what WP-CLI help is for, plus they add up as you install classic plugins or just WP-CLI packages. To name a few of the well-known plugins that add their commands to WP-CLI: All in One Migration, BackWPUp, Ninja Forms, Query Monitor, Maintenance, Redis Cache, UpDraftPlus, ShortPixel Image Optimizer, Rankmath SEO, WooCommerce and more.

Selected WP-CLI commands for managing WordPress

There are several commands that I use in local installations:

Core, plugins and templates

wp core update updates the WordPress core, which is automatically downloaded to the local cache if it is not already there,
wp plugin list lists the plugins, their status (active/inactive) and current status (version used, current version), similarly wp plugin status; try also wp plugin list | grep available to list only plugins that can be updated (thanks to the line listing you can grep everything),
wp theme list, wp theme status does the same for templates, for parent templates it shows „P“,
wp site list shows all sites in the network (multisite),
wp plugin toggle query-monitor toggles the state of the Query Monitor plugin between active-inactive,
wp user update vlasta –user_pass=newpassword is used to change passwords on the local if I forget them,
wp cache flush flushes the WordPress object cache, wp rewrite flush flushes the memory for permalinks (when you install a new plugin that creates custom CPTs, they often show a 404 error, this solves it),
wp plugin auto-updates status –all | grep enabled lists all plugins, for each of them, if they have active automatic updates, grep will filter only those that have this feature enabled:

# wp plugin auto-updates status --all | grep enabled
admin-taxonomy-filter enabled
wordfence enabled

If I’m not mistaken, WP-CLI cannot always detect if a paid (premium) add-on has updates available, probably because of the authorization mechanism that is not available for WP-CLI. While developers often use, for example, the Freemius framework to distribute paid plugins, they may well have their own solution and have little reason to create support for WP-CLI. So keep in mind that these plugins need to be maintained manually.

Tuning, debugging

wp config list lists the configuration values in wp-config.php,
wp config set WP_DEBUG true sets the constant for debugging,
wp cron schedule list displays the schedule for the cron jobs, i.e. the scheme of when to run what, while the wp cron event list displays the specific routines that are executed in that scheme and the time of their last and next run,
wp doctor check autoload-options-size finds out how big is the amount of data that is automatically loaded on each query to the database and properly slows down SQL queries,

wp query-debug –url=https://vasrozbityweb.cz/stranka/ –format=table 1>query-debug.log loads the page at the given url and returns the timeline, errors and other information about what happened during the load; the output is long, so it’s a good idea to redirect it to a file (or add 2>errors.log to save the error output),
wp profile stage –spotlight –url=“https://e-ott.info/wordpress/“ –format=table is a better and clearer listing of what is loading and how long it takes.

Edit content

There are more commands in each section, so type e.g. wp help media to learn more about them.

wp media image-size tells you what image sizes are set in the installation,
wp media regenerate recreates preview images, either for selected images, dimensions, or the entire media library,

wp post list (again, it’s possible to work with posts in CRUD mode) lists the site posts and immediately takes you to wp export –post_type=post, which saves these posts to an XML file,
wp post-type list lists custom post types and their basic parameters,
Similarly, wp taxonomy list lists all registered post taxonomies and wp role list lists all existing user roles.

wp export –post_type=nav_menu_item exports the menus,
wp scaffold plugin badger creates a plugin structure and wp scaffold post-type badger > cpt.php adds a CPT file named ‚badger‘ to it (other possible parameters are not mentioned here),

wp comment list –number=10 –fields=comment_date,post_title –user_id=3 shows the last ten comments of the user with ID 3, the table contains a column with the date of the comment and the title of the commented post (you can add the content of the comment to the fields or remove the user_id for comments of all authors)

I think it’s time to call it a day, you’ve got a headache anyway, don’t you? The possibilities are endless, it’s one big lego. You can display and assemble almost anything.

So nice playing. 🙂 (I didn’t mention anything about WooCommerce, so maybe another time.)

Interesting packages and links

Images

Debugging and debugging

Installation fixes and improvements

Content and code generation

Neglected e-shop

I was contacted by a lady from a company with a request to make some minor changes to their e-shop.

I was contacted by a lady from a company with a request to make some minor changes to their e-shop. It cost several hundred thousand Czech crowns, but some basic things don’t work.

Today, I don’t want to deal with how to manage a contract, or how to verify that a contractor has actually done what they were supposed to do, or how to spot poor quality work. We’ll take a look at that some other time.

How to actually recognize a broken e-shop

It’s actually simple: it doesn’t sell. Orders are rather random, if I evaluate the traffic statistics, they are low numbers, the responsible person (owner, shop manager) can see at a glance that the e-shop is not working as it should.

Poor functionality is visible even to the layman’s eye at a glance and is of course linked to successful business performance. That is to say, the money jingling in the account is conditional on the good functionality of the app itself. As a shopper, you can easily check whether the e-shop is in good shape:

When you click the Add to Cart button, it does not take four seconds or more to add to cart.
The product listings are not confusing and unclear.
Filtering and paging of products according to activated criteria and parameters is functional.
Payment and transport methods are not duplicated, they are realistic and logical.
Browsing through the e-shop shows no errors and is quick, ideally even on a mobile phone.

These are the accompanying phenomena of a properly set up e-shop. Or, to put it another way, this is what a dysfunctional e-shop looks like.

The e-shop that I got for a partial repair had these symptoms. Looking into the administration unfortunately revealed other (supposed) problems, by which I mean a jumble of various plugins, many inactive, the vast majority not updated.

Multiple plugins for one feature that were not set up correctly and conflicting with each other in different ways. As an added disadvantage, it was still necessary to reckon with the fact that someone had modified the Storefront template, which could not be easily updated. I applaud the fact that at least the code is pretty clean and uses hooks, so it will be easy to port. Too bad the author didn’t put it straight into a plugin, the webmaster could have updated in peace… this way her site is jammed.

How to fix and stabilize an e-shop

First, you need to describe the current state and take screenshots of screens that are not working properly, such as the cash register. I take for granted saving a report from Site Health, which lists plugins and hosting configuration.

One of the first steps I would take is to review the plugins. I wrote about it in the newsletter some time ago. In a nutshell, it’s about making sure that only plugins that are a) functional, b) properly licensed, and c) used in a meaningful way remain on the site. See image – I would definitely investigate whether they are all needed.

Along with the plugin revision I also check the hosting settings, which nowadays means PHP version 8.2 or 8.3 and enough memory for WooCommerce (256 MB is the minimum!).

This will show if all plugins support this version of PHP. It can easily happen that errors related to the migration to a new PHP version will occur. These should be resolved, for example by communicating with the author of the plugin. I also assume that you are preparing everything on a working copy of the site.

I personally do not support technical debt, i.e. various regressive elements that hinder development. I always try to prepare the site to be progressive – i.e. ready for future innovations. This will save me a lot of work in the future.

Next, it’s a good idea to map out what features are in the template. Unfortunately, if someone has modified a single site template, then it will be necessary to identify and allocate these changes to a plugin or child template (I wrote about this in the last newsletter).

Once you’ve isolated those changes, which is obviously more of a programming job, insert them into a child template, even if you don’t need it at first glance. You can have that second look a year from now and you’ll be glad you have a child template up and running.

In the process of finding customized code, don’t forget about snippet managers, i.e. plugins where different parts of the code are stored. This too should go into child templates or custom plugins (again, see last newsletter).

Once you have your hosting set up correctly,
revised and updated plugins that work without errors (check the logs),
a functional updated and ideally subordinate template,

E-shop setup

Then you can work on reviewing your WooCommerce settings and all related plugins. It’s not just about direct setup, but also about checking the processes that run through the store. There you have it:

Proper setup of payment methods, including payment gateway and order status marking.
Shipping methods for different types of products, postage, packing and other charges.
Ropes, crampons and pickaxes.
Interfacing with accounting or economic software, i.e. order processing by accountants.
Credit system, rewards, virtual packages, discount coupons, marketing discounts and other enticements for future clients – you have to account for them, communicate them to customers, bill them, record the performance, etc.
Different amounts of VAT taxes, their change over time, sales to other countries (to avoid double taxation), working with the euro and currency exchange rates…

There are many more different processes and resulting situations, running an e-shop is no fun, so it’s good to know exactly what we’re doing when adjusting the settings. The risk of damage is quite high. It certainly can’t be handled by one person – at the very least the owner must supply the specifications, and it’s also a good idea to establish controls and testing, for example, well-intentioned spam protection can effectively cancel or damage the entire ordering process.

Sending and delivering emails, whether transactional, marketing or regular informational, is also a big topic. And that brings us to the topic of data processing, which in my experience most e-shoppers pretty much ignore.

On top of all the activities is the proper setup of measurement codes to keep the analysts busy. Nowadays it only makes sense to use GTM for your e-commerce store, don’t leave plugins to run different tools like SiteKit or WooCommerce Google Analytics Integration. It will be very laborious for you to comply with all the consent management requirements, especially if you run ads on different networks (Google, Facebook, remarketing or retargeting) for your e-shop – everything will be easier if you run it all from GTM based on the consents granted.

As an e-shop administrator, we are at least a little bit responsible for these things, more than that. It is difficult to explain that the error or complication was not caused by our intervention. That’s why it’s a good idea to document your actions before and after the changes, both visually-that is, making a video or creating a screenshot-and factually, that is, using a log with timestamps. If any unwanted changes occur, we are the ones who should document how it happened, why it happened, and how we will prevent it from happening again.

We’re having a hard time. But we’re having fun, right?

WordPress plugin auditing

I would compare a plugin audit to a health check. Or a vehicle inspection. It's a process designed to find and fix misconfigured plugins to prevent a collapse or crash.

I would compare a plugin audit to a health check. Or a vehicle inspection. It’s a process designed to find and fix misconfigured plugins to prevent a collapse or crash.

WP-CLI handbook

Table of Contents

What is WP-CLI

How to use WP-CLI?

Main benefits

A few words on installation and use