Issue with EV SSL renewal

[RodG]

And unfortunately for some, there are those hosts that say: thou has no way as an end user to adjust the document root of the server as public_html is your document root, you have no access to a higher path/area,

Agreed, but it is *very rare* that anyone would need a doc_root at a level *higher* than public_html - I've never found a need for this in over 20 years of hosting (exect on my own servers/VPS servers, where a higher level can be used to greatly enhance some forms of security), but basically, this is a moot point that doesn't need to even be mentioned, let alone discussed.

and if you decide to place the contents of your store in a sub-directory from public_html you will forever be forced to use some other process to ensure that customers arrive at that location as the "root" of your store.

NOT SO! I've yet to find a host where this isn't possible - Not only is it possible, but in *many* situations it is actually *desired*.

The thing is here. The OP had previously hosted the site with this sub-directory is the domain,

This is pretty standard practice.

continues to want that and the site is not supporting that arrangement and the host has not provided a solution that complies with that arrangement. So... from the OPs perspective the document root has always been public_html with the site provided from catalog as the first directory off of public_html...

What can I say? The OP has simply never had the site correctly set up - Well, he *has*, but only if he ever uses a single domain/site for the given host.

As DrByte said, it worked before the host made a change and it was working in such a way that catalog was displayed in the browser as a sub-directory off of the domain name. If you are stating/giving a solution that will alter the uri that has been in existence and used for the site, the effects of such modification both "good" and bad should be explained to the OP. Otherwise, as has been provided give a solution that restores the web-facing operation back to what it was.

It is not my point to discuss any of the possible workarounds. I have already acknowledged that they exist. Let's leave it at that.

Like I said, I didn't see how the document root could be used to necessarily force a visitor onto the web-facing catalog directory by way of entering just the domain name. And no such solution was described as it isn't possible without some form of rewrite/redirect based on the above two posts.

You are correct, but this is still a 'workaround' of an iincorrect document_root.

As it stands (for the OP) - his URL for his zencart site is always going to show /catalog/ - In some cases this is fine, if there are other files/software (eg, Wordpress) exists in the document root, and the zenstore is a subset of the wordpress site), but his zenstore *isn't* a subset of any other software - He has *nothing* in the document root (other than the .htaccess file to force a *needless* redirect to a folder, that *should* be the document root.

I personally agree that a sub-directory in the uri (DIR_WS_CATALOG) is generally unnecessary if not in some ways harmful, but that is associated with a new install not an existing one of a relatively new store. Making a change at that point in the operation is something that should be planned not just done because a couple of people made it sound cool. :)

As I stated, I will never understand why people make it hard for themselves, and I strongly disagree with your statements that imply it can't be done *right*.

Lets look at a couple of examples... assume a person has a single hosting account with two different zencart stores - Based on what you are saying (and with full acknowledgement that a folder *above* public_html can't be used, then what will the folder structure be?

There are three possibilities:

1)
/public_html/zenstore#1/
/public_html/zenstore#1/zenstore#2

In this scenario. and based on the claim that doc_root can''t be changed, there will need to be a .htaccess redirect placed in public_html for zenstore#2 and zenstore#2 will need the WS defines for the folder/
The URL for zenstore# look quites unprofessional - being in a folder of the domainname. IOW, a 'workaround' is needed.

2)
/public_html/zenstore#1/
/public_html/zenstore#2/

This is very similar to scenario one, but now *both* stores/domains need a 'workaround' and the folder showing in the URL - There is effectively no 'root' for either domain.

3)
Same as #2
/public_html/zenstore#1/
/public_html/zenstore#2/

... But *this* time, we have set the document_root for zenstore#1 to be /plublic_html/zenstore#1 and the document_root of zenstore#2 to be /public_html/zenstore#2

In this scenario, we don't need any .htaccess redirects in /public_html/ - From the server perspective, this folder doesn't even exist. We also don't need to include zenstore#x in any of the zencart server defines, nor do we need to set any zencart WS defines to refer to any folders. THese will all simply be the default "/"

The only place where zenstore#x will be defined in the zenconfig file, will be in the FS defines.

It really couldn't get any simpler than that.

Even with just a *single* store in a folder located off of the public_html/ folder - as is the OP's case (/catalog/ ) - The /catalog/ is superfluous and unprofessional if shown/used in the URL. It smacks of *amateurism*.

And if *you* think that this *professional* scenario can't be achieved "due to ISP/host limitations, then please contact me via PM, because I have a *lot* to teach you about host configurations.

FYI,
http://www.radiosailingshop.com.au/
http://girlbysea.com.au

Are two *independent* zencart sites for a customer with a single hosting account with a file structure
/public_html/radiosailing/
/public_html/girlbysea/

There are no redirects in place, no /folders/ in the zencart config files (other than the FS defines) - You can go to either site, and no 'folders' are shown in the URL (one would expect http/domainname1.com/radiosailing/ and http://domainname#2/girlbysea/ unless a rewrite were used. The 'magic' that makes this work, with no redirects, and no /folders/ shown is simply because the document_root for the radiosailing domain is set to /public_html/radiosailing/ and the document_root for girlbysea is set to /public_html/girlbysea/

I have yet to find a host where this configuration isn't possible. I/we even have a policy these days that all sites we setup/host actually use a document_root one folder *deeper* than /public_html/ - It makes no difference to the webserver (which will always use the correct 'root' for any given domain for any given customer). but it makes a *huge* difference in regards to the file structure and ease of adding other domains for the same customer account.

Hopefully, this all makes sense to you (I suspect it doesn't though), else you wouldn't be making statements that imply that this isn't possible with all hosts. It *is* possible, and where one icould have been difficult, the cPanel (that most hosts use these days) makes it trivial.

BTW, I *hate* cPanel - It allows people without a clue the ability to set up their own 'hosting business'. (I'm not suggesting that you are one of these people) but without Cpanel (or should I say WHM) most hosting providers these days wouldn't even exist.

Cheers
RodG

[mc12345678]

Agreed, but it is *very rare* that anyone would need a doc_root at a level *higher* than public_html - I've never found a need for this in over 20 years of hosting (exect on my own servers/VPS servers, where a higher level can be used to greatly enhance some forms of security), but basically, this is a moot point that doesn't need to even be mentioned, let alone discussed.



NOT SO! I've yet to find a host where this isn't possible - Not only is it possible, but in *many* situations it is actually *desired*.




This is pretty standard practice.



What can I say? The OP has simply never had the site correctly set up - Well, he *has*, but only if he ever uses a single domain/site for the given host.



It is not my point to discuss any of the possible workarounds. I have already acknowledged that they exist. Let's leave it at that.



You are correct, but this is still a 'workaround' of an iincorrect document_root.

As it stands (for the OP) - his URL for his zencart site is always going to show /catalog/ - In some cases this is fine, if there are other files/software (eg, Wordpress) exists in the document root, and the zenstore is a subset of the wordpress site), but his zenstore *isn't* a subset of any other software - He has *nothing* in the document root (other than the .htaccess file to force a *needless* redirect to a folder, that *should* be the document root.



As I stated, I will never understand why people make it hard for themselves, and I strongly disagree with your statements that imply it can't be done *right*.

Lets look at a couple of examples... assume a person has a single hosting account with two different zencart stores - Based on what you are saying (and with full acknowledgement that a folder *above* public_html can't be used, then what will the folder structure be?

There are three possibilities:

1)
/public_html/zenstore#1/
/public_html/zenstore#1/zenstore#2

In this scenario. and based on the claim that doc_root can''t be changed, there will need to be a .htaccess redirect placed in public_html for zenstore#2 and zenstore#2 will need the WS defines for the folder/
The URL for zenstore# look quites unprofessional - being in a folder of the domainname. IOW, a 'workaround' is needed.

2)
/public_html/zenstore#1/
/public_html/zenstore#2/

This is very similar to scenario one, but now *both* stores/domains need a 'workaround' and the folder showing in the URL - There is effectively no 'root' for either domain.

3)
Same as #2
/public_html/zenstore#1/
/public_html/zenstore#2/

... But *this* time, we have set the document_root for zenstore#1 to be /plublic_html/zenstore#1 and the document_root of zenstore#2 to be /public_html/zenstore#2

In this scenario, we don't need any .htaccess redirects in /public_html/ - From the server perspective, this folder doesn't even exist. We also don't need to include zenstore#x in any of the zencart server defines, nor do we need to set any zencart WS defines to refer to any folders. THese will all simply be the default "/"

The only place where zenstore#x will be defined in the zenconfig file, will be in the FS defines.

It really couldn't get any simpler than that.

Even with just a *single* store in a folder located off of the public_html/ folder - as is the OP's case (/catalog/ ) - The /catalog/ is superfluous and unprofessional if shown/used in the URL. It smacks of *amateurism*.

And if *you* think that this *professional* scenario can't be achieved "due to ISP/host limitations, then please contact me via PM, because I have a *lot* to teach you about host configurations.

FYI,
http://www.radiosailingshop.com.au/
http://girlbysea.com.au

Are two *independent* zencart sites for a customer with a single hosting account with a file structure
/public_html/radiosailing/
/public_html/girlbysea/

There are no redirects in place, no /folders/ in the zencart config files (other than the FS defines) - You can go to either site, and no 'folders' are shown in the URL (one would expect http/domainname1.com/radiosailing/ and http://domainname#2/girlbysea/ unless a rewrite were used. The 'magic' that makes this work, with no redirects, and no /folders/ shown is simply because the document_root for the radiosailing domain is set to /public_html/radiosailing/ and the document_root for girlbysea is set to /public_html/girlbysea/

I have yet to find a host where this configuration isn't possible. I/we even have a policy these days that all sites we setup/host actually use a document_root one folder *deeper* than /public_html/ - It makes no difference to the webserver (which will always use the correct 'root' for any given domain for any given customer). but it makes a *huge* difference in regards to the file structure and ease of adding other domains for the same customer account.

Hopefully, this all makes sense to you (I suspect it doesn't though), else you wouldn't be making statements that imply that this isn't possible with all hosts. It *is* possible, and where one icould have been difficult, the cPanel (that most hosts use these days) makes it trivial.

BTW, I *hate* cPanel - It allows people without a clue the ability to set up their own 'hosting business'. (I'm not suggesting that you are one of these people) but without Cpanel (or should I say WHM) most hosting providers these days wouldn't even exist.

Cheers
RodG

If I were to properly split through the above, this might be "easier" but, I'm lazy. :)

I have not personally come across a server that can not permit assignment of a document root to anything other than public_html; however, in assisting other to *initially* setup their system I have been told that they would have to obtain a second domain in order to have any domain made accessible from deeper than the main public_html... I personally use one if not more levels deeper than public_html for my sites/test sites. That a site *can not* is really all/more about *will not* because it doesn't fit their business model or whatever other dumb @$$ reason that they have come up with to not make it amenable to the customer/store owner.

My issue here is that in none of the examples provided did a change in document root resolve the uri to what it has been before the SSL was installed and there has been no discussion of the impact of a change of the web-facing uri with regards to search engines or ranking.. Somewhat comical to bring to the discussion is the "professionalism" of the uri that *tongue in cheek* supposedly makes no difference to customers because they don't pay attention to them anyways, and could be anything. (Little bit of a continuous discussion about unrelated topic of URI rewriters and the web site path that with great surprise has dwindled as of recent. ;) )

Okay, but seriously, like I said, I agree that there is no business reason for a domain name that solely supports a single "subject" (store) should use a web-facing subdirectory as the base of the store. At the very least changing the document base for a store that has already been in operation to remove the web-facing sub-directory will break links that are/have been stored by visitors even those that only saved the store's home-page... And to prevent/correct that specific issue if one wished to maintain that level of reachability at least for a period of time would require a rewrite rule (again) which has also been suggested as unfavorable/unnecessary. Yes, of course could make the change and then let the chips fall where they may.. But that should be a conscious decision not just something willy nilly done.

Further unfortunately, it seems that perhaps a similar rewrite/redirect previously existed, but wasn't known to exist and when touching the site the host modified something to accomplish what we all would suggest (for a new site or to plan for as a transition) which is to place the site/software at the root of the domain name regardless of how many sub-directories exist on the "back-end". Regardless they changed the operation and have falsely accused ZC as being the fault.

OP, choose what you would like. Right now your what, at least 3 days without guests arriving at your store by typing in the domain name... How's traffic been? Reduced? Sales? Any change? Are you wanting operation as it was and setting aside time to address the other things that we're here talking about? I would suggest doing something, either move the document root, or move the store from the sub-directory to the document root, or redirect visitors to the sub-directory. Right now as you discovered, entering just the domain-name gives a 403 forbidden page which means off to the next site if/when provided.

[RodG]

If I were to properly split through the above, this might be "easier" but, I'm lazy. :)

<smiles>

Further unfortunately, it seems that perhaps a similar rewrite/redirect previously existed, but wasn't known to exist and when touching the site the host modified something to accomplish what we all would suggest (for a new site or to plan for as a transition) which is to place the site/software at the root of the domain name regardless of how many sub-directories exist on the "back-end". Regardless they changed the operation and have falsely accused ZC as being the fault.

OP, choose what you would like. Right now your what, at least 3 days without guests arriving at your store by typing in the domain name... How's traffic been? Reduced? Sales? Any change? Are you wanting operation as it was and setting aside time to address the other things that we're here talking about? I would suggest doing something, either move the document root, or move the store from the sub-directory to the document root, or redirect visitors to the sub-directory. Right now as you discovered, entering just the domain-name gives a 403 forbidden page which means off to the next site if/when provided.

I am in total agreement with all that you have written here.

As for all else that we have discussed, I am happy to conditionally agree, completely agree, or agree to disagree (depending on which particular point is/was being discussed).

I knew I ran the risk of this 'debate' when I tossed my 2cents worth into things, even though I 'knew' that the points I was making would be of no help to the OP in any way, but I was/am hoping that the principles I outlined would be useful/helpful to others (the prime point being 'get the document_root right first, and the other fixes/workarounds will never be needed), so kudos to you for bringing it back on track with suggestions and ideas that will be helpful to the OP... and the OP is the important part of this thread.

I know he is in good hands with you as a guide. You were *not* one of those that I was thinking of with my "I will never really understand why so many people make this so difficult for themselves" comment (which was more of a general swipe at the many that consider redirects/rewrites as the 1st, and sometimes only, option).

All good. No further debate from me.

Cheers
RodG