Ceon URI Mapping v4.x

[mc12345678]

mc12345678,

Is this version compatable with ZenCart 1.5.6?

Yes and no. Yes in that the Ceon related software will work, but no in that there are some (many?) differences in the "modified" ZC files. At the moment the suggestion would be to identify the changes made to common files for the specific code of this plugin and then make the same changes to the ZC 1.5.6 files. That said, in the move from ZC 1.5.5 to 1.5.6 some of the associated files were removed. So if you look at a 1.5.5 installation where the folder identifies 1.5.5 in the modified files section: that is the set of ZC files that were changed. If those files don't exist on the server, then there is something missing or changed from a default.

[shags38]

v1.55f php7.1

I have installed this plugin (most recent version), successfully according to the check installation and check configuration pages, however url's are still dynamic - the .htaccess file is attached and from what I have seen in other posts it 'seems' in order so I am a little stumped as to why the rewrite isn't working.

I have historically used USU but because of its issue with 155(f) (canonical not working in conjunction with SitemapXML) I decided to change to this one to test it out for myself.

cheers,
Mike

## 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-zA-Z]{2,5}$ [OR] 
RewriteCond %{REQUEST_URI} \.(html)$ [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} !^/dazzlers [NC]
# Don't rewrite editors directory
RewriteCond %{REQUEST_URI} !^/editors/ [NC]
# Don't rewrite bmz_cache directory
RewriteCond %{REQUEST_URI} !^/bmz_cache/ [NC]
# Don't rewrite readme directory
RewriteCond %{REQUEST_URI} !^/readme/ [NC]
# Don't rewrite teststore directory
RewriteCond %{REQUEST_URI} !^/teststore/ [NC]
# Don't rewrite cgi-bin directory
RewriteCond %{REQUEST_URI} !^/cgi\-bin/ [NC]
# Don't rewrite .htpasswds directory
RewriteCond %{REQUEST_URI} !^/\.htpasswds/ [NC]
# Don't rewrite logs directory
RewriteCond %{REQUEST_URI} !^/logs/ [NC]
# Don't rewrite DDG38 directory
RewriteCond %{REQUEST_URI} !^/DDG38/ [NC]
# Don't rewrite sitemap directory
RewriteCond %{REQUEST_URI} !^/sitemap/ [NC]
# Handle all other URIs using Zen Cart (its index.php)
RewriteRule .* index.php [QSA,L]

## END CEON URI MAPPING REWRITE RULE

###############################################################################
# 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.
###############################################################################
RewriteCond %{HTTP_HOST} ^sterlingsilverrings\.com\.au$ [OR]
RewriteCond %{HTTP_HOST} ^www\.sterlingsilverrings\.com\.au$
RewriteRule ^/?$ "https\:\/\/www\.sterlingsilverrings\.com\.au\/" [R=301,L]


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

[shags38]

please ignore the above post - I missed the most important content of all in the FAQ's (alas not in the plugin Overview) - 'This module DOES NOT automatically add mappings for EXISTING Categories/Products/Manufacturers/EZ-Pages!' ...... adding mapping per product for 5 websites (= 1000's of products) is too big a task me thinks .... my fault I suppose, an assumption that it would be like USU.

and I have no idea how this works ... 'Redirect the Store's Old/Current URIs - Prevent Broken Links. Stores that have URIs generated by other software, such as Ultimate SEO, Simple SEO, Magic SEO etc., can import these existing URIs as historical URI mappings. The old SEO module's URIs will redirect to the new Ceon URI Mapping URIs, reducing the possibility of broken links from search engines and other sites!


So I will have to wait patiently for someone to fix USU (and continue with suffering rankings)

cheers,
Mike

[mc12345678]

please ignore the above post - I missed the most important content of all in the FAQ's (alas not in the plugin Overview) - 'This module DOES NOT automatically add mappings for EXISTING Categories/Products/Manufacturers/EZ-Pages!' ...... adding mapping per product for 5 websites (= 1000's of products) is too big a task me thinks .... my fault I suppose, an assumption that it would be like USU.

and I have no idea how this works ... 'Redirect the Store's Old/Current URIs - Prevent Broken Links. Stores that have URIs generated by other software, such as Ultimate SEO, Simple SEO, Magic SEO etc., can import these existing URIs as historical URI mappings. The old SEO module's URIs will redirect to the new Ceon URI Mapping URIs, reducing the possibility of broken links from search engines and other sites!


So I will have to wait patiently for someone to fix USU (and continue with suffering rankings)

cheers,
Mike

In my opinion it is better than USU in the control it provides. There are a number of ways to further accomplish the task you describe but I suggest that you do some homework.

As to sustaining historical links/preventing breaking redirects, well that is one of the powerful things about this software. There is no need to build an htaccess file filled with redirects from this to that or whatever as the software tends to it by receiving the request to a uri and if it is the uri that is considered current for the item, then it shows it. If the URI is not the current URI for the item, then it identifies what the current URI should be and updates the browser/search engine with that new uri to indicate what the current designation for that object is. This is done through the database.

[shags38]

@ mc12345678

reply to thread not working for me ? so copied and pasted

In my opinion it is better than USU in the control it provides. There are a number of ways to further accomplish the task you describe but I suggest that you do some homework.

As to sustaining historical links/preventing breaking redirects, well that is one of the powerful things about this software. There is no need to build an htaccess file filled with redirects from this to that or whatever as the software tends to it by receiving the request to a uri and if it is the uri that is considered current for the item, then it shows it. If the URI is not the current URI for the item, then it identifies what the current URI should be and updates the browser/search engine with that new uri to indicate what the current designation for that object is. This is done through the database.

I did the homework, read every bit of the docs and comprehended what I could and then did the manual update thing - I can see why you like the software, it has solved the USU current issue in that it is submitting sitemaps in the rewritten url form as it should be and hopefully that will go some way to helping with the rankings ... however ... (there is always a however with me) I had / have a number of 404 broken links as a result, primarily from EZ pages and pages like what was /products_new.html now being /index.php?main_page=products_new. (featured, specials, products all, etc.)

My product pages have links to articles (EZ pages) - once I enabled uri mapping of course the links broke and deleting then copying and pasting the old original url resulted in a 404 .... so I have a number of redirects in my .htaccess - I can deal with a few instances like that and will likely exclude EZ pages from auto uri mapping on other sites.

However a major issue unfolded when checking Google WMT >> External Links I found a bunch of incoming links from other sites to pages that now result in 404. Some are to pages like new products referenced above whilst others are to categories, EZ pages and also to individual products - links are in USU form and none of them resolve, they all result in a 404. Needless to say this is very concerning.

example of a former USU url which is linked from an external site as https://www.harmonyballpendant.com/h...ll-p-1374.html .... is now https://www.harmonyballpendant.com/h...r-harmony-ball ... and returns a 404

I must admit I expected that this plug in should handle the redirection.

So I can only assume I have not done something correctly as "If the URI is not the current URI for the item, then it identifies what the current URI should be and updates the browser/search engine with that new uri to indicate what the current designation for that object is"


I added this code to .htaccess in the hope it would not redirect pages ending in .html however it is not working, well not working as I expected it might (not redirect existing urls ending in .html) - I added it after going through the process on the site but would expect that it should still work? .... and importantly I'm not sure if I should leave that code in my .htaccess
RewriteCond %{REQUEST_URI} !\.[a-zA-Z]{2,5}$ [OR]
RewriteCond %{REQUEST_URI} \.(html)$ [NC]

So understandably I need to establish whether I have done something incorrectly or that my expectations of the plugin are unrealistic before going ahead and doing my other sites.

cheers,
Mike

[shags38]

So I took the plunge and installed this plugin on another site and went through the process of 'updating' everything to CEON to create the new url's.
Result is in rebuilding sitemaps the url's are dynamic and not CEON.

During installation Check an error showed up as includes/init_includes/overrides/init_canonical.php was missing - I copied across an unmodified file from a downloaded copy of ZC 1.5.5f then I reinstalled the includes modified core files from the plugin and reran the Installation Check and all was good.

I mention this because the behaviour seems to be that which USU is doing, i.e. not activating canonical, hence sitemap files remain dynamic.

Something is not quite right - so how do I tackle this one? I do not want to lose all the 'updating' time if I can help it.

cheers,
Mike

[mc12345678]

(if reply with quote doesn't work, click it again... seriously. :) has happened to me, but the forum software has been setup/revised to go to a new screen instead of sliding out the entry box. Anyways...)

I believe each of the items asked about (for the like 98% of it) are fully covered in the instructions.

So, start on the first page of the documentation. There's a link about "mid-screen" where it says something like if you're having problems read these FAQs.

So, then the first issue about getting 404s. There are at least two topics with that in their title and the link for each goes to a slightly different discussion, but they are both of value. It appears that you've followed the rabbit trail at least to the discussion of the rewrite rule modification so that you can allow the plugin to manage an address ending with .html. So that is part of the aspect.

Pretty much the rest of the questions/issues are how to let the software know the destination of a provided url that has been used from outside of the software. This is something that is covered in the configuration section of the manual at or around section 10.

[mc12345678]

So I took the plunge and installed this plugin on another site and went through the process of 'updating' everything to CEON to create the new url's.
Result is in rebuilding sitemaps the url's are dynamic and not CEON.

During installation Check an error showed up as includes/init_includes/overrides/init_canonical.php was missing - I copied across an unmodified file from a downloaded copy of ZC 1.5.5f then I reinstalled the includes modified core files from the plugin and reran the Installation Check and all was good.

I mention this because the behaviour seems to be that which USU is doing, i.e. not activating canonical, hence sitemap files remain dynamic.

Something is not quite right - so how do I tackle this one? I do not want to lose all the 'updating' time if I can help it.

cheers,
Mike

Two things. Was Ceon URI Mappings turned on from within the configuration settings? (Default after install is for it to be off) and we're any uris set for rewrite before attempting to execute the sitemap update?

As far as homework,n there are places in this forum thread where it has been described a way to generate uris from existing product. One hint is to check the website in my signature.

[shags38]

(if reply with quote doesn't work, click it again... seriously. :) has happened to me, but the forum software has been setup/revised to go to a new screen instead of sliding out the entry box. Anyways...)

you may have a different entry to the forum? - this is what is happening to me, not sure if it is happening to others but would suspect so, 'reply with quote' simply 'circles' and goes nowhere - has been happening for a while now (days) - re-clicking doesn't help - what did help was after clicking that tab to then click the yellow reply to thread - server has been terribly slow for quite a while now ........ anyway, onwards and upwards.

I believe each of the items asked about (for the like 98% of it) are fully covered in the instructions.

So, start on the first page of the documentation. There's a link about "mid-screen" where it says something like if you're having problems read these FAQs.

So, then the first issue about getting 404s. There are at least two topics with that in their title and the link for each goes to a slightly different discussion, but they are both of value. It appears that you've followed the rabbit trail at least to the discussion of the rewrite rule modification so that you can allow the plugin to manage an address ending with .html. So that is part of the aspect.

Pretty much the rest of the questions/issues are how to let the software know the destination of a provided url that has been used from outside of the software. This is something that is covered in the configuration section of the manual at or around section 10.

Went back through the instructions as you suggested and found the fix to urls like new_products etc so will take care of that - FAQ's focus on the url's resolving as the program intended ..... and they are (with me having to make mods as per above) ..... they are simply not being reflected in the sitemap (see next post).

In respect to incoming links not resolving to new url but showing 404 ..... I guess I will have to do a bunch of redirects?

cheers,
Mike

[shags38]

@mc12345678

Two things. Was Ceon URI Mappings turned on from within the configuration settings? (Default after install is for it to be off) and we're any uris set for rewrite before attempting to execute the sitemap update?

As far as homework,n there are places in this forum thread where it has been described a way to generate uris from existing product. One hint is to check the website in my signature

CEON by default is set to on and no there were no other redirects in place except for http >> https://www which was the case with the first site I did which the sitemap produced rewritten urls.

As for the FAQ's - there is one on the subject of url's still resolving as dynamic, which is not the issue, (and it says 'If this does not fix things then there is simply something wrong with the server/site itself.') ... but there is nothing at all on the subject of url's working but not reflected in the sitemap, nothing at all about the relationship with Sitemap other than it is 'recommended to use sitemap as it enhances the plugin' and '[OPTIONAL but RECOMMENDED] Configure the Google Sitemap (XML) Module' ..... that is the core issue (as it was/is with USU) which tends towards a canonical issue .. yes/no?

This stands out as an anomaly - the original error discussed earlier of init_includes.php not being being found in init_includes/overrides (it was indeed missing - not sure how or why) but then uploaded and installation check then validating as OK ....

Question will re-installing the plugin affect the 'updating' already done ??? ...... if not then it might be worth a shot. That would be my last resort and if that doesn't work I will need to engage someone who can fix my issue - it is adversely affecting how and how often Google sees my site which in turn affects rankings ........... or a poor option is I wait until this plugin or USU are sorted for 1.5.6a and then upgrade and keep the fingers crossed :) ... upgrading from 1.5.1 to 1.5.5f caused the issue in the first place

cheers,
Mike