• If you are still using CentOS 7.9, it's time to convert to Alma 8 with the free centos2alma tool by Plesk or Plesk Migrator. Please let us know your experiences or concerns in this thread:
    CentOS2Alma discussion

Question Plesk 12.5 - Delete Subdomain - Keep Files

futureweb

Regular Pleskian
Hey there,
I'm just trying to delete a Sub-Domain but keep the Files on my Server. (multiple Sub-Domains pointing into the same Docroot)
But I can't find a way to do this?!? When I try to delete the Domain - Plesk warns me that it will also delete the Docroot ...
Any clean way to do this?
thx
Andreas Schnederle-Wagner
 
thx for this workaround - guess there is no "clean way" to do this?
As this approach isn't really End-User-Friendly ... ;-)

Guess I will open Feature Request for this ...
 
@IgorG Is there any update on this issue? This is an essential feature (and source for errors) in case you work with staging sites - as for instance explained by your colleagues at Working with a Staging Site.
It regularly happens that you want to delete the staging site once the new site is up and running.
I consider it that essential that it is not ok to request this on uservoice...
Also, the support article linked above should be updated to include / recommend a procedure on how to remove the staging subdomain once the new site is up and running.
 
@Kaspar Let's assume you have a site example.com which is associated with a corresponding subscription
- (www.)example.com as the main domain of the subscription currently runs any type of website/CMS, but no Wordpress, using current.example.com as document root
- While developing the new Website (e.g. with Wordpress), you create a staging site testing.example.com which is hosted in subdirectory new.example.com as document root

Once the client decides to switch to the new system, I would update the hosting settings, i.e. change the document root of (www.)example.com to new.example.com.
- while changing subdomain names (e.g. from new.example.com to old.example.com) would be possible, this does not seem to be the case for "renaming" testing.example.com (subdomain) to example.com (main domain). Thus, I have to change the hosting settings of example.com instead and point to the right directory (new.example.com)
- once the main domain works as expected, you would want to remove the subdomain testing.example.com. If you do not change the document root beforehand, this would delete the directory new.example.com, which still serves as document root for example.com.
- In order to be able to remove testing.example.com, I first need to point the document root of that subdomain to a new, empty temporary folder and then delete the subdomain.

To avoid this, I see two things that should be implemented:
a) The option to delete a (sub) domain WITHOUT deleting the associated content (folders, databases etc.), i.e. offer "delete domain + content" and "delete domain but keep content".
b) When the user clicks the "delete" link, Plesk should check if the document root (or any of its sub folders) is used by any other (sub) domain in this subscription. If this is the case, the option "delete domain + content" should be disabled and a warning should appear that explains which (sub) domains are still using the content.
 
Plesk should check if the document root (or any of its sub folders) is used by any other (sub) domain in this subscription. If this is the case, the option "delete domain + content" should be disabled and a warning should appear that explains which (sub) domains are still using the content.
I understand the demand, however the workflow and setup itself is flawed. Setting different domains to use the same document root directory is the issue. I've also seen, like you have, that users do that all the time, because they don't like to use an alias, don't want to use the WP clone function, want to save time to simply copy the files to another directory etc. It's still a flawed concept to associate different domains with the same root. The whole concept of a "domain" is that this is a dedicated area of objects. One domain controls all that is associated with it. If another domain starts stealing into it, it will cause problems. Also, when you expand the idea, then you'd also allow a second domain to control the same email addresses as the first domain. That's why people came up with aliases as a solution for that in the past.

But if you override this basic idea of what a domain is and use the same sources for several domains without configuring the additional domains a aliases, so that each of the additional domain also thinks it can control the domain, it becomes unclear which domain is finally responsible for the content. This is proned to fail and opposes the concept of a domain.

Anyway, the Uservoice suggestions exist and if they get enough votes, the ideas will be considered. It's good, too, that you have outlined here why you require this function and what your workflow is. It helps to understand this better.
 
Back
Top