Also, an option to keep the .git directories and .gitignore files (as mentioned by @Charles Roper).

Pleaseeeeeeeeee this would have saved me HOURS in migration.
How in the world has this been a wish list item for 8 years???

The clone process should also preserve any git repos on the server. Right now, the .git directory and .gitignore file is excluded from a clone. This means, in order to restore the repo after a clone, we need to remove the existing files and pull the repo down again from the origin (github in our case). This should not be necessary! A clone should preserve any git repos present on the server as these are a key part of many workflows.

Whenever I clone a server, or even restore from a backup, the server is configured with the default timezone, language, php settings, etc... It's always hard to configure because each configuration changed takes time to save.

So I would like that when a server is cloned it comes with the same settings as the original. Cloning should work like that, right?

Another request is that it is possible to configure the default preferences so that you can apply them all at once without having to manually configure everything one by one.

Thanks.

When cloning a WordPress app - enable an option to ensure that the PHP FPM Settings are also cloned to the new app. Currently PHP FPM Settings are not cloned to the new app.

I find this a bit cumbersome as I tend to forget to manually make the changes to the PHP FPM Settings in the newly cloned app.

(Even better have an option for global PHP FPM Settings - or an options to select multiple apps and apply PHP FPM settings to multiple apps at the same time.)

Yes, please!!! When performing site care on 100+ sites and creating a staging site each time, the repetitive adjusting of settings and SSL is very time consuming.

If I want to downgrade server plan, or move to a different provider, I have to clone the server. But cloudways clone does not clone the server: it selectively copies some of the applications, leaving behind all the staging sites. I typically have two or three staging/dev sites for every application on a server. So a 'clone' operation only moves over 1/3 of the applications! And everything else needs to be done manually. And worse, staging applications cannot be cloned. So we need to recreate every staging site on the new server, then use a migration plugin to move all the application over one at a time. Very bad.

a MUST... I don't even know why this has not been implemented since the start! A clone is a clone... not a clone of files/db with default settings!!

How it should look like is, before hitting the final "clone" button, you could just add a checkbox that say something like
"I want all my app settings to be cloned along".
That's it... as it's very annoying to manually input all settings, SSL, cron job, etc and it's not efficient in 2020... its' a machine world, let's put machines and script to do the job for us!!

I just sent an email to Cloudways about the exact same thing. I love many things about Cloudways, but that keeps me annoyed every time I migrate and suddenly mess around with the user credentials.

Yeah it also needs to have an option to choose if you want to use the same folder/db name or have cloudways generate a new one. Because currently it doesn't allow you to cloning one site multiple times to another server. It just says the application already exists.

Yes, I agree, the cloning process should have more options that allow application database name, crudentials, ect.

This is really needed.

Oh yes, I am refraining from cloning anything right now (specifically server clone) due to Domains and SSL not being cloned over as well, this is a HUGE issue for me and very time consuming to re-setup everything again...

When cloning applications it should be a checklist where you can choose if you want restore points to be cloned as well

I propose streamlining the WordPress Add Application process by modifying the Add Application screen to add fields for WordPress User, and WordPress User Password. This would allow us to input whatever user and password we would want, as opposed to having to accept the default user and password that Cloudways currently generates.

This would make it much easier to deal with new sites, as a new user must now be created in WordPress after the site is created. In addition, if the current WordPress user is deleted directly in WordPress, the Admin Panel section of Cloudways still shows the old (originally created) user and password, even though it has been deleted in the WordPress application.

These same changes should be added in the Clone App process, so that a new WP user and PW can be generated before the site is cloned. The cloning process would have to look at the current WordPress user and password, then create a new WordPress user and password to replace the one from the site being cloned (the original WP user would then be deleted as part of the cloning process).

Let's face it... WordPress is very popular, and by adding this type of functionality to Cloudways, it would make Cloudways much more useful, and desirable.

Thanks.