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. !?
-
Hey there! I've reached out to the user interface team to get their thoughts on this and I'll let you know what I find out! 0 -
I spoke with the team and they are going to do a bit of research to see what the most common option is, as that will decide if the checkbox is on by default. In general, I personally think Alias domains are a bit more common than Addon domains, which would encourage the checkmark being there by default, but I'll let them do the actual work on that and make a decision. If I hear any updates on this I'll be sure to post them. 0 -
Hi cPRex! Thanks for this first-fast answer :) From my tiny experience, I don't "think" that "Alias domains" are globally more common than "Addon domains", but since every case is unique, making the option available in the "Tweak Setting" to uncheck that "inheritDocumentRoot" by default (to the cPanel licence owner responsibility) should be a great choice ? I also ask the cPanel community opinion here. I will be curious to ask this to massive shared hosting providers that promote hosting for unlimited websites in a single cPanel account (bad practice, I know, but cPanel account have a cost). For my part, only less than 5% of my users use "Alias domains", but +50% use "Addon domains", at least. The actual default option for the "Share document root" checkbox could be destructive ; the second option (uncheck), not destructive. I'm hosting less than 1k cPanel account, but I am already worrying to get more users in the future who's made this "easy mistake"" (I do not worry for the hours of support to fix on our side > restoring backup" But worry for some sensitive files that could be definitely lost for my unexperimented users). I cannot tell them : "You must uncheck the box, it's your obvious mistake"" as myself I think this one should be unchecked. The tasks of Adding an "Addon Domain" and then "Install WordPress" via Toolkit should be straight for beginners, with no (such) risk to actually remove all the files of a previous WordPress install. Even if WP Toolkit, warn about it, it's not enough (you know, game consoles always ask if you want to "quit without saving" even if you actually saved the game 5sec ago ;-) it means that "warning are never enough", because people are in the hurry and "Skip the warning"). I would like to ask, what you think about a "Splash Screen" or "Dynamic Dropdown" asking : "What do you want to add [Addon Domain] [Alias Domain]"" but it was the cPanel old fashion way, and it was removed with the unified Domains section. I understand that your UX specialist look to avoid more "clicks" made by the users, for common task (and I support your "Jupiter, v100+ developments"!). That's why I want to warn the community about this issue, because more and more people will use Toolkit also (great product!). Better to fix globally !? than doing my selfish keeping my info and customize the XML Lang file to add my own warning-workaround :) As a provider, I serve only few hundreds of cPanel users, and it already happened Twice to my users base to forget to Uncheck this box, in the past 2 ~ 3 weeks. With the cumulative effect, for bigger companies, I cannot imagine the potential consequences of thisUX "issue" (my thoughts). As usual, in the meantime, my suggestions or ideas for a workaround : I already could customize my french XML translation file to better warn my users, but I am curious if there is something else I can do to unchecked that properly from my side by CLI ? Thanks a lot, I know cPanel is concerned by the "Data loss risk" (of course), and will offer us the best "solution" for the long run. 0 -
I vote for having the box unchecked. I have never added an alias domain, but have add quite a few addon domains over the years. I'm just a website owner, small business, not a backend admin guy. I moved to a Cpanel from Plesk, and when adding a domain on the cPanel I was presented with the checkbox already checked. I wasn't sure I should go with that or not. I had to search out what it meant by checking or unchecking the box so as not to make a mistake. This was my search term "cpanel which is better share document root or separate document root". Fortunately, I found this post and I now know I do not want to share the document root. I can't conceive of anyone ever wanting to do that when adding a domain to their hosting account. I agree with everything cPRex has stated. I think his points are really important and I registered on this forum just to put in this comment. "What do you want to add [Addon Domain] [Alias Domain]"" Having that simple instruction - and a checkbox for one or the other - would have been very helpful. 0 -
I also vote for having the box unchecked. Customers are breaking their websites and we're flooded with tickets. 0 -
It takes very long time to fix a so critical issue :( that drive some users removing their WordPress websites, by creating domain and using WordPress Toolkit after that (frequent behaviour). 0 -
Another simple solution would be to do something radical like have two separate options - one specifically for creating alias domains, and another for creating addon domains. Our end-users never encountered confusion or problems similar to this prior to cPanel's moves towards packing all the domain functions into one option. I really have doubts about the level of UI/UX expertise being employed of late in cPanel's interface changes. Regards, LBJ 0 -
I do see our User Interface team has created an internal case for this, so there will be some action on this. I'll continue to post updates as I have them. 0 -
@cPRex Thanks a lot for keeping us all informed. Is there an update on this? Websites have been breaking left and right for this feature every time there are some .htaccess rules in the public_html. We would like a tweak settings option to leave the [Share document root] option unchecked by default. This is a critical feature leading to misunderstanding and losing customers in some cases. Additionally, I would like to express my discontent with how the UX team collects feedback. It seems there is a consistent disconnect from the real world during the past couple of years. I haven't found a single server where there are more alias domains than addon domains. 0 -
I don't have any updates on my end just yet. @Dhrupodi - how would you like to see the feedback process improved? When I hear something from an end user, I take it straight to the team responsible, either through a case if there is an issue with the product, a feature request if we need to add something, or a direct message with a developer, depending on what the issue calls for. 0 -
@cPRex what you do is impeccable. I have seen you go above and beyond to help people, including me. I was expressing my frustration toward the UX dev team, not toward you. I do not know how they collect feedback. My users haven't appreciated their recent changes. My job has become harder due to their UX changes, too. I know this is a separate and frequent topic, but I won't venture any further into that. I love cPanel. I will continue to hope that cPanel will not continue to make our lives harder. 0 -
Chiming in, as a provider with 20 years of cPanel experience. We hardly ever see aliases, and many many of our customers make use of addon domains. I have never had to reply to a ticket asking about domain aliases. We get tickets about adding an add-on domain every other day. 0 -
We desperately need instructions for our customers here. I wonder if some HTML could be included via cPanel customization system so we can explain what"s going on? 0 -
Are the details in our documentation page at Domains | cPanel & WHM Documentation not sufficient? If so, is there something we could improve there? 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.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.
Thanks a lot! Appreciate that you are keeping us all informed.0 -
Any update? How is it possible that Cpanel does not have specific data on the use of this and also that it is thinking so much to fix it? In the forums, blogs, comments, you can see that the vast majority use additional domains, not aliases. This UI bug is causing us a lot of support issues. Is it so complicated to give us an option in configuration to choose whether or not to mark it as default? More than 4 months to decide to give us a configurable option? We're not talking about something critical to the kernel. Only the choose default option or not. For our part, I can confirm that out of 2400 customers, 0 customers use aliases. 0%. nobody. Please, more empathy with cPanel customers. 0 -
I did see you also posted this to the feature request as well. I've let the UI team know about the feedback. 0 -
I did see you also posted this to the feature request as well. I've let the UI team know about the feedback.
Hello cPRex ! An apology if the message is somewhat aggressive. It's just that these kinds of changes are hurting us all. And you say that the normal use is aliases, but in any comment that cPanel clients can see we say that the normal use is Addon Domains. Anyway an apology. I appreciate your management in the forums. A doubt and that can serve as a partial and temporary solution for us: How can we add a text block as an alert or warning on the cpanel Domains page? I am attaching an image as an example (manipulated from the console's HTML). Thank you.0 -
I completely understand the issues with the page, and the UI team is aware of the confusion this is causing for end users. I don't have a good way to add something to the page like your example. 0 -
Even after modifying cPanel to alert users about this, we are running into this issue almost daily. Please, please, please UNCHECK the "share document root". It would still be bad even if cPanel was in the user's native language. Being in a foreign language, it's a recipe for disaster. 0 -
I've let the developers know the urgency on this issue. 0 -
That's true. Posting the notice helps us because 95% of clients speak Spanish, but there is another problem. People don't read jejeje While it has helped us, there are still some cases where they mistakenly do it as an alias, and what they want is an additional domain. Hopefully that cPanel can correct that mistake very soon. 0 -
I just had another client erase his website. Of course they will not read any instructions. Can we just have some sane defaults that actively prevent customers from doing stupid things like erasing the contents of public_html? 0 -
I've let the developers know the urgency on this issue.
Thank you. If you wouldn't mind me asking, was any case number assigned to this issue? It seems to me that you and we are fighting an uphill battle. For whatever reason, someone at cPanel decided it is a bright idea to share the public root among multiple domains, while every norm in web hosting, web design, and web development strongly recommends the opposite. This is so destructive for a web application, if a web developer at any web development firm does it, they would probably get fired. It breaks a magnitude of things. I cannot fathom how the experienced developers at cPanel came up with this idea. And we are now stuck, with nobody making a simple change that has a destructive nature. It saddens me.0 -
@Dhrupodi - I haven't forgotten about you - I just had a few days off and now I'm waiting to hear from the development team about the status of this. I'm hoping I'll get good news this time! 0
Please sign in to leave a comment.
Comments
63 comments