Hi @tezalsec
thank you for the information.
Theoretically, between 1.9.3.5 and 1.9.3.6 there are no differences that can have an impact on the issue that you described. At least, I don’t see anything in the code that may give the issue with 1.9.3.6 and above and not with 1.9.3.5.
Between 1.9.4.0 and 1.9.3.7 I can suspect something, but not between 1.9.3.6 and 1.9.3.5.
There are no changes to the database structure regarding FDP. Don’t worry about that. In v 1.9.4.0 there is the possibility to move the Archives and Terms Archives option from the database to the filesystem, but if you didn’t touch it you have nothing to be worried about. I don’t think so, but If you used this new feature to move the option to the filesystem, I will tell you how to restore those settings.
Anyway, I suggest you always make a full backup, especially before you change something important, not only for FDP., in general, I also suggest you clone your site and test the new updates on the staging environment. If you have FDP I suppose you have many plugins. Especially when you have many plugins I think it’s a good idea to have a staging environment where you can test everything before updating the live site.
This is what many users do when they have a complex website.
If not done yet, I suggest you go to Backend => Backend URLs, add a row, and keep all the plugins active for this:
*/wp-admin/admin.php?page=SiteOpen&newWindow=yes&websiteid=*
Then go to Custom URLs => Frontend URLs, add a row, and keep all the plugins active for this:
*login_required=1&user=*&mainwpsignature=*&where=index.php
By doing that FDP will keep all the plugins active for the autologin, and you should not have any issues.
I suspect the issue s caused by the fact that you disabled MainWP or MainWP child on the homepage.
The URL https://example.com/?login_required=1&user=example&mainwpsignature=hash&nonce=xxx&nossl=0&where=index.php is nothing else than the homepage + some query arguments. Calling the homepage to do some actions for logging in is for me a bad practice, and no plugin should do that. Until 1.9.3.7, FDP didn’t disable any plugin if you called the homepage when the global variable $_POST wasn’t empty. But from 1.9.4.0 it does it. Probably MainWP or MainWP Child calls the homepage with a non-empty $_POST, and before it was working just because $_POST is not empty. If you have this kind of plugin, you need to explicitly say which plugins you want active with Custom URLs => Frontend URLs. This is because the new PRO version supports the Rest APIs, and there are some plugins that build the Rest API with the URL of the homepage. So, FDP now has to accept non-empty $_POST.
In your case, you should solve it as I suggested. I will also try to find a way to avoid this kind of issue and at the same time support the non-standard Rest APIs that call the homepage.
At least, I will find a way to warn the user in the backend when FDP detects this kind of situation.
Let me know if you still have the same issue after setting the Custom URLs => Frontend URLs.
Best regards
Jose