Update tests

features/check-core-update.feature

@@ -16,9 +16,11 @@ Feature: Check whether WordPress is up to date
       | name          | status  | message                                   |
       | core-update   | success | WordPress is at the latest version.       |
 
+  # This test downgrades to WordPress 5.9.0, but the SQLite plugin requires 6.0+
+  @requires-mysql
   Scenario: WordPress has a new minor version but no new major version
     Given a WP install
-    And I run `wp core download --version=4.5.1 --force`
+    And I run `wp core download --version=5.9.0 --force`
     And I run `wp theme activate twentyfifteen`
 
     When I try `wp doctor check core-update`
@@ -31,6 +33,8 @@ Feature: Check whether WordPress is up to date
       """
     And the return code should be 1
 
+  # This test downgrades to WordPress 5.9.0, but the SQLite plugin requires 6.0+
+  @requires-mysql
   Scenario: WordPress has a new major version but no new minor version
     Given a WP install
     And I run `wp core download --version=4.4.9 --force`

features/check-file-contents.feature

@@ -19,7 +19,7 @@ Feature: Check files in a WordPress install
     Given a wp-content/mu-plugins/exploited.php file:
       """
       <?php
-      eval( base64_decode( $_POST ) );
+      eval( base64_decode( $_POST[''] ?? '' ) );
       """
 
     When I try `wp doctor check file-eval`

features/check-plugin-active-count.feature

@@ -10,7 +10,9 @@ Feature: Check whether a high number of plugins are activated
 
   Scenario: Less than threshold plugins are active
     Given a WP install
-    And I run `wp plugin activate --all`
+    # Uses "try" because the SQLite plugin attempts to do a redirect.
+    # See https://github.com/WordPress/sqlite-database-integration/issues/49
+    And I try `wp plugin activate --all`
 
     When I run `wp doctor check plugin-active-count`
     Then STDOUT should be a table containing rows:
@@ -27,7 +29,9 @@ Feature: Check whether a high number of plugins are activated
           threshold_count: 3
       """
     And I run `wp plugin install user-switching rewrite-rules-inspector`
-    And I run `wp plugin activate --all`
+    # Uses "try" because the SQLite plugin attempts to do a redirect.
+    # See https://github.com/WordPress/sqlite-database-integration/issues/49
+    And I try `wp plugin activate --all`
 
     When I run `wp doctor check plugin-active-count --config=config.yml`
     Then STDOUT should be a table containing rows:
@@ -36,7 +40,9 @@ Feature: Check whether a high number of plugins are activated
 
   Scenario: Include network-enabled plugins in active plugin count
     Given a WP multisite installation
-    And I run `wp plugin activate --network --all`
+    # Uses "try" because the SQLite plugin attempts to do a redirect.
+    # See https://github.com/WordPress/sqlite-database-integration/issues/49
+    And I try `wp plugin activate --network --all`
 
     When I run `wp doctor check plugin-active-count`
     Then STDOUT should be a table containing rows:

features/check-plugin-deactivated.feature

@@ -43,6 +43,8 @@ Feature: Check whether a high percentage of plugins are deactivated
       | name               | status  | message                                          |
       | plugin-deactivated | warning | Greater than 60 percent of plugins are deactivated. |
 
+  # This test deletes all plugins, but SQLite requires an integration plugin to be installed.
+  @require-mysql
   Scenario: Gracefully handle no plugins installed
     Given a WP install
     And I run `wp plugin uninstall --all`

features/check.feature

@@ -2,7 +2,9 @@ Feature: Basic check usage
 
   Scenario: Use --spotlight to focus on warnings and errors
     Given a WP install
-    And I run `wp plugin activate --all`
+    # Uses "try" because the SQLite plugin attempts to do a redirect.
+    # See https://github.com/WordPress/sqlite-database-integration/issues/49
+    And I try `wp plugin activate --all`
     And I run `wp plugin update --all`
     And I run `wp theme update --all`