Conflict debugging is a navigation-back-and-forth marathon
Something on your product page broke after installing three plugins this morning. The standard plugin-by-plugin elimination flow: navigate to Plugins, deactivate suspect #1, navigate back to the product page, test. Navigate back to Plugins, reactivate #1, deactivate suspect #2, navigate back to the product, test. Repeat.
You'll spend more time navigating between pages than actually testing. By the third suspect, you've lost track of which plugin is currently off.
What most people do instead
/wp-content/plugins/ to force-disable everything. Nuclear option, loses activation state.A better way: toggle from the page under test
Open the navigator from the broken page itself. Type deactivate plugin -slug=suspect-plugin. The plugin flips off in place. You reload the same page you're already on to retest — no navigation, no lost context. The next suspect is one navigator-open away.
TrueCommander cannot deactivate itself. Hard-coded in Command_Deactivate_Plugin — a slug match resolving to the TrueCommander plugin file returns an error instead of running the deactivate call. No macro or shortcut can lock you out of your own command bar.
How it works
Same slug-resolution pipeline as activate — fuzzy folder match against get_plugins(), single match required, multi-match lists candidates. Before running deactivate_plugins(), the command checks whether the resolved file is TrueCommander's own base file. If it is, the call short-circuits with a self-protection error.
/wp-content/plugins/. Fuzzy — partial names resolve to the one plugin they match.deactivate_plugins() call. All deactivation hooks run. Already-inactive returns a no-op.| Parameter | Value |
|---|---|
-slug(required) | Plugin folder name (fuzzy — partial names work) |
| Match strategy | Exact folder match wins, else substring. Multiple matches return an error with the list. |
| Self-protection | Hard-blocked from deactivating TrueCommander itself — returns an error before any hook runs. |
| Already inactive | Returns status: already_inactive — no hooks fired twice, no error. |
| Can be used in |
Real example
The Add to Cart button disappeared on a WooCommerce product page after you installed three plugins this morning. Classic CSS conflict. You open the navigator from the broken product page and run deactivate plugin -slug=reviews-pro. Reload — button still gone. deactivate plugin -slug=wishlist-pro. Reload — button still gone. deactivate plugin -slug=compare-pro. Reload — button's back. That's the culprit.
You reactivate the first two from the navigator ( activate plugin), leave the third off, and write the bug report. Total time: under two minutes. On the Plugins page it would have been fifteen.