Ceon URI Mapping V5.0

[lat9]

Thanks, @mc12345678, I'll give that a shot and report back tomorrow (the cron runs at 5am EDT).

That "did the trick"! Sitemap ran this morning ... and no PHP notices; thanks again.

[mc12345678]

That "did the trick"! Sitemap ran this morning ... and no PHP notices; thanks again.

Somewhat more importantly, the rewrites in sitemap worked properly?

[lat9]

Somewhat more importantly, the rewrites in sitemap worked properly?

No additional rewrites required, just that teeny code change.

[mc12345678]

Somewhat more importantly, the rewrites in sitemap worked properly?

No additional rewrites required, just that teeny code change.

I think the question was misunderstood. As a result of the tiny code change in the URI Mapping Software, the generation of mydebug files stopped for each cron execution of SitemapXML but the output of SitemapXML wasremained as expected. The expectation of the output being that those URIs that have been rewritten and those that have not both appear in the output file(s), respectively.

[lat9]

I think the question was misunderstood. As a result of the tiny code change in the URI Mapping Software, the generation of mydebug files stopped for each cron execution of SitemapXML but the output of SitemapXML wasremained as expected. The expectation of the output being that those URIs that have been rewritten and those that have not both appear in the output file(s), respectively.

I guess it was (and might still be). The code change resolved the generation of the PHP notice when the sitemapxml was cron'd and, if I'm getting the question correctly, I've verified that the links generated in the sitemap are 'proper' Ceon URI Mapping ones.

[mc12345678]

I guess it was (and might still be). The code change resolved the generation of the PHP notice when the sitemapxml was cron'd and, if I'm getting the question correctly, I've verified that the links generated in the sitemap are 'proper' Ceon URI Mapping ones.

No, I think by the response that the question is now properly understood. I recall seeing posts about issues with the two modules together. This result seems to imply that there was some other reason fo those issues and that normally the two operate together with expected results provided.

[lat9]

I'm seeing an occasional log similar to

[08-Nov-2019 18:08:03 America/Chicago] Request URI: /index.php?main_page=product_info&cPath=91&products_id=2178, IP address: redacted
#1  CeonURIMappingHandler->_handleZCDynamicURI() called at [/home/mystore/public_html/includes/classes/class.CeonURIMappingHandlerBase.php:473]
#2  CeonURIMappingHandlerBase->_handleURI() called at [/home/mystore/public_html/includes/classes/class.CeonURIMappingHandlerBase.php:149]
#3  CeonURIMappingHandlerBase->__construct() called at [/home/mystore/public_html/includes/classes/class.CeonURIMappingHandler.php:52]
#4  CeonURIMappingHandler->__construct() called at [/home/mystore/public_html/includes/autoload_func.php:79]
#5  require(/home/mystore/public_html/includes/autoload_func.php) called at [/home/mystore/public_html/includes/application_top.php:170]
#6  require(/home/mystore/public_html/includes/application_top.php) called at [/home/mystore/public_html/index.php:26]
--> PHP Notice: Undefined index: products_id in /home/mystore/public_html/includes/classes/class.CeonURIMappingHandler.php on line 443.

on a zc156c site recently updated with the Ceon URI Mappings 5.0.0. Not clear (I haven't viewed the site's access-logs) where the initial link is coming from, but the processing should, IMO, be able to deal with the & vs & characters in the URL.

[mc12345678]

I'm seeing an occasional log similar to

[08-Nov-2019 18:08:03 America/Chicago] Request URI: /index.php?main_page=product_info&cPath=91&products_id=2178, IP address: redacted
#1  CeonURIMappingHandler->_handleZCDynamicURI() called at [/home/mystore/public_html/includes/classes/class.CeonURIMappingHandlerBase.php:473]
#2  CeonURIMappingHandlerBase->_handleURI() called at [/home/mystore/public_html/includes/classes/class.CeonURIMappingHandlerBase.php:149]
#3  CeonURIMappingHandlerBase->__construct() called at [/home/mystore/public_html/includes/classes/class.CeonURIMappingHandler.php:52]
#4  CeonURIMappingHandler->__construct() called at [/home/mystore/public_html/includes/autoload_func.php:79]
#5  require(/home/mystore/public_html/includes/autoload_func.php) called at [/home/mystore/public_html/includes/application_top.php:170]
#6  require(/home/mystore/public_html/includes/application_top.php) called at [/home/mystore/public_html/index.php:26]
--> PHP Notice: Undefined index: products_id in /home/mystore/public_html/includes/classes/class.CeonURIMappingHandler.php on line 443.

on a zc156c site recently updated with the Ceon URI Mappings 5.0.0. Not clear (I haven't viewed the site's access-logs) where the initial link is coming from, but the processing should, IMO, be able to deal with the & vs & characters in the URL.

Without the module I'm getting product not found when I include the & in the last parameter of the URI. I've been seeing something similar in the admin in particular when the action parameter is last on the uri, then well it doesn't take the action at least on the categories screen...

There seems to have been something modified that prevents recognizing the parameter, "reparsing" the last parameter of the uri or for $_GET to be set for the parameter that uses &.

Basically saying that perhaps a message is generated with this plugin, but it seems that there is something before it in the ZC code that should have prevented that issue from occurring.

[diamond1]

Hi, I installed ceon 5.01 with zencart 1.5.6c everything works well except the canonical which remains so:

<link rel="canonical" href="https://mydomaine:8890/index.php?main_page=index&amp;cPath=12" /> 

I have also rewritten some urls in admin everything works the rewrite with is done, but the canonical always remains unwritten. I specify that I have no error files in the log folder.

I have this though when Ceon URI Mapping Installation Check

A file has had a modification made to it, for an older version of Ceon URI Mapping, but this modification is no longer needed.

The path to the file is /Applications/MAMP/htdocs/myadomain/includes/extra_datafiles/ceon_uri_mapping_sessions_define.php

    Although the file had to be modified for a previous version of the module, this version works differently and the file is not modified for this version.

    Remove the modification from the file by editing the file and removing the block beginning with // BEGIN CEON URI MAPPING 1 of 1 and ending with // END CEON URI MAPPING 1 of 1 - including those two “marker comments”.
    Alternatively, if the file was modified only for Ceon URI Mapping and not for any other module, back up the file (e.g. copy it to your local computer) and replace it with a “fresh” version of the file from a “fresh” set of Zen Cart files.

[diamond1]

I forgot to tell you that in the bar of the browers the rewriting is done and only when I go to rivere the source code that I realize that the canonical is not rewritten.