• Resolved Rob Watson

    (@rcwatson)


    In trying to build a development workflow system, I was trying to deactivate the Stop Spammers plugin on specific staging environments using the WP-CLI command “plugin deactivate”. However, even when I have the IP address of the WP-CLI client machine (127.0.0.1) included in the “Allow” list, I still get prompted for a password when trying to deactivate the plugin. Other plugins I try to also deactivate have no problem, and no password is prompted for those. Just Stop Spammers asks for a password upon plugin deactivation commands. Any idea why and how I can configure it to allow itself to be deactivated via WP-CLI commands on staging environments?

Viewing 3 replies - 1 through 3 (of 3 total)
  • Anonymous User

    (@anonymized-5837566)

    Hmm, that’s pretty interesting. I don’t believe there’s anything specific to WP-CLI baked into Stop Spammers. Rather, it seems like the plugin is just protecting itself, which is actually pretty cool. Most likely, it probably comes down to how Stop Spammers interprets IPs.

    You might try whitelisting the router IP, the device IP, and your public internet IP as well just in case.

    And just to double-check, Stop Spammers isn’t actually interfering with any commands other than just when you’re trying to deactivate SS? I actually think the original creator may have baked in that only a whitelisted admin can deactivate it, which makes sense as to why it would direct you to log in.

    Thread Starter Rob Watson

    (@rcwatson)

    Thanks for the tip. I allowed the other IPs as you noted and it seems to have solved the issue. It also occurs to me that just waiting for a timeout after some previously blocked action may have done the trick as well. We’ll see.

    Anonymous User

    (@anonymized-5837566)

    You’re welcome.

Viewing 3 replies - 1 through 3 (of 3 total)

The topic ‘WP-CLI commands fail when plugin is enabled’ is closed to new replies.