Chemo's Ultimate URL's

To re-create the problem, you need to open a new session. Close Internet Explorer, then re-open it; go to shedkitstore.com, and the FIRST page you get should have ampersands in the non-catalog sidebox links, while the catalog sidebox links will have question marks. If the status bar is enabled in your browser, you'll see the ampersands when you mouse over the offending links.

This only happens on the first page of the session; ensuing pages are trouble-free.

Also, I restored to the original Google Analytics with regard to common/html_header.php ... thanks for the heads-up, by the way. That one could have languished for days or weeks if you hadn't pointed it out.

If anyone has a minute, I need a small favor. Please open a new browser window and go to shedkitstore.com. Once you get there, do NOT click anything! Not yet, anyway -- first, I need to know whether the non-category links in the sidebox menu contain ampersands (&) or question marks (?). (See mouse-over instructions in my last post.)

After noting ampersands-or-question-marks, go ahead and click one of those non-category links and tell me whether you get a page-not-found.

The problem I'm troubleshooting only manifests on the FIRST page -- at the BEGINNING of a new user session. All subsequent pages should not manifest the page-not-found problem, so I'm only interested in what you find on the first page.

Sounds crazy, but so far, I'm the only one to document the problem. Maybe it only manifests for an admin's client IP? ...

Thanks in advance,
Sean

Um, is this a Windows / IIS server ?
I think you'll have some serious difficulties getting URL-rewrite mods to work under IIS ...

jamie2k:

Hi to all you Zenners :)

I am very new to this, so please be gentle with me.

I have recently installed Chemo's Ultimate URL's, to be precise i actually used the DrByte updated version as i am running Zen Cart V1.35

I now am faced with a problem... Please take a moment to see the error here... http://www.dinkydrinks.eu/

I had the site working well prior to this install, which went a little wrong as i could not get it working with my modifications.

I had made the fatal mistake of not making adequate plans and my backups are not comprehensive.

I have actually used a comparison tool and replaced the core files and changes etc to try and rescue the site.

I am fairly confident that the site is now at the stage i was at when presented with the error you see now directly after dooing the URL mod i mentioned above.

Please help with this as i have spent several moments " hours :( " on this and am getting nowhere fast.

Many thanks in advance.

Jamie

I can't wait any more. This morning, I'm driving across town to test this on a client's computer. I simply need to know whether mine is the only IP where ampersands are used in the non-category links on the initial page of a new session. If anyone else is reading this and cares to click-and-report-back, I'd be very grateful.

tvadpro:

If anyone has a minute, I need a small favor. Please open a new browser window and go to shedkitstore.com. Once you get there, do NOT click anything! Not yet, anyway -- first, I need to know whether the non-category links in the sidebox menu contain ampersands (&) or question marks (?). (See mouse-over instructions in my last post.)

After noting ampersands-or-question-marks, go ahead and click one of those non-category links and tell me whether you get a page-not-found.

The problem I'm troubleshooting only manifests on the FIRST page -- at the BEGINNING of a new user session. All subsequent pages should not manifest the page-not-found problem, so I'm only interested in what you find on the first page.

Sounds crazy, but so far, I'm the only one to document the problem. Maybe it only manifests for an admin's client IP? ...

Thanks in advance,
Sean

tvadpro:

I can't wait any more. This morning, I'm driving across town to test this on a client's computer. I simply need to know whether mine is the only IP where ampersands are used in the non-category links on the initial page of a new session. If anyone else is reading this and cares to click-and-report-back, I'd be very grateful.

It's not so much that people don't want to help. Most people know that there are issues with this mod that is not worth going live with and probably do not see any need for wasting their time until some of those issues are fixed.

For example, let's assume you don't have the problem you're describing, have you figured out a solution to the login problem whereby some of your customers are not able to login once they create an account? This issue has been discussed in several post. If you have a mod that doesn't let your customer login sometimes that's not good.

Thanks, B.I. Lest I come across like an ingrate, I need to say that I'm not peeved in any way. I appreciate anyone who has the time and inclination to point me in the right direction. Conversely, anyone who ignores me is guilty of nothing. I accept Zen-Cart as-is: no contract compels anyone to supply or pay for support.

Once in a blue moon, I try to answer the obvious stuff when I see a recent post from a newbie who is looking for answers -- providing, of course, it's one of the few problems I have personally experienced and resolved. I wouldn't have a working open-source e-com solution if not for the countless times when more experienced Zenners have taken pity on me and answered my questions, so the least I can do is pitch in a few dollars and try to help someone new. But more often than not, I don't even have enough time to read other's posts. Considering how little I contribute to the Zen-Cart community, I'll be the last person to feel I am in any way entitled to the help of others.

I hope this clarifies my attitude in the context of my earlier posts. And if we have beaten this dead horse sufficiently, I am tickled to announce that my problem with SEO-URLs is fixed.

For the benefit of anyone who encounters this issue in the future, the problem was that I had entered search-engine friendly urls for EZ-page links to Shipping, Contact and Site-map pages. (I did this to disable the Information sidebox and consolidate these links into the EZ-pages sidebox -- fewer sideboxes, simpler page.)

Entering a friendly URL like site_map.html works fine, but not on the first page of the session. Of course, I was beyond the initial session page when I tested this, so I never noticed the problem with these links until weeks later.

To fix the problem, I first disabled SEO-URLs. Then, I set the Information sidebox to display -- so I could copy the "unfriendly" links to Site-map, Contact-us and Shipping-info pages. I then replaced the "friendly" URLs in the EZ-page links with the "unfriendly" URLs, disabled the Information sidebox and turned SEO-URLs back on.

Everything works on the initial session page now. And for what it's worth, just dialogging this with others helped me to clarify my own observations, which ultimately led me to isolate the culprit. Is that cool or what! :cool:

BlessIsaacola:

It's not so much that people don't want to help. Most people know that there are issues with this mod that is not worth going live with and probably do not see any need for wasting their time until some of those issues are fixed.

For example, let's assume you don't have the problem you're describing, have you figured out a solution to the login problem whereby some of your customers are not able to login once they create an account? This issue has been discussed in several post. If you have a mod that doesn't let your customer login sometimes that's not good.

Let us know when you fix the login problem with this mod and we will all be singing the Halleluyah Chorus. The inconsistent login problem which affects customers, which affects sales is one of the biggest reasons most users have uninstalled this.

Good luck and please report back if you fix that problem because I'd be ready to install this mod again.

Thanks!

I did stumble across a customer log-in problem a few weeks back, but I assumed it was a sessions problem and not an SEO-URLs problem. After adjusting one of my Admin/Sessions settings (I forget which one, sorry), the problem went away. At very least, my customers have reported no problems creating accounts and logging in -- and I'm not seeing any carts abandoned. Just to be safe, I created a test customer account just now, then logged out and successfully logged back in. Is the log-in problem erratic, or has anyone reported a persistent misbehavior?

If the change in the sessions setting did the trick, I assure you the discovery was by accident.

For whatever it's worth, here are my current Admin/Sessions settings:

• Cookie Domain True
• Force Cookie Use False
• Check SSL Session ID False
• Check User Agent False
• Check IP Address False
• Prevent Spider Sessions True
• Recreate Session False
• IP to Host Conversion Status false

tvadpro:

I did stumble across a customer log-in problem a few weeks back, but I assumed it was a sessions problem and not an SEO-URLs problem. After adjusting one of my Admin/Sessions settings (I forget which one, sorry), the problem went away. At very least, my customers have reported no problems creating accounts and logging in -- and I'm not seeing any carts abandoned. Just to be safe, I created a test customer account just now, then logged out and successfully logged back in. Is the log-in problem erratic, or has anyone reported a persistent misbehavior?

If the change in the sessions setting did the trick, I assure you the discovery was by accident.

For whatever it's worth, here are my current Admin/Sessions settings:

• Cookie Domain True

• Force Cookie Use False

• Check SSL Session ID False

• Check User Agent False

• Check IP Address False

• Prevent Spider Sessions True

• Recreate Session False

• IP to Host Conversion Status false

Although the problem is erractic, your session setting is different. I think this is the only time that I have seen some post Recreate Session False. Usually is set to true to prevent the situation when the search engine index a url with the session. If two customer simultaneously access the site using the same url they will share session ID but setting that option to TRUE prevent possibility of sharing account.

Perhaps that setting solves the problem. The Login issue was erratic in the past, we could test login 100 times and only experience the error 1-3 times. Basically, this only happens to existing customers trying to re-login to an account that has already been created.

Do you get a lot of customers (about 50) a day that logs into their account?

Just to follow up, the problem experienced by Jamie2k, where the SEO sql won't run correctly is an issue with the database structure. When importing the data into a test server, no AUTO_INCREMENT instructions were carried over, so none of the tables have auto incrementing IDs. This means that the fields which require an ID are therefore left unpopulated, and returns an error.

Just in case any of you have the same problem else where.

Absolute

Wow ... so a shopper who arrives on the same page and at the same time as another shopper could unwittingly access the second shopper's customer account information? :shocking:

The more I hear, the less I want to keep Ultimate SEO-URLs on my site. I think there's another SEFU contrib available -- has anyone here used it? Thumbs-up or thumbs-down?

Negative on the customer log-ins. My site sells products a customer would typically buy at most once per decade. Buyers create a user account, make their purchase, and then we never hear from them again. The entire user account element is superfluous and counter-productive. Obviously, I'm one of those people anxiously awaiting the release of a membership-optional Zen-Cart. I would do away entirely with customers setting up user accounts on my site -- if I could. But as the developers have said (and I believe them), that's easier said than done.> BlessIsaacola:

Although the problem is erractic, your session setting is different. I think this is the only time that I have seen some post Recreate Session False. Usually is set to true to prevent the situation when the search engine index a url with the session. If two customer simultaneously access the site using the same url they will share session ID but setting that option to TRUE prevent possibility of sharing account.

Perhaps that setting solves the problem. The Login issue was erratic in the past, we could test login 100 times and only experience the error 1-3 times. Basically, this only happens to existing customers trying to re-login to an account that has already been created.

Do you get a lot of customers (about 50) a day that logs into their account?

Wow ... so a shopper who arrives on the same page and at the same time as another shopper could unwittingly access the second shopper's customer account information?

Is that refering to my last post? If so, you got completly the wrong end of the stick. When the TEST site was created, the database was transfered over, and although the current IDs were all moved in the right tables, the AUTO_INCREMENT commands were ommitted in the SQL file, so new inserts all created an error.

Your store would certainly fail if this was the case with your install, and so no data is vulnerable, especially in this case, where it is only a TEST site.

With regard this module, I use it on alot of stores, ranging from stores doing 1 order a day, to those doing in the region of 200 a day. None have any trouble. We have tweaked some of the coding to ensure that the code runs a little more effectively in some places, but this would be the case with any module - you take the basic and enhance to suit the situation.

Absolute

Absolute:

Is that refering to my last post? If so, you got completly the wrong end of the stick. When the TEST site was created, the database was transfered over, and although the current IDs were all moved in the right tables, the AUTO_INCREMENT commands were ommitted in the SQL file, so new inserts all created an error.

Your store would certainly fail if this was the case with your install, and so no data is vulnerable, especially in this case, where it is only a TEST site.

With regard this module, I use it on alot of stores, ranging from stores doing 1 order a day, to those doing in the region of 200 a day. None have any trouble. We have tweaked some of the coding to ensure that the code runs a little more effectively in some places, but this would be the case with any module - you take the basic and enhance to suit the situation.

Absolute

Absolute, the previous post you quoted was not responding to your post. The issue actually is not related to Ultimate SEO URL. It's the whole issue where some bot still index the session id which although very rare, it's technically possible for two customer to share sessions. This of course is preventable by changing session settings on the Admin side.

You also mentioned that you've cleaned up Ultimate SEO URL mod, do you mind sharing with the community the changes you've made to make it work better?

i have had to turn off the recreate session option as well. if the newer files would fix the problem with sessions.. i would definitely be interested in it as well :)

Thanks for the link, Kelvyn. Interesting -- I read the entire thread carefully.

ShedKitStore.com is an ideal site for checkout-sans-account, since customer retention (repeat business) is a non-issue. A customer pays us thousands of dollars to buy one product, and assuming the product does what it should, they are not likely to buy another -- ever. But given the amount of money changing hands in just one sale, it would be foolish for me to implement a checkout that has not yet been abundantly tested and proven, as my unmodified Zen-Cart 1.3.7 has.

Getting back to the topic of this thread (with preemptive apologies to anyone preparing to hurl rocks at me for bringing up the customer accounts debate), I'm dying to know whether there is a newer/better version of Chemo's than the 2.103 I'm using.

And do I understand correctly that re-create sessions = true can sometimes prevent a customer from logging into their account -- regardless of whether I'm running SEO-URLs?

I too was forced to turn off recreate sessions because of login problems. I had hoped that this issue would be possibly addressed in the new release, but since the author has gone MIA since collecting the contributions . . .

I want to understand the exact symptoms. Voltage, are you saying that without SEO-URLs, customer log-ins always work (regardless of re-create sessions setting) ... but when one uses SEO-URLs, a TRUE setting for re-create sessions occasionally prevents customers from logging in? Is that correct?

Thanks in advance,
Sean

voltage:

I too was forced to turn off recreate sessions because of login problems. I had hoped that this issue would be possibly addressed in the new release, but since the author has gone MIA since collecting the contributions . . .

Voltage, thanks for reporting back your work around. I know that we discussed this last year without a solid resolution. It's too bad that Dreamscape did not deliver after we all made contributions.

Have you had any problems not recreating sessions? I am still concern that it's possible for two customers to share a session (and turning off recreate session really makes me nervous).

Please let us know if you come up with a solution that still allows recreate session. It sounds like Absolute has a fix but nothing has been posted.

Hey all, I'm having an issue I hope someone can help me with. I've searched the forums and found some information, but it doesn't seem to help with my issue.

I'm running ZenCart 1.3.6. We've installed the SEO URLs contribution, and everything works great. Actually, my problem is on the admin end - and it's an annoyance - but it doesn't seem to be messing with the actual functionality of the contribution.

The "weirdness" began happening immediately after resetting the SEO URL cache. Prior to this, there was no problem at all - but when we reset, we started getting all of these weird errors.

1. In the SEO URL area (under configuration), there is always an error that says:

Warning: call_user_func(zen_reset_cache_data_seo_urls): First argument is expected to be a valid callback in /home/SITENAME/public_html/admin/includes/functions/general.php on line 1528

2. When we update any product in the catalog, we get some MAJOR errors. Again, none of them seem to really affect anything - as the changes are always taken, but it's soooo annoying because, when we click "Update" from the "preview" screen of the product we're editing, instead of just updating, it takes us to this page with a list of errors:

Warning: main(includes/reset_seo_cache.php): failed to open stream: No such file or directory in /home/SITENAME/public_html/admin/product.php on line 18

Warning: main(): Failed opening 'includes/reset_seo_cache.php' for inclusion (include_path='.:/usr/lib/php:/usr/local/lib/php') in /home/SITENAME/public_html/admin/product.php on line 18

Warning: Cannot modify header information - headers already sent by (output started at /home/SITENAME/public_html/admin/product.php:18) in /home/SITENAME/public_html/admin/includes/functions/general.php on line 34

When we hit the "back" button, the "preview" page now shows all of the edits we've made, and they've taken on the site as well. So it's not really something that's damaging the site, but it's really annoying to have to do this every time.

Again, this all happened when we reset the cache. Oh, I should also mention that I have this on a local installation as well, and have had no issues with it. One thing I've noticed between the live install and the local is that, after resetting the SEO cache, on the local installation, in the last line "Reset SEO URLs cache", has an value next to it (true, false, etc.). But in the live install, after hitting this reset, there is no value at all - it's totally blank.

So if anyone has any ideas, I'd really appreciate it. Thanks!

I dunno if this helps, but whenever I install a contribution and it misbehaves, e.g. throws warnings, omits components in the admin, etc., I usually wind up uninstalling and then re-installing before it works as expected. Both uninstalling and re-installing can be tedious and time-consuming, but more often than not I learn in the process that I had accidentally skipped something in the initial installation.

I'll shut up now, as the folks who are familiar with Chemo's might know exactly what's causing your problems.

Good luck,
Sean