Marcoevich

That’s good to hear @cristianraiber-1, thanks a lot! ??

Hello @raldea89 and thanks for accepting the feature request. I hope it gets implemented some day.

Cheers,
Rick

@yatgirl If you haven’t solved this yet, the file pluggable.php is a WordPress core file, which shouldn’t be altered directly. The WordPress core file is not causing this issue, but merely showing the symptom here.

You can resolve this issue by disabling all your plugins and enabling them one by one. Then repeat the action that caused the error and check the error log after you enable them. Then you will find which plugin is the cause of your issue.

Just a heads up, this issue was never resolved for me. I just started to use a different plugin for one site.

Gotta love automatic updates in the latest wordpress version. Thanks for the notice here! ??

Hi @bcrodua,

Thank you for the clarification and taking the time to read my review. I understand how it works but my opinion remains unchanged. You could generate a random folder name for the free version and still have a premium feature which allows users to manually select or create a folder in Google Drive.

The fact that all backups are stored in the same folder by default and that you show those as available options for restore in websites they don’t belong to is something I will never understand. It doesn’t make any sense to me why you would think this is a good user experience.

If you insist on keeping it that way, I would suggest to add labels to the backups in the recent backup lists of the plugin. That way you can at least easily identify which backup belongs to which site.

All the best to you,
Rick

Hey Markus,

Thanks for your reply and keeping this plugin supported. It is appreciated!

I have just tried this and unfortunately it does indeed ignore sticky posts. The 2 first posts on my page are sticky, and should stay that way. Unfortunately, the project PPS Rijnstraat 8 is duplicated on the second page. When I use this parameter in the args, this problem goes away, but it also removes the sticky posts that should stay in place.

Do you know how to overcome this problem?

Thanks!

Rick

Hi Bryle,

I see. Then it seems you are correct and it’s a feature not a bug. I will mark this one as resolved.

Thanks!
Rick

Hi Bryle,

I see, that’s a useful feature for sure. I’ve read the guide on that one: https://updraftplus.com/how-to-migrate-a-website-to-another-server-using-updraft-migrator/

In the guide they describe the steps to perform migration, which require manually sending backup files from the source site to the destination site using the Migrator addon.

In the case of this issue, the Migrator addon was never installed and we haven’t performed manual sending of backups to any site. Yet there are still backups of other sites in my list of recent backups.

This looks like a bug to me.

Thanks,
Rick

Thanks Bryle!

I can confirm this. Actually, I just visited this page to report the same issue.

Hi bcrodua,

The process is running just fine, but Google Chrome doesn’t know that. It thinks we’re having an infinite loop here and so displays a message to kill the page or wait for the script to end. When the message is dismissed it is displayed again every 20-30 seconds, until the backups are downloaded.

That can be avoided by providing some feedback to the browser, maybe move the process bar a little. Any event which changes the DOM will probably prevent showing this popup.

Hi bcrodua,

Thanks for the info and the workaround. I can see why making backups to different subfolders is useful.

I do believe that this shouldn’t happen by default even in a free version. You don’t see what site you are restoring right until the last moment where you acknowledge the restore. By then the wrong backups are already downloaded to the server.

All backups are pushed to Google Drive with the sitename and an unique id for each backup in the filename. This should be enough for UpdraftPlus to recognize which backups belong to which site, and to display only the correct ones.

Hi David,

When the error happens, there’s nothing related to WP Optimize in the console. No error message at all.

When I start the preloader a second time (then it runs properly) this is printed to the console: https://prntscr.com/st221o

Hi David,

I’ve just tested this new version. The error message is now clear. It is now “An unexpected response was received”. It didn’t tell what response it received or what kind of response it expected.

This means the error message has improved a bit but the issue with the preloader is still there. The preloader doesn’t start on the first try. I wonder if that also happens when the preloader is started by the cron job. It would explain why the preloader hadn’t run even when the cache was expired.

Please let us know what you need to investigate this further.

• This reply was modified 4 years, 6 months ago by Marcoevich.