Create test DB tables using object-cache.php to generate demo data #42

Description

A clean environment is required for checks to run smoothly. There are a few possible scenarios that can be followed to run checks cleanly without affecting the site. So that users can run it on any site environment like production or staging.

The approach should be not to generate test content to the primary database tables, and all modifications to the site DB should be made through test DB tables. The plugin should create test DB tables with a different prefix specially generated through the plugin to populate test data for the site. Using wpdb::set_prefix, the plugin can change the base prefix of the site test DB tables. This approach can be run on the production site as well because the plugin is generating tables for demo content on need in the test tables.

Also, this approach will only be used for runtime checks that require DB operations to run. Runtime checks should only be run if the plugin is already active on the site. The plugin can prompt the user to activate the plugin when the check is initiated.

The plugin can use its own object-cache.php drop-in file added into the wp-content directory which overrides the DB table prefix. It can be used to run early and pause plugins other than the one being tested. It should not actually implement an object cache. If the site is already using its own object-cache.php file, the file should be renamed and conditionally required by the plugin checker’s object-cache.php file (see below note on an additional consideration there).

This approach will need to add to the database directly and preparations will need to do clean-ups to the database content. For example, some checks would require demo content to be added to the test DB tables via preparations.

Note: If a site is using a persistent object cache, it should be paused for the check requests as well so that it doesn’t add any of the demo test data into the real object cache of the site. The plugin can bypass it using the object-cache.php file.

Acceptance Criteria

• A Runtime_Environment_Setup class exists in includes/Checker
  • The Runtime_Environment_Setup class will be responsible for setting up the WordPress environment to run Runtime checks.
  • A public setup() method exists in the class and will handle the following steps:
    • Creates the demo database tables (if they do not already exist)
      • The demo tables will use a new wppc_ prefix.
      • The demo tables will be populated with the required installation data by running the regular WP installation functions.
    • Add the object-cache.php drop-in file to the wp-content folder. If an object-cache.php file already exists, this step is skipped.
  • A public cleanup() method exists in the class to reverse the changes from the setup() method
    • Delete the demo database tables.
    • Remove the plugin checker object-cache.php file.
• A Plugin_Request_Utility class exists in includes\Utilities
  • A public static initialize_runner() method exists in the class that will handle the following steps.
    • Instantiate both runner classes
      • Create CLI_Runner class #14
      • Create AJAX_Runner class #15
    • Call both runner classes is_plugin_check() methods.
    • If the is_plugin_method call returns true, the runners prepare() method is called.
    • If any check requested is a Runtime_Check, the prepare() method will update the wpdb prefix with wpdb::set_prefix to match the demo tables prefix.
  • A public static get_runner() method exists.
    • This method returns the runner instance that is being used for the current request, or null if neither is being relevant (e.g. when it is not a plugin checker request).
• Include an object-cache.php drop-in file.
  • The object-cache.php drop-in file will call the Plugin_Request_Utility::initialize_runner() method.

References

Below are issues/PR's from the Performance Lab plugin related to the object-cache.php drop in.

• object-cache.php conflicts with third party plugins performance#612
• Enhance object-cache.php drop-in interoperability with other plugins performance#616
• Introduce Server-Timing API as part of infrastructure performance#551
• Implement Server-Timing API foundation as well as basic load time metrics performance#553