drueck

Thanks so much for posting your phpinfo. I compared yours to mine and made a couple of changes to make mine closer to yours, but none of my changes seemed to make any difference. I also tried what my host suggested and changed from FastCGI to CGI and disabled mod_security and neither of those things made any difference either.

We are running different versions of MySQL… kind of doubt that has anything to do with it, but it’s possible. Data not getting saved? Man, kind of running out of ideas.

Anyway, thanks so much for your help, bootle. Definitely going above and beyond to help me out. I saved the output of your phpinfo just in case I want to further explore it, so feel free to take down your test site whenever you’d like to.

Yeah, I checked phpinfo and I’m running PHP 5.3.13 and max_input_vars is set to 3000 currently. : (

I really wish that would’ve fixed it.

Bootle, I replied in the Raygun forum, but I thought I’d reply here too for the benefit of anyone else reading this thread. I was excited to see that your host found a solution for you… that’s pretty impressive service! So, I tried setting my max_input_vars to 2000, then to 3000 to see if that solved the problem, but sadly it didn’t for me. So, there must be yet another issue in my configuration.

Update:

Just to test a different configuration I decided to try uploading over 100 images to a standard page on a different WordPress install on a different host without Porfolio Slideshow Pro installed. I uploaded 143 photos to a standard page on a WordPress install on Bluehost shared hosting and it allowed me to edit and save metadata on all the images with no problems. That install had WooCommerce installed, which I don’t think works side-by-side with Porfolio Slideshow, so I wasn’t able to test if Portfolio Slideshow made a difference or not.

I just wanted to post that as an admission that we may not have ruled out Porfolio Slideshow Pro yet. I am planning to do some more research, including possibly creating another WordPress install on my Bluehost account and installing Porfolio Slideshow on it without WooCommerce or any other plugins to see if it still works. If so, that might point to the host or my particular server with the host. My experience with Dreamhost so far hasn’t been very good, but that may be because of the other users on my shared server taking up a lot of resources?

Dreamhost is also following up with me, so maybe they will have some insights after they login and try to reproduce the error themselves.

Thanks, hel.io. I really appreciate you working on it.

I checked phpinfo and it looks like safe mode is off. And no, unfortunately there still isn’t anything new in the backup log. Let me know if there is anything else I can try to get you better info to work with.

One thing that might be a nice workaround of sorts is a couple more options in the “what to backup” section. If, for example, I could just backup the themes directory and the database, that would get me most of what I would really need… custom modifications to the theme(s) and the database. What’s making the backup so huge is the uploads directory where all the images are. Just a thought.

Thanks again for all your work on this.

So, the archive still wasn’t getting uploaded, and I’m pretty sure (like you said) it’s either because it’s timing out or running out of memory. I looked in the http log on my host and it showed:

Premature end of script headers: wp-cron.php

So, I tried backing up just the database and that succeeded, almost certainly because the file is smaller. Given that reality, do you have any recommendations on how to increase whatever parameters are necessary to get it to upload a considerably larger file? Or do you think I’m possibly out of luck on a shared hosting plan?

No problem. Thanks for patiently working with me to get to the bottom of it! I went ahead and fixed the typo and tried to run it again manually and I think it probably timed out in the browser, so I changed the schedule to never, saved it, then changed it back to daily. I’m watching the log now as it’s running the scheduled backup. I’ll let you know if it successfully uploads the archive this time. The archive is currently 198MB so I assume it will take some time.

Thanks again for your help!

-David

Cool, finally got some debugging info for you. There were two identical entries in the debug.log after attempting to run the manual backup again:

PHP Notice: Undefined property: Backup::$gdocs in [...]/plugins/backup/backup.php on line 854

-David

90% of the time I’m not getting any error in backup.log. Usually the last entry in the log is NOTICE Attempting to upload archive to Google Drive with no subsequent error line.

Out of 12 attempts so far to run the backup there have been two errors noted in the log. The first error was that name lookup timed out, which has only happened once. The second which has also only happened once is Operation timed out after 5000 milliseconds with 0 bytes received (http_request_failed). That has also only occurred once in the log out of 12 attempts.

I will try to turn on the WordPress debug logging and let you know if anything shows up there.

Thanks,

-David

Update:

I turned on php error logging and I was surprised and disappointed to see that even though the backup still failed to upload to my Google Drive, it did not show anything in the php error log (it would have been very helpful if something showed up). I verified that the php error logging is working by writing a quick php script with an error in it and running it from my browser and that error did show up in the log. Not sure if WordPress somehow redirects php errors to a different log, but if not, there is just no error showing up.

I haven’t tried disabling cURL, but I don’t think that’s the issue. I read that thread you linked to, and I don’t think that has anything to do with my problem. I am running the latest version of WP, and I can update my plugins and themes without any problems. That “name lookup timed out” error has not appeared again. I think that was a red herring.

I also increased the “time limit” setting to 240 like agentsully did and there was no change.

Would you suggest changing the time limit and/or memory limit php settings? Any other suggestions?

Thanks,

-David

This WP install is on a Dreamhost shared hosting plan and it doesn’t look like php error logging is enabled. I’ll try to get that enabled and see what it shows.

In the meantime, I’m running PHP 5.3 FastCGI and WordPress 3.4. Here are the backup settings:

• Local folder path: wp-content/backup
• Drive folder id: [the folder id]
• Authorization: granted
• When to backup: daily
• Store a maximum of: 10 backups locally and 2 backups on Google Drive
• What to back up: Database, Content, Uploads, Plugins
• Chunk size: 0.5MB
• Time limit: 120 seconds

According to the backup log, the archive file size is 78MB. Yesterday there were no log entries after the NOTICE: Attempting to upload archive to Google Drive, but when I tried it again today I got the following:

ERROR: name lookup timed out (http_request_failed)
NOTICE: Backup process completed in 59.28 seconds. Initial PHP memory usage was 20 MB and the backup process used another 7 MB of RAM.

And although php error logging is not enabled, I checked the http error log and the following entry was created each time I tried to manually run the backup:

Premature end of script headers: index.php

That’s all the info I have at this point, but I’ll try to enable php logging and let you know what I find out.

Thanks,

-David