Developing a WordPress plugin for debugging plugin conflicts

I am writing a media manager plugin for WordPress, but one feature of it isn’t working apparently due to a conflict with another plugin. Debugging these issues is a real pain. So I asked AI to help me build another plugin to aid in the debugging.

I started by asking ChatGPT to write a prompt for me. This is what I asked:

Write a prompt for a wordpress plug that debugs plugin conflicts. It should start by making a list of all the active plugins. It should let the user select 1 to be the test. Then it should deactive half of the other active plugins so the user can test to see if the test plugin now works. Then the user can choose to reactivate those just closed and deactive the other half, or repeat the sequence of deactiving half of the current set of active plugins. This behavior continues until the user tells the plugin to reactive all of the original set.

Prompt to ChatGPT

ChatGPT responded with:

Develop a WordPress plugin called “Plugin Conflict Debugger”. This plugin assists users in diagnosing conflicts between installed plugins by allowing them to selectively disable and enable groups of plugins in a controlled testing sequence.

Core Functional Requirements:

  1. List Active Plugins
    • On activation or launch, display a list of all currently active plugins.
    • Allow the user to select one plugin to test for conflicts (the “Test Plugin”). This plugin will remain active throughout testing.
  2. Divide and Deactivate Plugin Groups
    • Automatically divide the remaining active plugins (excluding the Test Plugin) into two halves.
    • Present the option to:
      • Deactivate the first half while keeping the second half and the Test Plugin active.
      • Allow the user to test the functionality of the Test Plugin.
      • Provide a button to toggle between the halves (i.e., deactivate the second half and reactivate the first half).
      • Provide a button to repeat the halving and deactivation process on the currently active set (binary search method).
  3. Stepwise Conflict Isolation
    • Continue allowing the user to repeat the divide-and-deactivate process on the active subset of plugins until the conflict source is identified or ruled out.
  4. Reactivate All
    • Provide a clear option to reactivate all the originally active plugins at any time, restoring the system to its pre-debugging state.
  5. Optional Features (Stretch Goals)
    • Save and display a session log showing plugin states at each step.
    • Allow exporting the session log or emailing it for support purposes.
    • Add visual cues (e.g., “Currently Deactivated”, “Active Test Set”) for ease of use.

User Interface Notes:

  • Use the WordPress admin panel with intuitive UI components (checkboxes for plugin selection, buttons for deactivation, toggling, and restoring).
  • Provide tooltips or short instructions on each step to guide the user through the process.

Technical Considerations:

  • Use get_option('active_plugins') to retrieve active plugins.
  • Use deactivate_plugins() y activate_plugin() for plugin control.
  • Ensure the plugin does not deactivate itself or the selected Test Plugin.
  • Handle exceptions gracefully and notify users of any issues during activation/deactivation.

Gemini

So I gave this prompt to Google Gemini and told it to provide me with a bash script file to build the plugin. It responded with a script that built the folder structure and files. I just had to zip up the folder so I could install the plugin on my site. This part was straight forward. The plugin installed and a menu item was added to the Tools sub menu.

Launching the plug, however, did not work correctly. There was an infinite loop with an Ajax call. Gemini quickly found the issue and gave me a patch.

So this process continued. I eventually uploaded the files to other AIs and had them check the code. I am finding that that is a good processes. It is like having another programmer look at your work with fresh eyes. I used ChatGPT and Claude.ai and eventually came up with a working plugin.

Conclusión

Having done this with several plugins now I have figured out that some simple WordPress plugins are very simple to code using AI. Even more advance ones that interace with plugins or the Media library are doable, but you have to work harder with the AIs to get to the final state. Nevertheless, even with the debugging, using AI saved significant time and effort.

My default position now, when I find a need for a plugin, is to use AI to write my own. Third party plugins, while convenient, often have a lot of extra features that I don’t want or need. Many of them try to upsell you to “Pro” versions and launch marketing pages when you install and activate them.

That said, you still need to know a bit about WordPress and debugging. Having ftp access to your site is critical, as the AIs typically wrote PHP messages to the debug.log file. Also being familiar with the browser debugger is important for the same reason. Javascript debugging was written to the console.log.

What was great about this was that all I had to do was copy the logs back into the AI and it analyzed the logs and made fixes.

And in the end I ended up with a nice plugin debug tool, which I discovered I didn’t need. It showed that there wasn’t a plugin conflict. What was causing the failure was how the plugin was dealing with a particular SQL statement. Giving the code to another AI found that and fixed it.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *