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”

Creating Custom Warnings and Conditions for Contact Form 7

The most Contact Form plugin for WordPress is Contact Form 7, indeed. It has very simple structure and shortcode logic. By default it offers very simple features, meanwhile there are a lot of custom addons for it.

Sometimes i need to put some unique custom rule inside Contact Form 7, without finding corresponding addon.

Here is how i do this:

Continue reading “Creating Custom Warnings and Conditions for Contact Form 7”

How to use the plugin template file as a theme template in WordPress

If the plugin contains some UI components, we can easily use it in the theme’s UI by putting widgets, shortcodes, JS enqueued scripts etc.

But there might be some plugins which may have completely independent UI template.

What to do in such cases? The plugin may have its own template with its own CSS, JS, UI – Say active theme is built on some custom CSS framework – but your plugin should use its own UI built on Bootstrap Framework. So they can’t live together if we just enqueue the plugin’s CSS, JS and use our UI as a shortcode or widget.

The only normal ways seems to create theme template logic inside the plugin.

Fortunately, it is possible and doesn’t need additional hacks and cheats.

Let’s first create some empty template file inside the plugin’s directory, called “the_plugins_template_file.php” – Custom Template

Continue reading “How to use the plugin template file as a theme template in WordPress”

Internal 500 error after directory renaming

Today in one client’s web hosting (it is Nexcess, but same problem can appear in another hostings using the same technology) i needed to rename WordPress home directory. (It was installed in a sub-directory)

I renamed directory, then modified .htaccess file, and then i changed siteurl and home options in wp_options table.

These simple steps above are quite enough for making WP to work in new directory. But i started getting strange errors instead.

Fatal error: require_once(): Failed opening required ‘/chroot/home/sitename/OLDNAME/wp-blog-header.php’ (include_path=’.:/opt/…/php’) in /chroot/home/sitename/OLDNAME/wp-blog-header.php on line 52

I have checked cache layers (all cache layers were turned off at that time) and configurations. Nothing wrong. Everything was provided correctly. Then i tried to print directory name before the line

require( dirname( FILE ) . ‘/wp-blog-header.php’ );

at index.php file. After saving and testing i saw that above error was solved and i started getting the same error for another file:

Fatal error: require_once(): Failed opening required ‘/chroot/home/sitename/OLDNAME/wp-load’ (include_path=’.:/opt/…/php’) …

This time wp-load.php can’t be loaded. At this time i figured out that there is some hosting based software which can’t be refresh itself after renaming directory (BTW, apache or httpd restart doesn’t help in this case) – but if you modify the file, it pings that software and that file starts to be recognized by webserver.

So there were two ways in order to solve the problem under those conditions.

  • To modify thousands of WP files one by one – which would be stupid time wasting.
  • To send some “ping” to all files. – That’s what i did. I opened SSH command line and run this command:

find -type f -exec touch {} +

This command doesn’t modify any file, it just modifies their timestamp data which is quite enough in our case.

After running this command the website started working normally under its new name.