Chemo's Ultimate URL's

Quote:

---

Originally Posted by 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.

Quote:

---

Originally Posted by 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?

---

Quote:

---

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

Quote:

---

Originally Posted by 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 :)

Quote:

---

Originally Posted by tvadpro

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.

---

Trust me, you're in the great majority wanting a change to the checkout process! However, meantime, you might be interested in "checkout without account"

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