I spend a lot of my time on WordPress, for a fair number of different clients. When I have problems the experience and advice on blogs and support forums is always invaluable. To that end I’ve decided to start a series of blog posts myself. Here I intend to share solutions I have found for those little ‘bugs’ and ‘features’ that waste hours out of your day.
Disclaimer: This will be from my experience and understanding. I will try and keep it on the right side of tech waffle. If I get anything wrong feel free to shout out, helpful comments are always appreciated.
Installing a new plugin can be the start of all new problems
For this tale of woe all I wanted to do was install a simple plugin to send out emails and give the options of weekly and daily digests. I installed the plugin (BuddyPress Group Email subscription plugin) and all seemed well.
However, the emails never appeared.
The mystery of the missing digest emails
My approach to solve this sort of problem.
1. Check the error logs (nothing)
2. Check the support for the plugin (lots of posts)
3. Google problem (many results)
No errors in the error logs. Personally I like errors at this point, errors are nice flashing sign posts to tell me what I have done wrong. No such luck this time.
I checked the support forum and googled lots of different phrases. An hour later I seemed to have some answers.
The problem must be the wp-cron.php
After some research I found that WordPress relies on one main file for sceduling tasks wp-cron.php.
wp-cron.php runs when people access your WordPress website and checks if you have any scheduled events.
Something must be stopping this file from running properly.
The problem must be loopback is disabled on my host
After reading many posts, I found that some web hosts block loopback requests, this stops scheduled events in WordPress from working.
Yes like many shared hosting my web host does disable loopback. So I need to find another way to kick off wp-cron.php . The general concensus on the forums was that a manual cron job would do this nicely. Of course this only works if your host gives you access to cron.
My host has its own scheduled task interface. Does not give the full cron access, but basically works just the same. So I added the command below.
/usr/bin/php5 /home/sites/mydomain.com/public_html/wp-cron.php
I also disabled the automatic cron from running. I added the line of code below to my wp-config.ph file.
define(‘DISABLE_WP_CRON’, ‘true’);
Don’t know if this makes any difference, but as I was running it manually don’t see the need to run it on page load as well.
All sorted? Unfortnately not.
302 error error on wp-cron.php
I found that when accessed from the server, rather than a web browser, my wp-cron.php file was performing a 302 redirect to the registration page of my website .
Obviously I checked my .htaccess file but no redirect set there.
After much searching I found that BuddyPress and multisites sometimes have a function enabled line of code that redirects to the login page. This was not affecting my site when accessed through the browser but seemed to be in effect when I tried to run a command via cron directly on the server.
I disabled this by adding some code to my theme function.php file.
/** Disable BuddyPress Register page redirection **/
if ( bp_core_is_multisite() ) {
remove_action( ‘wp’, ‘bp_core_wpsignup_redirect’ );}
else {
remove_action( ‘bp_init’, ‘bp_core_wpsignup_redirect’ );
}
Disclaimer: Be aware that if this works for you it also disables this redirect, so if you need it, which I didn’t, then this may not be a solution suitable for your website.
Finally we have a winner
Sometimes solving a problem is like following a trail of bread crumbs. In my case it included at least two road blocks and a detour. Hopefully this process will help someone else.
What to look for to solve a similar problem
There are usually 5 main questions to ask yourself.
1. Have I done something wrong?
Check your error logs and go over the instructions again. You have often missed a vital step without realising it.
2. Is it permissions?
Depending on how your site is set up you may find that permission changes are needed. Be wary of making these two open. WordPress usually needs 775 for folders and 644 for most files. Don’t change permission without some research and create security holes on your website.
Useful link: http://codex.wordpress.org/Changing_File_Permissions
3. Is there support and advice from the plugin author?
Someone else has often had the same problem, so there may be an answer waiting for you on the forums or support pages. If you ask for help keep it polite and give as much information as you can without giving away any security information for your website.
4. Is this a plugin conflict or something in my theme?
Sometimes this is a case of elimination. Change your theme to the default or turn off all your plugins and re-enable them one by one, until you find a culprit.
5. Is it a setting on my web host?
Again give as much information as you can and be polite and factual with your request for help. Most web hosts don’t stricly support software you install on your web space yourself. That said, most support staff want to help you if you approach them in a reasonable and friendly manner.
It is hardly ever just one factor
The bad news is it is often a combination of more than one of these. Sometimes it is just trial and error. A break and some coffee also helps.
My number one tip
Always back up your website before you start any changes.
Sometimes putting it back and starting all over again is the best solution. Of course this solution is not always going to make you happy.
Right I’m off for coffee and cake. Have fun out there.
