Forgetting to uncheck "Share document root", one user erase his website
Hello,
Today I had the bad news to get a ticket from a user who erased his website by installing a new WordPress (through WP Toolkit), to an "addon" domain (or, now, I don't know how we are supposed to call that : "second domain added in an existing cPanel account!?").
Looking on that issue, we discovered that instinctively, he had "add another domain" under the unified "Domains" section > Submit that form and go straight to WP Toolkit to install WordPress.
I mean that he did not Unchecked the "Share document root" checkbox under the "Document Root (File System Location) " section.
[QUOTE]Document Root (File System Location)
If the document root is shared then the created domain will serve the same content as "example.com". This setting is permanent.
Share document root (/home/example/public_html) with "example.com".
the Default option offer the ability to ERASE the files through WP Toolkit (specially dangerous for (not so) beginner users) See screenshot below. It seems obvious to me that this checkbox should be Unchecked by default, to avoid the risk that users erase their WordPress websites with Toolkit, right after adding a new domain to the cPanel account (sure, Toolkit shows a warning, but my user was sure that he had selected the right "addon domain"). My users even don't know in which case they should point several domains to the same index.php file. The most part of the addon domains are not kind of "alias", but real websites hosted at the cPanel account root level (/home/user/example.com/). Do you agree that "most of the time, addon domains are used to host addon websites" ? If yes, you should agree that this checkbox should be Unchecked, because 1. it is the most common usage 2. the actual behaviour is "destructive" in case users do not read well the "disclaimer" each time they add an addon domain (and most of the users don't read all the disclaimers" and I confess I could make the mistake too by adding domains quick, the unified "domains" section was confusing in some way => specially this "inheritDocumentRoot" checkbox :-( Or at least, give us the possibility to uncheck the box from WHM tweak settings... Hopefully, I am doing daily backups. So I was able to restore the files from the night, but it seems he lost some data. Thanks A Lot in advance for the people from cPanel who are reading users complaining here :-D Tell me if I am wrong with this UX choice. !?
the Default option offer the ability to ERASE the files through WP Toolkit (specially dangerous for (not so) beginner users) See screenshot below. It seems obvious to me that this checkbox should be Unchecked by default, to avoid the risk that users erase their WordPress websites with Toolkit, right after adding a new domain to the cPanel account (sure, Toolkit shows a warning, but my user was sure that he had selected the right "addon domain"). My users even don't know in which case they should point several domains to the same index.php file. The most part of the addon domains are not kind of "alias", but real websites hosted at the cPanel account root level (/home/user/example.com/). Do you agree that "most of the time, addon domains are used to host addon websites" ? If yes, you should agree that this checkbox should be Unchecked, because 1. it is the most common usage 2. the actual behaviour is "destructive" in case users do not read well the "disclaimer" each time they add an addon domain (and most of the users don't read all the disclaimers" and I confess I could make the mistake too by adding domains quick, the unified "domains" section was confusing in some way => specially this "inheritDocumentRoot" checkbox :-( Or at least, give us the possibility to uncheck the box from WHM tweak settings... Hopefully, I am doing daily backups. So I was able to restore the files from the night, but it seems he lost some data. Thanks A Lot in advance for the people from cPanel who are reading users complaining here :-D Tell me if I am wrong with this UX choice. !?
-
I did reach out to the UI team and confirmed it is on the agenda, but I don't have an ETA at this point. 0 -
I did reach out to the UI team and confirmed it is on the agenda, but I don't have an ETA at this point.
It is sad that they didn't prioritize this. If they need time, why doesn't someone write a KB on how to modify the theme to uncheck the option? There is an official theme modification guide, but it seems one had to dive deep to deselect the option as the official guides don't have any information on how to do that, which would be time-consuming and might break other things. In any case, I am sorry for you CPRex, as you are the one who has to endure all the public banter.0 -
In any case, I am sorry for you CPRex, as you are the one who has to endure all the public banter.
It's all good - I just try and help the community, and relay stuff to the development team, whether that feedback is good or bad. Being stuck in the middle is *exactly* why I'm here.0 -
Oh, it's a shame we don't even have an ETA for something so critical and easy to implement. Was a case number generated? This is something that has been requested since last year and continues to cause serious problems in the user experience. Even with the notice, in 2 days we have had around 4 clients that delete the content of public_html to use other domains since it appears that they already have a wordpress installed, ignoring that they are sharing the same folder as another domain. We need an immediate and effective solution. Just uncheck the default option. Please cPRex, help us convey the urgency. 0 -
Thinking out loud, can we include some jquery that unchecks it? 0 -
It seems to me there just wasn"t enough thought in the consequences of users deleting WordPress sites from WP Toolkit that reside in public_html when this was added to the UI. I agree a resolution for this issue should be prioritized. 0 -
Update - the UI team has left the following comment on the case, so I wanted to pass this along:
Update the interface to use a clearer distinction between the options it is presenting. Change the default to create a unique document root when addon or subdomains are available to create. When the user doesn't have the ability to create an addon or subdomain, the default should remain "alias"
I just wanted to let you all know this is getting some action.
do you know any eta for the second? "change the default to create an addon domain if available". this would for sure, reduce the amount of tickets we receive every month. clients wrongly add them as alias, since it's the default one right now.0 -
@JoseDieguez - you've likely seen me say this before, but there is never an ETA. I have expressed how critical this is to the team as much as I possibly can, so they are well aware at this point. 0 -
@JoseDieguez - you've likely seen me say this before, but there is never an ETA. I have expressed how critical this is to the team as much as I possibly can, so they are well aware at this point.
sorry, i try to read as much as i can of every thread of my interested, may have missed the no eta yet. I came here, again, because a client asked for 10 manual wordpress migrations, and all his domains were added as alias to the /public_html, so this gave us some extra steps, of removing and re-adding the domains, before we can actually work on his request.0 -
@JoseDieguez - not, I just meant in general, on any thread or any case, I don't provide ETAs until I am 100% certain they will be fixed. 0 -
That's why I asked if a case number was assigned. And it was not. In other words, it didn't make it to the official to do list. 0 -
@Dhrupodi - yes, the case number is PH-19276 0 -
Mohon dibantu penjelasannya mengenai "share document root", karna saya cari2 belum dapat penjelasannya, 1.apa fungsinya? 2. ketika kita membuat subdomain, apa yang harus dilakukan? di centang atau tidak? jika dicentang apa yg akan terjadi? begitu juga jika tidak dicentang? 3. kalau buat subdomain apakah nanti auto ada folder baru? dimana posisi file nya? Terima kasih. 0 -
@justitia muhardiman 1 - Jika Anda membiarkan opsi ini dicentang, Anda membuat domain alias, yaitu domain yang memiliki konten yang sama. 2 - subdomain tidak akan memiliki opsi yang dicentang 3 - ya, ada folder baru, dan Anda dapat menentukan lokasinya di halaman. ================================================================================================= 1 - If you leave the option checked, you create an alias domain, which is a domain that shares the same content. 2 - a subdomain would not have the option checked 3 - yes, there is a new folder, and you can specify the location on the page. 0 -
@Dhrupodi - yes, the case number is PH-19276
Thank you for the update.0 -
Sure thing! 0 -
Hi Guys, We have exactly the same problem - so a official fix would be great (ASAP) After reading through the entire tread, it dont see any workarrounds, just a method for placing a notification, which I dont belive (knowing our clients) will help that much. Anyone found out how to uncheck it via JS maybe? Thanks 0 -
Hi @cPRex ! It's been about 3 months since my query, plus seeing new WHM/Cpanel updates but still no option to tweak the big frontend bug on addon domains. I would like to ask you if there is any news or ETA available? Thanks 0 -
I don't have any updates to provide on the case at this point. I know they are still looking into it, though, as I have seen recent activity on the case. 0 -
Hello ! cpRex, do we have any news? The problems persist. It really is an issue that cPanel should give priority, it is considered a failure in the user experience. We remain very attentive, thank you! 0 -
@Jaime Eduardo Gomez - I'll see if I can get some real answers tomorrow. Everyone was already out by the time I saw this one. 0 -
For those of us on the LTS (servers with CL7) this won't be fixed though. It'd be great to have a jquery that unchecks the box. 0 -
@Jaime Eduardo Gomez - I left a comment on the case as I couldn't poke the person I really wanted to today. I'll going to leave this browser tab open so I can check back in on it. 0 -
Here's my understanding of this issue as it currently stands - yes, the team does want to make this change, but there are also some other "ease of use" changes they'd like to make to that page as well, and it seems like those will all be happening at the same time. That's why it seems that this is slow to get adopted. Since we all know development work can change or hit snags, I don't have much other information I can provide or an ETA at this point. 0 -
Softaculous shows a warning if a WordPress install already exists in the same directory. Could that be a solution? 0 -
We don't have any integration with Softaculous, so I don't see how that would work for this situation. But yes, a warning or change of some type is needed. 0 -
Here's my understanding of this issue as it currently stands - yes, the team does want to make this change, but there are also some other "ease of use" changes they'd like to make to that page as well, and it seems like those will all be happening at the same time. That's why it seems that this is slow to get adopted. Since we all know development work can change or hit snags, I don't have much other information I can provide or an ETA at this point.
Oh I understand, it means that we won't see it in 2023. A shame. Personally, it seems like a bad decision to leave an error of this type for 1 year or more, nor to provide any practical temporary option to solve it. But there is nothing that can be done, just wait. What a bad experience with cpanel. Let's hope that the changes they have in mind are really friendly and designed to make life easier for the user and for us, and don't ruin it even more. Thank you so much @cPRex !0 -
Hi @cPRex ! I had not seen the changelog for version 116 in detail. I saw this note: Fixed case CPANEL-43003: Make configurable the default state of the "Share document root" box on the "Create a New Domain" page in cPanel. Could you please give us more details if it will be configurable from UI or from code? Good news is coming :) 0 -
The option will be included in Tweak Settings! 0 -
The option will be included in Tweak Settings!
That's great. I suppose there's no chance of backporting this to the LTS release, right? Many of us are stuck on Cloudlinux7 and are putting together our migration plans.0
Please sign in to leave a comment.
Comments
63 comments