Hi all, maybe somebody has a solution to this ? Currently running Ecommerce Plus PHP v7.2.3.003

For all websites, in the .htaccess file at the very end, I have always defined a full set of Custom HTML Error Pages like so:

# =========================
# Custom HTML Error Pages
# =========================
ErrorDocument 400 /400.php
ErrorDocument 401 /401.php
ErrorDocument 403 /403.php
ErrorDocument 404 /404.php
ErrorDocument 405 /405.php
ErrorDocument 406 /406.php
ErrorDocument 407 /407.php
ErrorDocument 408 /408.php
ErrorDocument 409 /409.php
ErrorDocument 410 /410.php
ErrorDocument 500 /500.php
ErrorDocument 501 /501.php
ErrorDocument 502 /502.php
# =========================

They are all static pages with the key ErrorDocument there being the 404 Not Found: https://itzap.com.au/404.php

To test, you simply enter any non-existent address in the browser like xxx.php. When using the vanilla Ecommerce Templates page URL's, that all works just fine and dandy.

But when you activate the Search Engine Friendly URL's (which I really do like):
> You are not directed to the 404.php page, but instead ...
> You get the message "Sorry, this product is not currently available.", which is $GLOBALS['xxSryNA'] from the languagefile_en.php file.

So is that working as intended, or is there some way to have "ErrorDocument 404 /404.php" take precedence ?

Regards, Gary

Hi Gary
I changed the recommended rules for SE URL's a while back as here...
https://www.ecommercetemplates.com/seo/search-engine-friendly-urls-php.asp
...to this for the product detail SEO URL's...

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule (.*) proddetail.php?prod=$1 [QSA,nc,L,B]

This means that only URL's that do not resolve to a file or directory name would be passed to the product detail page and I think that may help in your case.

Vince

Click Here for Shopping Cart Software
Click Here to sign up for our newsletter
Click Here for the latest updater

Trouble there is, that file/directory exists check is really inefficient. To evaluate that rule, Apache has to drill down into every single directory in the site and look at every single file to see if it's true. It's similar to WordPress do, and while that might be OK on a blog with a few hundred images, it's really slow on an e-commerce site which might easily have tens of thousands of product images and what have you to wade through. At the very least you could exclude irrelevant file types to avoid the worst of that, maybe something like:

Peter


Professional ecommerce web hosting services
Shared hosting Windows & Linux | Dedicated servers | Domains | SSL
Ecommerce Templates specialists since 2003
https://servelink.com

Thank you very much for those replies Vince and Peter. You helped me find this solution, which I think works a bit better:

(1) In .htaccess # comment out 3 lines and use a different proddetail.php RewriteRule

# RewriteCond %{REQUEST_FILENAME} !-f
# RewriteCond %{REQUEST_FILENAME} !-d
# RewriteRule (.*) proddetail.php?prod=$1 [QSA,nc,L,B]
RewriteRule ^([^/.]+)$ proddetail.php?prod=$1 [QSA,nc,L,B]

(2) In includes.php spark up the message displayed when an extensionless SEO friendly style URL is not found, like: xxx

// Extensionless SEO friendly style page URL not found message
$GLOBALS['xxSryNA']='<span style="font-size: 150%; font-weight: bold;">Sorry, that page has now been removed.</span><br><br>You can <a href="search.php" title="Go to the Search page"><strong>search</strong></a> for something similar.';
$GLOBALS['xxSimPro']='Click here to view other pages in the same category';

And when an extensioned URL is not found, like xxx.php, the static Custom HTML Error Page 404.php is displayed. That explains likely reasons why that particular page or file was not found, and includes the "Search Website" option.

Also, while looking through includes.php parameter entries, I was using the "Product detail static page" parameter:

$urlfillerchar='-'; // For proddetail.php page, use-dashes-to-separate-words in Product Name

Correct me if I am wrong, but that $urlfillerchar entry becomes obsolete (and should be omitted) when using the SEO friendly URL's and $detlinkspacechar='-'; ... yes ?

Gary

quote:

---

Trouble there is, that file/directory exists check is really inefficient. To evaluate that rule, Apache has to drill down into every single directory in the site and look at every single file to see if it's true.

---

I'm not sure I necessarily agree with that. It may be that the flag is inefficient but it wouldn't be for the reasons given. It's nothing more than a "file exists" function. And it is used on millions of wordpress sites which may well not be the most efficient bit of code going, but I'm not sure this is it's weak point.

quote:

---

Correct me if I am wrong, but that $urlfillerchar entry becomes obsolete (and should be omitted) when using the SEO friendly URL's and $detlinkspacechar='-'; ... yes ?

---

Yes Gary, and thanks for pointing that out, The $urlfillerchar is basically redundant and the one place it is used (301 redirects for static pages) should be revised.

Vince

Click Here for Shopping Cart Software
Click Here to sign up for our newsletter
Click Here for the latest updater