The staging-site fallback is the part most macros skip: telling a store owner to deactivate plugins on a live checkout page during business hours just generates a second angry ticket. Ask for hosting provider and PHP version up front too, since a fair number of “conflicts” turn out to be a version mismatch.
Support
Write a troubleshooting macro for a suspected plugin conflict
A reusable macro for diagnosing whether another plugin or theme is the real cause of a bug reported against yours, with a safe path for live sites.
Works with Claude / GPT1,400 uses★ 4.4
The prompt
support-plugin-conflict-troubleshooting-macro
Support tickets keep coming in like this one: "After activating your Forms plugin, my checkout page shows a blank white screen. I'm using [Page Builder X] and a caching plugin. Please fix your bug." Write a troubleshooting macro (a reusable reply template with instructions) that a support agent can send to any customer reporting a similar "your plugin broke my site" issue, before assuming it's actually a bug in our plugin. Requirements: - Ask the customer to enable WP_DEBUG and share the exact error text, not just "blank screen" or "it's broken." - Walk them through an isolation test in order: deactivate all other plugins except ours and switch to a default theme, then check if the issue persists. If it's gone, reactivate plugins one at a time to find the actual conflicting plugin. - Explicitly cover the case where the customer refuses or can't do this on a live site: give a safe alternative, a staging site clone or a maintenance-mode window, instead of insisting on live-site testing. - Ask for their hosting provider and PHP version, since some "plugin conflicts" are actually a PHP version incompatibility. - Close by setting expectations: this test usually takes 10-15 minutes, and the results tell us exactly where the bug actually lives. This is a macro, so keep placeholders like [Page Builder X] as blanks the agent fills in per ticket, not values to guess.