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.

More than one SSL should be allowed to be installed on per-application bases. SAN SSL or Wildcard SSL does not cover this case.

This is what I mean.
When running a Wordpress multisite network with subdomains as subsites, wild card SSL can only cover the subsites and the primary domain name.
If you intend to map custom domain names to individual subsides, this becomes impossible. Even though a SAN certificates can cover this, it has its limits of only 100 domains. This is essentially limiting your business to only 100 customers.

This is already possible with hosting accounts running Cpanel.

Hopefully, this will be added very soon so I can return to Cloudways. I really love your sevrvices.

There is suggestions dating back to 2016,17,18 and 19 to be able to do this but still no working solution?

You are able to do this at other platforms such as at Heroku, AWS, Azure and more.

Else the staging functionality would be pretty useless or at least an hassle to deal with if you need to reset your .env every time before you push your code while using a framework.

I do under stand that the servers are hosted at other services and could be a bit tricky to set env if there apis dosen't support it.But at least add it for those that dose...

Or an other approach would be to add an ignore functionality for specific files such as .env when pushing data.

The .env file and its vars should NEVER be track by git and should ALWAYS be ignored do to it cant include secrets or in laravel/lumens case even passwords.

I was advised by your support to create a php script that calls Cloudways api to trigger the staging push then overwrite my .env after this i done.
This works but still this would not be a valid solution in my opinion do the secrets and passwords has to be hard coded and/or tracked.. Also if you have many applications hosted you also need to create this script for every application you create.