Viewing 6 replies - 1 through 6 (of 6 total)
  • Plugin Author Jose

    (@giuse)

    Hi @tezalsec

    I suggest you go back to the previous version, so you can confirm that it’s really the last update that caused the issue. You can find it here: https://downloads.wordpress.org/plugin/freesoul-deactivate-plugins.1.9.3.7.zip

    If you confirm it, I will investigate deeper.

    Another thing, is the new “last changes” section in the plugins page really necessary? No other plugins does that, as it is all available with one click. Please dont bloat that page.


    If we receive similar suggestions from other users we will probably remove the last changes, but as I know they don’t disturb anybody else, and I find this information very useful for people who would not click on “More details”.

    Best regards

    Jose

    Thread Starter tezalsec

    (@tezalsec)

    Hi @giuse ,

    so I doublechecked, I can confirm it is your plugin that causes it, but the issue started earlier, in version 1.9.3.6

    I rolled back step by step from to 19.4.0 to 1.9.3.5 , I hope I have not corrupted any database data related to your plugin by this rolling back. I did do my large configuration of your plugin way before 1.9.3.5.
    Have there been any infrastructural changes in the way your plugins uses tables or entries between these versions, or is it all just code enhancements?

    I will stay for now at 1.9.3.5, I hope you come up with a solution. Version 1.9.3.6 is probably conflicting on entry with the plugin https://wordpress.org/plugins/mainwp-child/ somehow.

    Thanks again for your great plugin and the love you put in.

    Regards,
    Tez

    • This reply was modified 1 year, 8 months ago by tezalsec.
    Plugin Author Jose

    (@giuse)

    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

    Thread Starter tezalsec

    (@tezalsec)

    Thanks a lot again, @giuse ! You are right, and I could/should have figured that out myself. Just activating the mainwp child plugin on the homepage was enough to get it working again. I didn’t even have to add the backend URL and frontend URL as you suggested.

    Why it worked before and then not anymore in relation to your plugin, is unclear to me, maybe what you said about the $_POST.

    On another note, I just stumbled on your plugin https://wordpress.org/plugins/editor-cleanup-for-elementor/ , and will give it a try, the elementor editor slowness is quite bothersome, and I have often needed to increase the php memory limit just to load that. Any chance that plugin will be a part of your main plugin in the future?

    Thanks again for your helpful and professional support.

    Tez

    Plugin Author Jose

    (@giuse)

    Hi @tezalsec

    many thanks to you! Yes, the issue was caused by something related to the $_POST super global variable.

    Why would you like to see Editor Cleanup For Elementor included in FDP?

    If Editor Cleanup For Elementor was included in Freesoul Deactivate Plugins, the only difference would be that on the page of plugins, you would see one plugin less, nothing else. In terms of performance, it would be exactly the same.
    Or is it for other kinds of reasons?

    Have a great day!

    Jose

    Thread Starter tezalsec

    (@tezalsec)

    It’s just to bundle associated subjects together, like you do with other speed improvements within this plugin, and not having to expand in the number of plugins, that’s all. 🙂

    You have a great day as well!

    • This reply was modified 1 year, 8 months ago by tezalsec.
Viewing 6 replies - 1 through 6 (of 6 total)
  • The topic ‘MainWP autologin conflict’ is closed to new replies.