Ceon URI Mapping V5.0

https://github.com/zencart/zencart/issues/4939

I also did if (!defined

I have this mod working in production with ZC158, but since I have the UMM version, I can't make my changes public.
I invested a lot of time keeping this mod alive in the interim between Conors passing and CEON support being reactivated. I'm not doing that again.

CEON support needs to clarify the support plan for the free mod.

swguy:

If you would set one up, that would be great, I have some fixes as well and I'm sure others do.

If CEON Support hasn't been responsive over several months, we'll need to proceed on our own.

Hi Scott,

Apologoes this has taken a while to get round to. I've been busy of late as I've recently taken over JSWeb.
Anyway, here's the GitHub link for CEON URI MAPPING

https://github.com/JSWebSteve/Ceon-URI-Mapping-V5.1.0

@Strelitzia
I have forked your repository and pushed my changes for ZC158/php8.2 to my fork.

Can I ask, @torvista or anyone here, what you do about EZ pages, if anything? I just ran into ezpage URLs not working in my 1.5.8 upgrade, I traced it to the fact that URIMappingHandler basically sets $_GET['id'] = (int)$associated_db_id, and later sanitize.php checks with a strict ctype_digit test, so an integer value in $_GET['id'] is discarded, and the ez page header.php gets an empty $ezpage_id and panic redirects to the home page.

This change seems to have come in from lat9 pull #4954 here 4 months ago https://github.com/zencart/zencart/pull/4954/commits/f7058733872ae6506bef7d9bed9eb3e460775e64

Your fork doesn't appear to address this issue. I'm guessing you don't use EZ pages :) My Mickey Mouse fix is to hack the URIMappingHandler to set $_GET values to strings instead of integers, i.e.: $_GET['id'] = "$associated_db_id";

I'm guessing you don't use EZ pages
Correct. Sorry.

neekfenwick:

Can I ask, @torvista or anyone here, what you do about EZ pages, if anything? I just ran into ezpage URLs not working in my 1.5.8 upgrade, I traced it to the fact that URIMappingHandler basically sets $_GET['id'] = (int)$associated_db_id, and later sanitize.php checks with a strict ctype_digit test, so an integer value in $_GET['id'] is discarded, and the ez page header.php gets an empty $ezpage_id and panic redirects to the home page.

This change seems to have come in from lat9 pull #4954 here 4 months ago https://github.com/zencart/zencart/pull/4954/commits/f7058733872ae6506bef7d9bed9eb3e460775e64

Your fork doesn't appear to address this issue. I'm guessing you don't use EZ pages :) My Mickey Mouse fix is to hack the URIMappingHandler to set $_GET values to strings instead of integers, i.e.: $_GET['id'] = "$associated_db_id";

There is also the following known issue with ez pages in the released version of Zen Cart 1.5.8: https://www.zen-cart.com/showthread.php?229042-Known-bugs-%28and-fixes%29-for-v1-5-8-series&p=1390772#post1390772

Why the core code was changed to necessitate the values to be a string in order to validate that the string is made of numbers seems silly to me. Instead of removing the cast to an integer, why not then cast it to a string?

strelitzia:

Apologoes this has taken a while to get round to. I've been busy of late as I've recently taken over JSWeb.
Anyway, here's the GitHub link for CEON URI MAPPING

https://github.com/JSWebSteve/Ceon-URI-Mapping-V5.1.0

@strelitzia Hi, are you a Ceon support rep, and is this the official Ceon URI Mapping repo, and can we issue Pull Requests? Or if not there, then where? The repo doesn't seem to be forked from anywhere, but also the files don't have much history so it seems to have been borrowed rather than formally developed. It would be nice to be able to feed useful code fixes back to the addon.

First, I'd like to see a little discussion as @mc12345678 mentioned, why the init_sanitize code works the way it does. I presume the logic behind using ctype_digit() is that a $_GET parameter ought to have come in via a query parameter, which ought to only be able to be text, so any non-string data probably is a hack, but this seems rather tenuous logic and I don't know of any spec that defines what data type $_GET parameters may be. It is amusing that products_id is not sanitised (it's not in the array of fields to check), so URIMappingHandler can set $_GET['products_id'] = 123 without problems, which is possibly why this 'bug/feature' hasn't been noticed before since it doesn't affect product pages.

First, I'd like to see a little discussion as @mc12345678 mentioned, why the init_sanitize code works the way it does.
Please open an issue on Github.

https://github.com/zencart/zencart

neekfenwick:

It is amusing that products_id is not sanitised (it's not in the array of fields to check), so URIMappingHandler can set $_GET['products_id'] = 123 without problems, which is possibly why this 'bug/feature' hasn't been noticed before since it doesn't affect product pages.

The parameter products_id is not strictly an integer because many, many years ago, it was determined that the products_id would be used to support carrying the attribute information related to the product.

Not everyone uses attributes in every store, so yes, it may in part be possible that a store could operate with such integer sanitization. But, the broader use of the field is numerical and whatever character(s) result from hashing the attributes separated by a colon.

In a way that hashing can be useful to recreate the product, though nearly falls apart when the product has an attribute allowing user provided text.

swguy:

Please open an issue on Github.
Fair point, thanks. https://github.com/zencart/zencart/issues/5366

mc12345678:

The parameter products_id is not strictly an integer because many, many years ago, it was determined that the products_id would be used to support carrying the attribute information related to the product.

Ah yes good point, you've set off a nasty tic in my left eye, remembering the get_prid() function and how the cart links back to the product page to 'edit' the product, and how I tried to reverse engineer how this stuff works from code with little documentation :) Now I look again, init_sanitize does check products_id with more complicated preg_match logic allowing the colon-separated format and /\d/ regex which, I just checked, an integer PHP variable does test OK with, as does a string type variable, so the ceon addon can put an integer type into $_GET['products_id'] without error. Anyway I'll comment on the github issue I raised.

Handling changed/old/outdated URLS?

After updating some urls with a new format or names etc., how does the old url get handled?

I see a lot of requests from search engines that end in page not found as it is a historical url.

When working properly, CEON will automatically 301 redirect old URIs to the new URIs.

When working properly, CEON will automatically 301 redirect old URIs to the new URIs
That's what I feared...I have to understand how this bit is supposed to work...ugh.

torvista:

That's what I feared...I have to understand how this bit is supposed to work...ugh.

The old, recognized URI is attempted against the database where it is identified as not being the current, active URI. The associated dynamic data is returned and then the active version of the URI with that data is sought. If not found (in either case) it is expected that the URI is identified as not found (404).

If a matching new address is found then a redirect occurs to identify that the provided URI has changed. This happens for any and all of addresses that remain in the database marked as old (not current).

Attempting to add a new manufacturer doubles up the content of the sidebar so that the core fields (manufacturer name, image, etc.) are prompted twice.

This is a defect in includes/ceon_uri_mapping_javascript.php l.150-187, I'm just not sure of the fix yet.

Yes... I noticed this some weeks ago. Both sets of fields need in-filling for it to parse the data to the dbase.

I don't have this issue, I imagine I fixed it long ago.
Review my fork

UPDATED URL*
https://github.com/torvista/Ceon-URI-Mapping-V5.1.0/

Steve, yours works, thank you.
You are missing some fixes, I will PR to your repo.

I'm setting Steve's fork as the Github repo since it seems to be the most up to date.