Hi Conor (Sorry for misspelling your name)
She's working now thanks.

Hi,

windsurfer:

Hi Conor (Sorry for misspelling your name)
She's working now thanks.

Glad to hear that, and no problems about the name! ;)

All the best..

Conor
ceon

Hi Conor,

Sorry to bother you. For the first time in my life I am playing with pinterest. Hmmm, yes, I love social media and flaky interfaces. It appears that the URI rewriting somehow breaks the pinterest pinit functionality. Now, I know that this really isn't your problem in some ways but wondered if you had any quick thoughts about that. Other than the obvious about Pinterest that is!

Pinterest operates in a javascript created popup. Some of the communication seems to happen just fine. The popup is populated fine with details from the users account. But when it comes to actually 'pinning' the page things just do not happen. Which is just odd. With the mod turned off things work fine.

I will obviously talk to Pinterest about it but they are not seeming to have magnificent developer support.

As I say, not expecting a big answer. Just if you see something that I have missed or have a Conor moment of inspiration then let me know.

Hi,

niccol:

As I say, not expecting a big answer. Just if you see something that I have missed or have a Conor moment of inspiration then let me know.

I've no idea what this pinterest is (never even seen/used Facebook myself nevermind other networks!) but your issue simply sounds like a path on the server is being blocked by the rewrite rule so you need to add an exclusion to the rule.

The docs have all the information you need to do that.

If you get stuck then send me FTP and admin details and I'll take a look.

All the best..

Conor
ceon

I am on your wavelength about facebook, twitter, pinterest.......

Thanks for the time.

:smile:

Hi,

niccol:

I am on your wavelength about facebook, twitter, pinterest...

I think they are probably quite useful/interesting but I have my own ideas about things and in a way they are probably partial competitors to my future software (aarck/aawe ;) ) so I don't want to have any bias by seeing how they "do things".

I think a "design it as I think it should be, then look at how others do it to see if there aspects you may have missed" is the best design strategy. :)

Anyway, as I said, I'd need to look at your site to actually see what's being blocked and how to fix that, but as a suggestion, at a guess, you could try adding:

RewriteCond %{REQUEST_URI} !^/pinterest/ [NC]
```To your rewrite rule.

If that doesn't work then the info in the docs really should be enough if you want to try this yourself. It's quite easy to get Ceon URI Mapping working with anything, I've been careful about that!

All the best..

Conor
[ceon](http://dev.ceon.net)

Well it isn't a direct file block because there are no files on the users server.

They load into a iframe. Which to the user appears just to be a button. That iframe creates the popup. The only things that are passed to the iframe when it is created by javascript are the url, the image url and the description of the pin and a couple of configuration settings.

After four days of playing with it on that site, it now works. Not sure what I did to be honest. It didn't work with URI rewriting on. I made no changes to the files. Turned URI rewriting off and it worked. Turned it back on and it still worked. At the moment am busy enough to be in 'if it is not broken do not fix it' rather than 'hmmm that is interesting' mode.

Best of luck with the future software. I hope that you are drinking champagne when you float it on the stockmarket in a few years :-)

Hi,

niccol:

Turned URI rewriting off and it worked. Turned it back on and it still worked.

Hmm, I certainly have no answers for that one! Glad it's working either way! :)

niccol:

Best of luck with the future software. I hope that you are drinking champagne when you float it on the stockmarket in a few years :-)

Thanks.. actually, I don't believe in stock markets, I believe that they're one of the biggest problems society ever created!

Stocks in companies yes, absolutely, an essential, smart societal idea.

Being able to sell them at more than buying price plus inflation, no, idiots came up with that one! ;)

Plus it's OS software that's free for non-commercial use. :)

Anyhoo.. a bit off topic! - Glad you're sorted, that's the main thing.

Back to preparing 4.0.8 for release later today hopefully, have a good day yourself!

All the best..

Conor
ceon

Hey, Conor, hope you are feeling good today!

Got an oddity that I've never seen before with manufacturers. The site has cars in the manufacturers list such as mg, mercury, mazda and many others. The reason why I mentioned the one's that start with M is that these are showing 404 errors.

I'm upgrading the version and went into the database to make sure there were obvious conflicts and just don't see any.

What do you think the problem could be?

Hi,

delia:

Hey, Conor, hope you are feeling good today!

Hmm, trying to get these module releases out, the years go on and on.. :|

delia:

What do you think the problem could be?

I've no idea but don't think it's the module. You could possibly have a condition in the rewrite rule blocking URIs starting with "m"?

I can take a look later if you send FTP and admin details but I have no other ideas I'm afraid. I just know it can't be a problem with the module itself.

Hope you're well yourself!

All the best..

Conor
ceon

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?

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/show_bug.cgi?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.

Hi,

sfatula:

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.

sfatula:

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.

sfatula:

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.

sfatula:

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

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?

Hi,

sfatula:

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

sfatula:

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! :)

sfatula:

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.

sfatula:

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.

sfatula:

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

sfatula:

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

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.

Hi,

niccol:

First best wishes for your health and a speedy recovery.

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

niccol:

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

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!

conor:

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.

conor:

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.

Hi,

sfatula:

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!

sfatula:

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! :)

sfatula:

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