Add support for the new SQLite driver

[JanJakes]

This PR adds support for the new SQLite driver.

When the new SQLite driver is available and enabled, it will execute all the MySQL queries using the new driver. Otherwise, the legacy SQLite driver will be used.

[wojtekn]

@JanJakes, thanks for adding support for AST to the SQLite command. I used those steps to test it in Studio:

1. Clone the PR locally
2. Run composer install --no-dev --optimize-autoloader --ignore-platform-reqs in the wp-cli-sqlite-command directory
3. Replace wp-files/sqlite-command in the Studio code with a symlink to your local wp-cli-sqlite-command directory
4. Apply 3658f-pb patch to the Studio repo
5. Comment out the line that updates the SQLite command:

//await updateLatestSQLiteCommandVersion();

6. Run npm start
7. Click on the Import / Export tab
8. Click on the "Export database"
9. Observe .sql file is created
   10 Open the .sql file and validate that the dump is correct

I couldn't make it fully work yet. I needed to make a few changes, see inline comments.

[wojtekn]

In my tests, DB_NAME and WP_SQLITE_AST_DRIVER constants are undefined. I needed to hardcode the first one as database_name_here and $new_driver_enabled as true for testing purposes.

[JanJakes]

@wojtekn The "correct" value of the database name will be needed with wp sqlite import because CREATE TABLE statements need to write it in the information schema. Are we in a context where importing the wp-config.php of a given site would be conceivable?

[wojtekn]

The command runs on before_wp_load, so wp-config.php is not loaded. See #7 for some context.

Perhaps we could load it manually, similar to how WP CLI runner already does?

eval( WP_CLI::get_runner()->get_wp_config_code() );

Or alternatively, to limit the amount of loaded code, what if we used the WP CLI parameter instead of the WP_SQLITE_AST_DRIVER constant to enable the new driver? Like --driver=[ast|legacy]?

[JanJakes]

Or alternatively, to limit the amount of loaded code, what if we used the WP CLI parameter instead of the WP_SQLITE_AST_DRIVER constant to enable the new driver? Like --driver=[ast|legacy]?

@wojtekn This would work for the AST/legacy and would be temporary anyway. But what about the DB_NAME? 🤔

There's this edge-case scenario:

1. Someone imports a DB (we use some DB name during that process).
2. Then a plugin code runs SELECT * FROM information_schema.tables WHERE table_schema = 'my-db-name' AND ....

In point 2, we'd like the DB name to match the DB_NAME that was set during the import.

By the way, is Playground booted anywhere before the import command is run? Because we know that site exports without DB_NAME exist, and the fallback to inject their value in wp-config.php is done in Playground at the moment.

[JanJakes]

@wojtekn Looking at wp db import, it seems to me they're using after_wp_config_load on the class level, and no other annotation for the import command. A couple of commands use after_wp_load.

Also explained here: https://developer.wordpress.org/cli/commands/db/import/

This command runs on the after_wp_config_load hook, after wp-config.php has been loaded into scope. Runs SQL queries using DB_HOST, DB_NAME, DB_USER and DB_PASSWORD database credentials specified in wp-config.php. This does not create database by itself and only performs whatever tasks are defined in the SQL.

Maybe we could use after_wp_config_load for the import command?

[wojtekn]

@JanJakes, it makes sense to try with the after_wp_config_load for the import command, especially since it would be consistent with wp db import.

[JanJakes]

@wojtekn I pushed that change, let me know if it works for you.

[JanJakes]

@wojtekn I pushed some changes to fix all the issues, except for DB_NAME — I'm wondering if there's a way to use the correct database name in that case.