Ceon URI Mapping V5.0

[mc12345678]

v1.5.5f PHP7.1 CEON uri mapping - IH - and others (previously reported in this thread July 26 with no responses https://www.zen-cart.com/showthread....16#post1360016)

When adding new products in configuration/catalogue/products/new_product I am getting the following problem.

Problem. 404 error: When I add a new product then go to the site the product is there in category/listing but when clicking on it to go to product/info page I get a 404 error 'this resource is not available on this server' i.e. a blank page, not the default ZC 404 page.

the box at the bottom of the create product page is ticked by default for auto generation of url - if I add a product and untick the CEON automatic uri generation box the product loads and works as it should on the site (it then has a generic ZC url).

I have checked and re-checked the CEON installation and configuration using the inbuilt checking and all is OK - I even added the "/" in front of index as suggested - "Try adding a slash to the front of index.php, this may resolve the problem: RewriteRule .* /index.php [QSA,L]" but that made no difference.

notes:
1. another site (former site) is wildcard redirected to this new site
2. this new site is an exact clone of the former site, i.e. all folders are exactly the same and so is the data base (renamed)
3. site works seamlessly except for adding new products
4. .htaccess which I thought may be an issue is an exact copy from another site that also is a clone site that is also widcard redirected - so same same - and that site does not have the new product creation issue
5. I have in fact rolled back the site to a saved copy pre redirection above

I do not want to reinstall CEON because I will lose all existing mapped urls

So looking for some ideas here please.

cheers,
Mike

.htaccess file

RewriteCond %{REQUEST_URI} !^/[0-9]+\..+\.cpaneldcv$
RewriteCond %{REQUEST_URI} !^/[A-F0-9]{32}\.txt(?:\ Comodo\ DCV)?$
RewriteRule ^index\.php$ - [L]

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

###############################################################################
# Add any other directives relating to the handling of physical files
###############################################################################
# Notes:
#
# If processing makes it this far, the request was for a real file or folder.
# Example: Adding further processing related to browser caching or security.
###############################################################################
<IfModule mod_security.c>
    SecFilterScanPOST Off
</IfModule>

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

## BEGIN CEON URI MAPPING REWRITE RULE

RewriteEngine On

# Don't rewrite any URIs ending with a file extension (ending with .[xxxxx])
# Don't rewrite any URIs for some, popular specific file format extensions,
#   which are not covered by main file extension condition above
# 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
# Don't rewrite editors directory
# Don't rewrite bmz_cache directory
# Don't rewrite .well-known directory
# Don't rewrite teststore directory
# Don't rewrite cgi-bin directory
# Don't rewrite zc_install_done directory
# Don't rewrite blog directory
# Don't rewrite logs directory
# Don't rewrite sitemap directory
# Don't rewrite temp directory
# Handle all other URIs using Zen Cart (its index.php)
RewriteCond %{REQUEST_URI} !\.[a-zA-Z]{2,5}$ [OR]
RewriteCond %{REQUEST_URI} \.(html)$ [NC]
RewriteCond %{REQUEST_URI} !\.(mp3|mp4|h264)$ [NC]
RewriteCond %{REQUEST_URI} !^/dazzlers [NC]
RewriteCond %{REQUEST_URI} !^/editors/ [NC]
RewriteCond %{REQUEST_URI} !^/bmz_cache/ [NC]
RewriteCond %{REQUEST_URI} !^/\.well\-known/ [NC]
RewriteCond %{REQUEST_URI} !^/teststore/ [NC]
RewriteCond %{REQUEST_URI} !^/cgi\-bin/ [NC]
RewriteCond %{REQUEST_URI} !^/zc_install_done/ [NC]
RewriteCond %{REQUEST_URI} !^/blog/ [NC]
RewriteCond %{REQUEST_URI} !^/logs/ [NC]
RewriteCond %{REQUEST_URI} !^/sitemap/ [NC]
RewriteCond %{REQUEST_URI} !^/temp/ [NC]
RewriteRule .* /index.php [QSA,L]

## END CEON URI MAPPING REWRITE RULE

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

## Optional caching improvements
## Requires mod_header and mod_deflate to be enabled within Apache
##################

##################
## Optional caching improvements
## Requires mod_header and mod_deflate to be enabled within Apache
##################
<filesMatch ".(ico|pdf|flv|jpg|jpeg|png|gif|webp|js|css|swf)$">
Header set Cache-Control "max-age=2592000, public"
</filesMatch>
<IfModule mod_deflate.c>
  <FilesMatch "(?i)\.(js|css)$">
    SetOutputFilter DEFLATE
  </FilesMatch>
</IfModule>

##################
## Optional improvements
## Requires mod_expires to be enabled within Apache
##################
## EXPIRES HEADER CACHING ##
 <IfModule mod_expires.c>
 ExpiresActive On
 ExpiresByType image/jpg "access 1 year"
 ExpiresByType image/jpeg "access 1 year"
 ExpiresByType image/gif "access 1 year"
 ExpiresByType image/png "access 1 year"
 ExpiresByType text/css "access 1 month"
 ExpiresByType application/pdf "access 1 month"
 ExpiresByType application/javascript "access 1 month"
 ExpiresByType application/x-javascript "access 1 month"
 ExpiresByType application/x-shockwave-flash "access 1 month"
 ExpiresByType image/x-icon "access 1 year"
 ExpiresDefault "access 7 days"
 </IfModule>
 ## EXPIRES HEADER CACHING

# php -- BEGIN cPanel-generated handler, do not edit
# Set the “ea-php70” package as the default “PHP” programming language.
<IfModule mime_module>
  AddHandler application/x-httpd-ea-php70 .php .php7 .phtml
</IfModule>
# php -- END cPanel-generated handler, do not edit

In review of other .htaccess rules I have seen and had to implement, a possible alternative RewriteRule line could be:

RewriteRule ^(.*)$ /index.php [QSA,L]

or

RewriteRule ^(.*)$ index.php [QSA,L]

The problem described certainly appears to be related to the .htaccess file where the installation check seems to just offer a recommended .htacess file based on a few minor factors, not necessarily guaranteed to work on the specific server.

As an aside, it appears that the admin directory has been published for all to see. Would recommend that the admin directory be renamed both on the server and in the .htaccess file.

Now there are also a number of other questions that have gone unanswered: what version of Ceon URI Mapping is being used, is the site in a sub-directory as seen in a web-browser? Why are some of the other RewriteCond statements in the installation check not included?

[shags38]

In review of other .htaccess rules I have seen and had to implement, a possible alternative RewriteRule line could be:

RewriteRule ^(.*)$ /index.php [QSA,L]

or

RewriteRule ^(.*)$ index.php [QSA,L]

The problem described certainly appears to be related to the .htaccess file where the installation check seems to just offer a recommended .htacess file based on a few minor factors, not necessarily guaranteed to work on the specific server.

As an aside, it appears that the admin directory has been published for all to see. Would recommend that the admin directory be renamed both on the server and in the .htaccess file.

Now there are also a number of other questions that have gone unanswered: what version of Ceon URI Mapping is being used, is the site in a sub-directory as seen in a web-browser? Why are some of the other RewriteCond statements in the installation check not included?

Many thanks for your response mc ....

I changed that rule but to no effect. The version installed is 4.5.5. Not sure what you mean about this 'As an aside, it appears that the admin directory has been published for all to see' ? ... my admin name doesn't appear in the .htaccess - the site is in the root, it is not a sub-domain. All the RewriteCond statements in the installation check are in fact included.

This comment is interesting to me 'not necessarily guaranteed to work on the specific server' - the very same .htaccess file works on at least 3 other sites that are all on the same server, different nodes. Given you didn't see anything glaringly faulty is it possible that it could be a server 'permissions' issue. The problem has occurred subsequent to the wildcard redirect from the former site but that redirect is functioning fine and I am at a loss to fathom how that could have an effect on CEON ... other than ... is the installation of CEON 'domain specific'? - i.e. this site is a clone of the former site, would that have any effect? (clutching at straws now methinks).

Is v4.5.5 upgrade-able to v5.0.0 without losing existing mapped urls? - I have v5.0.0 downloaded as I used it in the ZC v1.5.6b version of this site which is not live because of template issues. I note in v5.0.0 it shows modified files specifically for zc v1.5.5f ... one of which is this admin/includes/modules/update_product.php

Again probably clutching at straws given that v4.5.5 was working ok in zc v1.5.5f before the change of site/wildcard redirect - just a rambling thought.

So can you think of any other areas I should be looking at?

cheers,
Mike

[shags38]

@mc .... I've had my host look at possible causes and they came up with zip (see below).

So it appears something likely within the CEON code is not submitting the uri mapping correctly to the server (if at all) such that the server can recognize it, (guessing here - possibly in a corrupted format?) - regardless something is stopping the uri mapping from uploading when update is clicked in product_update HOWEVER only for new products since the new site was built (copied over) - possibly a bad ftp transfer of a crucial file in CEON? (grabbing at straws again). I can go into existing products and alter the existing uri mapping and the product still resolves - so it tends away from simply the update_product button.

I need to add some new products so may end up doing so by un-ticking the auto generate button in product creation and when the problem has been found I can go back and tick it and update - I hate doing this sort of thing as it screws things up with Google Search.

Hopefully you will come up with a fix soonish - I will keep trying different things my end.

Importantly ... can I re-install CEON without losing existing mapping data? .... if so then that may be a good step - if it does lose the existing data then not so good.

cheers,
Mike

from my host:

I have contacted a Senior Technician to overlook your query and we both can confirm that your rewrite conditions will not have an effect to your 404 issue.
I would also like to mention that this cPanel service is also on the same server as the domain dazzlersharmonynecklace.com.

Both of these domains are being resolved from the following shared IP address:

------------------- A/AAAA record(s) -------------
103.27.34.7 >> r131.syd3.hostingplatform.net.au.

While your error logs have also not provided any issued related to the permissions of this website specifically, I suggest running our Permissions fixer tool which will default your files permissions to 755 and 644 respectively; this will also eliminate the concern of the incorrect permissions within this specific cPanel account.
This can be done via the following:

Log into VIPControl >> Web Hosting >> Manage >> List Accounts >> Manage >> Permission Fixer

[mc12345678]

To address the first of things, this forum thread is about version 5 of the module. If wanting to address things about version 4 they should be discussed in the appropriate forum thread. That said, version 5 can be installed it seems by following the install and/or upgrade instructions.

As far as I know and understand the module, because it's power is in database use, as long as you maintain the database entries associated with any existing "use" then you can install and/or upgrade without specific issue. Now that said, reuploading the files that are in the files section is not exactly like reinstalling and it seems that the software is written to handle the situation of an attempt to reinstall. Even in my experience I've "removed" the plugin following the directions and loaded it again without loss. As always backup the database...

The fact that existing uris can be modified and work, but new uris are causing a problem seems to indicate that there may be a problem with the database. Understanding that this database was in some way carried over from another system calls to question the success in that move and/or the verification that all of the files made it fully intact and as suggested by the host with the appropriate permissions and ownership.

From what is described, existing rewritten uris continue to function, but those generated for new product are not reachable. That would seem to indicate that when storing the new uri(s) there is some information associated with the Zen Cart portion of the designation that is not correct. Therefore when the rewritten uri is provided to the system, the retrieved Zen Cart portions do not resolve to a known page.

As far as I recall seeing in the 4.5.5 version, I'm not so sure that the installation check had been updated to reflect the expected condition of the software. I can say that I'm glad Ceon was able to finally distribute an updated version and it seems that version 5 includes the files necessary to operate on Zen Cart 1.5.5 (as well as other versions).

[shags38]

As far as I know and understand the module, because it's power is in database use, as long as you maintain the database entries associated with any existing "use" then you can install and/or upgrade without specific issue. Now that said, reuploading the files that are in the files section is not exactly like reinstalling and it seems that the software is written to handle the situation of an attempt to reinstall. Even in my experience I've "removed" the plugin following the directions and loaded it again without loss. As always backup the database...

The fact that existing uris can be modified and work, but new uris are causing a problem seems to indicate that there may be a problem with the database. Understanding that this database was in some way carried over from another system calls to question the success in that move and/or the verification that all of the files made it fully intact and as suggested by the host with the appropriate permissions and ownership.

Thanks mc ... I appreciate your detailed response and the explanation of the database emphasis and the potential of a corrupt carry over makes sense. I will endeavor to upgrade to v5.0.0 and hopefully that will resolve the issue.

Again many thanks,
Mike

[mc12345678]

Thanks mc ... I appreciate your detailed response and the explanation of the database emphasis and the potential of a corrupt carry over makes sense. I will endeavor to upgrade to v5.0.0 and hopefully that will resolve the issue.

Again many thanks,
Mike

One thing though, while the newer version may integrate better, if there is a problem with the installation of Zen Cart (as it was likely an upgrade) or the database, even using the newer version of this module may not resolve the problem with adding new product. There may still be an issue with either the database or fileset that causes this problem. Just offering my own input on the matter. Your feedback on the result will be an indicator.

[shags38]

One thing though, while the newer version may integrate better, if there is a problem with the installation of Zen Cart (as it was likely an upgrade) or the database, even using the newer version of this module may not resolve the problem with adding new product. There may still be an issue with either the database or fileset that causes this problem. Just offering my own input on the matter. Your feedback on the result will be an indicator.

Hi MC .... UPDATE ... I found the problem but am not sure of the solution per se.

I changed the main products 'category' name after I did this site duplication (cloned site to new domain) - so 'all clip on earrings' (old) became 'dazzlers clip on earrings full range' (new) ..... whilst experimenting I changed the category name back to what it was (old) and all is good.

So that solved the 404 issue but I have no idea why CEON would not redirect the new category name - it rewrote the url according to the new category name but that resulted in a 404 - the mapping uri in the category remained as [all-clip-on-earrings-c1] but CEON used the category name and not the designated uri name saved in category configuration?? I can understand the DB entries uri's carried over from the former site being the 'old' original category name, that is why they still functioned correctly, just not understanding why CEON didn't adapt?

So if I changed the uri mapping name to the new category name then I get 404's for all the products in the database at time of cloning - so I guess once you have category names then you have to stick to them, right?

Thanks for all your help.

cheers,
Mike

[mc12345678]

Hi MC .... UPDATE ... I found the problem but am not sure of the solution per se.

I changed the main products 'category' name after I did this site duplication (cloned site to new domain) - so 'all clip on earrings' (old) became 'dazzlers clip on earrings full range' (new) ..... whilst experimenting I changed the category name back to what it was (old) and all is good.

So that solved the 404 issue but I have no idea why CEON would not redirect the new category name - it rewrote the url according to the new category name but that resulted in a 404 - the mapping uri in the category remained as [all-clip-on-earrings-c1] but CEON used the category name and not the designated uri name saved in category configuration?? I can understand the DB entries uri's carried over from the former site being the 'old' original category name, that is why they still functioned correctly, just not understanding why CEON didn't adapt?

So if I changed the uri mapping name to the new category name then I get 404's for all the products in the database at time of cloning - so I guess once you have category names then you have to stick to them, right?

Thanks for all your help.

cheers,
Mike

On the surface, this makes no sense and does not really answer/address the issue. The original report was that new product did not get a functional rewrite. Now the discussion is that the rewrite works, but only if the category designation remains the same as it originally was. This doesn't make sense either, because the rewrite generation for a product is independent of the rewritten category.

By that I mean (and I just tested this so am comfortable saying it) if a category exists that has a name of say 'test1' and assuming it is found at the root of the store, the initial uri would be /test1. If one goes in and edits that empty category to change the rewrite to /newtest1, then specifically the category is reachable by /test1 and /newtest1. The browser though when using either of those will show /newtest1 as that is the single active uri for that category.

If now a product is added to the category, the initial rewritten uri will be based off of the category's name, not its rewritten uri. So if the product were called prod1, then the auto-generated rewritten uri would be /test1/prod1, even though the category in whole would be reached by /newtest1. If a second product were added (to account for potential settings regarding going directly to a product if there is only 1 product in a category) that is named prod2, then it's autogenerated uri would be /test1/prod2.

Navigation now to /test1 would show in the browser as /newtest1, and the links to the products would show as /test1/prod1 and /test1/prod2 respectfully for product 1 and product 2.

Attempting to go to /newtest1/prod1 will result in a product not found, because the product doesn't have that rewritten uri associated with it (whether as an original uri or as a new/revised uri).

To change the uri for each of the product to have /newtest1 in the path, both product would need to be edited to have that as part of their rewritten uri and stored.

Sum and total, every rewritten uri is maintained independent of any higher up rewrite where a new rewrite for an item is built directly off of the name of whatever is above it. In the above situation of adding product after revising the category rewrite, the category's name would need to be changed to "match" the rewritten uri before attempting to add product to the category using the auto-generation feature. Of course, the product could be edited after that rename, the checkbox ticked to auto-generate, and the new uri will then be generated where the previous is still accessible along with the new uri.

None of this though really explains why you received a 404, but also, there is no explanation about exactly how the issue was discovered as in from where the link was attempted that was generated for said new product.

To then also try to answer the questions firectly about changing a category, you can modify the category uri all you want, it will not change the link(s) to the product in the category. If you change the category name, but do not check the auto-generate box when doing so, then the category rewrite will remain the same and new product will follow the rewrite rule to auto-generate the uri with the new category name. This would result in old product still having the old category name and new product having the new category name. I believe though that the commercial version makes this "easier" to handle/address as it is designed to make changes en mass rather than one product/category/ez-page/manufacturer at a time.

[DannyVarley]

Hi Guys, I am having an issue with updating the category fields. I belive it has something to do with where it is placing the fields on the page

DISCLAIMER, I mostly do not know what I am on about so please excuse anything that is wrong or otherwise just stupid im just guessing at most stuff here after testing

On the category pages I believe that it places the URI mapping fields just before the last form, as you can see on my screenshot the row highlighted in blue is the mapping fields and this is in the main for so works fine.


However if you restrict the category to only certain product types then it places the URI mapping fields inside the wrong form as the last form on the page is the currently restricted product types, So when the category is restricted to product types it does not let the URI mapping work


I hope this makes sense and you can help me figure out a way to solve! Basically when the category is restricted to certain product types the URI mapping will not update as it is not in the main form.

[mc12345678]

Hi Guys, I am having an issue with updating the category fields. I belive it has something to do with where it is placing the fields on the page

DISCLAIMER, I mostly do not know what I am on about so please excuse anything that is wrong or otherwise just stupid im just guessing at most stuff here after testing

On the category pages I believe that it places the URI mapping fields just before the last form, as you can see on my screenshot the row highlighted in blue is the mapping fields and this is in the main for so works fine.


However if you restrict the category to only certain product types then it places the URI mapping fields inside the wrong form as the last form on the page is the currently restricted product types, So when the category is restricted to product types it does not let the URI mapping work


I hope this makes sense and you can help me figure out a way to solve! Basically when the category is restricted to certain product types the URI mapping will not update as it is not in the main form.

Looks like somewhere around line 369 of admin/includes/ceon_uri_mapping_javascript.php change:

var place = classList[classList.length - 1];

To:

var place = classList[0];