Disable import/export for sites not using SQLite integration

[fluiddot]

Related to https://github.com/Automattic/dotcom-forge/issues/9395

Proposed Changes

• Add a function to determine if SQLite integration is installed on a site.
• Add an IPC handler that determines if the Import/Export feature is supported for a site. For now, the condition we check is if SQLite integration is installed for that site as the import/export commands used only support SQLite databases. In the future, we could add more.
• Render a warning notice in the Import/Export tab if the site doesn't have the SQLite integration.

Testing Instructions

• Create a site.
• Navigate to the site folder.
• Remove the file wp-content/db.php.
• Navigate to the Import/Export tab.
• Observe a warning notice is displayed and that the Import/Export functionality is disabled.
• Select another site.
• Observe the Import/Export functionality is enabled and working.

Pre-merge Checklist

• Have you checked for TypeScript, React or other console errors?

[fluiddot]

@matt-west let me know if you could take a look at the UI and share thoughts/feedback. I decided to use the WordPress Notice component as an initial iteration, but we could follow a better approach. Thanks 🙇 !

[jeroenpf]

I don't think we need to check this because even if you remove this file, the site will still work and use SQLite. It will just create a new .ht.sqlite file automatically.

[fluiddot]

Ah, thanks for pointing this out. I've tested removing the file and confirmed it's recreated. Hence, I'll remove this check.

[fluiddot]

I've addressed this in 3314f63.

[jeroenpf]

Is this function checking if SQLite plugin is installed or if it is active? I think, based on the code inside the function, that it is to check if SQLite is active. If that is the case, for clarity maybe this can be renamed to isSQLitePluginActivated or something similar.

[fluiddot]

Yep, good point. The function checks both that is installed and active. My rationale is that since the SQLite plugin is a must-use plugin if it's installed we also consider it active. However, I agree that it's more accurate to reference in the function's name that the plugin is active. I'll rename it.

[fluiddot]

I've addressed this in 566e657.

[matt-west]

@fluiddot Sorry for the slow response on this!

Using the Notice component here makes sense. We’ll have an updated version of this in the new design system, but we can use this one for now.

I think we could tweak the copy to something like:

Import / Export is not available for this site
This feature is only available for sites using the default SQLite integration.

[fluiddot]

@fluiddot Sorry for the slow response on this!

Using the Notice component here makes sense. We’ll have an updated version of this in the new design system, but we can use this one for now.

I think we could tweak the copy to something like:

Import / Export is not available for this site
This feature is only available for sites using the default SQLite integration.

Great, thanks @matt-west for taking a look 🙇 ! I'll update the message and wrap up the PR with the current design 👍 .

[fluiddot]

@jeroenpf @matt-west I've addressed the latest comments and updated the message in the notice. The PR is now ready to review. Thanks 🙇 !

[wojtekn]

@fluiddot it works for most of my sites. However, it disables Import / Export for some older sites that had -main appended to the sqlite plugin name:

Could we handle those, too?

[fluiddot]

@fluiddot it works for most of my sites. However, it disables Import / Export for some older sites that had -main appended to the sqlite plugin name:

Could we handle those, too?

Sure, I'll cover this case when we use -main for the folder's name. I feel this case can be easily overlooked when testing, so I'll consider adding some unit tests to cover it.

[sejas]

@wojtekn, I wonder how is possible to have a site with the old integration 🤔 .

From what I can see the old/main SQLite folder gets renamed when the site starts.

studio/src/lib/sqlite-versions.ts

Line 173 in 792b39e

await removeLegacySqliteIntegrationPlugin( sqlitePluginPath );

studio/src/lib/sqlite-versions.ts

Lines 139 to 142 in 792b39e

	const sqliteInstalled = await isSqlLiteInstalled( sqlitePath );
	const sqliteOutdated = sqliteInstalled && ( await isSqliteInstallationOutdated( sqlitePath ) );
	if ( ( ! sqliteInstalled && ! hasWpConfig ) || sqliteOutdated ) {

Could you share your zip? Maybe your site is using MySQL?

[wojtekn]

@sejas I checked two sites, and one has a plugin in wp-content/mu-plugins/sqlite-database-integration-main and another in wp-content/plugins/sqlite-database-integration.

The sites that show the warning, have the plugin in wp-content/mu-plugins/sqlite-database-integration. Stopping and starting site doesn't change anything.

[sejas]

@wojtekn , can you try again?

I tried using a different approach, by checking if the $wpdb uses the SQLite PHP class, but I had to go back to use the paths check because my approach only worked for started sites. Making it work for stopped sites is possible but we need a big refactor, and I think that is currently out of scope of this issue.

Here is the code for reference to check if SQLite is used in a WordPress site:

		const isSQLitePhp = `<?php
		require_once('${ this.server?.php?.documentRoot }/wp-load.php');
		global $wpdb;
		echo get_class($wpdb) === 'WP_SQLite_DB' ? 'true' : 'false';
		`;
		let isSQLiteString = null;
		try {
			isSQLiteString = await this.server?.runPhp( {
				code: isSQLitePhp,
			} );
		} catch ( error ) {
			Sentry.captureException( error );
		}
		return isSQLiteString === 'true';

So in the end I just added the alternative paths and added a new test. Let me know if it works for your old sites.

[wojtekn]

Works well for all three cases: plugin in wp-content/, plugin in mu-plugins/, and plugin in mu-plugins/ with -main appended to the name.

[wojtekn]

As we only check if files and directories exist, should we find a more accurate name for the function like hasSQLitePlugin?

[sejas]

Great suggestion. Done! 9e54f4a