Category Archives: WordPress

The Way of A WordPress Developer

From my very old private programming diary:

2 months later…



WordPress Database Optimizations

delete from wp_usermeta where meta_value = '';
delete from wp_postmeta where meta_value = '';
delete from wp_options where option_value = '';

Because why not?



WordPress HTTPS to HTTP Cookie Error

After switching from HTTPS to HTTP (local development) WordPress may sometimes get stuck in the following error message:

Cookies are blocked or not supported by your browser.

The browser complains:

This Set-Cookie was blocked because it was not sent over a secure connection and would have overwritten a cookie with the Secure attribute.

The solution is:

1. Visit the https:// version of the site (it would error out as Connection Refused, or give you an SSL warning, whatever)
2. Clear the cookies while in the error screen.

Makes sense.



Cleaning Up Bot Registrations in WooCommerce

…or Optimizing Slow Sub-Queries in WordPress

Bot registrations are a nuisance in many WooCommerce sites. Cleaning them up seems to be a trivial task: just delete all users without a placed order from a month ago and backwards.

select * from wp_users where user_registered < "2020-07-01 00:00:00";                                                                                                         
47665 rows in set (0.06 sec)

select meta_value from wp_postmeta where meta_value = '_customer_user';                                                                                                       
51253 rows in set (0.44 sec)

Okay, so we almost 50 thousand customers and a bit over 50 thousand orders.

The query to delete all the users that have no order is seemingly a simple one:

delete from wp_users where user_registered < "2020-07-01 00:00:00"
and id not in (select meta_value from wp_postmeta where meta_key = '_customer_user' group by meta_value);

Great. Yet there's a huge issue: Query OK, (59 min 7.22 sec)

Ooomph! This won't effing do!

Continue reading



WooCommerce Can’t Count Either

In continuation of yesterday’s post about bbPress, I decided to look for a more impactful race condition vulnerability. What’s more impactful on an online business than ecommerce?

WooCommerce is up for the thread-safety test in this post and probably a couple of other to follow.

WooCommerce Can't Count Either

Continue reading



bbPress Can’t Count

In a highly-concurrent high-load environment bbPress will not count the topics and replies correctly. This happens due to several race conditions in the code. While not a critical vulnerability, it’s annoying. I wonder how the dotorg forums keep the numbers accurate? Maybe they don’t and nobody cares πŸ™‚ but it’s something I’ve been very passionate about – data accuracy and race conditions.

bbPress Can't Count

Continue reading



W3TCache + nginx + subdirectories

This is a simple instruction on how to make W3Total Cache (version 0.13.1) work with nginx (version 0.14) and subdirectory installs.

W3TCache + nginx + subdirectories

Continue reading



Testing Race Conditions in WordPress

WordPress is not thread-safe.

I’ve spoken about this, and even started work on a plugin called WP_Lock that will aim to introduce some thread-safety into core to address the occasional TOCTOU bug under high load (and concurrency). For example ticket #44568 is an easy-to-reproduce complaint about concurrent REST API access πŸ˜‰

Testing Concurrency Issues in WordPress with PHPUnit

If you thought writing thread-safe code in WordPress plugins is hard, unit testing the code for concurrency issues is even harder. One of the ways I found works best is by utilizing the PCNTL module in PHP to fork and test critical sections.

Continue reading



Part 3: Safety nets vs. bad code

If you haven’t looked at part 1 and 2 here, I suggest you do before reading on. This is a direct continuation of part 1.

So the original $wpdb->prepare vulnerability, which, I remind you is based on a potential typo in third-party code, is followed up with a new potential vulnerability based on double preparing a query. So again, bad third-party code.

So here’s one for you. If a developer does $wpdb->prepare( "SELECT * FROM wp_users where ID = %d OR %d". $_GET['param1'], $_GET['param2'] ); (note the . instead of the ,) do I also get a $500 bounty? How far will this go? Will the method be removed completely because #security? To what extent should WordPress and PHP be blamed for potential developer mistakes?

Shouldn’t these be addressed in the actual third-party code and not in core? I’m at a complete and utter loss now. What’s next?

Shout outs to Slavco for bringing all these issues up both with the codebase and the community, and how things are or should be handled.



On WordPress Security and Contributing

…and how neither really worked today.

A sad story in two parts, where I’m rash, harsh and untactful. An explanation, a rant, a call for support, a call for action. You do not have to agree with me, I may be just an asshole and haven’t realized it yet πŸ˜‰

Continue reading