The other night, I was browsing my posts list in my admin panel on the website and noticed something odd — my scheduled post for yesterday morning didn’t actually post. And right next to it in the internal WordPress admin panel was a nice little red warning called “missed schedule”. I had seen this before and thought it was just a glitch, no biggie — just click publish now and it goes live. No problem with the post, it just didn’t go live when it should have. I don’t often schedule future posts when I’m writing detailed posts, although I might change the time stamp to 8:00 or 9:00 in the morning even if I’m writing it at 1:00 in the afternoon, like now. Just a small quirk I do to manage an indexing protocol that checks the time stamp, no real reason.
However, from time to time, I will write a bunch of posts all at once, and I want them spread out over several days. So I “schedule” them for future publication, usually 9:00 in the morning. So, the question was, “Why didn’t they post?”.
Running around the WordPress community
As with most glitches with WordPress, one is often not the first person to encounter it. Simply googling “WordPress Missed Schedule” brought up a whole series of people who had the same problem, posed the question online and had people respond. In most cases, their problem was slightly different in config once I scratched the surface, or the solutions were a bit different than what would seem to fit my situation. However, they did send me looking into several plugins.
I tried a plugin called WP CRONTROL that wasn’t a fix so much as a way to glean some additional diagnostic information. Namely that the small “glitch” was bigger than I thought — my CRON file was not running, and there were problems going back to August. Hundreds of behind-the-scenes happen on your website without your having to control them directly, little bots that can run from time to time, and your website software or the server software has ways to schedule them. Basically the same as your CALENDAR on your computer keeping track of reminders, etc., or even your regular WINDOWS update that does certain things at regular intervals. In this case, WordPress has a file that keeps track of all things it has to do (its own internal to-do list) called WP-CRON. I started trying to clean out the long list of expired entries but it would take forever.
So I added another cron manager called ADVANCED DATABASE CLEANER. Sure, I could have logged into the PHP admin area of my website and manually cleaned things in my database, but why would I do that when this plugin would do it for me?
Down the rabbit hole
I went down a rabbit hole after that. Lots of little tips and tricks everywhere, but few that were specific enough to help me, nor even in a good logical fashion. More like eight hundred people playing hunches and trying something on their server, some with luck, some with none. I jumped the queue while I was working through some of the options and started chatting with the Server Customer Support Rep, but honestly, their Tier 1 people are more about sales than they are tech support. They do okay, but this is way beyond them.
What I often find helpful though is that explaining the problem to them seems to crystallize it better in my own mind, and often triggers thoughts to try x or y that hadn’t occurred to me earlier or that I dismissed too soon. And it gave me a structure for understanding how to solve the problem.
A. GET YOUR DIAGNOSTICS
As I mentioned above, I used WP CRONTROL to see the list of cron activities and ADVANCED DB CLEANER to fix it a bit. WP CRONTROL also told me there was a 403 error (forbidden) on the WP-CRON file, but it wasn’t very convincing since some of the other errors might be causing it.
After going around the pole a few times, I found a great little tool called WP CRON STATUS CHECKER. It only has a few hundred downloads/installs, and it is a great little tool. The plugin doesn’t have a lot of info with it, but it adds a widget in your dashboard that tells you the status of your CRON files. It DOES nothing to fix problems but it does a quick test to see if WP-CRON can even run, and if not, tells you the status (403, etc.). I wish I had found this first. It told me for sure part of the problem was that WP-CRON was not running. And once fixed, you can deactivate it and leave it off. If you leave it activated, it will run on its own every 24 hours to check, but my site isn’t busy enough that I need that level of monitoring.
B. CHECK .HTACCESS
HTML sites have a small file in the directories called “HT access” that controls how visitors can access the individual files in the directory and subdirectory and is the second line of defense against people doing silly things like writing files and overwriting certain files on your site. On sites like WordPress, it’s the equivalent of a master security file that controls a lot of the subsequent access rights.
Some sites said to see if .HTACCESS was corrupted, but I was pretty sure mine wasn’t (I have other plugins that check the status of HTACCESS regularly, they would throw flags if it was corrupted).
What the sites FAILED to mention was that it isn’t just simple CORRUPTION that could be screwing up WP-CRON, it could be the actual proper setup is messing with it. I should have thought of that immediately when I saw the earlier 403 FORBIDDEN message in WP CRONTROL, but when I saw it again in the WP CRON STATUS CHECKER, I knew I had found my problem. Unfortunately, I did this step sixth or seventh instead of second!
The simplest way to see if .HTACCESS is your problem is to temporarily rename it something like .HTACCESS_TEMP or .HTACCESSXX. Then check the status again — if it was .HTACCESS causing the problem, the status will go green when you check after renaming it. If it is still red, move on to other options.
C. CHECK SECURITY PLUGINS
I run WordFence and iThemes, and of all the types of plugins, security ones are the most likely to cause access issues like above and conflicts with other plugins or activities. So, I temporarily deactivated them and then checked my other settings. Nope, still broken, so that was out.
D. CHECK OTHER PLUGINS
Anyone who has had a problem with WordPress, or really any CMS ever, they know that the simplest way to look for a conflict is to just deactivate all your plugins. Considering some people are running TONS of plugins, this isn’t often the favorite solution, but it’s better than turning them off and on one at a time. I deactivated them all, checked status, still broken.
E. CHECK FILE PERMISSIONS FOR WP-CRON
Of course, lots of people would say to check this one first — if WP-CRON is the problem, the “obvious” first step could be to check the file permissions on that specific file to see if the settings are wrong. Good logic, but since WP sets them in batches, the reality is that other files would likely have the wrong settings too and would have thrown red flags much earlier. Remember that this is a low-level file that only flags errors when it DOESN’T run.
For me, I temporarily changed the setting to 777, full read/write/execute and checked status again. Still broken.
F. CHECK FOLDER PERMISSIONS FOR WP ROOT DIRECTORY
I can’t say this would have occurred to me on my own. If WordPress is running, the folder must be set pretty close to right, or the red flags would be borderline catastrophic for failure. Never the less, it was still worth a try — again, I changed to full 777 rights, no change, still broken.
Why did I do all those things?
If all those had failed, I would have eliminated the three most likely internal problems:
- corruption of access files;
- access / permissions to the file or folder; and/or
- conflict from security or other plugins.
That leaves you three other options that I’ve seen:
- Try a plugin called WP MISSED SCHEDULE. It isn’t on the main WP install directory, you have to do it manually from GITHUB. I’m personally leery of installing plugins that don’t reside in the WP repository, and on top of that, the installation instructions did not seem awesome for clarity. Lots of people have tried it and had it fail; others did it and said it worked; others said, “huh?”. I also feel like if the problem was any of the first five, this plugin would not fix any of those issues.
- Check with your host to see if there is a server config issue. Lots of people have said very simply, “Oh, it’s a config issue, contact your server”, but that is a bit too reactionary. If it is any of the above issues, the server people won’t know how to fix the problem either and unless you’re paying a lot for access to their tech support personnel, they’ll say, “Sorry, that’s a software issue, you’re on your own”. I used mine to get the ticket started, but I had resolved the diagnostic phase before we were done creating the ticket and I had figured out it was an .HTACCESS issue which they don’t help with anyway.
- Bypass WP-CRON and create a server cron file to do it at the server level. Yep, to me that’s as advanced as it sounds. If you google, you’ll see lots of people who have written why they don’t use WP-CRON, why they turn it off, etc. Almost all of them are hardcore techies who are totally comfortable running LINUX, the type who would thumb their nose at building a Raspberry Pi project as “toys for kids”. If you go this route, and you have access to CPANEL setup, it really is a single line to tell it what to run and when, but I confess it didn’t work for me, and I didn’t want to mess around too much in that level of direct intervention
You might note that I’ve also left out the nuclear option of reinstalling WordPress from scratch. Honestly, that is pretty low on the list of probable solutions if you have done an upgrade from a previously working version and haven’t mucked around with the configuration too much recently. It *should* work, and if it doesn’t, something else is likely configured wrong, not your basic WP install. Always worth a shot of course, and many people would say to start with that in the first place. Who would say to do that? Those who did everything else, failed, tried a fresh install and it solved their problem and now they preach purity of install. 🙂
So what does this have to do with running my own server?
All of these problems? And I’m only talking about a SMALL software config issue that sent me way down the rabbit hole. If I was running my own server, I would have another 20 possible causes, all having to do with either server configuration or potentially even a hardware issue. One of the “saving” graces to paying someone else to carry the load of managing / running a server with a large hoster is that the cost/benefit ratio to me is WAY in my favour, particularly the number of times a problem like this has frustrated the hell out of me. I don’t need that added stress in my life. And if others are running the same install just fine on the big server, I know it is MY problem, not a technical screw-up that I did in the server setup. Worth it’s weight in gold.
As for me, now that I know it’s an HTACCESS challenge, I can push it to the back burner. I can work around it for now, and at some point, I’ll fix it. For now, I’m leaving it alone.
If you ended up here while searching for a solution, feel free to let me know how it’s going in the comments!
