WordPress site has the site type "custom site" when Acorn in included as mu-plugin

DevKinsta Application Support
1

We’ve created several sites on our Kinsta account as WordPress sites, but when we clone them locally via DevKinsta and add our custom theme + plugins, they show up as having the “Custom site” site type. This results in some funkiness (I assume these issues are related, but I’m not sure). For example, the WP Admin button becomes inaccessible, and when we push a database from our local DevKinsta environment up to Kinsta, it doesn’t perform a complete search/replace on URLs in the database, necessitating an additional manual search/replace each time.

My question is: What defines whether a site is listed as a “custom site” vs. a WP site?

Edit: I’ve determined the switch from WordPress site to custom site occurs when we install Acorn as a mu-plugin. Any ideas on how to avoid this? Acorn is required for our Sage-based theme.

Edit 2: Interestingly, the site type does not change to “Custom site” when we install Acorn as a normal plugin rather than a mu-plugin.

2

Hi @ian, welcome to the DevKinsta community!
Thanks for sharing the troubleshooting you have done so far, that quickly lead me to find the culprit.

What defines whether a site is listed as a “custom site” vs. a WP site?

We use a specific WP CLI command to verify that WordPress is installed and that it isn’t returning an error. When this command isn’t able to return a standard response, DevKinsta uses the label “Custom site”.

I was able to replicate that DevKinsta shows “Custom site” when the Acorn plugin is installed as a mu-plugin. This is due to the fact that when not installed as a regular plugin, Acorn is returning a critical error regarding the PHP version being used as it checks the CLI version of it via Composer instead of checking the FPM version (which is set in DevKinsta and that can be easily changed).

You can verify this on your side too, if you are familiar with Docker, by using this command inside the devkinsta_fpm terminal after moving to the site location: wp core is-installed --allow-root; echo $?

The error returned should then be:

PHP Fatal error:  Composer detected issues in your platform: Your Composer dependencies require a PHP version “>= 8.0.2". You are running 7.4.30. in /www/kinsta/public/yoursitename/wp-content/mu-plugins/acorn/vendor/composer/platform_check.php on line 24
Fatal error: Composer detected issues in your platform: Your Composer dependencies require a PHP version “>= 8.0.2”. You are running 7.4.30. in /www/kinsta/public/yoursitename/wp-content/mu-plugins/acorn/vendor/composer/platform_check.php on line 24
Error: There has been a critical error on this website.Learn more about troubleshooting WordPress. There has been a critical error on this website.

So, as explained above, since that WP CLI command isn’t returning 0 as response, DevKinsta shows “Custom site”.

If you really want to solve that, you will need to manually edit the PHP version used by the command line. This can be done by running the following command and selecting the preferred version (in this case, 8.0 or 8.1) inside the same docker terminal: update-alternatives --config php

Once this has been done, DevKinsta should then change “Custom Site” to “WordPress x.z.y” where x.z.y is the version used.

I hope this helps!

Regards,
Alessandro

3

I would politely suggest that this should be part of the DevKinsta container setup, so that if someone shells into that container to issue any CLI php - including the wp CLI - they’d just get the matching version to what FPM is currently configured to use.

4

Thanks, that works like a charm! I greatly appreciate your help and speedy reply, Alessandro! :star: :star:

This is a little odd, however, since I have the site (and basically all the sites on our account) set to use PHP 8.1 specifically to avoid errors like this. My expectation is that when clone a site from Kinsta using DevKinsta, and both sites are set to use PHP 8.1, I wouldn’t see this type of error. Just my two cents, for what it’s worth.

Thanks again!

5

@Whitesided thanks for your feedback and welcome to the DevKinsta community :+1:
I’ll pass this as a feature request to our devs.

@ian I’m glad to read that it worked!
The reason why you haven’t noticed this issue on your sites in Kinsta is that when you change the PHP version in MyKinsta from the Tools page, that is changed both for the FPM and for the CLI version, while this doesn’t happen in DevKinsta.
I’ve just sent a feature request to the team so that when the PHP version is changed or set in DevKinsta, the PHP version for CLI is changed accordingly. Our devs will review and discuss the ways and means of it and see if it can be implemented one day👍

6

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.