Change existing site from sub directory to the root of the web site

[mc12345678]

So your domain points to something like:

/home/username/public_html

Most cPanels have the ability to modify to where the domain points, which would mean that you could modify the domain to point to: /home/username/public_html/shop

The user would see your domain name, but the subfolder of shop would be where the content was/is. Therefore, the site could be in a folder, but the user would not see that folder. This is similar to what you should have had to do for the subdomain that you setup where you identified that the subdomain could be located in a particular folder. If that folder was specifically your public_html and not a subfolder off of it, then yes there is a mess. :)

Popular good versus bad? Well, everyone has their preference and reason and method of managing. I've worked significantly from two different hosts, neither specifically has a public_html folder, but they have "defaults" for all that they do. Is it good to follow a "social" norm? Sure, that way everyone can talk from the same page... It is also why certain things are used/stated for certain conditions and expectations on this forum. That way everyone can relate and work from a common basis. :)

[RodG]

I can't help it, I let too many people in the front door over the years, each one dropping a file here or there. Now I have to figure out if they are needed before I delete them.

If your 'site' consists of Zencart and nothing else, and the site resides in
/public_html/shop/ then any other files in the /public_html/ folder can be deleted.

HOWEVER, do yourself a favour and don't just go head first into deleting everything. In fact I suggest you delete *nothing*. Either create an 'archive' of the files first, or make a local backup of them. Then and only then should you consider deleting anything.

If you delete 'too much' things will surely break, but at least you'll be able to restore the files that are needed. As I say though, if you are only using zencart and its files are in a sub-folder, then everything (other than the sub folder) can be deleted.

I guess I'm not following how web addresses work cause my store is in a folder now , /shop/ so my site points to it by thestitchsanctuary.com/shop

But I want to be able to just refer to it as thestitchsanctuary.com.

Are you saying that is possible?

Sure it is.

Now I have to figure out if they are needed before I delete them.

Back 'em up, then delete from the server. Check that the site is *fully* functional, then *move* (don't copy) all of the files out of /public_html/shop/ into /public_html/

Edit the config files to match the new location. Check that all is OK.

The reason I say *move* rather than copy, is because if you make a copy and don't get the configure file changes 100% correct you *could* end up with a site that *appears* to be fully functional, but is in fact pulling some data from the relocated files, and some data from the /shop/ folder. This can be a bit of a nightmare to both identify and resolve. In contrast, if you move the files the /shop/ folder will be empty, so now if you don't get the config files 100% correct the store simply won't function - But at least you'll know where to look for a solution - The config files.

Right now I have my blog folder, and a few backup folders in my public_html directory.

Are you using the blog? If not, archive/backup the folder and delete it. If you are using it, leave it where it is.

It is bad practice to keep backup files in any 'publicly accessible' folder, that includes the /public_html/ folder and all of its sub folders.

I was told to set up my test directory as a subdomain,

I've no desire to confuse you, but directories/folders and domains/subdomains are entirely different things that have no direct relationship with each other.

domains/subdomains relate to the URL/URI that people need to use to access your site.
directories/folders relate to the *physical location* of the files on the server.

If you take a good look at the ZenCart configuration files you'll note that some 'defines' read like "DIR_FS_" and others are like "DIR_WS_"
These denote the 'File System' (where the files reside on the server) and the 'Web Server" (The URL/URI that people need to use to access the site) respectively.

which I did but it's files are in the public html too. So I do editing of the htaccess rules when I need to run a test. I don't like having to do that but wasn't sure how else to do it.

Although not *strictly* true, a web server will only function with files placed in the /public_html/ folder and its subfolder. On some systems this folder will be called /www/, /docroot/ and even \inetpub\
The exact name depends on what the server itself, and how the server admin has configured things. For the majority of people this can't be changed. Folders that reside *above* these defined folders are inaccessible to the webserver itself. This is a security measure to prevent people accessing the critical system files via a web browser.

Cheers
RodG

[lruskauff]

So your domain points to something like:

/home/username/public_html

Most cPanels have the ability to modify to where the domain points, which would mean that you could modify the domain to point to: /home/username/public_html/shop

The user would see your domain name, but the subfolder of shop would be where the content was/is. Therefore, the site could be in a folder, but the user would not see that folder. This is similar to what you should have had to do for the subdomain that you setup where you identified that the subdomain could be located in a particular folder. If that folder was specifically your public_html and not a subfolder off of it, then yes there is a mess. :)

Ok, I went to my CPANEL and there is a "script" or "button" that I press and fill in the blanks for where I want my subdomain and blog to point. So I actually don't see what goes on behind the scenes. But I asked them (hosts) and they said I could do it by putting the following in my htaccess file.

The code is:

RewriteEngine on
RewriteCond %{HTTP_HOST} ^domain-name.com$ [NC,OR]
RewriteCond %{HTTP_HOST} ^www.domain-name.com$
RewriteCond %{REQUEST_URI} !folder/
RewriteRule (.*) /folder/$1 [L]

I will assume that I would put it at the top before all other rewrites but will it interfer with my Ceon URI Mapping rewrite rules as they stand? My current code besides the CEON URI Mapping is:

#used cpanel to add the following 301 redirects

###############################################################################

RewriteCond %{HTTP_HOST} ^thestitchsanctuary\.com$ [OR]
RewriteCond %{HTTP_HOST} ^www\.thestitchsanctuary\.com$
RewriteRule ^/?$ "https\:\/\/thestitchsanctuary\.com\/shop" [R=301,L]

RewriteCond %{HTTP_HOST} ^stitchsanctuary\.com$ [OR]
RewriteCond %{HTTP_HOST} ^www\.stitchsanctuary\.com$
RewriteRule ^/?$ "https\:\/\/thestitchsanctuary\.com\/shop" [R=301,L]

RewriteCond %{HTTP_HOST} ^thequiltsanctuary\.com$ [OR]
RewriteCond %{HTTP_HOST} ^www\.thequiltsanctuary\.com$
RewriteRule ^/?$ "https\:\/\/thestitchsanctuary\.com\/shop" [R=301,L]

I would be removing all of that. The first because it will no longer be needed and the next two because I read that those just cause google to split the rankings between them therefore hurting my rankings.

This is my CEON code:

# ONLY rewrite URIs beginning with /shop/
RewriteCond %{REQUEST_URI} ^/shop/ [NC]
# Don't rewrite any URIs ending with a file extension (ending with .[xxxxx])
RewriteCond %{REQUEST_URI} !\.[a-z]{2,5}$ [NC]
# Don't rewrite any URIs for some, popular specific file format extensions,
#   which are not covered by main file extension condition above
RewriteCond %{REQUEST_URI} !\.(mp3|mp4|h264)$ [NC]
# Don't rewrite any URIs for some specific file format extensions,
#   which are not covered by main file extension condition above
#   Uncomment the following line to apply this condition! (Remove the # at the start of the next line)
#RewriteCond %{REQUEST_URI} !\.(3gp|3g2|h261|h263|mj2|mjp2|mp4v|mpg4|m1v|m2v|m4u|f4v|m4v|3dml)$ [NC]
# Don't rewrite admin directory
RewriteCond %{REQUEST_URI} !^/shop/myadmin [NC]
# Don't rewrite editors directory
RewriteCond %{REQUEST_URI} !^/shop/editors/ [NC]
# Don't rewrite logs directory
RewriteCond %{REQUEST_URI} !^/shop/logs/ [NC]
# Don't rewrite sitemap directory
RewriteCond %{REQUEST_URI} !^/shop/sitemap/ [NC]
# Don't rewrite cgi-bin directory
RewriteCond %{REQUEST_URI} !^/shop/cgi\-bin/ [NC]
# Don't rewrite bmz_cache directory
RewriteCond %{REQUEST_URI} !^/shop/bmz_cache/ [NC]
# Handle all other URIs using Zen Cart (its index.php)
RewriteRule .* shop/index.php [QSA,L]

## END CEON URI MAPPING REWRITE RULE

I don't think I would want the /shop/ rewrites but not sure how to format the one that just says /shop/ . Would it be just "/" (no quotes, first rewrite cond). Or can I just rre-run the ceon configuration script again.

Popular good versus bad? Well, everyone has their preference and reason and method of managing. I've worked significantly from two different hosts, neither specifically has a public_html folder, but they have "defaults" for all that they do. Is it good to follow a "social" norm? Sure, that way everyone can talk from the same page... It is also why certain things are used/stated for certain conditions and expectations on this forum. That way everyone can relate and work from a common basis. :)

Thanks. (Please tell me I didn't expose anything)

[mc12345678]

Did to those that have subscribed to this thread... Was just going to advise about that, but see to some extent that it has been resolved. Still would recommend making the appropriate changes.

[lruskauff]

If your 'site' consists of Zencart and nothing else, and the site resides in
/public_html/shop/ then any other files in the /public_html/ folder can be deleted.

HOWEVER, do yourself a favour and don't just go head first into deleting everything. In fact I suggest you delete *nothing*. Either create an 'archive' of the files first, or make a local backup of them. Then and only then should you consider deleting anything.

Yes, I've been renaming things with a .del or .old very slowly to see if there is any effect. And my blog and test folder reside there too. Along with some random html.

Back 'em up, then delete from the server. Check that the site is *fully* functional, then *move* (don't copy) all of the files out of /public_html/shop/ into /public_html/

Edit the config files to match the new location. Check that all is OK.

The reason I say *move* rather than copy, is because if you make a copy and don't get the configure file changes 100% correct you *could* end up with a site that *appears* to be fully functional, but is in fact pulling some data from the relocated files, and some data from the /shop/ folder. This can be a bit of a nightmare to both identify and resolve. In contrast, if you move the files the /shop/ folder will be empty, so now if you don't get the config files 100% correct the store simply won't function - But at least you'll know where to look for a solution - The config files.

That makes sense, thank you. But I may leave them in the folder and change the domain pointer as mc12345678 suggested. I would like it though that I didn't have to share the htaccess file. Is that file always in public_html?

Are you using the blog? If not, archive/backup the folder and delete it. If you are using it, leave it where it is.

Trying to.

It is bad practice to keep backup files in any 'publicly accessible' folder, that includes the /public_html/ folder and all of its sub folders.

Yes, I know. They are kindof my quick backup. I also have a copy on my pc.

I've no desire to confuse you, but directories/folders and domains/subdomains are entirely different things that have no direct relationship with each other.

domains/subdomains relate to the URL/URI that people need to use to access your site.
directories/folders relate to the *physical location* of the files on the server.

If you take a good look at the ZenCart configuration files you'll note that some 'defines' read like "DIR_FS_" and others are like "DIR_WS_"
These denote the 'File System' (where the files reside on the server) and the 'Web Server" (The URL/URI that people need to use to access the site) respectively.

A big thank you for that one, I sure it saved some BIG confusion down the road for me. I realized that they were two different things but I thought that they had the same structure. Well I did until I installed CEON URI, which made me realize something was logical in my brain, I just hadn't put the two together yet.

Although not *strictly* true, a web server will only function with files placed in the /public_html/ folder and its subfolder. On some systems this folder will be called /www/, /docroot/ and even \inetpub\
The exact name depends on what the server itself, and how the server admin has configured things. For the majority of people this can't be changed. Folders that reside *above* these defined folders are inaccessible to the webserver itself. This is a security measure to prevent people accessing the critical system files via a web browser.
[\quote]
Funny, I just quized my host on what all those folders were above my public_html directory and what they are for. Since I can access many of them, I figured I should know.

Thank you all for the many explanations.
Lin
Cheers
RodG

[mc12345678]

Unless I'm missing something, the suggested code from your host looks like it forces the uri to show the store as being in a subdirectory which is exactly what is desired to not be presented.

I say this because I entered that into an .htaccess file tester and when entering domain-name.com it results in a uri of domain-name.com/folder

Like said I may be mistaken, but doesn't look like they are offering the solution we were discussing. Instead it is all back to having it all hosted in the file path one up above from the current file path.

[mc12345678]

.Htaccess file is considered a hidden file. As far as ZC is concerned, there is no need for a .htaccess file in the store's root. It is because other things require the rewrite offered by the .htaccess.

[lruskauff]

Unless I'm missing something, the suggested code from your host looks like it forces the uri to show the store as being in a subdirectory which is exactly what is desired to not be presented.

bummer. You are prob right cause I just checked my blog and it adds the /blog too instead of just blog.thestitchsanctuary.com/

I say this because I entered that into an .htaccess file tester and when entering domain-name.com it results in a uri of domain-name.com/folder

Like said I may be mistaken, but doesn't look like they are offering the solution we were discussing. Instead it is all back to having it all hosted in the file path one up above from the current file path.

Thank you for doing that extra step. I'm asking them again. They aren't that wordy but they do answer quickly.

So .htacceess file, is it always in public_html directory (or whatever the host calls that directory)? So even if I moved my site down 12 levels, I would still do my rewrites here?

Do we ever use them elsewhere?

[RodG]

Ok, I went to my CPANEL and there is a "script" or "button" that I press and fill in the blanks for where I want my subdomain and blog to point. So I actually don't see what goes on behind the scenes. But I asked them (hosts) and they said I could do it by putting the following in my htaccess file.

Hmmmm... there's a bit of a confusion/contradiction going on here.

First up, *exactly* what is the 'script' or 'button' that you are referring to.

I'm assuming it is one of
Subdomains
Addon domains
Parked domains
or Redirects.

These each have their own purpose, and if you are referring to the subdomain one this is a setting that directly controls the server. This is the 'document root' setting.
There are no redirects taking place (under normal circumstances), and nothing gets added to the .htaccess file.

Your host is misleading you (or you are misleading them).

The code is:

RewriteEngine on
RewriteCond %{HTTP_HOST} ^domain-name.com$ [NC,OR]
RewriteCond %{HTTP_HOST} ^www.domain-name.com$
RewriteCond %{REQUEST_URI} !folder/
RewriteRule (.*) /folder/$1 [L]

This is code that performs a redirect. Redirects have their uses, but should be avoided wherever possible.
(It is at this point that DivaVocals is going to step in and tell me how wrong I am) <SIGH>

I will assume that I would put it at the top before all other rewrites

Personally, I'd never make such an assumption. One of the biggest headaches and drawbacks of URL rewrites is getting the *order* of the rules correct and this order depends on your specific needs and requirements.
The best way to get it right is to not use the rewrites or redirects at all, they are only needed in *specific* circumstances, and as far as I can tell, you aren't up to the stage where these 'specific circumstances' would apply.

but will it interfer with my Ceon URI Mapping rewrite rules as they stand?

I'm not going to say Yes, and I'm not going to say No. I will say that they *could*. The fact is looking at the rewrites that you have supplied here NOT ONE OF THEM IS REQUIRED.

They are all 'Fixes' for 'problems' that wouldn't exist IF the documentRoot and DNS have been configured correctly in the first place.

Trouble is. many people (Hi DivaVocals) just *love* URL rewrites and redirects, and tend to use this 'tool' to 'fix' every problem rather than doing it the right way in the first place. The rewrite 'solutions' do tend to work, but what a mess they are to create, and it gets worse if/when you come across a situation where a rewrite is actually the correct tool for the job.

I don't think I would want the /shop/ rewrites but not sure how to format the one that just says /shop/ . Would it be just "/" (no quotes, first rewrite cond). Or can I just rre-run the ceon configuration script again.

You're not even using CEON for what it was designed for in the 1st place. Get rid of it. Simplify, simplify, simplify. Don't rewrite anything that doesn't need rewriting.

Seriously, get rid of them all. Set the documentRoot to where the files actually reside and your as good as done.

Cheers
RodG

[RodG]

bummer. You are prob right cause I just checked my blog and it adds the /blog too instead of just blog.thestitchsanctuary.com/

DocumentRoot isn't set to the correct folder. A rewrite has been added to 'correct' this. A better solution would be to correclty set the documentroot for the blog subdomain.

So .htacceess file, is it always in public_html directory (or whatever the host calls that directory)? So even if I moved my site down 12 levels, I would still do my rewrites here?

Do we ever use them elsewhere?

The .htaccess file(s) can be placed in any folder that the webserver uses. These files are/were traditionally created and used for (Guess what?) To control who can access the files/folders in which they reside.

The ability to use these same file(s) for redriects and rewrites were a later addition (saved having to create another 'control' file for this purpose), so although rewrites and redirects *could* be placed in these files in the subfolders, they are *generally* only used in the documentRoot folder(s) rather than any of their subfolders.
That said, it isn't uncommon to have a single redirect in the .htaccess file(s) of subfolders that people shouldn't have access too.. This redirect takes the user back to the store front (or perhaps the login page).

Cheers
RodG