Forum Replies Created

Viewing 15 replies - 1 through 15 (of 56 total)
  • This is nothing new – the plugin has had these issues for years! – and it seems developers are clueless why it’s happening.

    A) The Plugin seems to be quite buggy, it leaves garbage after deactivation and deletion.
    – Left over files, database rows and transients.
    – If you can’t make working plugin, can you at least clean after yourself?

    B) This plugin also utilizes transients incorrectly, expecting them to stay in the system.
    – The developer did NOT read this: https://developer.wordpress.org/apis/transients/

    “Transients should be used to store any data that is EXPECTED TO EXPIRE, or which can expire at any time. Transients should also never be assumed to be in the database, since they may not be stored there at all. (MEMCACHE anyone?) It is possible for the transient to NOT be available before the expiration time. Much like what is done with caching, your code should have a fall back method to re-generate the data if the transient is not available.”

    Not only does this plugin use transients incorrectly, but it also relies on transient data for the connection to work, even though transients may disappear at any time. Additionally, some transients are set as persistent and are not deleted when the plugin is removed. Not defining expiry for transient, does not mean it will stay available. Transients WILL disappear!

    After plugin deletion, it also leaves multiple entries in the wp_options table where option_name contains “mwp”. These leftover entries remain there even after reinstalling the plugin, leaving you stuck with the same connection issues.

    I just used following process for ~20 disconnected websites, and it seems to restore the connection.

    Shit ton of unnecessary work due developers, who are not bothering to read the WP Developer Resources and Handbook. … and yet we have to pay monthly fees for this CRAP.

    Here’s how:
    0) Take full filesystem and DB backup.

    1) Deactivate and delete the plugin – if you can find it in the plugins list.
    (Check your white label settings in the MWP dashboard.)

    2) Go to wp-content/mu-plugins – delete 0-worker.php, if present.

    3) Go to wp-content/plugins – delete worker folder, if present.

    4) Go to the database – search options table for “mwp” and delete all items, where option_name has mwp in it. Including this one: _site_transient_mwp_sessions
    Make sure you do not delete rows, where mwp is not in the option_name.
    – DELETE FROM wp_options WHERE option_name LIKE ‘%mwp%’;

    5) Reinstall the plugin – Activate it.

    6) Navigate here: https://<your-website-url>/wp-admin/plugins.php?mwp_force_key_refresh=1

    7) Copy the connection key and paste it to the MWP Dashboard

    If it still does not work, you can try this: (replace key with given one)
    INSERT INTO wp_options (option_name, option_value, autoload)
    VALUES (‘mwp_communication_key’, ‘12345678-1234-1234-1234-123456789012’, ‘yes’)
    ON DUPLICATE KEY UPDATE option_value = ‘12345678-1234-1234-1234-123456789012’;

    Thread Starter Ilari Arovuo

    (@iarovuo)

    That worked! but why is the plugin targeting ahrefs, and simply obliterating the snippet, without asking, without warning, without a note. … Took me quite a while find out that it’s this plugin INTENTIONALLY targeting ahrefs.

    1. Deactivate and delete the plugin
    2. Delete option_name _site_transient_mwp_sessions from options table in database
    3. Reinstall plugin and reconnect

    Plugin seems to have a bug (for very long time) – it uses transients for persistent session/connection data – but, does not consider memcache which could be enabled and disabled at any point of time.

    Very poor choice by developer using transient for persistent data storage, and not consider memcache while playing with transients. Back to school boys!

    Thread Starter Ilari Arovuo

    (@iarovuo)

    pay attention to the fact, that many websites have MEMCACHED
    and one disables/enables memcache on the fly, the plugin cannot read the transient anymore!
    Also, you would not know if the transient was stored in memcache or options table.

    Now we had transients in BOTH, as the plugin does not cleanup, nor does it consider memcache.

    … and then, WHY are you using transient for data, which you are not auto expiring?
    Deleting or not able to access transient should be no problem, by the design and purpose of transients.

    If you need to save data persistently, you should NOT use transient, but options table!!! – or a custom table.

    Thread Starter Ilari Arovuo

    (@iarovuo)

    The snippet looks like this:

    <script src="https://analytics.ahrefs.com/analytics.js" data-key="<redacted>" async></script>

    The script is placed in Elegant Themes Divi Theme Theme Options, Integrations <head> section. But, the siteground speed optimizer javascript combiner eats the whole script. and there is no way to exclude it.

    Thread Starter Ilari Arovuo

    (@iarovuo)

    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.

    Thread Starter Ilari Arovuo

    (@iarovuo)

    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' );
    Thread Starter Ilari Arovuo

    (@iarovuo)

    The problem is in the plugin code. Fix it.

    Thread Starter Ilari Arovuo

    (@iarovuo)

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

    Thread Starter Ilari Arovuo

    (@iarovuo)

    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.

    Thread Starter Ilari Arovuo

    (@iarovuo)

    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.

    Thread Starter Ilari Arovuo

    (@iarovuo)

    Thank you @elenachavdarova.
    You may close this thread.

    Thread Starter Ilari Arovuo

    (@iarovuo)

    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.

    Thread Starter Ilari Arovuo

    (@iarovuo)

    Then this plugin should be removed from the repository!

    Thread Starter Ilari Arovuo

    (@iarovuo)

    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

Viewing 15 replies - 1 through 15 (of 56 total)