Resources on WordPress

Make a query variable public

In case you are messing with custom rewrite rules in WordPress and especially creating new ones with the generate_rewrite_rules hook, you should know how to make a private (or a custom, which is by default – non-public) query variable public in order to have it working correctly in the rewrite rule.

It’s actually pretty simple – you just need to add a new element in the array, that is filtered by the query_vars filter. Like so:

add_filter( 'query_vars', 'so_employer_var_public', 10, 1 );
function so_employer_var_public( $query_vars ) {
    $query_vars[] = 'employer';
    return $query_vars;
}

add_filter( 'query_vars', 'so_employer_var_public', 10, 1 );

function so_employer_var_public( $query_vars ) {

$query_vars[] = 'employer';

return $query_vars;

}

That’s all.

“Nulled” WP Rocket when I got the original?!

Now here’s what happened to me last night. Follow me closely, as this will explain why you might get a very specific error message upon activating the plugin on staging or production environment one day, that would imply you have a nulled unlicensed plugin.

I installed my original licensed WP Rocket on my local development environment. As it was an older package, I decided to update it first, and then push it to staging. And so I did.

Once I pulled the latest code from my repo on staging and activated WP Rocket, I tried to configure the plugin, but got this message instead:

License validation failed. You may be using a nulled version of the plugin.

A tiny detail I need to mention here – the staging environment is not reachable publicly, as I’ve protected it behind a basic authentication wall.

So, it turns out that if you install WP Rocket in one place and then move it to another, protected WordPress instance, the plugin will not be able to work, as it will assume that the user is trying to configure a compromised plugin with malicious code inside.

How did I fix this?

I removed the new version of the plugin, then installed the original one, without activating or updating it on my local environment. Activated it staging and it worked just fine there.

Expired transients don’t get deleted on protected sites

I found it the hard way.

My database is rather small. It’s actually less than 20 Mb in total. That’s of course, if I exclude the 1.4Gb of data that I have in wp_options alone. Most of if being transients. Most of which have expired some time ago.

I’ll spare you the story of how I came to the conclusion, but will skip straight to it:

If the whole site is hiden behind a basic authentication (htpasswd) wall, then there is a very good chance the wp-cron will not be running. And if it’s not running, it will not run the process for deleting expired transients, which would lead to causing the database clogging.

Generating a new administrator user in WordPress through SQL

If you need access to a website, built on WordPress, but you have SSH access only, you could still cope with the situation with a few line in the command line.

Here are the steps you need to follow:

Find the database credentials. They are usually in wp-config.php file under the web-root directory of your WordPress based website.
Connect to the database, using the credentials from the configuration file, using the following command

mysql -u <username> -h <hostname> -p

1

mysql -u <username> -h <hostname> -p
Switch to your database:

use <databasename>;

1

use <databasename>;

Create your user:

INSERT INTO `users` (`user_login`, `user_pass`, `user_nicename`, `user_email`, `user_registered`, `user_activation_key`, `user_status`, `display_name`) VALUES ( 'your-username', MD5('your-password'), 'Your Name', 'your@email.com', '2018-07-18 14:10:00', '', '0', 'Your Name');

1	INSERT INTO `users` (`user_login`, `user_pass`, `user_nicename`, `user_email`, `user_registered`, `user_activation_key`, `user_status`, `display_name`) VALUES ( 'your-username', MD5('your-password'), 'Your Name', 'your@email.com', '2018-07-18 14:10:00', '', '0', 'Your Name');

Check the id of the newly created user. Try to guess the right SELECT, and if you can’t, go standing face to the wall and repeat a hundred times “I should not mess with the database if I don’t understand basic SQL.”. Seriously.
Make your user an administator with this:

INSERT INTO `usermeta` (`user_id`, `meta_key`, `meta_value`) VALUES ( '<user_id>', 'capabilities', 'a:1:{s:13:"administrator";s:1:"1";}');

1

INSERT INTO `usermeta` (`user_id`, `meta_key`, `meta_value`) VALUES ( '<user_id>', 'capabilities', 'a:1:{s:13:"administrator";s:1:"1";}');

Now you should be able to login with your username and password.

Recovering missing Facebook comments (and like counts) after switching to SSL

You might notice that you are missing your Facebook comments once you switch to HTTPS from serving your site initially on HTTP. The problem is with Facebook not linking the old URLs with the new ones, which is why you might have to do some additional work in order to have your comments back.

It’s important to notice that you’ll still have your Facebook comments form and you might even have some new comments there from after you switched to using SSL, but the old ones from before that would be gone. Not irreversibly, though.

Here is the solution I found in a couple of WordPress.org Forum threads. It worked great for me:

Install and activate Really Simple SSL plugin (https://wordpress.org/plugins/really-simple-ssl/);
See if your dashboard breaks. It did on one of my sites due to some weird environment edge case.
Add a custom replacement for HTML attributes that would contain the address of the website with HTTPS, instead of HTTP:

add_action('rsssl_fixer_output', 'rsssl_exclude_http_url');

function rsssl_exclude_http_url($html) {
  $html = str_replace('data-href="https://pod-rb.eu', 'data-href="http://pod-rb.eu', $html);
  return $html;
}

add_action('rsssl_fixer_output', 'rsssl_exclude_http_url');

function rsssl_exclude_http_url($html) {

$html = str_replace('data-href="https://pod-rb.eu', 'data-href="http://pod-rb.eu', $html);

return $html;

}

Oh, it’s usually the same problem with Facebook likes, so don’t worry that much if all of a sudden you lost all your Facebook like stats on your like buttons in the site. Same solution should fix this too.

Some good sources for starting your knowledge path in SEO

A friend of mine sent a list of resources to a client of mine and CC’ed me in the conversation. I do find these resources really helpful, which is why I decided to put them here. We are not affiliated to any of the sources.

SEO 101:

Google’s SEO Starter Guide https://static.googleusercontent.com/media/www.google.com/en//webmasters/docs/search-engine-optimization-starter-guide.pdf

MOZ: https://moz.com/beginners-guide-to-seo

WordPress SEO hints by the authors of the most popular WordPress SEO plugin: https://yoast.com/wordpress-seo/

Search Engine Land: https://searchengineland.com/guide/seo

SEO Blogs:

Backlinko: https://backlinko.com/blog

Neil Patel: https://neilpatel.com/blog/

SEMRush: https://www.semrush.com/blog/

“Sorry, you are not allowed to access this page.” on News Cherry theme options page

The problem

It happened to a client of mine just recently – they tried to change something in the theme options, but they couldn’t, as reaching out to http://their-site.com/wp-admin/admin.php?page=options.php produced

“Sorry, you are not allowed to access this page.”

message. The theme is News Cherry by Bdaia, found on ThemeForest.

The solution

Turns out the theme is using the native WordPress file editor, which is used for editing themes and plugins through the admin panel. So once we’ve disabled this through iThemes Security -> WordPress Tweaks, it stopped working for accessing the theme options. If iThemes Security is not present or the option there is disabled, it would be a good idea to check your wp-config.php file for

define('DISALLOW_FILE_EDIT', true);

1	define('DISALLOW_FILE_EDIT', true);

and set it to false. It’s a good setting to be enabled, so News Cherry is to be blamed for forcing you to lower your guard.