• We value your experience with Plesk during 2024
    Plesk strives to perform even better in 2025. To help us improve further, please answer a few questions about your experience with Plesk Obsidian 2024.
    Please take this short survey:

    https://pt-research.typeform.com/to/AmZvSXkx
  • The Horde webmail has been deprecated. Its complete removal is scheduled for April 2025. For details and recommended actions, see the Feature and Deprecation Plan.
  • We’re working on enhancing the Monitoring feature in Plesk, and we could really use your expertise! If you’re open to sharing your experiences with server and website monitoring or providing feedback, we’d love to have a one-hour online meeting with you.

Resolved WP Toolkit: Live site cloned, clones using plugins folder of original site

ArmReu

New Pleskian
Server operating system version
Ubuntu 20.04.5 LTS
Plesk version and microupdate number
Plesk Obsidian v18.0.49_build1800230110.16 os_Ubuntu 20.04
Hi everyone! I have experienced some very strange behavior with a clients site, or with its clones to be more precised

The situation:

I had a live site managed in Wordpress Toolkit and everything works fine (WP Toolkit version: 6.1.2-7079, Web Admin license). I cloned the live site into two new instances in subdomains (dev and stage). There everything went fine aswell, no errors or anything

Lets call them:
livesite.com
dev.livesite.com
stage.livesite.com

Now the issue: When updating stage or dev somehow live was updated aswell. Further investigation showed all three instances are using the same plugin directory. When checking the directries in wordpress health screen the plugins dir shows the live sites plugin dir, all others look fine.

Heres how it shows in the health/direcitories screen:
WordPress directory location
/var/www/vhosts/livesite.com/dev.livesite.com
Uploads directory location
/var/www/vhosts/livesite.com/dev.livesite.com/wp-content/uploads
Themes directory location
/var/www/vhosts/livesite.com/dev.livesite.com/wp-content/themes
Plugins directory location
/var/www/vhosts/livesite.com/httpdocs/wp-content/plugins

As you can see only the plugins directy is wrong and not set to the plugins folder of the clone dev.livesite.com but using the patt of the original site livesite.com

My obvious problem is that i now cant test plugins updates in dev or stage as it keeps updating the plugins directory of the live site.

I checked the pathes in the data base as well as in default-constants.php and could not find anything that refers directly to the old/original site.

HTACCESS also just has the default stuff from wordpress and wordfence, so nothing there that might cause the issue ether.

Here a copy of the plugin directoy constants:

function wp_plugin_directory_constants() {
if ( ! defined( 'WP_CONTENT_URL' ) ) {
define( 'WP_CONTENT_URL', get_option( 'siteurl' ) . '/wp-content' ); // Full URL - WP_CONTENT_DIR is defined further up.
}

/**
* Allows for the plugins directory to be moved from the default location.
*
* @since 2.6.0
*/
if ( ! defined( 'WP_PLUGIN_DIR' ) ) {
define( 'WP_PLUGIN_DIR', WP_CONTENT_DIR . '/plugins' ); // Full path, no trailing slash.
}

/**
* Allows for the plugins directory to be moved from the default location.
*
* @since 2.6.0
*/
if ( ! defined( 'WP_PLUGIN_URL' ) ) {
define( 'WP_PLUGIN_URL', WP_CONTENT_URL . '/plugins' ); // Full URL, no trailing slash.
}

/**
* Allows for the plugins directory to be moved from the default location.
*
* @since 2.1.0
* @deprecated
*/
if ( ! defined( 'PLUGINDIR' ) ) {
define( 'PLUGINDIR', 'wp-content/plugins' ); // Relative to ABSPATH. For back compat.
}

So my questions:

1. Anyone has an idea what might have caused this? To me the cloning seems to have worked perfectly except the adjustment of the plugins path.
2. I am searching for a way to fix this, ideal would be to now having to recreate the dev and stage clones again.
3. If I really have to remove dev and stage from within WPtoolkit I am concerned this might even delete the live sites plugin directoy.

Any help would be highly appreciated.

Kindest regards

Armin
 
A little typo in my post:

2. I am searching for a way to fix this, ideal would be to now having to recreate the dev and stage clones again.

That was ment " ..., ideal would be NOT having to recreate the dev and stage clones again."

Sorry about that.
 
A little update:

I just created another clone of the live site (without any errors) and the new clone shows exactly the same problem. All directories are corrent pointing into the subdomains folders except the plugin directory. This - again - is pointing to the plugin directory of the live site.

So from my wild guessing is it is not an issue of the sites but perhaps a bug or issue of the cloning process in the current plesk version?!

This way or that way makes my original question even more important: How to change a sites plugin folders path in configs after a site has been cloned?
 
And highly related to this:

If I remove a wordpress installation from wordpress toolkit, where the plugin path is set to outside the normal wordpress path, will the plugin directory still be deleted, even if it "belongs" to another wordpress installation managed by wordpress toolkit too?
 
Okay ... now it gets even more confusing ... and concerning:

I did another clone of the site but to a different domain. And even here the plugin path remains the same to the original site/domain.

I checked the plugins folder of the cloned sites and it looks like all the files have been copies correctly and complete, including permissions and all.

It looks like the step of adjusting the plugin path is completely skipped everytime during cloning process when the configuration files are corrected/re-written ... o_O
 
Update and appologies:

It turned out all the trouble were simply caused by a custom added define( 'WP_PLUGIN_DIR' ...) in wp-config.php which had a fixed path in it.

So I guess it is not really a problem of the cloning process. Yet perhaps the devs should be informed that this variable definition might cause problems and should be checked for during cloning.

@Mods: Issue can be closed
 
Back
Top