Ilari Arovuo

I disagree. The logic should be to clean after itself by DEFAULT.

If someone wants to retain the settings, there could be a tick-box for it.

Because many of the websites do NOT have this plugin anymore, they still contain the crap from this plugin. In order to clean those websites across internet, people would need to reinstall the plugin, use wipe button, and delete the plugin again. – It should not be like this.

Well, if your developers were upto the task, they would KNOW NOT TO LOAD 3rd party scripts and css – or at least try minimize the amount of them.

Also, transients are nothing new! The developers could cache the scripts, and throw them out locally without a single 3rd party script loading. But, no, your developers are clearly not up to the competence required.

Your response is unacceptable.

You should fire those developers who do not seem to have any idea how to develop a proper plugin, which also observes SEO and other very standard performance guidelines.

Instead of asking us to read discussions, and decrypt what’s wrong with your software, you should FIX THE SOFTWARE!

The PHP snippets we need to manually add to WP are:

add_filter( 'wc_stripe_load_scripts_on_product_page_when_prbs_disabled', '__return_false' );
add_filter( 'wc_stripe_load_scripts_on_cart_page_when_prbs_disabled', '__return_false' );

The problem is in the plugin code. Fix it.

@paulshultz Please share your snippet, so others can learn as well.

Thanks, There was nothing in the phperror.log nor debug.logs
– So, I suggest to add some error_log commands in the code base, when ever errors happen, so that we can see what causes the issue.

You can close this ticket, as I was able to resolve this specific case.

Thanks for confirming the bug.

Can you also please help to confirm where the “Auto Purge” is set? As it’s quite frustrating to keep flushing the caches, after every edit.

Thank you @elenachavdarova.
You may close this thread.

Thanks @elenachavdarova,

I did contact GoDaddy, waited over 2 hours to speak someone (!) and they blatantly refused to provide any support, even after escalation – nothing new with GoDaddy.

I also questioned modsec rules, etc, and response was simply “our systems are fine” – without any effort to actually look at it – I guess they know they have rules to block the SG Migrator. So sad attitude from them.

So, I used alternative method to conduct this migration – and we can finally get rid of GoDaddy for good. </end_of_venting>

Elena, Can you please also look at your API server end error messages, which are then shown in the source server plugin admin UI, and provide more accurate error, preferably with source and destination IP addresses, port numbers, user agent, etc, which will be super helpful to identify potential traffic blocks in firewalls, etc.
– You may want to hide that information under a button “more details” or so, to keep the clean look of the admin UI.

The current error message in this case was extremely confusing, as it focuses on file permissions, which is not the actual cause, but the source server blocking socket connection.

You may close this thread. Thank you.

Then this plugin should be removed from the repository!

I can see that the API query uses this
base_ident=1636041709-c38db4849ce27557b13fd43a09864b0a21c0bcba

But, the SiteGround Site Tools WP Migrator is providing
1636006122-9c9f12351d99010a-57f8b5e6b0353d8e

I can see server response to API query;

[body] => {"err_code":400,"status":400,"message":"Can not connect to SiteGround Migrator plugin at https://<redacted>/"}
[response] => Array
(
  [code] => 400
  [message] => Bad Request
)

The IP Address delivered in API query is my browser IP address, not the source server address.

I have been also verify that the directories are created and existing.

So, the error message is truly misleading to point "Please check files and directories", when the actual issue is in forming the proper API request by the plugin!

• This reply was modified 3 years ago by Ilari Arovuo.

I can see in the database;
siteground_migrator_current_step = 0

Hi @wfphil

Divi Mega Pro is the plugin developed by DiviLife.com

We have confirmed this LFI Attack was caused by the plugin, and has been fixed in plugin version 1.9.3

You can close this ticket.

• This reply was modified 3 years, 1 month ago by Ilari Arovuo.

It appears the issue is with the DiviLife Mega Menu Pro plugin.
New version 1.9.3 of the plugin resolves the issue, although the version is not yet publicly available as of today.

Confirmed. This bug litters debug.log with these redux errors.