/index.php essential?

[picandnix]

Ok, so I'm getting splinters from scratching my head so I'm going to ask for help:
New and clean install as SUB domain of main site demo.mystore. com
Admin works fine, as does store front IF url has /index.php included, click on logo or simply have demo.mystore. com as url and I get a 404 error.
Something in configure.php I'm guessing, but what?

Thanks in advance.

[mc12345678]

Actually, this is typically a result of something related to the .htaccess file in the directory(ies) in front of the sub-domain's location. Ie. The lack of identifying that index.php is one of the files to use instead of index.html as the main page.

[mc12345678]

Actually, this is typically a result of something related to the .htaccess file in the directory(ies) in front of the sub-domain's location. Ie. The lack of identifying that index.php is one of the files to use instead of index.html as the main page.

Didn't out right state it, but the issue is not related to how ZC operates but instead the server on which it is being hosted. A command that will resolve this issue to be added into a .htaccess (either in the directory above where this store is located in the filesystem or directly in the root of where the store is hosted) is:

DirectoryIndex index.php

If the host server settings can be modified, then there are other options that could be implemented based on what type of server/server software is used.

[picandnix]

...added into a .htaccess (either in the directory above where this store is located in the filesystem or directly in the root of where the store is hosted) is:

DirectoryIndex index.php

Hmm, no luck with that. To clarify I added the .htaccess to the root folder (above public_html) the main store (inside public_html) folder, by adding it to my existing .htaccess in there (I'm using ceon uri rewrite mod on main store hence already having a .htaccess in there) and also tried it inside the /demo folder housing the demo sub domain site that's having the issue.

[mc12345678]

Hmm, no luck with that. To clarify I added the .htaccess to the root folder (above public_html) the main store (inside public_html) folder, by adding it to my existing .htaccess in there (I'm using ceon uri rewrite mod on main store hence already having a .htaccess in there) and also tried it inside the /demo folder housing the demo sub domain site that's having the issue.

That is/was important information to have that CEON URI Mapping (requiring an htaccess file) was installed in the primary domain/folder structure.). A redirect to bypass the remainder of the htaccess before the CEON rules or an exception to the CEON rules is needed to prevent incorrectly rewriting a uri not associated with the rules.

You're welcome to post the htaccess contents to support evaluation, but if the rules are written per the CEON module's recommendation, obscure the admin directory name (or even if not written as directed by CEON URI Mapping, please don't post the admin directory's actual name or any information not desired to be known to the internet.)

[picandnix]

Apologies for the delay.

	## BEGIN CEON URI MAPPING REWRITE RULE
RewriteEngine On

# 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} !^/mysecretadmin [NC]

# Don't rewrite editors directory

RewriteCond %{REQUEST_URI} !^/editors/ [NC]

# Don't rewrite min directory

RewriteCond %{REQUEST_URI} !^/min/ [NC]

# Don't rewrite DELETEdownload directory

RewriteCond %{REQUEST_URI} !^/DELETEdownload/ [NC]

# Don't rewrite languages directory

RewriteCond %{REQUEST_URI} !^/languages/ [NC]

# Don't rewrite functions directory

RewriteCond %{REQUEST_URI} !^/functions/ [NC]

# Don't rewrite cgi-bin directory

RewriteCond %{REQUEST_URI} !^/cgi\-bin/ [NC]

# Don't rewrite logs directory

RewriteCond %{REQUEST_URI} !^/logs/ [NC]

# Don't rewrite auto_loaders directory

RewriteCond %{REQUEST_URI} !^/auto_loaders/ [NC]

# Don't rewrite setup directory

RewriteCond %{REQUEST_URI} !^/setup/ [NC]

# Don't rewrite classes directory

RewriteCond %{REQUEST_URI} !^/classes/ [NC]

# Handle all other URIs using Zen Cart (its index.php)

RewriteRule .* index.php [QSA,L]

## END CEON URI MAPPING REWRITE RULE

[picandnix]

This line the issue?
RewriteRule .* index.php [QSA,L]

[mc12345678]

This line the issue?
RewriteRule .* index.php [QSA,L]

Sort of... let me explain. That line is what to do if all of the rewritecond (conditions to be met to support the rewrite rule) lines above check out as true... so, with the way it is currently testing, nothing specifically says: hey this is a demo site that is trying to be reached (or reverse, this isn't the main site that is trying to be reached) and then preventing the rewrite rule from taking action...

But if you add:

RewriteCond %{HTTP_HOST} ^www.mydomain.com$ [OR]
RewriteCond %{HTTP_HOST} ^mydomain.com$

Somewhere above the rewriterule (but also after a previous rewriterule if there were one) and below the rewriteengine on statement then, if demo.mydomain.com is accessed, the uri will not be rewritten from the root domain when trying to access the sub-domain...

[buildingblocks]

sounds like what I've encountered a number of times when installing a test cart to a sub-domain or sub-folder when the top domain cart is using ceon uri installed. Adding

RewriteEngine Off

to the .htaccess file of the cart in the sub folder or sub-domain stopped the problem