ext237

So we have to click “Restore” on dozens of backups going back-and-forth to this page until we finally find the right one, that’s the solution? A dropdown filter, search bar, domain name next to the date, anything could clear this bug. A hover popup on the Restore button before we click it could even be helpful. This isn’t a huge bug, it’s easy to fix. You have the data of the backup when you do the refresh, so give us something to work with.

“view log” button does not appear on backups added to the interface from the “rescan remote storage” routine. It’s impossible to know which, if any, of these backups are appropriate to apply to this site.

When I’m hired after a disaster, I don’t know the previous developer’s dates for making backups. I clicked the most recent in the list and installed the wrong backup from a completely different website.

I am a Premium feature customer for All In One Migration, Dropbox and Unlimited extension. Extra features are worth the money.

If directory sorting is something some people need, they should pay for it. But knowing which website is going to be installed when you click Restore shouldn’t be a “guess-or-pay up” feature.

If you are going to show ALL websites, then not letting people know which “Restore” button belongs to the website isn’t a premium feature, it’s a bug.

Thanks.

After reinstalling WordPress after a server outage/crash, clicking the refresh button is required to pull in the list of backups. It is impossible to know which “Restore” button is the correct one. The plugin does not allow you to filter based on site, and does not display the backup names. This lead us to unknowingly install the restore the wrong website, costing valuable time.

>> What if you were migrating one site to another?

Then the site owner would use the migration plugin, not the backup plugin. Or the backup plugin could display the name of the site in the backup list rather than just “Restore” buttons.

>> As you have all your backups stored in one folder they are all shown when you rescan the storage.

Correct. There’s no way to know which listed backup is the correct backup for THIS site. It should either automatically filter itself for this domain/relevant site, or it should provide a way for the user to know which “Restore” button goes with which website.

Installed update and verified fixed. Thanks.

Same/similar. After removing and re-adding all plugins, for us it was a conflict with The Events Calendar plugin. They both cannot be installed and activated, or we get the following error. Started happening this AM after updating Pods.

Fatal error: Uncaught Pods\Prefixed\lucatume\DI52\NotFoundException: nothing is bound to the ‘editor.compatibility.classic-editor’ id and it’s not an existing or instantiable class. in /home/customer/www/aliefsuperneighborhood.org/public_html/wp-content/plugins/pods/vendor/vendor-prefixed/lucatume/di52/src/Builders/ClassBuilder.php:84 Stack trace: #0 /home/customer/www/aliefsuperneighborhood.org/public_html/wp-content/plugins/pods/vendor/vendor-prefixed/lucatume/di52/src/Builders/Resolver.php(233): Pods\Prefixed\lucatume\DI52\Builders\ClassBuilder->__construct(‘editor.compatib…’, Object(Pods\Prefixed\lucatume\DI52\Builders\Resolver), ‘editor.compatib…’) #1 /home/customer/www/aliefsuperneighborhood.org/public_html/wp-content/plugins/pods/vendor/vendor-prefixed/lucatume/di52/src/Builders/Resolver.php(210): Pods\Prefixed\lucatume\DI52\Builders\Resolver->resolveUnbound(‘editor.compatib…’) #2 /home/customer/www/aliefsuperneighborhood.org/public_html/wp-content/plugins/pods/vendor/vendor-prefixed/lucatume/di52/src/Contain in?/home/customer/www/aliefsuperneighborhood.org/public_html/wp-content/plugins/pods/vendor/vendor-prefixed/lucatume/di52/src/Builders/ClassBuilder.php?on line?84

I’ve been exchanging email with your support staff for 3 weeks, they even had me spend the time to stand up a staging environment and provide them admin access. They never told me it was a pro-only feature. Otherwise, I would have upgraded and saved an enormous amount of time and hassle.

Looks like the patched version you sent me has resolved the issue, I haven’t received messages from the host in quite a while. Thanks for the help.

Hello, can I get an update? I got another complaint email from my web host and I forwarded it to your support team. They replied by sending me the same patched plugin and instructions to click the clear cache button.

But as mentioned, neither of those work. The only thing that resolves the issue is logging into the server every couple of days and running the database optimization feature of the WP-Optimize plugin. Having to do database maintenance every two days is not going to work for us.

Thanks.

I got another over-size database error today, so I installed the plugin. How long should it take before it clears the records? I clicked clear cache from the ec-params page, but the page just refreshes, no messages, warnings or errors — and the database options table remains at 1.1 GB. Is there a delay when using the ec-params page to clear the cache?

I received an email from Support. They asked me to install the plugin and then go to this page to clear the cache: /wp-admin/admin.php?page=cparams

The plugin is already installed, that’s how I found this issue. And the cparams page didn’t resolve the issue when it was first suggested several days ago. They did not send a patched version.

Thanks for any help or suggestions you can provide.

• This reply was modified 2 years, 10 months ago by ext237.

I was able to remove them from one of the sites by disabling the Ecwid plugin and then re-enabling it.

Not multisite, two individual sites on different servers. Sorry, logging in every few days to do this manual isn’t how this should work. This is an issue that needs to be handled by the plugin, right?

Already checked delete_expired_transients, it is enabled and when I triggered it manually there was no change in table size.

I didn’t know about page=ec-params. Just did that, clicked clear caches. Page refreshed, no status code or error code. wp_options table size is still > 1.1GB.

Most records are “_transient_ecwid_products_****” and “_transient_timeout_ecwid_products_***”

We need to resolve this before the next release.

Commenting out line 151 of add-search-to-menu.php seems to fix it without disabling the plugin or search. This workaround is good enough until the plugin is repaired. Hope this info helps you guys until we hear back from the dev.