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.

lat9:

That "did the trick"! Sitemap ran this morning ... and no PHP notices; thanks again.
Somewhat more importantly, the rewrites in sitemap worked properly?

mc12345678:

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?

lat9:

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.

mc12345678:

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.

lat9:

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.

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.

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.
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.

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&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.

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.

diamond1:

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

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.
So, you mean that when looking at category 12, the browser path has the rewritten uri, but the page source shows that the canonical path is unmodified from the Zen Cart version?

The final file to output the canonical information is: includes/templates/YOUR_TEMPLATE/common/html_header.php and may require modification depending on the template being used (template used is not described in the above posting). Otherwise it appears that there are three files potentially involved with generating the canonical link though the file from the installation check message may also play a part.  Two of the files are provided by this plugin, the third is a core file that is used by the plugin and those two files.

The two files that should be present to support the canonical link generation are:
includes/classes/observers/class.ceon_canonical.php
which is called by:
includes/auto_loaders/config.ceon_canonical.php

That uses a notifier from the core file:
includes/init_includes/init_canonical.php

The first two files need to be verified to be present (most likely the config.ceon_canonical.php file is missing or not named to support loading) and/or there is either an override in includes/init_includes/overrides that prevents using the associated/necessary notifier or the file is possibly not up-to-date to the Zen Cart 1.5.5 version or better (based on notes in the observers file).***
***

The first two files need to be verified to be present (most likely the config.ceon_canonical.php file is missing or not named to support loading) and/or there is either an override in includes/init_includes/overrides that prevents using the associated/necessary notifier or the file is possibly not up-to-date to the Zen Cart 1.5.5 version or better (based on notes in the observers file).[/FONT]
[/FONT][/QUOTE]

Happy New Year and best wishes for 2020, MC, health you and the other guru of the forem I do not know how we would do, that to tell you that you are very strong. You put me in the right track I had a residue in init_includes / overreides / init_canonical.php which probably came from USU which was installed before Ceon Uri Mapping I just had to delete this file and Ceon Uri is set to work as it should.
Thank you so much.

The template is ########## from themeforest, I have had a lot of problems with it since the first day, but now with the update the problems have started again, I hope to solve them with all of you.

Mappings Manager

Continuing a conversation from the old 4x thread that should go here.

The (free) Uri Mapping plugin 5 is a pile of files updated to work with php 7+ and make use of new notifiers in ZC156+.
The plugin fileset also has legacy files for older ZC that don't have the notifiers.

The Mappings Manager (not free) is some extra files and replacement files for the URI Mapping plugin, that offers an Admin user interface to customise the structure of the mappings (per product, category etc.) and generate/update/edit the mappings on demand.

So does it work with older Zen Carts...yes, as long as attention is paid to use the correct files that don't expect notifiers to be in place.

I purchased it recently (I still feel in debt to Conor), and can testify that the support from CEON is fine (it was required for my multi-language store).

Hi,

I have a freshly installed 5.0.1 UMM Edition. I just noticed that the categories are not being captured in my product URI's.

For instance I sell Furry Kittens. The category chain is Pets > Cats. I want my URI to look like this:
MyStore.com/Pets/Cats/Furry_Kittens

But I'm getting:
MyStore.com/Furry_Kittens

I am attaching a screenshot of my settings, which I think I have set up correctly. Do I need to change something?

Another possibility is that maybe there is a character limit? If I have too many categories and/or if my category names are too long, does it circumvent and just do prod name?

Thanks!

^^The above has been sorted, thanks!

As it turns out, the commercial mod (Mapping Manager) has it's own settings page as well. On that page, I was able to add category-path to my product URI and then everything worked out.

:)

this is my Website configuration file

/public_html/includes/configure.php

define('HTTP_SERVER', 'https://'.$_SERVER['SERVER_NAME']);
define('HTTPS_SERVER', 'https://'.$_SERVER['SERVER_NAME']);

/public_html/admin/includes/configure.php

define('HTTP_SERVER', 'https://'.$_SERVER['SERVER_NAME']);
define('HTTPS_SERVER', 'https://'.$_SERVER['SERVER_NAME']);
define('HTTP_CATALOG_SERVER', 'https://'.$_SERVER['SERVER_NAME']);
define('HTTPS_CATALOG_SERVER', 'https://'.$_SERVER['SERVER_NAME']);

I modified the corresponding file according to the suggested error and changed it back to the default value, it still does not work

ikirin:

this is my Website configuration file

/public_html/includes/configure.php

define('HTTP_SERVER', 'https://'.$_SERVER['SERVER_NAME']);
define('HTTPS_SERVER', 'https://'.$_SERVER['SERVER_NAME']);

> 
> 
> /public_html/admin/includes/configure.php
> ```php
define('HTTP_SERVER', 'https://'.$_SERVER['SERVER_NAME']);
define('HTTPS_SERVER', 'https://'.$_SERVER['SERVER_NAME']);
define('HTTP_CATALOG_SERVER', 'https://'.$_SERVER['SERVER_NAME']);
define('HTTPS_CATALOG_SERVER', 'https://'.$_SERVER['SERVER_NAME']);

I modified the corresponding file according to the suggested error and changed it back to the default value, it still does not work
Not sure what "still does not work", but looking at the installation check code for the review of the catalog side configure.php file (first set of errors reported), it will not be able to "fill in" the value of $_SERVER['SERVER_NAME'] which for one is a completely atypical Zen Cart representation of the server name and is prone to its own issues including potential security issues if the value is edited without the store owners knowledge (which would not be detectable in the fileset). The installation check is seeking the complete text as a unit on the right side of the define, so even if it were 'https://' . 'mysite' then the same response would be provided as compared to 'https://mysite' which would then not provide the "value ends with a slash" issue.

As for the other perhaps more important issues (considering the site itself supposedly operates as is without this plugin) that when the plugin was "added" there appears to be three files that are supposed to have changes made to them that weren't or in one case the change may be commented out, but it is not clear. In one case (the last message) a change has been made that is no longer needed, though it probably doesn't really affect operation.

Now, fortunately the screen shot contains information that was not provided in the above post, though every post seeking a solution should contain. It appears that this is/was installed to a Zen Cart 1.5.5f version and it also looks like there really shouldn't be any changes made to the html_output.php files for Zen Cart 1.5.5x, so looks like Ceon's installation check could be updated a little more to exclude those two files from a Zen Cart 1.5.5x install.

But, there still is the question of what doesn't work?

mc12345678:

Not sure what "still does not work", but looking at the installation check code for the review of the catalog side configure.php file (first set of errors reported), it will not be able to "fill in" the value of $_SERVER['SERVER_NAME'] which for one is a completely atypical Zen Cart representation of the server name and is prone to its own issues including potential security issues if the value is edited without the store owners knowledge (which would not be detectable in the fileset). The installation check is seeking the complete text as a unit on the right side of the define, so even if it were 'https://' . 'mysite' then the same response would be provided as compared to 'https://mysite' which would then not provide the "value ends with a slash" issue.

As for the other perhaps more important issues (considering the site itself supposedly operates as is without this plugin) that when the plugin was "added" there appears to be three files that are supposed to have changes made to them that weren't or in one case the change may be commented out, but it is not clear. In one case (the last message) a change has been made that is no longer needed, though it probably doesn't really affect operation.

Now, fortunately the screen shot contains information that was not provided in the above post, though every post seeking a solution should contain. It appears that this is/was installed to a Zen Cart 1.5.5f version and it also looks like there really shouldn't be any changes made to the html_output.php files for Zen Cart 1.5.5x, so looks like Ceon's installation check could be updated a little more to exclude those two files from a Zen Cart 1.5.5x install.

But, there still is the question of what doesn't work?

zen cart version 1.55f

Thank you very much for your reply. I replaced the entire configure.php file and it is now ready to use.
However, the inspection still indicated an error. I checked the core file of the plugin. There are no modified_core_files\1.5.5\admin\includes\functions\html_output.php and modified_core_files\1.5.5\admin\includes\functions\html_output.php files. I checked the plug-in's documentation and suggested that this file is not needed for 1.55.
I tried to modify the two html_output.php files according to the Ceon URI mapping (SEO) version: 4.5.6, the error disappeared, but there are still two files reporting errors,
A file requires a modification to be made for it but the modification has not yet been made. The file does however have 2 comment marker(s) in it.
/home/petstoys/public_html/dLt4_hxsP/includes/modules/move_product_confirm.php
A file has had a modification made to it, for an older version of Ceon URI Mapping, but this modification is no longer needed.
/home/petstoys/public_html/includes/extra_datafiles/ceon_uri_mapping_sessions_define.php

In addition, I tried to install the Ceon URI mapping (SEO) version: 4.5.6, and it works perfectly.

ikirin:

zen cart version 1.55f

Thank you very much for your reply. I replaced the entire configure.php file and it is now ready to use.
However, the inspection still indicated an error. I checked the core file of the plugin. There are no modified_core_files\1.5.5\admin\includes\functions\html_output.php and modified_core_files\1.5.5\admin\includes\functions\html_output.php files. I checked the plug-in's documentation and suggested that this file is not needed for 1.55.
I tried to modify the two html_output.php files according to the Ceon URI mapping (SEO) version: 4.5.6, the error disappeared, but there are still two files reporting errors,
A file requires a modification to be made for it but the modification has not yet been made. The file does however have 2 comment marker(s) in it.
/home/petstoys/public_html/dLt4_hxsP/includes/modules/move_product_confirm.php
A file has had a modification made to it, for an older version of Ceon URI Mapping, but this modification is no longer needed.
/home/petstoys/public_html/includes/extra_datafiles/ceon_uri_mapping_sessions_define.php

In addition, I tried to install the Ceon URI mapping (SEO) version: 4.5.6, and it works perfectly.
So are you saying that "it doesn't work" because the installation check is reporting that 1. Two files that don't actually need modification are reported as needing a change and 2) there have been changes made that possibly in the instructions are either no longer needed or are not fully and correctly made? Or is there something else that actually isn't working? The installation check doesn't actually drive operation. There are multiple ways to make code do something. The check does a review based off of what may be expected. It's not like it is intelligent and able to identify that say i++ is the same as i=i+1...

Basically there still has been no identification of what "isn't working"... the messages are displayed to tell you to do something. As I said earlier, it looks like Ceon will probably have to fix the installer to ignore reporting on the html_output files... the others, well, in one case it found a file on your server that is modified and shouldn't be, in another there is a modification that may or may not be correct... those two files have been edited by someone accessing the server, not the code.

Please help me understand.

mc12345678:

So are you saying that "it doesn't work" because the installation check is reporting that 1. Two files that don't actually need modification are reported as needing a change and 2) there have been changes made that possibly in the instructions are either no longer needed or are not fully and correctly made? Or is there something else that actually isn't working? The installation check doesn't actually drive operation. There are multiple ways to make code do something. The check does a review based off of what may be expected. It's not like it is intelligent and able to identify that say i++ is the same as i=i+1...

Basically there still has been no identification of what "isn't working"... the messages are displayed to tell you to do something. As I said earlier, it looks like Ceon will probably have to fix the installer to ignore reporting on the html_output files... the others, well, in one case it found a file on your server that is modified and shouldn't be, in another there is a modification that may or may not be correct... those two files have been edited by someone accessing the server, not the code.

Please help me understand.

Sorry, my English is not good.
I restored two "configure.php" files, and Ceon URI Mapping V5.0 now works properly on my website.

The error prompt is the prompt for installation check, please see this screenshot
https://send.firefox.com/download/56d988c7a7ff39fa/#0AkKoWzn8_eD3ghLS3476g