Jon Jennings

Buzztone – that’s a great resource you’re written!

DDT – I’ve been having a similar issue… some emails getting through, some not. For *ME*, it’s turned out to be on-domain emails that don’t work & anything that has to go off-domain gets through OK. eg if the client’s site was https://clientsite.com then [email protected] would fail but [email protected] would work.

It sounds like your problem, like mine, probably isn’t with CF7 itself, but with something to do with the email server.

If you’re comfortable with a little PHP, Example #2 in the PHP mail() documentation at https://php.net/manual/en/function.mail.php is a good starting point for testing things out. By putting your own emails in that script you can check whether or not they work outside of CF7 and determine whether the problem is in the mailing functionality or in the plugin.

[OK, there’s also technically a small chance it’s in WP’s internal mail handling as CF7 calls wp_mail() which does quite a lot of manipulation, but at least if the Example PHP script fails then you know it’s something to do with the server and not the PHP]

Looking through the code, I THINK there’s a bug in the plugin if you’re trying to show tweets from a list.

I’ve made a modification & tested it on my own site & it seems to work. I’ve submitted a pull request to Aaron so he can check that I didn’t actually break something.

In the meantime if a) you’re OK testing a random patch from a random person and b) you’re OK modifying PHP on your own site then you might want to check the one-line mod that seems to fix this:

https://github.com/OpenRange/twitter-widget-pro/pull/7

[And a big THANK YOU for plugin authors who put their code up on github!]

Wow – confirmed here!

I’ve now checked the “allow this application to be used to sign in with twitter” box (seems kinda obvious in hindsight!) and Twitter logins work for me as they should.

I currently HAVEN’T got the “read and write” radio button checked, just the “read only” button – but I’ve turned several settings on and then off again so this doesn’t provide categorical proof of exactly how the settings should be, although it does seem like login shouldn’t really need write access to your twitter account.

Either way, looks like Twitter authentication does work. Thanks for your help jayweb

I’m seeing that too – every time a user who authenticates with Twitter clicks on the Twitter icon to login, they’re asked by Twitter to authorize the app again.

I wonder if it’s common to all people using this for Twitter & nobody else has noticed/reported. Or if there’s something we’re doing wrong.

I’m running on WP 3.6b1 if that might make a difference.

chainlinq – I got around this issue by signing up for a new Dropbox account, authenticating the new account to BackWPup and then sharing the new account into a specific folder on my main Dropbox account. That way I know that nothing can get compromised.

Of course if your backups are >2GB then this probably won’t work for you.

servicemax – really odd that you should see failures with datasets that small. Besides my GoDaddy client, I’ve got another client that’s on a “$5/month unlimited everything” shared hosting plan and her backups are running OK with much bigger datasets than that.

If you (or anybody else) wanted to do some debugging work, I think you’re along the right lines for testing.

The output from phpinfo() will show you how high your current memory limit is – there’s a “memory_limit” parameter output in there somewhere.

If you’re on shared hosting I’m not sure if you’ll be able to make changes to a php.ini… maybe it depends on the company. You could always try ini_set(“memory_limit”, “200M”) or something like that.

Try reducing/increasing PHP’s memory limit and see if it affects things. Try logging the return values from memory_get_peak_usage(true) to see how close the script’s getting to the limit.

If you’ve got access to your server’s error logs, you should see a “PHP Fatal error: Allowed memory size of xxxxxxx bytes exhausted” in the logs somewhere if you’re hitting the limit.

I’m pretty sure there must be a host-related part to this problem.

I’ve got a VPS where BackWPup can successfully run 600MB backups with 5300 files, but I’ve just installed it on a client’s server and it’s freezing 3/4 of the way through a 180MB 4300-file backup. I THINK they’re hosted on a GoDaddy shared server.

Switching to .gz, or the PHP ZIP option don’t help.

For now, I’ve split their 2012 upload directory out into its own backup job (I figure I don’t need to run *that* very frequently!) and everything’s OK, but I look forward to trying out the new release.

Agreed – 777 isn’t a great set of permissions to leave around.

I’d like to suggest to the authors that they put a random number in the tmp directory name. Same as the logs file has a random number in it to make it less likely that a script hacker would find it, if the tmp directory was called (say) tmp-348712 then having it as 777 wouldn’t worry me as much.

But in answer to your question, you don’t want to be changing wp-config for this, you want to be changing the tmp directory permissions and leaving it that way.

Not ideal, but (other than writing a script that changed the directory permissions to 777 just before a backup job and then changed them back again after, or maybe doing something with group membership), I’m not sure what else we can do right now.

I think a quick & easy way to fix this is to change the elseif line to

elseif ( FALSE !== stristr( $content, '//youtu.be' ) ) {

This works because youtu.be shortcode URLs never have www on the front. So now we’re only entering the conditional clause if the host portion of the URL starts with youtu.be – an instance of ‘youtu.be’ later on in the URL won’t confuse us.

malq – I suspect you might have hit the same issue that I have

If you have the text “youtu.be” anywhere in your URL then the plugin thinks the URL is using the YouTube shortcode and assumes it’s structured with “https://youtu.be” at the beginning – but YouTube URLs can include those characters as a parameter. By changing your URLs to actually use the shortcode you’ve stepped around the bug ??

That sounds like my theory might be correct then. The default script execution time is usually 30 seconds. My guess is that the plugin fires off gzencode on line 1029 of wp-db-backup.php then gets killed before it finishes.

Firstly, have you tried setting MOD_EVASIVE_OVERRIDE? Looking in the instructions & the code around line 50 suggests this might help if the backup dies prematurely.

I suspect though that that’s for handling situations where the script times out during the actual creation of the backup file. If the backup file is complete then it’s perhaps more likely to be caused by the gzencode. Sticking a set_time_limit with a large time limit just before the gzencode might fix things. Either that or stick some debug around there to see if it makes it into/out of that part of the code.

I can’t really debug it myself because all my sites are small & the plugin works for me ??

Ahhhh yes Rev! I spotted that… the difference between the body classes including ‘page-template-default’ rather than ‘page.php’ and it made me think maybe there was logic at work but I didn’t think it all the way through.

Good explanation… it ISN’T using a page template in so far as there is no special named template for this page… it’s had to fallback to the default.

So WordPress is working correctly and being consistent. But the original requirement still exists… I guess the question now becomes “how do I test to see if my page is using the default page template?”

Maybe (is_page() && !is_page_template()) would do the trick.

Thanks again for your explanation.

PS To save the overhead of exploding the array, I did

!strcmp($myTemplate, substr(strrchr(get_page_template(), '/'),1))

as a drop-in replacement for is_page_template($myTemplate)

I’ve been hitting the same wall with is_page_template() and the default page template. To my mind it seems inconsistent – maybe it’s a bug? Maybe there’s a logical reason why it behaves this way but I haven’t poked into the WP code to see if maybe this is deliberate.

Thanks for the workaround Devin… yeah processing get_page_template() will solve the problem for me too.

Glad to see other people have hit the same issue as me so I’ll stop poking it & assuming it was me at fault and I’ll just work around it ??

Is your site really big? Does it take a long time to generate the backup?

Maybe you’re running into your server’s PHP execution timelimit? I think that’s typically set at 30 or 60 seconds.

I just tried the on-demand backup on a (small) 3.2.1 site & it’s working OK for me (I know, I know… that’s no consolation!)