Implement new experimental SQLite integration module by aristath · Pull Request...

As far as I understand, this is the only logic that runs when activating the module, correct? And then it would mean the user would land on a blank WP install?

Based on previous conversations we had on Slack, I would suggest that we also set up the database right away, so that it is at least a blank WordPress install with the Performance Lab plugin and the same modules enabled. This way it would make for a much better and less confusing user experience.

Would it be possible to call wp_install() here for the new SQLite database (at least if that database is empty)? If it's not possible within the initial request where a regular MySQL / MariaDB database is still used, we could also redirect to a custom endpoint that does this in a new request and then redirects the user back to the Performance Lab settings screen.

While this is initially going to be an experimental module and we're not going to get into the weeds of e.g. migrating a full DB, I still think a smoother user experience for this would be crucial, and the above suggestion may be feasible without too much effort.

As far as I understand, this is the only logic that runs when activating the module, correct? And then it would mean the user would land on a blank WP install?

Correct.

Based on previous conversations we had on Slack, I would suggest that we also set up the database right away, so that it is at least a blank WordPress install with the Performance Lab plugin and the same modules enabled. This way it would make for a much better and less confusing user experience.

If an SQLite database doesn't exist (ie, this is the 1st time the user activates the module), they will land on the WP-install screen so they can enter their admin username/password, sitename etc.
The copied db.php file then takes care of activating the performance-lab plugin, and activate the default modules + SQLite.

Would it be possible to call wp_install() here for the new SQLite database (at least if that database is empty)? If it's not possible within the initial request where a regular MySQL / MariaDB database is still used, we could also redirect to a custom endpoint that does this in a new request and then redirects the user back to the Performance Lab settings screen.

I just pushed a tweak that does that
However, I was unable to achieve it in PHP so it was accomplished using a window.location.reload(true); call. That in turn, triggers WP to redirect to the login screen if a database exists - and then after login the user lands on the perflab settings - OR, if a database doesn't exist, WP redirects the user to the install screen.

While this is initially going to be an experimental module and we're not going to get into the weeds of e.g. migrating a full DB, I still think a smoother user experience for this would be crucial, and the above suggestion may be feasible without too much effort.

@aristath

If an SQLite database doesn't exist (ie, this is the 1st time the user activates the module), they will land on the WP-install screen so they can enter their admin username/password, sitename etc.

Why do we need to require the user to do that though? They already provided that information when they set up the original DB, so I think it would be a much smoother experience if we didn't prompt them to the WP install screen, but rather called wp_install() for the new DB right away, based on the values that are in the current DB.

Related is my comment #547 (comment), we could right after wp_install() also run logic to mark the Performance Lab and the current modules as active in the new SQLite DB.

Maybe I'm missing something here that makes this infeasible though?

In the week that has passed since this comment, I tried multiple iterations and approaches to this. Unfortunately, I was unable to make it work... I agree that it would be better UX if the database was auto-populated.
However, no matter what I tried, there are issues because it's a different database, there are timing issues, we actually need to have 2 different database connections open, and overall it's a nightmare If I'm not getting an install screen, I'm getting database errors. Switching databases on the fly is no easy task

Since the "copying" functionality will not be part of Core if and when this gets merged, I don't think that getting an install screen would actually be a blocker to get this in the plugin
If anything, it will allow us to ensure that the actual WP installation runs smoothly when a user wants to use SQLite on their site.