Ceon URI Mapping v4.x

[sfatula]

On Zen 1.5.0, using Ceon 4.0.7. Site is plain Zen with Ceon installed only (test). Installed via Zen Cart installer, site was working fine. Reviewed the FAQ, did not see anything that applied here. Using the default template for now (classic).

So, I turned off auto gen, have a product, added a URI on the product page in admin. The URL does show up in the list of products for the category, so, the URI is correctly recognized. However, when I click on the product link, it goes to the home page where it says there are no products to list in this catrgory.

Rewrite rules listed in the Apache config file:

# Don't rewrite any URIs ending with a file extension (ending with .[xxxxx])
# RewriteCond %{REQUEST_URI} !\.[a-z]{2,5}$ [NC]
RewriteCond %{REQUEST_URI} !\.[a-zA-Z]{2,5}$ [OR]
RewriteCond %{REQUEST_URI} \.(php)$ [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} !^/fe3rfgf [NC]
# Don't rewrite editors directory
RewriteCond %{REQUEST_URI} !^/editors/ [NC]
# Don't rewrite admin directory
RewriteCond %{REQUEST_URI} !^/admin/ [NC]
# Handle all other URIs using Zen Cart (its index.php)
RewriteRule .* /index.php [QSA,L]

So, I have NO categories with any URI mapping, nothing else, just ONE product. Files were copied to the appropriate Zen dir via cp -aR. Browsing the directories shows the files in the correct places.

The site is only on our intranet, not publically available. Have any thoughts as to why the mapping is not being recognized by Zen?

[sfatula]

So, to answer my question.... PHP_SELF as used in the Ceon code is the before rewritten value. So, the Ceon code checks:

if ($PHP_SELF != (DIR_WS_CATALOG . 'index.php')) {

Well, it was non equal since PHP_SELF was the configured URI, not index.php. So, the code did not execute. Apparently, this happens when you do not put the difrectives in a .htaccess file.

According to this site:

https://issues.apache.org/bugzilla/s...i?id=40102#c11

If you specify the PT flag in the RewriteRule, it seems to work. So...

RewriteRule .* /index.php [QSA,L,PT]

Should this be added to the FAQ somewhere or, in the suggested directives that come from the initial install?

An alternative would be to use $_SERVER["SCRIPT_FILENAME"], which for me also seems to be set correctly.

[conor]

Hi,

Well, it was non equal since PHP_SELF was the configured URI, not index.php.

I'm pretty sure that's a problem specific to your server then. You've misconfigured it somehow.. hence you being the first person ever to have this probem.

So, the code did not execute. Apparently, this happens when you do not put the difrectives in a .htaccess file.

No, we us the VirtualHost directive on Apache here ourselves.

Should this be added to the FAQ somewhere or, in the suggested directives that come from the initial install?

No, as 1 out tens of thousands isn't enough for the F in FAQ :)

Glad you have things working for yourself now. I wonder if your server's misconfiguration of the PHP_SELF variable won't create problems for you in the future though.. but then you did say this was s local test server so I'd imagine things will be different on your production server.

An alternative would be to use $_SERVER["SCRIPT_FILENAME"], which for me also seems to be set correctly.

If you look at Ceon URI Mapping's source, you'll see there is an entire method dedicated to analysing and coming up with the correct value for PHP_SELF (_normaliseServerEnvironment()). Perhaps it needs upgraded for setups like yours, but I don't think so, I think your setup is simply broken. Either way, things are working for you and I'm snowed under so I'll leave things as they are for 4.0.8.

Enjoy the new URIs!

All the best...

Conor
ceon

[sfatula]

I don't believe it is broken at all, it's certainly not self installed or built, it's the OS supplied installation. If you search the net for php_self and mod_rewrite, or, read the apache issue I gave you a link to, I am not the only one. (though that was not Ceon specific). On that link, you will see the behaviour is different between using .htccess or not based on different test results. Apache blamed php. They have some explanation as to why as well. So, I think the evidence is clear it's not a case of being broken, just more likely some sort of incompatability between php and apache in certain circumstances.

We have more than a dozen open source packages installed (and one java as well), and they all work fine. Also, the OS has a number of php related screens and they also work fine. We have another test site on the same machine using that certain other SEO URI contribution with Zen, and it also works fine (wanted to try this one with yours to see what we like better). I see posts on php.net as well related to this. However, I can't tell you specifically what combination of stuff may cause it, so, I am sure you're right that no one else may have the issue (whio is using this mod), it must be some specific circumstance. I couldn't find any related to the Ceon mod. Overall, it would appear $PHP_SELF is not very reliable from reading the PHP site. Though, it's certainly very widely used.

In the end, it is working. So, I suppose it's not a Frequently asked question! Here's hoping my post will help someone else though with the debugging.

What I did to prove the issue was added in the code:

die($PHP_SELF);

right before:

if ($PHP_SELF != (DIR_WS_CATALOG . 'index.php')) {

On the screen, it showed the friendly URL. Just file it for future use, if any! Thanks for responding.

How does this perform with say 50,000 products? It appears the table ceon_uri_mappings has no primary key? And the searches seems to be on URI. This implies a serial read?

[conor]

Hi,

I don't believe it is broken at all, it's certainly not self installed or built, it's the OS supplied installation.

Not to be [too! ;)] weird, and going slightly off topic, but I've a very low opinion of the qualty of most software, whether closed or open source, and have had enough of poorly made Linux insallations to last me 1000 years. Including official commercial releases from the world's largest software companies (in which I've found serious bugs).

And no, I don't rate my own software releases very highly either, at least not the stuff since the Amiga days. ;)

If you search the net for php_self and mod_rewrite, or, read the apache issue I gave you a link to, I am not the only one. (though that was not Ceon specific). On that link, you will see the behaviour is different between using .htccess or not based on different test results.

I did look at it and consider incompatibilites between PHP and Apache etc. to be a "broken" setup, whether on a "fresh" OS installation or not. Of course everyone's definitions differ! :)

However, I can't tell you specifically what combination of stuff may cause it, so, I am sure you're right that no one else may have the issue (whio is using this mod), it must be some specific circumstance.

I don't know how the other mods work but given everything you've said my gut feeling is nnoe of them use the PHP_SELF variable so the issue donesn't show with them.

As I said, I could have the code for checking PHP_SELF wrong but from everything I've read the .php of the index.php should be matchable. When it's not, my code attempts to build the value from DOCUMENT_ROOT or SCRIPT_NAME etc.

In the end, it is working. So, I suppose it's not a Frequently asked question! Here's hoping my post will help someone else though with the debugging.

Thanks, hopefully it does. As I said though, with the corrupt value returned by your die statement, the "correct" value should have been bult. If you send me FTP and admin details for your site I can check to see why the correct value wasn't subsequently built when Ceon URI Mapping would have identified a problem with the supplied value.

How does this perform with say 50,000 products? It appears the table ceon_uri_mappings has no primary key?

Try it and see. :) The software was tested with 24,000 products when being built and I know people have used it with many more. The primary focus of the software is not speed but flexibility so it is not optimised for sites as large as that, but you do have options..

One of which is to throw hardware at it if you feel that's necessary (a perfectly fine policy in this day and age)...

And the searches seems to be on URI. This implies a serial read?

The other is that the software was specifically written to allow the use of subclasses optimised for speed..

The idea is that you can simply override the appropriate database lookup and storage methods to reorganise the way the URIs are stored and matched, for example putting all historical URIs in their own table (or yearly tables if there are loads), as they are "less likely" to ever be used as time goe on, so you could optimise the size of the "current" URIs database without having to optimise lookup code etc.

This override system is how the UMM supports templates for URI mappings.. I never got round to writing subclasses for speed, no-one's ever complained about the speed enough that they wanted me to bother! Which is good I suppose. :)

Hope that helps.. as I said, I can try debugging your server setup if you have a way for me to connect.

It's unlikely to be in the next day or two though as I'm writing this from a hospital bed.

All the best..

Conor
ceon

[niccol]

Conor

First best wishes for your health and a speedy recovery.

Secondly, and not anything important, when I run on Zen 1.5 this mod is creating some errors.

Basically errors due to the non-existence of FILENAME_TELL_A_FRIEND which just, thank god, does not exixt in 1.5.

They seem to come out of autoManageProductRelatedPageURI(). So, I have just removed the bits that apply to tell a friend from that function and it seems to work just fine now. But if there is a better solution then let me know.

I am using 4.0.7 and it says that it is the most recent version. But if not then apologies.

Just thought I'd let you know.

[conor]

Hi,

First best wishes for your health and a speedy recovery.

Thanks, there's no hope of that but I appreciate the nice comments. :)

Basically errors due to the non-existence of FILENAME_TELL_A_FRIEND which just, thank god, does not exixt in 1.5.

Yes, 1.5.0 withdrew this functionality.

In 4.0.8 I have it so that it sets the tell-friend functionality to disabled for new installations.

Unfortunately due to circumstances I didn't get to release 4.0.8 last weekend as planned.

I might just skip to releasing 4.2.0 in a week or so, we'll see.

You can untick the Tell-A-Friend box in the Configuration Utility in 4.0.7, my advice is to do that!

Thanks for the update.

Hope that helps.

Al the best...

Conor
ceon

[niccol]

best wishes Conor.

Hmm, that's it really and thanks as always. There I was fiddling with code when I could have just unchecked a box. Duh!

[sfatula]

Hi,

As I said, I could have the code for checking PHP_SELF wrong but from everything I've read the .php of the index.php should be matchable. When it's not, my code attempts to build the value from DOCUMENT_ROOT or SCRIPT_NAME etc.

Thanks, hopefully it does. As I said though, with the corrupt value returned by your die statement, the "correct" value should have been bult. If you send me FTP and admin details for your site I can check to see why the correct value wasn't subsequently built when Ceon URI Mapping would have identified a problem with the supplied value.

I don't think any login is needed, it would be a waste of your time at this point since I have it working and it's so rare anyway. BUT, I don't think the code does what you say, so, here's something to look at.

In class.CeonURIMappingHandlerBase, the code says:

		// Ceon URI Mapping should only run when Zen Cart itself is responsible for runtime
		// execution. If this code is running because some other software has called the Zen Cart
		// initsystem then don't attempt to map the URI
		if ($PHP_SELF != (DIR_WS_CATALOG . 'index.php')) {
			return;
		}

So, it's the return there that bypasses the code, apparently, on purpose. For what it's worth.

I do hope you get well. I have numerous medical challenges myself.

Try it and see. :) The software was tested with 24,000 products when being built and I know people have used it with many more. The primary focus of the software is not speed but flexibility so it is not optimised for sites as large as that, but you do have options..

The other is that the software was specifically written to allow the use of subclasses optimised for speed..

The idea is that you can simply override the appropriate database lookup and storage methods to reorganise the way the URIs are stored and matched, for example putting all historical URIs in their own table (or yearly tables if there are loads), as they are "less likely" to ever be used as time goe on, so you could optimise the size of the "current" URIs database without having to optimise lookup code etc.

This override system is how the UMM supports templates for URI mappings.. I never got round to writing subclasses for speed, no-one's ever complained about the speed enough that they wanted me to bother! Which is good I suppose. :)

Conor

So, given that, do you see any issue with adding a primary key of the uri? Not, you, me. (Side effect is MySQL workbench allows one to edit the table data, it does not when there is no primary key). I don't think there should be any duplicates, after all, those would be bad anyway.

[conor]

Hi,

BUT, I don't think the code does what you say, so, here's something to look at.

lol I think I know my own code. :)

You've missed seeing the call to $this->_normaliseServerEnvironment() a few lines before the abort code you refer to is encountered. :)

Please do send login details so I can debug the server environment.. may as well have Ceon URI Mapping cope with such broken servers, can only be good to be as compatible as possible!

I do hope you get well. I have numerous medical challenges myself.

I'm sorry to hear that, I hope you are on top of things and well on the way to beating them! :)

So, given that, do you see any issue with adding a primary key of the uri? Not, you, me. (Side effect is MySQL workbench allows one to edit the table data, it does not when there is no primary key). I don't think there should be any duplicates, after all, those would be bad anyway.

Unfortunately, yes, as historical URIs can have used the same URI as a current URI but with the current URI referring to a different product etc.

Also, multi-lingual sites can have the same URI but with different language IDs.

It's for these reasons that the uri column can't be made a key in the "standard" edition of the software.. but if you override the DBLookup and Admin classes and create a new edition, storing the historical URIs in a separate table, and not using other languages, you can indeed key the table by the uri column.

Hope that helps!

All the best...

Conor
ceon