Cleanup runtime testing database tables during uninstallation

[mukeshpanchal27]

Describe the bug

During the runtime check process, our plugin installs new database tables for testing purposes. These tables are intended to be removed in the Runtime_Environment_Setup::clean_up method. However, in certain cases, such as when encountering conflicts with other plugins (e.g., Elementor), the tables are created but not removed.

Additionally, when a user deactivates our plugin, the tables remain in the database, leading to potential orphaned tables and unnecessary data.

To address this, we propose implementing a solution to remove these testing tables during the plugin uninstallation process. This will ensure proper cleanup and prevent any lingering database artifacts.

We suggest the following steps to resolve this issue:

@jjgrainger @felixarntz @joemcgill Please share your thoughts and suggestions regarding this approach.

WDYT?

Steps to Reproduce

1. Clone the plugin code to your local system.
2. Set up a local WordPress installation.
3. Install and activate the Elementor plugin from the WordPress repository.
4. In the WordPress admin area, navigate to "Tools" > "Plugin Check."
5. Select "Elementor" from the dropdown menu on the Plugin Check page.
6. Open the developer tools in your web browser and switch to the "Network" tab.
7. Click on the "Check it!" button on the Plugin Check page.
8. Monitor the network requests in the developer tools and wait for an error in the Ajax request.
9. Upon encountering the error, note that the DB table is created.
10. Deactivate the Plugin Check plugin.
11. Access the WordPress database.
12. Verify the presence of the DB table related to the Plugin Check plugin.

Screenshots, screen recording, code snippet

No response

Environment information

No response

WordPress information

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

[swissspidy]

Is this still valid?

[felixarntz]

I suppose this could still happen? However, I'm not sure the proposed approach to delete these tables during uninstallation is the right path. Shouldn't we rather try to catch problems during the runtime check execution and delete the tables after the process even if it fails? That would seem a more appropriate solution to me.