Title: "?doing_wp_cron" Last modified: August 19, 2016 --- # "?doing_wp_cron" * [lilydustbin](https://wordpress.org/support/users/lilydustbin/) * (@lilydustbin) * [15 years, 5 months ago](https://wordpress.org/support/topic/doing_wp_cron/) * Whenever any link on my site (mabellearts.ca) is hit, “?doing_wp_cron” is always added to the end of the URL. * So for example, if you go to [http://mabellearts.ca](http://mabellearts.ca) – often it resolves to [http://mabellearts.ca/?doing_wp_cron](http://mabellearts.ca/?doing_wp_cron) * I first noticed it when I couldn’t get my RSS feed to resolve properly with some readers. * Can someone point me in the right direction to correct this? Viewing 10 replies - 1 through 10 (of 10 total) * [mkirkwag](https://wordpress.org/support/users/mkirkwag/) * (@mkirkwag) * [15 years, 5 months ago](https://wordpress.org/support/topic/doing_wp_cron/#post-1782925) * The same thing happens to me when I use a twitter feed plug in – all the twitters have and addition at the end that results in a 404 error – I’ll look forward to reading the answer! * [dolekjole](https://wordpress.org/support/users/dolekjole/) * (@dolekjole) * [14 years, 10 months ago](https://wordpress.org/support/topic/doing_wp_cron/#post-1783284) * For others have the same Problem: [http://wordpress.stackexchange.com/questions/12777/what-is-this-doing-wp-cron](http://wordpress.stackexchange.com/questions/12777/what-is-this-doing-wp-cron) * [Pieter Bos](https://wordpress.org/support/users/senlin/) * (@senlin) * [14 years, 8 months ago](https://wordpress.org/support/topic/doing_wp_cron/#post-1783290) * it seems that backupbuddy is the cause of this problem… * [DrProtocols](https://wordpress.org/support/users/drprotocols/) * (@drprotocols) * [14 years, 7 months ago](https://wordpress.org/support/topic/doing_wp_cron/#post-1783291) * Could you please explain that statement? * The appearance of the doing_wp_cron tag on a url is related to the use of the alternate wp cron “fix” which some people have to enable because their host has disabled loopbacks and hosed their WordPress scheduling. Without that fix no scheduled tasks will be executed on the site. Their are loads of plugins that create scheduled tasks and if they cannot be run then the behaviour of that plugin is compromised. * The “cause’ of the problem is the host disabling loopbacks. * If the alternate wp cron fix doesn’t work for you then either you have to accept that you can’t use _any_ WordPress functionality that requires task scheduling; move to a more enlightened host or investigate external means of triggering the scheduling. * [Pieter Bos](https://wordpress.org/support/users/senlin/) * (@senlin) * [14 years, 7 months ago](https://wordpress.org/support/topic/doing_wp_cron/#post-1783293) * The actual **cause of the problem** is the line defining ‘ALTERNATE_WP_CRON’ in the wp-config.php file. * BackupBuddy suggest to add that line if the host does not enable loopbacks. * On a sidenote, I asked my host (Bluehost) to enable loopbacks and I had to explain myself quite a few times before they understand what it means. The term “enabling loopbacks” does not seem to be an official and/or technical term. * On top of this, a **free** plugin like WP-DB-Backup also schedules tasks and works out of the box. I just don’t understand why a premium plugin like BackupBuddy cannot work like that and why it does not issue a warning to potential buyers. After all, it’s not an unknown issue… * [DrProtocols](https://wordpress.org/support/users/drprotocols/) * (@drprotocols) * [14 years, 7 months ago](https://wordpress.org/support/topic/doing_wp_cron/#post-1783294) * That makes more sense – basically the advice given is the standard advice for someone trying to operate a WordPress site and needing WordPress scheduling capability where the host has disabled loopbacks (or they aren’t working for some reason). * The response you may have gotten from your host sounds like a fairly standard first-line, knee-jerk response from a lot of hosts – basically they try and deny all knowledge of something and hope it goes away. I’ve had some shocking responses from hosts when they think you don’t know what you are talking about – when it becomes clear that you do it’s quite amusing when they try and backtrack and pretend it was “just a miscommunication” blah blah. “Loopback” is actually a commonly used term and is certainly used by the WordPress community – actually see here for the full run down on the requirement for the alternate cron fix: [http://wordpress.org/support/topic/scheduled-posts-still-not-working-in-282?replies=13](http://wordpress.org/support/topic/scheduled-posts-still-not-working-in-282?replies=13)( see Otto’s post a short way down). If your host support realy doesn’t understand it then shame on them; if they do understand it but are just hoping you’d drop it then shame on them again – either way they deal in servers, it’s their job to know and that’s what you pay them for 🙂 * As regards another plugin like the one you mention – I think that has a totally different backup paradigm and in any case only does a fraction of what BackupBuddy does – I think it even mentions only backing up the core WordPress database tables so hard luck if you have any other important tables. Also you have to restore using phpMyAdmin, it doesn’t do migration etc. I don’t think it uses task scheduling as part of it’s actual backup process and you’d probably find the backup scheduling doesn’t work if loopbacks are disabled and alternate wp cron fix isn’t in place. Don’t get me wrong, I’m sure it’s a great plugin for what it does and if that’s all you need then great, go for it, but if you need more you can’t really compare the two 😉 * [Pieter Bos](https://wordpress.org/support/users/senlin/) * (@senlin) * [14 years, 7 months ago](https://wordpress.org/support/topic/doing_wp_cron/#post-1783295) * WP DB Backup indeed doesn’t do all the stuff that BackupBuddy offers, but it does do scheduling of backups and on the exact same host with the exact same setup it works without any problems! * So, got that out of the way 🙂 * Actually I opened a ticket for the issue at Bluehost and their “advice” was to find another host… * So I think they’re not inclined to do anything about it. * As I am quite happy with Bluehost and I find the issue too minor to change hosts over and somehow miraculously BackupBuddy seems to be able to do the task it was made for, I have dropped the issue. BUT, even if BackupBuddy would not be functioning properly I would never change hosts over a plugin issue! * But having said that, I do lay the blame with BackupBuddy as they are very well aware of the issue and they should at least mention it to the potential buyer. * This is similar to selling an insurance to a home owner and telling the home owner after payment that the insurance in his street is not valid unless he A. redecorates his home or B. moves to another street. * [DrProtocols](https://wordpress.org/support/users/drprotocols/) * (@drprotocols) * [14 years, 7 months ago](https://wordpress.org/support/topic/doing_wp_cron/#post-1783296) * Ah, well that’s changing the goalposts a bit then. Looking at the information from iThemes it does say that the fix for cron is for a very specific problem with the loopbacks. Probably if you have no other indication that loopbacks are not working (or you have actual positive proof that they are) then that isn’t actually the specific problem you have and therefore you shouldn’t be making that change. * There are other reasons why scheduling can fail (for a task to actually be scheduled or for a task to fail to be executed) as other topics in this forum and across the interweb will testify. So this may depend on some specific problem on your installation – things like prematurely terminated database connections, plugin conflicts, etc. Maybe the backupbuddy scheduling of backups works but the actual execution of the backups fails – different thing? * As regards “blame”, hmm, that’s a tricky one – in the case where loopbacks really are disabled this isn’t the “fault” of iThemes is it? Did the host who claims to provide WordPress hosting say that actually loopbacks are disabled and so they are hobbling your shiny new WordPress installation from the get go? Especially as WordPress itself recognizes this negative behaviour by hosts and _specifically_ provides a workaround for it as standard WordPress functionality so that _standard_ WordPress functionality _and_ plugins that require this capability can actually function. Shouldn’t a “reputable” host be “well aware” of the consequences of their behaviour and at least mention it to potential buyers of their hosting service (and please note that unavailability of loopback capability doesn’t necessarily affect just WordPress but can affect application behaviour in general). * I’m not sure what backupbuddy would say and whether it would mean anything to 95% of the people who might (just might) read it – maybe your host may disabled loopbacks which means they are crippling your WordPress installation in which case WordPress provides a workaround for you… Would that make any difference, don’t know? How many people would actually read that, how many would understand it, how many would it actually apply to, would they ask their host? It would probably just make life more confusing. * I’m happy that you are happy with Bluehost and, as you mention, your backupbuddy plugin is working (which probably means the main issue isn’t disabled loopbacks?) but I am constantly amazed when I read posts from people who seem prepared to forgive their host anything and lay the “blame” for any problems at the door of another. Low cost hosts are low cost for a reason – they just rely on volume, packe ’em in, pile ’em high and if a customer isn’t happy then it doesn’t really matter as there will be another along in a minute. It’s a perfectly valid business model for sure, but if you buy into it you also have to accept the consequences and limitations and not simply try and shift the responsibility for overcoming those elsewhere. Not a personal comment on you, just a general observation 😉 * Anyway this has probably gone way off-topic so probably best to draw a line 🙂 * [Pieter Bos](https://wordpress.org/support/users/senlin/) * (@senlin) * [14 years, 7 months ago](https://wordpress.org/support/topic/doing_wp_cron/#post-1783297) * i can’t help but wonder whether you are somehow related to/with iThemes… * [DrProtocols](https://wordpress.org/support/users/drprotocols/) * (@drprotocols) * [14 years, 7 months ago](https://wordpress.org/support/topic/doing_wp_cron/#post-1783298) * I am a customer of iThemes and I have experience of WordPress and using various plugins as well as maintaining website for various clients on which I use iThemes products – does that somehow invalidate what I have said? You can take it or leave it as you like but it’s all just based on personal experience and getting on and getting things done. If you (as in the general hosting customer world) are happy to give your money to a host and be happy with whatever they happen to feel like giving you then fine, personally I prefer to hold them to account and if they are shortchanging me without telling me then I’m happy to move elsewhere where I get a better product and better service – you are of course entitled to your own view 🙂 Viewing 10 replies - 1 through 10 (of 10 total) The topic ‘"?doing_wp_cron"’ is closed to new replies. ## Tags * [cron](https://wordpress.org/support/topic-tag/cron/) * [doing_wp_cron](https://wordpress.org/support/topic-tag/doing_wp_cron/) * In: [Fixing WordPress](https://wordpress.org/support/forum/how-to-and-troubleshooting/) * 10 replies * 5 participants * Last reply from: [DrProtocols](https://wordpress.org/support/users/drprotocols/) * Last activity: [14 years, 7 months ago](https://wordpress.org/support/topic/doing_wp_cron/#post-1783298) * Status: not resolved ## Topics ### Topics with no replies ### Non-support topics ### Resolved topics ### Unresolved topics ### All topics