Tag: WooCommerce

WordPress doesn’t even know what it is

The folly of blog-centric “author” functionality in the context of a modern WordPress-based, non-blog website

This week’s article on The Verge about the latest messy drama in the WordPress world (tl;dr it’s Matt Mullenweg vs. WP Engine, and if you’ve read any of my previous writings about WordPress you can probably guess whose side I’m on in that fight) got me thinking once again about how Matt really doesn’t understand his creation.

And yes, I’m personifying the entire core team in Matt. But, let’s be serious. He kind of does that himself.

Anyway, today I got an email from a long-time client who uses WordPress and WooCommerce — which, fun fact, is now owned by Automattic, the company that not only is the primary supporter of the open source WordPress project, but is “cleverly” named after Matt himself! — describing a weird situation.

This client’s WooCommerce site has been running for ages. Well over a decade. And a lot of their products have been on the site with minimal edits for years. But this client noticed a few days ago that a large number of those products had suddenly lost their images, and he was hoping I could get to the bottom of it.

Fortunately, I have the excellent Simple History plugin installed on the site, so I was able to go back and investigate the recent activity.

Much to my surprise, I found that this client himself had deleted all of those product images a week ago. At first I jumped to the conclusion that his account had been compromised. But I noticed that the IP address he was logged in from matched the local ISP his business uses. So, it sure seemed to be him.

I scrolled through pages and pages of logs just like this, all with timestamps in a span of 3 minutes:

Finally, at the end of that list, there was this:

Now I understood what was going on.

Once again it’s a situation where the origins of WordPress as blogging software come back to bite it. Or rather, me. And my clients.

There’s a lot of functionality around “authors” in WordPress that really only makes sense if the site is a blog — a blog with multiple authors. Like the fact that author archive pages exist. Even if your site isn’t a blog. And that, unless you take steps to shut these off, e.g. with a plugin, every user with author- or higher access automatically has an author archive page that shows all of the posts they published on the site.

Do you want that? Do you even know it exists? I’ve made my living in the WordPress ecosystem for more than a decade and even I usually forget it’s a thing.

But there’s something even worse…

Uh-oh.

Does the average WordPress site admin (not developer, just an ordinary site admin) really understand what content ownership means in WordPress?

Is it reasonable to assume that someone faced with this screen truly understands that clicking that Delete all content radio button is going to delete all of the images in the Media Library that this user ever uploaded, even to posts (and remember, WooCommerce products are “posts”) that they didn’t initially create?

Because that’s what it’s about to do.

In fact, that is exactly what it did do to my client last week. And now I’m working on a way to restore those deleted images.

Well, what should WordPress do in this situation?

For starters, the text of the options could be a lot more explicit about the implications of the choice. The radio button for attributing the content to another user — ideally whatever Administrator-role account’s email address matches the primary admin email, if one exists — could be pre-selected as the default. There absolutely should be a confirmation dialog warning, in scary language, that anything the user ever created, including file uploads to the Media Library, will be deleted permanently.

Or, maybe it could be “smarter” on a whole other level, and adapt contextually so that when the site is clearly not using the blog author functionality, it would not even present this option. Just un-assign the authorship meta data, but keep the content. At least for Media Library files.

So, now what?

Fortunately, the site is hosted at WP Engine (remember them?) and they automatically make daily backups of every site. Downloading the backup from the day before all this went down was the easy part. But since a week has gone by and the client has been busy updating the site, I can’t just restore the backup… they’d lose all their work (plus all of the details of orders that came in over the same week). So I need to find a way to reimport the relevant images and remap them to the products.

Also fortunately, I’ve done a ton of direct, hands-on work in MySQL databases over the years, so I think I’ll be able to pretty quickly narrow down the list of products that “lost” their images last week, as well as which images those were. Getting them reassigned where they belong though may not be so easy.

And all because 43.3% of all websites that currently exist have put their faith in the house of cards that is WordPress. Speaking of cards…

That’s been Matt’s cute little tagline on his own WordPress blog since the dawn of time, but I feel like we’re the unlucky ones.

Update, a while later: Instead of leaving this post as an unresolved rant, I decided to make something constructive out of it and write up how I restored the images.

First I went into WP Engine’s Backups section, and used the Prepare ZIP option on the backups from both the day before and the day after the incident. I chose to download the database and the uploads directory. I left the plugins and themes directories out of it, because they’re not relevant here, and I’ve got enough to deal with already.

Once I downloaded and extracted the two zip files, which — no joke — took over a half hour even on my fiber gigabit connection, I put them into two adjacent folders on my Mac desktop, and then in Terminal I ran the following command:

diff -rq folder1 folder2 > differences.txt

The actual folder names should be subbed in for the black text. This gave me a file called differences.txt that listed all of the files in the old archive that were not in the new archive. I opened the file in BBEdit for further processing.

Of course, this list included all of the scaled-down versions of the images, and I only really want the source images. WordPress appends the dimensions of each scaled-down image into the filename before the extension, so I was able to use BBEdit’s Process Lines Containing… tool to filter those out with a grep. (Note: This regular expression is a little rough, because it assumes that you didn’t upload any images that included a string consisting of a hyphen, some digits, an x, some more digits, and a period.)

-[0-9]+x[0-9]+\.

Since I’m on a Mac and had already been mucking around in those folders in the Finder, I also had to run the tool again to delete the inevitable .DS_Store files.

Inside the parent folder for the old archive, adjacent to the uploads directory, I created a new director called images-to-restore where I intended to put all of the images I… need to restore. Then I ran a find-and replace on the remaining lines in the text file in BBEdit to turn it into a series of commands in this format:

cp uploads/2023/03/filename.png images-to-restore/

Obviously the part in black was unique for each line. And, of course, this is assuming they never uploaded files with the same filename in different months. (Hint: They did, of course they did, and I won’t realize that until much later in the process.) I will leave it for the reader to determine the most efficient way to modify this cp command to avoid overwriting duplicates.

I saved this to a new file in that same directory called script.sh and in the Terminal, gave it execute permission. Then… I ran it. Boom, within a second, the 531 deleted images were all gathered in one place, ready to upload back into the Media Library.

This is where I stopped for the night. It was already 6 PM, and I needed a fresh start to figure out the database portion.

Update #2, the next morning: OK, how is this database portion going to work? All 531 images are now in the Media Library, but I have two main challenges here:

Figuring out how WooCommerce handles the main Product Image. Is it just a relabeling of the standard Featured Image, as it seems to be? Answer: Yes. So, how are those handled in the database? In the wp_postmeta table, there are records with the product ID in the post_id field, '_thumbnail_id' in the meta_key field, and the attachment ID in the meta_value field. Knowing that, I can move on to…
Figuring out how to map the new attachment IDs for the re-uploaded images to the correct product IDs. This is involved enough that I need to break out of the ordered list, so… here we go, back to regular paragraphs.

Before I continue… if you are getting the impression that I’m writing this as I go through the process, you’re absolutely correct. And that will come back to bite me.

Along with the images themselves, I downloaded copies of the database from the days immediately before and after the incident. The problem is, running a diff in BBEdit on two large (360 MB) SQL files is not going to be very useful. I need to just load those tables into a sandbox database and run some queries against them.

First, I used BBEdit to cut out just the tables I need (wp_posts and wp_postmeta), from the rest of the SQL files. I also did a find-and-replace to change the table prefixes so I could put both versions into the same database and easily tell them apart. I used wp22_ and wp24_ as the prefixes, to match the before-and-after dates.

There are two ways I could handle this next step. Since I have a list of the filenames I re-uploaded, I could search on those. Or, I could search for attachment-type posts in wp22_ that are missing in wp24_. I went with that approach since it’s much cleaner:

SELECT ID, guid FROM wp22_posts WHERE post_type = 'attachment' AND ID NOT IN (SELECT ID FROM wp24_posts WHERE post_type = 'attachment');

(Note: I conventionally wrap table and field names in backticks, but that’s not technically required — unless their names match a SQL command keyword, which good database designers know not to do anyway — and since the Block Editor uses the backtick character as a shortcut to jump into and out of “inline code” mode, I had to omit them here.)

All I really needed was the ID field, but I brought in the guid field as well so I can do a sanity check. That field contains the full direct URLs to the images in the Media Library.

This query only returned 529 records, not the 531 I was expecting, but I’m not too worried about that. Even if I’ve lost the mapping for two images along the way, this is going to get my client back 99.6% of the missing images. Eventually they’ll find the two products that still don’t have images, and since those images are back in the Media Library now, it’ll be easy to fix them manually. (Or, it’s possible that only 529 products are missing images and the other two images are something random.)

Of course, I also need to know the new attachment IDs for the re-uploads. So I went into the current version of the database and extracted the wp_posts and wp_postmeta tables there too. (I left their prefixes unchanged.) There’s a useful record in the wp_postmeta table, with a meta_key of '_wp_attached_file'. That’s the relative URI for the original image file, under the site’s wp-content/uploads directory.

In the “current” table, I’m just going to search for attachments I (user ID 1) uploaded yesterday:

SELECT ID, guid FROM wp_posts WHERE post_type = 'attachment' AND post_author = '1' AND post_date LIKE '2024-09-30%';

The trick of course is that the guid records are not going to be the same, thanks to how WordPress sorts uploads into year- and month-based subdirectories. (Also, I’m assuming they never uploaded two images with the same filename in different months. But again we’re back to just trying to resolve the bulk of the problem. I’m not going for 100% perfection.)

What I need is a way to find just the filename portion of the guid URL value. Fortunately, there’s a way to do that in MySQL, and even though my SQL skills are rusty, my googling¹ skills aren’t, so I found a solution courtesy of StackOverflow. It’s the SUBSTRING_INDEX() function.

So, here’s my way of finding a mapping of the old attachment IDs to the new attachment IDs, using that function. Note that I’m only bothering with using the second of the above queries (reduced to one operand to avoid MySQL error #1241) in narrowing down the list, because that’s all I really need to do with an INNER JOIN.

SELECT wp22_posts.post_parent AS product_id, SUBSTRING_INDEX(wp22_posts.guid, '/', -1) AS filename, wp22_posts.ID AS old_id, wp22_posts.guid AS old_guid, wp_posts.ID AS new_id, wp_posts.guid AS new_guid FROM wp22_posts INNER JOIN wp_posts INNER JOIN wp22_postmeta ON wp22_postmeta.post_id = wp22_posts.ID AND wp22_postmeta.meta_key = '_wp_attached_file' WHERE SUBSTRING_INDEX(wp22_posts.guid, '/', -1) = SUBSTRING_INDEX(wp_posts.guid, '/', -1) AND wp_posts.ID IN (SELECT ID FROM wp_posts WHERE post_type = 'attachment' AND post_author = '1' AND post_date LIKE '2024-09-30%');

RRRRRRRRRRIP…

That was the moment when I realized that the client did, in fact, upload quite a few different images with the same filename over the years. And since I didn’t account for that in my shell script yesterday, those got flattened down to just one instance each. Fortunately, the problem isn’t as bad as I initially feared. This mapping query returned 558 results. That’s 29 more than I expected, and it corresponds to 29 duplicate filenames. But, the wp22_posts.post_parent field (labeled as product_id for clarity for myself), which corresponds to the product records the images are actually attached to, returned a lot of 0 values. What that means is, the products those images were associated with had already been deleted at some point. That was 205 of the total 558 records, bringing the number of products I actually need to “fix” down to 353, and among those I was only able to find 7 duplicate filenames. So we’re at 98.0% now.

Most importantly, with this narrowed down list, I also now have a direct mapping of the product IDs to the new attachment IDs. I copied just the product_id and new_id columns from the spreadsheet and pasted them into BBEdit, to generate my list of SQL UPDATE statements.

Maybe there’s a better way to do this, but this is how I’ve always handled it. Now I have a text document in BBEdit with a pair of numbers on each line, with some tabs in between. Some careful use of find-and-replace can turn those tabs and line breaks into a series of individual UPDATEs that will look like this:

UPDATE wp_posts SET post_parent = 111528 WHERE ID = 118861 AND post_parent = 0 LIMIT 1;

The AND parent_id = 0 LIMIT 1 portion is just kind of a safety check. It means that I won’t modify any records that already have a post_parent set, and that each update will only affect one row. (I mean, that’s really redundant because the WHERE ID = clause necessarily limits it to one row since ID is the primary key of the table. But better safe than sorry.

I ran the batch of UPDATEs in my sandbox database first and did some spot checks to make sure the correct post_parent values had gotten assigned to the newly re-uploaded image records. It checked out, so I went ahead and ran it on the live database. Fingers crossed…

Oh, but before I ran it on the live database, I backed up the table. That’s a lesson I learned the hard way, many years ago.

And…

It didn’t work.

Well now, hang on a second. Maybe the problem is that I missed a step. That’s right, back to #1 from today’s to-do list. I need to create those '_thumbnail_id' records in the wp_postmeta table.

Back to the old database to cross-reference these:

SELECT post_id as product_id, meta_value as old_id FROM wp22_postmeta WHERE meta_key = '_thumbnail_id' AND meta_value IN (SELECT ID FROM wp22_posts WHERE post_type = 'attachment' AND ID NOT IN (SELECT ID FROM wp24_posts WHERE post_type = 'attachment'));

Now that’s the simple version, just to make it reasonable to grasp what’s going on. It’s only returning the product IDs along with the old attachment ID associated as the featured image. But I need to map these to the new image IDs. That’s going to require merging in that really complicated query from above.

Honestly, trying to think that through started to melt my brain, so I decided to take a novel approach. You can make up whatever meta data you want. So I decided to insert a new type of meta data in the current database, to store the mappings of the old IDs to the new ones. Back to my BBEdit find-and-replace approach, pulling the old and new IDs in and generating a set of INSERT statements like this:

INSERT INTO wp_postmeta (meta_key, meta_value, post_id) VALUES ('_recovery_20240930_old_id', old_id, new_id);

With that step completed, I’m able to short-circuit further exploration and jump straight to the following update statement. In the interest of time, I once again blasted through a BBEdit find-and-replace. I believe it’s possible to do this with a single UPDATE statement with the correctly chosen subqueries, but I’m running out of time so I need to resort to the quick-and-dirty approach. (Note, this turned out not to require those '_recovery_20240930_old_id' meta data records at all, but they’re nice to have for possible future reference anyway… and they’d be essential to the smarter, single-query solution.)

I discovered that as I had worked with a few of the products, their meta records for _thumbnail_id had already been deleted, so the best approach was to delete all of the associated _thumbnail_id records, and then insert new ones.

DELETE FROM wp_postmeta WHERE meta_key = '_thumbnail_id' AND meta_value IN (…) LIMIT 353;

The ellipses should be replaced with a comma-delimited list of the “old” attachment IDs. Then, blast through BBEdit find-and-replace again to create insert statements like the following, mapping the new attachment IDs to the associated product IDs:

INSERT INTO wp_postmeta (meta_key, post_id, meta_value) VALUES ('_thumbnail_id', 114396, 118771);

It worked! Of course, there are a bunch of products with multiple images and those are not yet reassigned to the WooCommerce galleries, but at least all — or almost all — of the products now have a featured image again so the WooCommerce “missing image” placeholder isn’t showing up everywhere.

Of course I actually use DuckDuckGo. ↩︎

WooCommerce code snippet: add customer IP address to admin Orders page

First off, this is not solving a problem. It’s making it easier to deal with the fallout of the problem.

Here’s the problem: bad actors steal credit card numbers, and sell batches of those credit card numbers to other bad actors who like to find ways to test out the credit card numbers to see if any are still active.

One way they like to do this is to find WooCommerce sites that sell cheap products — especially stickers, which are generally priced at $5 or less — and they use a script to spam the site with fake orders… well, real orders… for these cheap items, using fake contact information and the stolen credit card numbers. Most of them are already canceled and the transactions fail, but a small percentage of the cards are often still active, and the ability to place an order with them confirms it. I suspect the reason they place very small orders is that it’s easier for those transactions to go unnoticed by the real card owners.

Anyway, this is a problem I am seeing with increasing frequency on my clients’ WooCommerce sites, and there are generally two ways I address the problem.

First, I install Brian Henry’s WooCommerce Checkout Rate Limiter plugin. This can be very effective at throttling the scripts that place these huge blasts of orders from the same IP address, which leads to…

Second, I get the fake orders’ IP addresses and block them in the server’s firewall. You can get the customer IP address of any order in WooCommerce by clicking through to the detail page for an order. There are various ways to block IP addresses, including WordPress plugins, but I like to go straight to the source and block them in the ufw firewall right at the Linux OS level.

But the bad actors are perhaps becoming aware of these techniques to block them, and are modifying their tactics. I can see three ways they would do this, although I am only personally able to observe two of them: 1) slowing the rate of submissions, 2) spreading the submissions across multiple different sites, and 3) using different IP addresses. The first and third are the ones I can observe, of course, unless by chance the multiple sites are all maintained by me. (I do support a very large number of client sites, but not enough that this has happened yet.)

Anyway, we are now getting to the point of this post. I wanted a way to quickly see the customer IP address for a whole list of orders, instead of having to click through to each individual order’s detail page. Sure, I could fire up phpMyAdmin and do direct SQL queries, but I prefer the convenience of having this happen right within the WordPress admin. And so, I present to you a code snippet that will add an IP Address column to the WooCommerce admin Orders page:

add_filter('manage_edit-shop_order_columns', function($columns) {
    $columns['ip_address'] = 'IP Address';
    return $columns;
});

add_action('manage_shop_order_posts_custom_column', function($column, $post_id) {
    if ($column == 'ip_address') {
        $order = wc_get_order($post_id);
        echo $order->get_customer_ip_address();
    }
}, 10, 2);

That can go into your theme or a small plugin. The first block of code adds the IP Address column to the table on the Orders page, and the second block outputs the customer’s IP address in that cell in each row of the table.

Of course, this won’t stop bad actors from being bad actors. But it might help you reduce the number of fake orders your clients have to refund.

The “house of cards” approach to development is a “fatal error” in itself

This morning my work of putting out a fire for one client was interrupted by the need to put out a blazing inferno for another client. Specifically, they’re running a big sale on their WooCommerce store, and the site was returning a fatal error.

Turning on debugging, I saw this message:

PHP Fatal error: Declaration of Dhii\\Container\\ProxyContainer::has($key) must be compatible with Psr\\Container\\ContainerInterface::has(string $id): bool

Ugh.

There is so much about this that I hate. Mainly, what is any of it for? I have to question whether any of the developers of PayPal Zettle POS for WooCommerce, the affected plugin, really know either. This plugin suffers from what I call the “house of cards” approach to development. Why write your own code if you can just slap together dozens of packages that already do the things you want? On the surface, that’s great. But the problem is, then you don’t really know what your own software does.

I recognize that this is a necessity in many cases. It’s just not practical to reinvent every wheel. But when your application is structured like this, you may have 6 different kinds of wheels, or wheels made out of other wheels, or wheels that also contain a kitchen sink. As usual, xkcd nails it:

Fortunately, WP_DEBUG let me see exactly where the errors were occurring, and although my 20 years of idiosyncratic PHP development experience didn’t help me to understand what the error meant, this StackExchange post did. I just had to change this:

public function has($key)

…to this:

public function has($key): bool

And then I had to do that about a dozen more times in various other files deeply nested in the plugin’s vendor folder, until the PHP fatal errors stopped appearing.

In the WordPress support forums, I discovered near the top of the list a post from someone else experiencing this same error, and the devs suggested it was probably a plugin conflict. They didn’t seem interested in pursuing the possibility that their own code was broken.

But, then again, it really isn’t their code. And that’s the problem.

I’m not above reproach here. I’m a WordPress developer. I use other people’s code all the time! I even sell a product that is substantially constructed out of other people’s code. But I am very judicious about what does or does not get placed in my vendor folder. And I realize that if something goes wrong with it, it’s up to me to fix it, even if it’s not my code.

Speaking of which… I have some updates to make. Gotta go!

How to purge fake/bot WooCommerce customer accounts directly in the MySQL database

DANGER! If you don’t know the havoc one can wreak with a DELETE statement in MySQL, stop right here. I take no responsibility for what you might do with the information that follows.

Bots like to create fake customer accounts on WooCommerce (WordPress) sites, apparently. What they’re attempting to do, I don’t know. But if you don’t stay on top of things, you might find you have thousands of fake customer accounts in your site. Chances are they haven’t, won’t, and can’t actually cause any damage, but they’re cluttering things up, and any unnecessary user account in a WordPress database represents a potential future security risk.

On a particular client’s heavy-traffic WooCommerce site, I discovered that over the course of the site’s 7-year lifespan it had accumulated nearly 8,000 such accounts, and I wanted to be rid of them.

After carefully exploring the data surrounding a few of these obviously fake accounts, I determined a pattern, and came up with a fairly cautious set of conditions that, to me, indicated a customer was fake:

They had the customer role.
Their user account had nothing in the First Name or Last Name fields.
Likewise, their user account had nothing in the Billing First Name or Billing Last Name fields. (If you’re feeling extra draconian, you might skip this one.)
They had never placed an order while logged in — their user ID did not have an _order_count entry in the wp_usermeta table. Which is perhaps an obvious condition because…
They had never logged in at all — their user ID did not have a wfls-last-login entry in the wp_usermeta table. This condition will only apply if your site uses WordFence.

You can test all of those conditions with a single SQL query:

SELECT DISTINCT `user_id`
FROM `wp_usermeta`
WHERE
`user_id` IN (SELECT DISTINCT `user_id` FROM `wp_usermeta` WHERE `meta_key` = 'wp_capabilities' AND `meta_value` = 'a:1:{s:8:"customer";b:1;}') AND
`user_id` IN (SELECT DISTINCT `user_id` FROM `wp_usermeta` WHERE `meta_key` = 'first_name' AND `meta_value` = '') AND
`user_id` IN (SELECT DISTINCT `user_id` FROM `wp_usermeta` WHERE `meta_key` = 'last_name' AND `meta_value` = '') AND
`user_id` NOT IN (SELECT DISTINCT `user_id` FROM `wp_usermeta` WHERE `meta_key` = 'billing_first_name') AND
`user_id` NOT IN (SELECT DISTINCT `user_id` FROM `wp_usermeta` WHERE `meta_key` = 'billing_last_name') AND
`user_id` NOT IN (SELECT DISTINCT `user_id` FROM `wp_usermeta` WHERE `meta_key` = '_order_count' AND meta_value > 0) AND
`user_id` NOT IN (SELECT DISTINCT `user_id` FROM `wp_usermeta` WHERE `meta_key` = 'wfls-last-login');

You may want to spot check some of these IDs in the wp_users table, or directly in the site admin, just to be sure everything looks right. Then you can turn the above into a subquery that will delete all of the matching users. Be sure to make a full backup of your database before doing this!

DELETE FROM `wp_users` WHERE `ID` IN (
SELECT DISTINCT `user_id`
FROM `wp_usermeta`
WHERE
`user_id` IN (SELECT DISTINCT `user_id` FROM `wp_usermeta` WHERE `meta_key` = 'wp_capabilities' AND `meta_value` = 'a:1:{s:8:"customer";b:1;}') AND
`user_id` IN (SELECT DISTINCT `user_id` FROM `wp_usermeta` WHERE `meta_key` = 'first_name' AND `meta_value` = '') AND
`user_id` IN (SELECT DISTINCT `user_id` FROM `wp_usermeta` WHERE `meta_key` = 'last_name' AND `meta_value` = '') AND
`user_id` NOT IN (SELECT DISTINCT `user_id` FROM `wp_usermeta` WHERE `meta_key` = 'billing_first_name') AND
`user_id` NOT IN (SELECT DISTINCT `user_id` FROM `wp_usermeta` WHERE `meta_key` = 'billing_last_name') AND
`user_id` NOT IN (SELECT DISTINCT `user_id` FROM `wp_usermeta` WHERE `meta_key` = '_order_count' AND meta_value > 0) AND
`user_id` NOT IN (SELECT DISTINCT `user_id` FROM `wp_usermeta` WHERE `meta_key` = 'wfls-last-login')
);

OK… so the users are gone. But each one has a bunch of records in the wp_usermeta table. Now that we’ve gotten rid of the users themselves, it’s easy to purge their associated meta data:

DELETE FROM `wp_usermeta` WHERE `user_id` NOT IN (SELECT `ID` FROM `wp_users`);

How to make the WooCommerce main shop page show featured products only in 2022

Sorry for the click-bait-y title (especially the “in 2022” part), but I searched fruitlessly for way too long and found too many woefully outdated answers to this. Ultimately what I found still wasn’t quite the complete answer, so I modified it a bit myself to arrive at the following.

The goal here is, as the title suggests, to get the WooCommerce main shop page to only show your featured products. Why this isn’t just a checkbox option in WooCommerce is beyond me. But then a lot of the decisions made by the WooCommerce dev team are beyond me. (Excuse me, Professor Brainiac, but I’ve built e-commerce platforms from scratch and, uh, I think I know how a proton accelerator… oh wait, never mind.)

Anyway, this is it:

add_action('woocommerce_product_query', function($query) {
    if (is_shop()) {
        $query->set('tax_query', array(array(
            'taxonomy' => 'product_visibility',
            'field' => 'name',
            'terms' => 'featured',
            'operator' => 'IN',
        )));
    }
});

What exactly is happening here? Well, as noted by the most helpful resource I found, since WooCommerce 3 (currently on 6.1.1), the “featured” status has been handled by the product_visibility taxonomy, and not by the _featured post meta field. So this needs a tax_query and not a meta_query.

Beyond that, we’re making an extra check that we’re on the shop main page — so this doesn’t affect category archive pages. And we’re using the woocommerce_product_query hook, not pre_get_posts as some other examples suggest, so it only runs on WooCommerce queries and we can skip adding extra conditionals for pre_get_posts to run on, you know, every single post query on every page of the site, including admin.

That’s all there is to it. Now your main WooCommerce shop page will only display featured products, and nothing else changes.