Saving MySQL queries is the part of WordPress Debug processes.
If the website works slowly, probably there are some problematic MySQL queries which can be from some plugin or your current theme. Without debugging we can’t know what happens under the hood.
If to define SAVEQUERIES constant in wp-config.php, we can monitor all running queries in single process. To see that we can add simple code to our themes footer.php. Here is how it looks like
But it might not be enough helpful if we can’t catch the problem in our testing process. We may not detect the problem in action, but the visitors still complain about it. So what to do? Let’s keep SAVEQUERIES ON mode for some time and gather all slow queries for that period. At the end of this period we will be able to see all problematic queries and may be we will be able to solve them.
Add this string to our wp-config.php : define( ‘SAVEQUERIES’, true );
Add the code below to your theme’s footer.php. It will gather slow queries and save it to as WP Option data.
After some time passed, check get_option(‘custom_mysql_debug’); value, it will show all slow MySQL queries in one string, one per line. Here is what it will look like.
Let’s say that we have WordPress post objects with geolocation parameters.(lattitude, longitude). And we want to create geo filter and show relevant products to our visitors. For example if the visitor enters the website from New York, we want to show him only New York related products.
It is possible yeah. There are several ways. We can use 3rd party solutions (such as GeoPlugin ) in the website backend and detect where the visitor is. But to wait response from 3rd party service at backend – actually is not good idea.
So let’s try to do something at frontend side.
This piece of code detects the visitor geolocation, saves latitude + longitude as a cookie. Then it makes simple reload. It runs once when the visitor visits your website first time. And if you run this script before wp_head, the visitor will not feel redirect. So it will look smooth.
But what will happen at the backend side then? The only thing we need to do at backend side is to detect if the needed cookie exists and do some filters for that.
In this sample we have created sample filter which will show only those products which latitude is between 39-40, and longitude is between 47-49.
Sometimes it is so important to find any string in plugin or theme directory files. Or to find where the given function is situated. You have to edit some plugin hook, but you don’t know in which file it is.
It is more needed when the project is not yours, the code is not yours (for own codes there are native OS feature, desktop softwares, IDE, server commands for that).
I am using my own solution for that.
If i start working on fixing some issue on client’s live website, first i install this plugin, then use it when it is needed. It is very helpful when you don’t know how client’s theme/plugin built.
The plugin is lightweight and contains just one single file.
So, which steps we have followed to create this plugin:
Create empty plugin and activate it. (here is how to do it)
Register wp-admin submenu for the plugin’s action/settings page. (here is how to do it)
Create simple html form to submit data.
Write the needed backend code which does iterative file search in specified directory and displays the results.
With simple plugin we can create responsive adsense ad shortcode and put it anywhere inside our WordPress post.
Here is how to create it.
The usage is easy. Just put [responsive_adsense] anywhere inside your post, and responsive adsense ad will appear there.
Another shortcode in our code – [responsive_adsense_single] is for cases if you want those ads to appear only in single page (not in another pages where post content shown)
There are obviously a lot of ways to block our WordPress admin area login page from attackers, there are a lot of plugins for that.
But what if we want to build own logic – the secret key which changes itself daily, but we always know it, because we know its built logic.
For example what about if our secret key to wp-admin is today’s date + any custom string? Funny yeah? Or md5 encrypt of today’s date + any custom string – in this case nobody will recognize how this keys are generated.
Let’s write a little 2 functions which fulfill this solution.
In this sample our logic is ” secret key is current date + sesame” , so for example if today is 2016-10-10, our secret key would be 2016-10-10-sesame.
So yoursite.com/wp-admin?call=2016-10-10-sesame will work, yoursite.com/wp-admin will give 404 error.
You can also build your own funny logic which changes keywords by the current date, last post name or any other dynamic data. Or to hide how your key is built you can use md5 encryption for that.
For that purpose just use $secretstring = md5(date(‘Y-m-d’) . ‘-sesame’) in the code above.