258 replies to this topic

[Mort-lemur]

Hi Sam,

Finished the install and works great.

One possible suggestion from me for any future update.

On the Create Account Page, there is a title "returning Customer" with boxes where the customer can login.

Underneath this box, I think it needs a title "New Customer" or whatever just so there is no confusion whatever in the customers mind where he should be filling in boxes.

Thanks

[sarafina]

Does this have purchase without account? I'm sure its a silly question but I remember hearing one contrib had it and wonder if its this one.

[spooks]

sarafina, on 10 April 2010, 19:02, said:

Does this have purchase without account? I'm sure its a silly question but I remember hearing one contrib had it and wonder if its this one.

Yes, it has the form suggested by ClubOsc and provides a more secure form of PWA (Purchase Without Account), and makes the personal details input a seamless part of the checkout, removing any password input requirement in that mode. [img]http://forums.oscommerce.com/public/style_emoticons/default/smile.gif[/img]

[Mort-lemur]

Hi again Sam,

Been doing some testing and either I have made an error in the install or there may be a slight bug....

If a customer comes to the shop and buys an item using the PWA feature (ie does not save his data), then returns some weeks or months down the line and tries to buy again, his email is rejected as a duplicate and tells him to log in or use another email.

As he did not want to register in the first place he will probably have deleted the email he received with a password, so in effect can not buy from the store with that email address.

Thanks

[spooks]

Mort-lemur, on 10 April 2010, 20:33, said:

Been doing some testing and either I have made an error in the install or there may be a slight bug....

If a customer comes to the shop and buys an item using the PWA feature (ie does not save his data), then returns some weeks or months down the line and tries to buy again, his email is rejected as a duplicate and tells him to log in or use another email.

As he did not want to register in the first place he will probably have deleted the email he received with a password, so in effect can not buy from the store with that email address.

Thanks

Hi, yes, I would say not so much a bug as a possible senario.

There are a number of solutions

1. You need the e-mail whilst the order is in progress but add a note for admin to change/delete the email following completion.
2. Add a note for the customer after email is rejected as a duplicate to say we still have details related to his e-mail & he can use the password forgotten feature to get a password to his profile/account. (I've seen a number of sites do that)
3. Add a new dbase field to store the 'non save' status of the account, which is checked in this situation & the old e-mail deleted to avoid the conflict.


Let me know your ideas. [img]http://forums.oscommerce.com/public/style_emoticons/default/wink.gif[/img]

[Mort-lemur]

Quote

Hi, yes, I would say not so much a bug as a possible senario.

There are a number of solutions

1. You need the e-mail whilst the order is in progress but add a note for admin to change/delete the email following completion.
2. Add a note for the customer after email is rejected as a duplicate to say we still have details related to his e-mail & he can use the password forgotten feature to get a password to his profile/account. (I've seen a number of sites do that)
3. Add a new dbase field to store the 'non save' status of the account, which is checked in this situation & the old e-mail deleted to avoid the conflict.

Ok Thanks,

Option 1 is out, because from admin I dont know if they created a "real" account or not.
Option 3 is a non-starter to me - I wouldnt have a clue where to start.

So I think that option 2 is the way for me to go - a nice simple edit of the error message.

........unless you know better of course ?

Thanks - love the contribution by the way.

[Mort-lemur]

Hmmmmm maybe not so simples...

Edited the error message fine, instructing the customer to use the "password Forgotton" link....but by the time the error message is displayed the page has changed and that link is not there....

I think as well as the edit to the error message it needs a link to show, if there is an error, offering password forgotton options.

Thanks

Edited by Mort-lemur, 10 April 2010, 21:25.

[spooks]

Mort-lemur, on 10 April 2010, 21:24, said:

Edited the error message fine, instructing the customer to use the "password Forgotton" link....but by the time the error message is displayed the page has changed and that link is not there....

OK, easy fix, in modules/validate_name_fields.php

after:

if ($check_email['total'] > 0) {
  	   $error = true;

add:

 $mail_exist = true;

then in create_account.php

after:

$short_check = false;

add:

$mail_exist = false;

and relpace (251):

  <?php } elseif (!$process) { ?>

with:

  <?php } elseif (!$process || $mail_exist) { ?>

[Ken44]

Hi Sam

I was about to post the same concerns when Heather posted.
The code changes work great
Thanks

Regards

Ken

[Mort-lemur]

Hi Sam,

Thanks for the code - works great.

One (hopefully final) question from me, and apologies for this one:

When a customer visits and uses the PWA function, he is choosing not to register, and to not have his details saved for his next visit. However, his details are saved (against his wishes?) and he is remembered.

How do we stand on this legally with data protection etc? could it be seen that we are saving his data covertly ?

Sorry for the question.

Thanks

[spooks]

Mort-lemur, on 11 April 2010, 16:02, said:

When a customer visits and uses the PWA function, he is choosing not to register, and to not have his details saved for his next visit. However, his details are saved (against his wishes?) and he is remembered.

How do we stand on this legally with data protection etc? could it be seen that we are saving his data covertly ?

I'm no lawyer, so take my advise accordingly, ie ask a lawyer if you need to be sure.

The data you are keeping is that contact information you require to process the order, including any required warantee information, therefore it is reasonable that you would retain such info.

Obviously you must keep the info secure in accordance with data protection.



I would advise adding a relevent entry to your sites T & C for this.

I will be adding a new field in the next version for an option of 'Must agree to T & C'



PS
I would also point out the Google checkout method: your visitor does not set up a account at your site, but gives GC his contact info, but then GC sets up a account for him at your site providing address details etc GC then sends the visitor login details for his account at your site.

Edited by spooks, 11 April 2010, 16:30.

[Mort-lemur]

Hi again,

Installed on my live site now and it is working lovely - sanitises all code etc.

Maybe I missed a line in the install, but when I use the Contact Us form and then go to the contact Us Success page - the heading at the top of the success page is the same as on the Contact Us Form. ie.

Quote

Contact Us on 000 - 111 - 000 or use the form below

Have I made an install error ?

thanks

[spooks]

Mort-lemur, on 11 April 2010, 22:17, said:

when I use the Contact Us form and then go to the contact Us Success page - the heading at the top of the success page is the same as on the Contact Us Form. ie. Contact Us on 000 - 111 - 000 or use the form below

Have I made an install error ?

Its what's in your language file!!

The define used for both is: HEADING_TITLE which is set to 'Contact Us' by default, you have altered it to smthg else!! [img]http://forums.oscommerce.com/public/style_emoticons/default/wink.gif[/img]


I suggest you place your 'Contact Us on 000 - 111 - 000 or use the form below' in a more appropriate place, like within the $mytext section. [img]http://forums.oscommerce.com/public/style_emoticons/default/biggrin.gif[/img]

[Mort-lemur]

Thanks Sam,

I suppose I should have thought of that myself - getting there, all be it slowly .....

Thanks for your help and patience

[pilvinen]

I'm having trouble with the clean_post function in includes/functions/account_secure.php.

It removes all the "ö" but _only_ lower case "ö" is affected. "ÅÄääÖ" are all fine.

Any suggestions what I could do?

[spooks]

pilvinen, on 20 April 2010, 12:29, said:

I'm having trouble with the clean_post function in includes/functions/account_secure.php.

It removes all the "ö" but _only_ lower case "ö" is affected. "ÅÄääÖ" are all fine.

Any suggestions what I could do?

The simplest solution is just to add the ö to the exclude list in the function.

I`ve tried to allow for most chars, but some can be made up differently (ie from multiple chars) Could you find what charset you are using & how your server supports unicode?

[pilvinen]

spooks, on 20 April 2010, 12:55, said:

The simplest solution is just to add the ö to the exclude list in the function.

I`ve tried to allow for most chars, but some can be made up differently (ie from multiple chars) Could you find what charset you are using & how your server supports unicode?

My charset is ISO-8859-1. I suppose the server supports unicode...

I've been trying to add the letter to the exclude list, but it seems I don't know how to do it.
Should be simple in theory, but what ever I try I don't get the result I want.

// Clean post vars	

	function clean_var ($vars) { 

		if (!is_array($vars)) {                              

		return preg_replace("/[^\p{L}\p{M}\w\r@ :{}ö_.-]/i", "", urldecode($vars));  

		} else {     

		return array_map('clean_var', $vars); 

		}

	}	

This just won't do it and after some 3 hours of reading about reg expressions I'm just getting
very very tired about this whole matter ...

Some help would be appreciated :-)

[pilvinen]

// Clean post vars	

	function clean_var ($vars) { 

		if (!is_array($vars)) {                              

		return preg_replace("/[^\w\r@ :{}öäåÖÄÅ_.-]/i", "", urldecode($vars));  

		} else {     

		return array_map('clean_var', $vars); 

		}

	}	

By removing the \p{L} and \p{M} and adding öäåÅÖÄ it now seems to be working. The L seems to be any unicode letter, right?
But I have no idea what the M, Mark, stands for. The problem with unicode specs is that it's sooo confusing, there is just
too much to read.

Is there any reason why doing the above is stupid or is this fine? It does seem to work at least in contact us and reviews.

[spooks]

pilvinen, on 20 April 2010, 14:44, said:

Is there any reason why doing the above is stupid or is this fine? It does seem to work at least in contact us and reviews.

If your not prepared to say precise details of your charset use & how your server supports unicode, I can't help you with your issue as my server setups show no issue with ö

Just replying with 'I suppose the server supports unicode' tells me nothing!! [img]http://forums.oscommerce.com/public/style_emoticons/default/huh.gif[/img]


Yes \p{L} means any letter, but some chars are made of multiple combinations typically a letter & mark combination, hence \p{L}\p{M} (thats how ö is usually constucted) [img]http://forums.oscommerce.com/public/style_emoticons/default/wink.gif[/img]


Your change will work, but means only those & standard a-z are covered, ie most 'foreign' chars are removed.

[AndreN]

Hi Sam

I have a strange issue with this contribution.

Once installed by copying over the files from your contribution, I could not add items to the cart. I noticed that I no longer had session IDs'

In html_output.php at Line 45

if ( ($add_session_id == true) && ($session_started == true) && (SESSION_FORCE_COOKIE_USE == 'false') ) {

I changed the last 'false' to 'False' and this restored my session IDs' and I was able to add contents to the cart again.

However with '$no_pword = true;' set in create_account.php and I follow the logic as explained in your account_mods.html i.e. PWA and complete the Create Account page and click the 'continue' button I get a cart empty message.

YET when I log in with the account credentials created by the above, I once again have contents in my cart.

With '$no_pword = false;' I get my cart with contents and functionality as it should be.

Any ideas why? What is killing/changing the Session ID ? I think this is something to do with the PWA logic.

Any suggestions or help would be appreciated.

Edited by AndreN, 02 May 2010, 16:04.