Removing added Class Methods from Action/Filters in WordPress

To remove independent function from WP actions/filters is easy thing, we know. We just set remove_action(‘action_name’, ‘function_name’, PRIORITY); and that’s all.

But this simple way doesn’t work for Class Methods. That’s why there is another approach for classes.

remove_action('action_name', array($class_object_variable,'method_name'), PRIORITY);

Well, in some cases this method doesn’t help us either. f.e. When we shouldn’t re-construct that class. (if we declare some $obj=new CLASSNAME(), its construct method re-triggers, and some cases it may cause some problems)

So, what personally i use is guaranteed way – To list already added actions, detect the one we are looking for, get its temporary name generated by WP, and remove it.

In my case i will remove “woocommerce_proceed_to_checkout” action added by third party plugin’s class method “display_form” (priority=9 in my case). Here is how it looks:

add_action('init',function(){
  global $wp_filter;
  if(!empty($wp_filter["woocommerce_proceed_to_checkout"][9])){
    foreach($wp_filter["woocommerce_proceed_to_checkout"][9] as $key=>$removed){
      if(strpos($key,'display_form')!==false){
        remove_action( 'woocommerce_proceed_to_checkout', $key, 9 );
      }
    }
  }
},100);

Simple way to run WP Scheduled Crons

WordPress and Cron Jobs

As we know, by default WordPress is using its own pseudo-cron logic. It just runs at background, and while visitors don’t notice it, actual cron jobs runs when they are browsing our website.

Due to performance issues some developers decide disabling this auto-run at background and use custom calling instead.

For this purpose they simple add

 define('DISABLE_WP_CRON', 'true');

to wp-config.php file and then they add real cron job to their server’s crontab. Like this

* * * * * php /var/www/html/wp-cron.php

So it solves all problems. But, not all actually. I have faced some plugin’s where scheduled tasks are using some front-end data which doesn’t exist in php-cli mode.

That’s why for those cases i use simple trick.

Hybrid Solution – Keeping WP_Cron disabled at front-end, but with one exception.

Here is my code in crontab:

#you can keep this as well * * * * * php /var/www/html/wp-cron.php
*/5 * * * * wget --delete-after -qO- https://www.SITENAME.com/?custom_cron=1

And here is my code in wp-config.php

if(empty($_GET["custom_cron"])) define('DISABLE_WP_CRON', 'true');

These 2 small codes are doing this:

  • They are keeping wp_cron disabled for all visitors. So, no any according slowing down.
  • They let wp_cron to be enabled when custom_cron GET parameter exists.
  • And each 5 minutes, crontab calls https://www.SITENAME.com/?custom_cron=1 URL and runs all tasks via wp’s own cron.

Quick trick – running wp-cli command via Cron Job

WP-Cli via Cron Job in Crontab

Today i faced strange issue with WP-Cli command.

I have simple php script (let’s call it task.php) which runs through Crontab. All blocks of main procedure were running OK except one. That one with

shell_exec("cd /var/www/appname;wp COMMAND_HERE");

Nothing special, just one line of simple shell command.

I run the script in SSH Console

cd /var/www/appname; php task.php

and everything works OK, included shell_exec line.

But same script behaves differently when it is called from cronjob.

After quick investigation i noticed that it was because of WP command.

In cronjob the system doesn’t recognize this command for some already known reasons for me.

That’s why i had to set full path of WP command. And it started working.

Thus, if you face such problem, just replate this

shell_exec("cd /var/www/appname;wp COMMAND_HERE");

with this

shell_exec("cd /var/www/appname; /usr/local/bin/wp COMMAND_HERE");

And it will start working OK.

Restrict wp-admin access by IP – when you are using Cloudflare

Restricting your wp-admin access by using simple Apache’s .htaccess rules is easy, we know.

Just this rule and that’s all

<Files wp-login.php>
Order Deny,Allow
Deny from all
Allow from IP1
Allow from IP2 
#and so on
</Files>

But this would not work if you are using Cloudflare. Just because Cloudflare is middle layer between your website and your website visitor, and you get request with Cloudflare’s own IP-s, not clients’ IP-s.

In order to to lose this information about visitor IP, Cloudflare sends us real visitor’s IP as $_SERVER variable.

So, we just need to adjust our htaccess rule and pass $_SERVER variable there, instead of using IP addresses.

Here is simple htaccess code which works OK with Cloudflare:

SetEnvIF CF-Connecting-IP "SOMEIPHERE1" MyIP
SetEnvIF CF-Connecting-IP "SOMEIPHERE2" MyIP2
<Files wp-login.php>
Require env MyIP
Require env MyIP2
</Files>

That’s all. After saving this block to htaccess, your wp-admin would open for specified IP addresses only.

Easy way to collect all SQL queries in WordPress – with and without SAVEQUERIES enabled

As we know WordPress has built in DB class called WPDB and all SQL queries should run via that class.

And in WordPress Debugging the only way to collect/debug executed SQL queries is activating debug constant called SAVEQUERIES.

And this constant forces WPDB to collect all SQL queries – but to display or save those queries we need to use some custom function.

Q: Where to run that function?

A: Usually it is recommended to add saving function to wp_footer hook – simply because wp_footer runs after most processes are finished. (and admin_footer for wp_admin)

But this is totally wrong! Why? Just because wp_footer runs in template side and doesn’t include some processes such as AJAX processes.

So we need to use another hook for that.

Here are 2 simple ways to catch all SQL queries of WPDB.

Continue reading “Easy way to collect all SQL queries in WordPress – with and without SAVEQUERIES enabled”