CurtisN

I got a chance to do more debugging and need to apologize for implying that the error I encountered was the fault of your plugin. Turns out it’s not.

Based on the error I listed in my first post I looked at the docs for ../wp-includes/pluggable.php and realized that another plug-in is either declaring wp_mail() before GSMTP or is causing ../wp-includes/pluggable.php to be loaded before GSMTP can load its version of wp_mail().

GREPing the code in the plugins folder revealed a few plugins that were loading ../wp-includes/pluggable.php directly.

One of these is alphabetically before GSMTP and since WP loads plugins in alphabetical order when the offending plugin is enabled it loads before GSMTP and causes this error. This has likely always been true and we simply never realized it because this plugin is usually disabled.

As I have no interest in forking the offending plugin to fix it so it does not load ../wp-includes/pluggable.php directly (seems like a bad idea to load pluggable.php for one function), I wrote a patch for my theme’s functions.php.

In testing I wrote a function that, if added to the beginning of GSMTP, will cause GSMTP to load before all other plugins by re-ordering the active-plugins array in the db.

It seems stupid that you should have to compensate for other people’s coding choices but if this is of interest to you, you can see the code at https://gist.github.com/curtisnehring/8d11437ab5c403d1903277f5da740588

Thanks for making your plugin freely available. I really appreciate it!

For others who run into this type of issue and stumble on this post, the function I am using in my theme’s functions.php can be seen at https://gist.github.com/curtisnehring/0241c35ee77744137d8adf17c099c480

• This reply was modified 3 years, 2 months ago by CurtisN.

David,

This is a new site and does not have much traffic yet. However, after clicking backup now, waiting a minute or two, and loading the front of the site, nothing happens. Over the last few tests I reloaded the front of the site every minute or so and it still took in excess of 20 minutes before the backup was run even when loading the site from a different browser to make sure cookies, cache, etc. were not an issue.

Is there any way to trigger a backup without the WP scheduler being a factor? I like your extension, it’s by far the best I’ve found of its type, but this issue causes a situation where I cannot make a backup before updating the site without waiting for several minutes to a half hour or more for the backup to happen. Which in turn makes site maintenance more time consuming than it should be.

I realize that this is not an error or issue directly caused by your extension but rather by WP scheduler taking it’s sweat time to run the scheduled task, but it seems like there should be a way to execute the backup immediately without waiting for some other WP process or function to be run.

Is there anything I can do to get the backup to fire immediately?

Thanks for your time and help.

Curtis

David,

Thanks for your reply. Yes I completely misread that as being when the backup was scheduled for. Sorry about that.

After reading your response I went back to look and sure enough the backup did run but it took over 30 minutes for it to do so.

EG. when I got your response I logged in and clicked backup now to see how long it would take. As of 2:32 pn PST the last log entry says “A backup run has been scheduled (Aug 08 21:16:02)” and the backup job run says “Thu, August 8, 2013 13:52”.

It seems like if this was working as expected, a backup should have already run.

Is there something I need to do to trigger the backup once I have clicked backup now?

Thanks again for your time and help.

Curtis