Issue WP Toolkit Cloning/Copying Fails to Isolate Scheduled Tasks (Cron Job Conflict)

[RegioOnline]

Server operating system version

Ubuntu 22.04.5 LTS

Plesk version and microupdate number

Plesk Obsidian 18.0.73 Update #3,

Hi Plesk Support Team,

We are experiencing a critical failure in task isolation when cloning WordPress installations using the WP Toolkit. This issue leads to immediate interference with the scheduled tasks (cron jobs) of the original live site, specifically affecting critical backup routines.


Steps to Reproduce the Issue:

1. Ensure the Live Site (e.g., example.nl) has active custom scheduled tasks configured (e.g., a daily backup script running via crontab).
2. Go to the WP Toolkit and click Clone or Copy the Live WordPress installation.
3. Choose to clone the site to a new webspace/subdomain within the same subscription (e.g., staging.regioonline.nl).

Observed Malicious Behavior:

• Upon completion of the cloning process, the custom scheduled tasks (cron jobs) belonging to the Live Site are either deleted, overwritten, or propagated to the staging environment, causing the Live Site's critical backups to immediately fail.
• This suggests that the automatic cloning process fails to assign a truly unique and isolated UNIX System User to the new webspace, leading to a shared or incorrectly linked crontab environment between the two installations.

Workaround (Confirming Diagnosis):We confirmed that manually copying the files and database to the new subdomain (without using WP Toolkit's Clone/Copy function) prevents the cron job conflict. This isolates the failure point specifically to the WP Toolkit's automated process of configuring the new webspace and its Web Hosting Access/System User.

Could you please investigate why the automated cloning process fails to ensure absolute isolation of the underlying UNIX System User and associated scheduled tasks (crontab) between the two WordPress installations?

Thank you for your assistance.

Best regards,
Egbert van den Bosch (Netherlands)

 

[Sebahat.hadzhi]

Hello, @RegioOnline . Thank you for the report. Unfortunately, I was unable to replicate the behavior. I tried cloning the website under a subdomain associated with the same domain and with a different one (under the same subscription). In both cases, the cron task remained unaltered. I would also like to point out that if both websites (original and clone) are located under the same webspace, it is expected for the system user to be the same.

Workaround (Confirming Diagnosis):We confirmed that manually copying the files and database to the new subdomain (without using WP Toolkit's Clone/Copy function) prevents the cron job conflict. This isolates the failure point specifically to the WP Toolkit's automated process of configuring the new webspace and its Web Hosting Access/System User.

Was the manual cloning in this case performed under the same subscription or under a different one?

 

[RegioOnline]

Hi Sebahat.hadzi,
Thanks for your fast response. The manual cloning was under the same subscription but tried to chance that with a new webspace, I found the possible cullprit. I think that the real reason of this behaviour is because I am using Plesk web admin edition. I learned that this version does not allow using seperate workspaces. I was not aware of that and bought a subscription for WP Toolkit for cloning. Although the cloning part works great, it seems the Plesk version does not allow the seperation of workspaces. I have my own (unmanaged) VPS and installed Ubuntu with Plesk from the account of my vendor (STRATO). I made sure everything is updated and set with optimal settings. I think I need to upgrade to Plesk Web Admin Pro (or something like that) to enable seperate workspaces. WP Toolkit full version is a part of that subscription. I run 1 site, highly dynamic (newssite with over 52.000 posts and 20 new every day) on on Apache VPS with 16cpu, 60GB RAM and 2TB storage. I want to run one or two more sites in the future and ofcourse use staging for testing purposes. Would upgrading Plesk solve my issues? And what plan would be the right one for my situation you think.

 

[Sebahat.hadzhi]

If your end goal is to have different system users for the production and staging environments, then, yes, Web Pro Edition is probably your best option as the entry point including subscription management. The other option is to review the command and, if possible, to adjust it so it could be ran independently for both websites from the same user.

 

[RegioOnline]

Thanks for the reply Sebahat.hadzhi. I now know I need to upgrade my Plesk version, else seperate webspaces are not possible. With my current version everything stay under the same system user, so also the cronjobs. Thanks for giving your insight and a direction for me to follow. Much appreciated!

 

[Kaspar]

@RegioOnline cloning or copying a Wordpress installation to another (sub)domain should not alter any scheduled task you've manually added for the domain, regardless of which Plesk edition you're using.

In your posts you're mixing the terminology of webspaces, subscriptions and workspaces. Which makes it a bit difficult to understand what you're actually referring to. Within the user context of Plesk a webspace and a subscription are the same. (I.e; a primary domain with it's own resources and system user, to which you can add additional (sub)domains and aliases who share the same resources and system user.) The webspace naming is primarily used when using the Web Admin edition (or when using the Power User view on the other editions). A subscription naming is used on the Service Provider view (which lets you manage customers and Service Plans too). They are technically the exact same thing.

To my knowledge there is no limitation with the Plesk Web Admin edition in cloning a Wordpress installation to a different webspace. When cloning a Wordpress installation you've got two options to clone the Wordpress installation to:

​

1) Create sub-domain​

Which allows you to create a new subdomain for the clone to an already existing domain within the current webspace. Using this option will always create a subdomain within the same webspace. This behavior is the same for all Plesk editions.​

​

2) Use an existing domain​

Selecting an existing domain let's you clone the Wordpress installation to any (sub)domain already present on your server. Even to domains who use a different webspace. This is the only option to clone your Wordpress installation to a domain in a different webspace.​

I don't think that upgrading your Plesk licence to a different edition will solve your issue.

If any scheduled task you've manually added to a domain is actually altered after cloning I recommend opening a ticket with Plesk support for an investigation on your server. As this very likely unintended (and undesirable) behavior which should be investigated. Since you mentioned that you've got your server from Strato I assume you Plesk license is too. In which case they should provide support. You can opening an issue with them and they can forward it to the Plesk support team. Or you could signup for a Plesk support subscrption to get support directly from Plesk.

Hope this helps.

 

[RegioOnline]

Hi Kaspar,

Thanks for your insight. I might have overcomplicated things a bit that got lost in translation. I wil try explain it straightforwrd as possible.

I have a newssite in the Netherlands on a VPS, with Ubuntu and Plesk Web Admin Edition. For the live newssite, I have created several backup cronjobs, for seperate backups of my website files and database. Through a Windows powershell script backups wil be downloaded to local drive with retentions and uploaded to cloud. Because I have a newssite this backup routibne is very important.

If I clone my newssite with WP Toolkit to staging.mywebsite.nl, I get a perfect clone, but all cronjobs are also active on this clone. If I delete the backup cronjobs at the staging site, they are also deleted for the main live site. This is because Plesk Web Admin Edition only allows only one systemuser.

As you can understand it is not my intention that the staging site is also running this backup cronjobs (at same times). In fact the cronjobs are systemwide, since I can not seperate a staging site to a different webspaces/systemuser with Plesk Web Admin Edition. Only Web Admin Pro and above are able creating separate webspaces/systemusers. That is the issue in a nutshell Kaspar.

 

[Kaspar]

[...] Through a Windows powershell script backups wil be downloaded to local drive with retentions and uploaded to cloud.

Just to be sure, the server you're using with Plesk runs on Linux? Or is it a Windows server?

In fact the cronjobs are systemwide, since I can not seperate a staging site to a different webspaces/systemuser with Plesk Web Admin Edition.

You mean you created the cronjobs in Plesk via Tool & Settings > Scheduled Tasks (Cron jobs), instead of via Scheduled Tasks of the domain itself? If that's the case, what system user is selected for the cron job to run as?

 

[RegioOnline]

Just to be sure, the server you're using with Plesk runs on Linux? Or is it a Windows server?

I am using a Linux server. On the server cronjobs make the backups. On my Windows computer Windows Scheduled Task starts a small batch file wich call de powershel script, toggling between Linux server, Windows OS (for local) and Google Drive (for cloud). Downloads are done by the script, for uploads the powershell script calls rclone to handle the uploads. It took several weeks to create with some help of Ai, but it works like a charm.

You mean you created the cronjobs in Plesk via Tool & Settings > Scheduled Tasks (Cron jobs), instead of via Scheduled Tasks of the domain itself? If that's the case, what system user is selected for the cron job to run as?

No, I created the cronjobs through Websites & Domains > Dashboard > Scheduled taks on the live site. That is controled by the systemuser A. When I clone that site to staging.mywebsite.nl, the same cronjobs are in Website & Domains > Dashboard > Scheduled task under the same systemuser A.

If I created a systemuser B and created a blank new site under systemuser B with domain staging.mywebsite.nl and then manual copy the wp site to the domain staging.mywebsite.nl and imported a databasedump of the live site. Then my live site is suddenly managed by system user B and cronjobs stay the same.

What if have read sofar, it is a limitation of Plesk Web Admin Edition. Only the Pro edtion (WP Toolkit included for free) as the possibility to make seperate webspaces for seperate systemusers. At least, that is what I can make of it up to now.