• My experience was when testing this plugin on behalf of some of my customer’s complaints.

    Right after installing it, some dynamic images stopped working due to modifications this plugin makes to .htaccess file.

    Such modifications are registered as being part of iThemes Security which makes it even harder to identify.

    Because most of my customers don’t even use git or any version control system, it gets even harder to identify such changes.

    Also, by deactivating or even removing the plugin (using wp-cli or via panel) will not undo those intrusive changes.

    Same goes to changes made in wp-config.php disallowinging file editing, regardless you configure the plugin to not alter your wp-config.php file.

Viewing 2 replies - 1 through 2 (of 2 total)
  • Plugin Support Ben Meredith

    (@benmeredithgmailcom)

    Hey @martins56 !

    First, thanks for testing out the plugin for clients! (buckle up for a comprehensive reply here!)

    Next, I really appreciate you bringing to my attention that the changes that Solid Security makes are still listed as iThemes Security in the wp-config.php file and .htaccess file. I definitely thought we changed that behavior for new installs at the time of our rebrand last year, and hate that it slipped through the cracks. I just now escalated that to the team to have a look at fixing. There’s an outside chance there’s some valid reason we didn’t change that behavior at the time of rebrand, so I can’t guarantee that we’re going to fix it, but I’d hope that we can fix it at least for new installs going forward.

    Note: We certainly don’t want to go trying to fix it for sites where it’s already saved to both database and file structure in the old way… that’s a recipe for headaches… but for new installs I’d hope we can make that change.

    Next, the fact that those edits persist on deactivation and uninstallation: I’ve raised this issue with the development team in the past and we’ve always been reticent to do much “cleaning up” on uninstall of changes made to wp-config and .htaccess, because it can have unintended consequence and end up doing more harm than good. I’ll raise that issue again to see what they say, but know that it’s something we’re aware of and made a conscious decision not to do, for the benefit of our (current and former) users.

    Next, the issue of you telling Solid Security not to edit the wp-config and .htaccess files, and it still editing it: I just tried multiple ways to replicate that, and as best I can tell my test install obeyed that setting. I am going to surface to the team some UI improvements we can make when that setting is disabled (it isn’t clear that once you uncheck that box, it really doesn’t matter what other changes you make in the settings… those changes need to be manually made), but the setting appears to be *working*. If you can get me some steps to make it malfunction, I’m happy to look into it. It might be best to open a support request for that so that I don’t miss a reply to the thread here.

    Finally, the root issue of “it broke some dynamic images” (which ultimately surfaced all of these other issues): I am more than happy to try and see about mitigating the issues if you’d be willing to pass along some steps to replicate the problem. My hunch is that the dynamic images are being handled in a fancy way that bypasses normal WordPress conventions for the sake of performance improvements, and therefore would need some special care to “play nicely” with a security plugin (like Solid Security).

    I can’t guarantee we’d find a solution that would not just be “change the setting in the .htaccess file” like you ended up doing, but it’s worth a shot.

    Thread Starter Ricardo Martins

    (@martins56)

    Thanks for replying and giving so many details.

    Regarding the check/unchecked option you mentioned, it didn’t matter. The .htaccess was modified during the installation with the default options (which come checked as default, modifying everything).

    Unchecking them, don’t rollback the changes, neither uninstalling the plugin.

    As any other plugin, even if it make unexpected changes to things we don’t want, is expected that those changes are undone once we uninstall/deactivate the offending plugin. As an advanced user, with control version in place I could identify those changes, but most of users will not, and will probably break their production websites (after all, in WP almost no one test things in a separate environment).

Viewing 2 replies - 1 through 2 (of 2 total)
  • You must be logged in to reply to this review.