David

Ditto to all of that. Virtually all of my data is added through Advanced Custom Fields, but just finding links in specific custom fields on custom post types would be enough for me.

I had this problem and think I figured it out. In the Settings, under the Advanced tab, check the Server Load Limit setting. Mine was preset to 4 after installing the plugin, but my server was constantly running at about 50… maybe because I’m on shared hosting. I simply removed that value so there was no load limit, and now the plugin is working!

I have the same problem and have tried just about every configuration option imaginable. If page caching is disabled in W3TC, the form submission works fine. If page caching is enabled, the spinner doesn’t stop. The contact form is in the footer and even if the page itself is not getting cached, the form submission still doesn’t work. As noted above, the email does send, but I’m using an on_sent_ok setting to open a confirmation modal, which never shows.

If I use WP Super Cache, it works fine. If I use every other option in W3TC, it works fine. The problem is simply when page caching in W3TC is activated. I have tried deactivating all of the options on the page caching settings page, and I have added footer.php to the ignore list, all to no avail. Thanks for any insight you have on this.

I am having this exact problem… I have a contact form in my footer.

If I disable the page caching option in W3 Total Cache, everything works fine, even with that plugin activated.

When I enable page caching, the ajax loader just spins for forever (it literally never stops) after I submit the form. It DOES actually send out the email, but it doesn’t display a confirmation message — not even a failure message.

I spent a couple hours trying to figure this out, testing different configurations. Nothing I did helped the issue. I’m using the latest version of everything.

Here’s the solution:
https://www.ads-software.com/support/topic/not-working-with-35-39?replies=1#post-3734116

3.5 isn’t the issue… the plugin simply doesn’t work, because Youtube changed their system.

You need to replace the ampersands with question marks and remove “?feature=oembed” entirely. I’m not sure if there’s a downside to doing this… all I know is that it works.

Here’s the bad code on line 33:
return str_replace('&feature=oembed', '&feature=oembed&rel=0', $data);

And here’s what it should be:
return str_replace('?feature=oembed', '?rel=0', $data);

However, if you’re like me and use other embeds, like Flickr, you’ll want to make this adjustment for Youtube embeds only. So here’s what I changed line 33 to:

$data = preg_replace('/(youtube\.com.*)(\?feature=oembed)(.*)/', '$1?rel=0$3', $data);
return $data;

Hope that helps.

Tom, thanks for adding the option of a custom root to the latest update. The plugin now works out-of-the-box for me, and I’m finally using the latest version! I did notice a few minor bugs. Please let me know if some of these should go in another thread.

1. The download link to the zipped archive is going to “https://example.com-content/backups…” instead of “https://example.com/wp-content/backups…”

2. I can exclude folders like “/uploads/” in the exclude section, which correctly excludes that folder from the backup. However, at the top of every admin page it shows a warning: “BackUpWordPress has detected a problem. You have defined a custom exclude list but the following paths don’t exist /plugins/, /uploads/”, etc.
If I use “https://example.com/wp-content/uploads/”, then that doesn’t show a warning, but it also doesn’t actually exclude the uploads folder from the backup.
An easy “fix” for now would be to limit the warning to only BackupWordpress admin pages. I would be fine with that, because I know that it’s a false warning. But when all my editors have to look at that on every admin page, it’s a bit annoying.

3. In the exclude box, “, /plugins/, /uploads/” correctly excludes both of those directories, but “/plugins/, /uploads/” does not exclude the plugins directory.

Hope that helps.

Tom, thanks for trying to fix it.

There are still some issues though. The problem isn’t that my ABSPATH is at ‘/’; it’s that my ABSPATH is different from my content path. In fact ABSPATH for me is what it always is: the path to WordPress. But my content sits outside of that. For me, ABSPATH = “/wp/”, and WP_CONTENT_DIR = “/wp-content/”. To backup everything I have, I’d need to backup from the document root, not ABSPATH. For me personally though, I only care about backing up from WP_CONTENT_DIR, since WordPress is already backed up through the repo.

Here’s what I see: when I activate the plugin it lets me backup like normal, which backs up /wp/. When I go download the zip, it has a problem with the url. It tries to download it from “www.my-site.com-content/backups…”. Obviously that throws an error, so when I manually insert in the missing “/wp”, it works. I make a change on line 157 (mentioned up above) and it backs up everything like I want it to. I exclude some paths (like “/wp-content/uploads/2010”), and it always throws a warning error, since it’s not in /wp/.

Hope that helps you understand what’s going on, and I think this setup of mine is not unique, since I did it by following Otto’s tutorial. Thanks.

Hey, I’m not sure if my issue relates to the above, but it does relate to the title of this thread.

The problem I’m having is that while ABSPATH correctly points to WordPress, which I have at “public_html/wp”, the actual content of my site is not in there. It’s beside the wp folder at “public_html/wp-content”. This is so I can easily upgrade WordPress via Subversion without it messing with my content.

So I obviously want to backup my content. On line 157 of hm-backup.php, I see $this->root = $this->conform_dir( ABSPATH );
That only works when the site’s content is in the same folder as WordPress. I changed that line and it correctly backed up my content.

Am I missing something here? Is there a way I can fix this without tweaking the plugin?