[Resolved] GP Premium Conflict with WP Migrate DB Pro

Home Forums Support [Resolved] GP Premium Conflict with WP Migrate DB Pro

Home Forums Support GP Premium Conflict with WP Migrate DB Pro

Viewing 8 posts - 1 through 8 (of 8 total)
  • Author
  • #563439
    Garth Dryland

    Hey Tom,

    I’ve recently been experiencing staging issues on my sites. As a result I had to set up fresh staging sites and start adding and staging plugins one by one to find the problem. While GP Premium doesn’t appear to be the only issue it does impact the staging window of WP Migrate DB Pro adding 3 additional ticks and what appears to be a blank error panel. I’ve tested other plugin with WPDBMP and they all work as expected whereas GP Premium is not.

    I believe there is another contributing plugin causing other issues however GP is a concern and a potential contributing factor with respect to another plugin/errors I’ve as yet to narrow down.

    I haven’t changed anything at all on one of my sites for months yet I now have staging issues so I’m convinced its linked to either a WP core issue (yet unlikely) and or its plugin related potentially conflicting with more than one plugin. I can only assume it occurred following an update in the last 2-3- months or thereabouts. Before that WPDBMP worked seamlessly for years.

    I linked a screenshot for reference.

    This is the WPDBMP error I get on one of my production sites (the one I made no changes to)

    Unable to connect to the remote server, please check the connection details – <response code> <response message> (#129 – scope: <scope>)

    This error is usually caused by a HTTP connection error when attempting to connect to the remote machine. The solution relies heavily on what the actual HTTP error is, please contact support with the full message.

    and this is the error I get on another site (On this site I made a post update, emptied Yoast Premium tables which repopulate and removed the BackWPup plugin and its respective tables.)

    JSON Decoding Failure — Our AJAX request was expecting JSON but we received something else. Often this is caused by your theme and/or plugins spitting out PHP errors. If you can edit the theme or plugins causing the errors, you should be able to fix them up, but if not, you can set WP_DEBUG to false in wp-config.php to disable errors from showing up. (#144)

    This error occurs during migrations when the JavaScript process controlling the migration is expecting a JSON response to an AJAX request that was made, but something else is received instead. This usually happens when your theme or plugins cause errors to be printed in the program’s output due to errors in their code or a conflict with another plugin, theme code, or even WP Migrate DB Pro itself.

    The best course of action would be to fix any bugs in your theme or plugin files that are causing the errors and update or disable any offending plugins. You can also try enabling compatibility mode and setting WP_DEBUG to ‘false’ in your wp-config.php file to prevent any non-fatal program errors from being output.

    While these may be unrelated to what GP is doing GP is doing something somehow creating the output as shown in the screenshot.

    This is a screenshot with a fresh install and GP Premium deactivated.


    Lead Developer
    Lead Developer

    Hmm, that seems strange.

    GPP shouldn’t cause any of the HTTP stuff – you can check your error_log for specific errors though.

    As for the styling issue, what if you deactivate all of the GPP modules? Fixed? Now what if you activate them one by one? This will help us narrow down the conflicting module.

    Garth Dryland


    Re the http issue I suspect it’s related to another plugin. I’m at the point now where I can start to test each sites plugins IE all double ups are now tested and installed other than GP which certainly appears to create the extra abnormal ticks issue. The remaining plugins are relevant to each live site and issues #129 and #144 respectively.

    I will do what you said re GPP once I’ve independently tested the remaining plugins as GP may be connected to those errors also as far as I know. Said error messages are to my knowledge not related to the extra ticks issue in so much as the ticks occur without said messages being thrown, just the staging plugin (which works fine by itself) and GP activated.

    I should be able to recreate one or more of the # issues using an independent fresh install leaving my live sites running. I will install each set of five plugins, stage and hopefully get the new site to throw the relevant messages. I sent you the error messages in case they were useful to determine why GP is no longer working seamlessly with WP Migrate DB Pro.

    The plugins below are either from the default install and or are plugins both site use which I’ve tested so far and don’t cause staging issues. I have ten more to test (excludes GP Premium). Five are from one live site and remaining five are from the other. The currently installed and activated plugins are used on both sites.

    I will update this thread in due course.

    Akismet Anti-Spam
    Activate | Delete


    Broken Link Checker
    Deactivate | Settings

    Enable WP Database Tools
    Activate | Delete

    Hello Dolly
    Activate | Delete

    iThemes Security Pro
    Settings | Deactivate | License

    Jetpack by WordPress.com
    Jetpack | Deactivate

    Maintenance Mode
    Deactivate | Settings | Support

    SG Optimizer
    Activate | Delete

    Simple CSS

    WP Migrate DB Pro
    Settings | Deactivate

    Yoast SEO Premium
    FAQ | Premium Support | Settings | Deactivate

    Lead Developer
    Lead Developer
    Garth Dryland

    Hey Tom

    I tried that code and while it appears to have stopped the tick issue GPP is now throwing the 129 error. On my new test staging sites I’ve only been able to recreate the ticks issue and potentially resolve it, the 129 error but not the 144 as yet. I certainly wasn’t expecting to find more than one plugin throwing the 129 error and GP didn’t with just GP and the staging plugin activated so it’s potentially the staging plugin.

    I will continue to test and hopefully I can narrow these issues down. I’ve found 3 plugins which appear to be connected to the 129 error.

    GP Premium (though appears to require other plugins potentiality one below).

    Meeting Scheduler By Vcita and

    WP-Sitemap Page

    Brad at Delicious Brains recently sent me some logging suggestions to try re the WP Migrate DB Pro plugin so I’ll be running some tests on my live staging sites later today and hopefully those logs will help.

    Expect another update in due course.

    Garth Dryland

    Hey Tom

    I’m still testing however this is what I’ve sent to my staging plugin support and my host.
    It’s potentially irrelevant to you as far as providing a fix however it may be useful to know.


    I have a few more tests to run to know for sure however I’ve isolated my hosts server setup using AMPPS creating fresh installs replicating the test staging pairs on my hosting account.

    While AMPPS does use a slightly different version of PHP and SQL etc, they’re close. What I’ve found so far is that I have no issues whatsoever with any of my staging pairs using AMPPS with my typical site configuration and plugins whereas the only way I can get my hosted sites to work, getting a successful push and pull is by adding the following lines to the relevant .htaccess files.

    LimitRequestBody 999999999999
    SubstituteMaxLineLength 20M

    So far I’ve pretty much completed testing the staging pair on my host which typically throws the #129 error – 502 gateway related issue. I have not as yet tested or worked out whether the above said lines will also solve the #144 Json issue which my other hosted live staging pair encounters. Like as with the #129 error I also do not experience the #144 error when pushing or pulling these sites on AMPPS.

    I also fixed a small CSS issue adding the following function so GeneratePress Premium no longer impacts the WPMDBP staging windows styling.

    add_action( 'admin_head', 'fixGPStyleIssues' );
    function fixGPStyleIssues() {
            div:not(.site-box) .complete:after{
                display: none !important;

    I intend on running tests on the remaining live staging pair later tonight. If I still have issues with this staging pair I will probably end up creating a complete clone of those sites and install them on AMPPS so they’re identical on both platforms. By identical i mean including the posts functions css etc etc.. This will also help narrow down if its server, site or plugin related. Something certainly appears to have changed on my hosts configuration creating the #129 issue which now appears to have solved by adding the code above to the htaccess files.

    Any suggestions to try re the Json issue would be appreciated. Feedback on the htaccess code I need to use would also be useful.

    Kind Regards
    Garth Dryland

    Garth Dryland

    Hey Tom,

    Just confirming the main issue appears to have been 100% due to server side security related changes.
    I haven’t as yet completed all tests however I’m confident the .htaccess code above sorted my problem.
    The function you provided above also sorted the staging plugin as far as GPP breaking it’s styling.

    I assume that code will be added to GPP at some stage?


    Lead Developer
    Lead Developer

    Great to hear. Yes, it will be in GPP 1.6.3 🙂


Viewing 8 posts - 1 through 8 (of 8 total)
  • You must be logged in to reply to this topic.