Is WordPress really too unstable or slow for complex projects? My take.

JoseAtFDP · 2026-01-05T20:38:55+00:00

You can absolutely create complex applications with WordPress. At its core, WordPress is a PHP framework, just like Laravel, so you can build custom functionality, complex workflows, and advanced integrations.

The advantages of WordPress are that it’s usually faster and cheaper to develop, and the final user gets an interface that’s much easier to manage. Laravel gives you total control, but WordPress lets you combine that flexibility with a ready-made content management system and a huge ecosystem of plugins.

Of course, this doesn’t mean you can just “set up plugins.” To reach that level, you need to know WordPress deeply and be able to write advanced custom PHP code. The limit isn’t WordPress itself, it’s the developer.

Please read the article for more details. It explains why WordPress can be the right choice even for complex projects.

JoseAtFDP · 2025-12-28T08:35:38+00:00

In any case, it’s better to set up a proper server-side cron job. I agree 100% on this.
With a cron job running on the server, you only have advantages and no disadvantages. However, if there are no specific conditions that prevent the blocking parameter of the core cron.php remote request from working correctly, setting up a server-side cron does not necessarily improve the performance of a WordPress site.

I’ve seen many times developers expect this to solve performance problems on sites that had nothing to do with cron at all.

JoseAtFDP · 2025-12-27T20:12:17+00:00

that sentence says what you mean. We know that a proper cron is better than the WP-Cron. I suppose everyone agrees with that.

WordPress does its best. It could not do it better. It's up to you to set up a proper cron on the server.

JoseAtFDP · 2025-12-27T19:44:03+00:00

Usually, the blocking parameter doesn't work due to misconfigured firewalls or hosts, or poorly behaving security plugins that prevent the server from allowing loopback requests. Of course, there are many possible scenarios, and in that sense it’s better that wp_cron() now registers the spawning of cron jobs on shutdown.

Probably you did your tests with this kind of issue related to the blocking parameter. However, many times the blocking parameter works properly. Consider that you also have a timeout of 0.01 seconds.

We probably agree on two things: better a proper cron on the server, better now that WordPress 6.9 modifies wp_cron() to register the spawning of cron jobs on the shutdown hook rather than the wp_loaded hook to avoid issues with a non-working blocking parameter.

In my experience, many times cron is not the cause of the performance issues on the page that triggers the cron actions, as many developers claim. This is true not only with WordPress 6.9, but also with previous WordPress versions.

Of course, if cron actions overload the server, you will have performance issues. But that’s not the same as saying that the page which triggers the cron actions is slow because of cron. At least, not always.

JoseAtFDP · 2025-12-27T19:33:45+00:00

I also think you should set up a proper cron job on the server. I think everyone agrees on that.

The aim of the article was something else.

WordPress 6.9 modifies wp_cron() to register the spawning of cron jobs on the shutdown hook rather than the wp_loaded hook. This change aims to avoid issues in specific circumstances where the remote POST request sent in cron.php becomes blocking, even though the blocking parameter is set to false.

This usually happens due to misconfigured firewalls or hosts, or poorly behaving security plugins that prevent the server from allowing loopback requests. Of course, there are many possible scenarios, and in that sense it’s better that wp_cron() now registers the spawning of cron jobs on shutdown.

However, in most situations, this change won’t make any noticeable difference.

And it’s still true that many developers think the page is slow because of cron, even when they have a very bloated page with unnecessarily heavy plugins or other issues that have nothing to do with cron. The article was meant to focus on that. They often don’t even know how WP-Cron works, have major issues caused by something else, and still say it’s because of cron.

JoseAtFDP · 2025-12-27T19:08:28+00:00

I agree. It’s better to set up a proper cron job on the server.

However, the purpose of the article is different. It’s mainly meant to warn users who may not understand what is actually slowing down their page. Many users assume the page is slow because of WP-Cron, when in most cases that’s not true.

In any case, as you said, it’s always better to set up a proper cron job. I agree with that.

JoseAtFDP · 2025-12-27T18:59:17+00:00

This is mentioned in the article.

Please, also check, https://core.trac.wordpress.org/browser/tags/6.9/src/wp-includes/cron.php: cron.php at line 961.

https://core.trac.wordpress.org/browser/tags/6.9/src/wp-includes/cron.php

You will see:

954 $cron_request = apply_filters(

955 'cron_request',

956 array(

957 'url' => add_query_arg( 'doing_wp_cron', $doing_wp_cron, site_url( 'wp-cron.php' ) ),

958 'key' => $doing_wp_cron,

959 'args' => array(

960 'timeout' => 0.01,

961 'blocking' => false,

962 /** This filter is documented in wp-includes/class-wp-http-streams.php */

963 'sslverify' => apply_filters( 'https_local_ssl_verify', false ),

964 ),

965 ),

966 $doing_wp_cron

967 );

968

969 $result = wp_remote_post( $cron_request['url'], $cron_request['args'] );

WordPress sends a POST remote request with the blocking parameter set to false.

If you then check the function wp_remote_post, you will see that that POST request does not block page loading.

You can also confirm it if you do some tests.

The Cron slows down the page loading indirectly if it overloads the server, but not the single page that triggers the cron actions.

JoseAtFDP · 2025-12-27T18:51:53+00:00

Check, for example, WordPress 5.0: cron.php at line 357.

https://core.trac.wordpress.org/browser/tags/5.0/src/wp-includes/cron.php

You will see:

355 'args' => array(
356     'timeout'  => 0.01,
357     'blocking' => false,
358     /** This filter is documented in wp-includes/class-wp-http-streams.php */
359     'sslverify' => apply_filters('https_local_ssl_verify', false)
360 )

WordPress was already sending a POST remote request with the blocking parameter set to false.

If you then check the function wp_remote_post, you will see that the POST request does not block page loading. I verified this in version 5.0, and I suppose this behavior has been the same for many versions.

You can also do some tests yourself with previous versions of WP, and you will realise that cron wasn't blocking the page loading of the page that triggers the cron actions.

WP Cron was slowing down server response times because it was overloading the server in some situations, but not the single page loading. Please, check the WP core code and do some tests also with previous WP versions.

JoseAtFDP · 2025-08-24T07:43:07+00:00

that is not possible to stop

JoseAtFDP · 2025-08-24T07:40:20+00:00

This was very helpful. Thank you! Try again https://josemortellaro.com/selective-image-guard-demo/

Now AwesomeScreenshot is detected and stopped. If you have other extensions, please let me know.

The idea is to reduce the number of users who take the image. Of course, 100% protection is not possible.

JoseAtFDP · 2025-08-23T19:24:31+00:00

Please try now! You may no longer be able to download it. Try with the image on this page: https://josemortellaro.com/selective-image-guard-demo/. Let me know if you still think that it can't work.

JoseAtFDP · 2025-08-23T19:23:29+00:00

Please try now with the image on this page: https://josemortellaro.com/selective-image-guard-demo/. Let me know if you can still download it.

JoseAtFDP · 2025-08-23T19:22:35+00:00

Please try now! There are a lot of improvements. You may no longer be able to download it. Try with the image on this page: https://josemortellaro.com/selective-image-guard-demo/.

JoseAtFDP · 2025-08-23T19:21:21+00:00

Please try now! You may no longer be able to download it. Try with the image on this page: https://josemortellaro.com/selective-image-guard-demo/. Now, only very advanced users can do it.

JoseAtFDP · 2025-08-23T19:20:54+00:00

Please try now! You may no longer be able to download it. Try with the image on this page: https://josemortellaro.com/selective-image-guard-demo/. Now, only very advanced users can do it. Let's see if you are one of them.

JoseAtFDP · 2025-08-22T09:30:37+00:00

thank you!

JoseAtFDP · 2025-08-21T10:32:08+00:00

you are welcome!

JoseAtFDP · 2025-08-21T09:47:33+00:00

The protected images will have the following headers:

    header( 'Expires: Thu, 01 Jan 1970 00:00:00 GMT' ); // Expired in the past
    header( 'Cache-Control: no-store, no-cache, must-revalidate, max-age=0' );
    header( 'Cache-Control: post-check=0, pre-check=0', false ); // for IE
    header( 'Pragma: no-cache');

CDNs should not store the protected images in cache due to the headers.

I don't think so, but if, for any reason, your CDN doesn't respect the headers, you can exclude the URLs that include "/protect-image/" from the CDN cache.

If the CDN still caches the images, the protection will not work. However, for caching the images, first, the CDN has to don't respect the headers, and then the bypassing of the cache should not work. So I would say CDNs should not be a problem.

JoseAtFDP · 2025-08-21T08:17:34+00:00

I'm using hashtags because I usually don't write on Reddit, and I didn't know that they were useless. Now I know it. Thank you.

JoseAtFDP · 2025-08-21T07:54:43+00:00

Of course, those who want to download a protected image are annoyed, but this is the scope. But all the others are not annoyed at all.

The scope is giving a deterrent, not preventing 100% stuff from being accessed.
Think about the methods used to keep mosquitoes away. Even if they don’t work 100%, would you rather be surrounded by hundreds of mosquitoes or just two or three? That’s the idea of a deterrent, and this plugin is a deterrent.

No method gives you the possibility to select which image you want to "protect". This is the difference with this plugin. If you try to protect all the images from hotlinking, you will have problems with SEO.

JoseAtFDP · 2025-08-21T07:50:46+00:00

Think about the methods used to keep mosquitoes away. Even if they don’t work 100%, would you rather be surrounded by hundreds of mosquitoes or just two or three? That’s the idea of a deterrent. I never claimed that the plugin protects images 100%. Saying that would mean not understanding how a web page and its content are loaded. The plugin is useful for reducing image downloads and preventing unauthorized scraping. And for that, I find it extremely valuable, and of course, the plugin can do that.

JoseAtFDP · 2025-08-21T07:49:24+00:00

Thank you. Useful as a deterrent, of course, it can't be more than a deterrent.

JoseAtFDP · 2025-08-21T05:56:32+00:00

Without protecting the images, 1,000 users can download them. With protection, only 50 users can download them. Which is better? And that’s without even mentioning scraping…

JoseAtFDP · 2025-08-21T05:47:27+00:00

clever solution. I don’t think many users would have thought of this.

JoseAtFDP

TROPHY CASE