E-mail case sensitivity

@adam_jack,

THe email checking in Subscribe2 is consistent with internet standards. Those states that the domain part (after the @) of an email should be lower case and case insensitive. The local part (the part before the @) can be treated as case sensitive depending on the server. As such Subscribe2 will treat such emails as being different and while your server may not some do.

Interesting.

The practical upshot of that is that people on (say) an iPad who try to subscribe with Subscribe2 are likely to get a poor experience.

I wonder if there is merit in applying this (for iOS and/or all) in the HTML:

https://stackoverflow.com/questions/5171764/how-do-you-turn-off-auto-capitalisation-in-html-form-fields-in-ios

type=”email”
autocapitalize=”off”
autocorrect=”off”

… I’ve not checked to see if there is some pure HTML5 solution.

Also, what is that standards approach? Something like “Produce strict, accept loose” i.e. be as close to the standard yourself but accept when others are not? How about something like do a first search as case sensitive but if it fails do a second that is not case sensitive? That would allow you to work well with strict situation but perhaps let those not conforming (and this was an @yahoo.com address, so not a small subset) work. That, or just be case insensitive ‘cos chances are very few domain support case sensitivity.

Anyway, thanks for your work on this plugin.

@adam_jack,

I’ll have a look at those and assess how they impact functionality on desktop devices as well as portables.

@adam_jack,

The Standard is a published internet starred for email messages.

https://www.ietf.org/rfc/rfc5321.txt

The pertinent part is section 2.4.

Using type=’email’ is not a great solution right now as that’s HTML5. Some sites using my code won’t be using that yet and some browsers don’t support the tag either. (IE being a prime example).

@mattyrob you don’t need to tell me about the SMTP standard ‘cos I’m not implementing an SMTP server or service. ?? It is Yahoo! and GMail (of the two I’ve tested so far) that are accepting e-mail without case sensitivity rejections.

Does adding type=”email” do harm to IE or other browser? It might be the lesser evil to add it.

Stil, your plugin, your choice. Good luck.

@adam_jack,

Yahoo! and Gmail have implemented the mail servers for you and while they may be case insensitive others may not be. I need to work the plugin for the lowest standards implementation.

Changing to type=”email” – I have no idea if it’ll break older browsers but having done a little reading it isn’t looking good and until I can test and be sure I can’t risk breaking the plugin for a lot of users.

As I went in to change the plugin for my site it dawned on me that replacing type=”text” with type=”email” would almost certainly break old browser (I hadn’t looked to see that type=”text” was already there.) As such I’m planning to add just these two since they are additions not replacements:

autocapitalize=”off”
autocorrect=”off”

@adam_jack,

Let me know how you get on adding those fields. I’ve read in some places that changing type=”text” to type=”email” WILL work, even on old browser. It would do very much validation at all (even in newer browsers it’s a pretty basic test – some just check that there is an @ in the entered string) but on older browsers that value is ignored and type=”text” is presumed instead.

I make these code tweaks to class-s2-frontend.php

// build default form
		if ( $nojs == 'true' ) {
			$this->form = "<form method=\"post\"" . $action . "><input type=\"hidden\" name=\"ip\" value=\"" . $_SERVER['REMOTE_ADDR'] . "\" />" . $antispam_text . "<p><label for=\"s2email\">" . __('Your email:', 'subscribe2') . "</label><br /><input type=\"text\" name=\"email\" id=\"s2email\" value=\"" . $value . "\" size=\"" . $size . "\" autocapitalize=\"off\" autocorrect=\"off\" />" . $wrap_text . $this->input_form_action . "</p></form>";
		} else {
			$this->form = "<form method=\"post\"" . $action . "><input type=\"hidden\" name=\"ip\" value=\"" . $_SERVER['REMOTE_ADDR'] . "\" />" . $antispam_text . "<p><label for=\"s2email\">" . __('Your email:', 'subscribe2') . "</label><br /><input type=\"text\" name=\"email\" id=\"s2email\" value=\"" . $value . "\" size=\"" . $size . "\" onfocus=\"if (this.value == '" . $value . "') {this.value = '';}\" onblur=\"if (this.value == '') {this.value = '" . $value . "';}\" autocapitalize=\"off\" autocorrect=\"off\" />" . $wrap_text . $this->input_form_action . "</p></form>\r\n";
		}
		$this->s2form = $this->form;

here is the site:

https://www.coalcreekcanyonfd.org/blog/

… and it seems to be working fine for me (tested on iPad.)

@adam_jack,

I think the best way around this is to filter the entire output form and so allow dynamic changes to be made on individual sites where people want to do things differently.

The changes were committed recently ready for the next version:
https://plugins.trac.www.ads-software.com/changeset/794390

With the filter you can create a little plugin to Subscribe2 like this to change the input type and add the autocapitilize and autocorrect parameters, you could even look at just changing those on mobile devices:

add_filter('s2_form', 'my_s2_form');

function my_s2_form($form){
	$form = str_replace('type="text"', 'type="email" autocapitalize="off" autocorrect="off" ', $form);
	return $form;
}

@mattyrob,

I could see how filter plugins like this might be useful, but at the same time I do wonder if the default out of the box experience should disable autocapitalization and autocorrection, if not set type to e-mail. Most folks installing Subscribe2 aren’t going to realize why all the red capitalized e-mail addresses are in their subscriber list and aren’t going to think to do this.

BTW: I don’t know if a plugin can know if the WordPress (theme) is running as HTML5 but if so, then at that point it’d make sense to set type=”email”.

Finally, back to my original point … I suspect enforcing case sensitivity on the non-domain portion of email addresses is somewhat “too correct” also. If you cannot let that go perhaps use a token based verification mechanism so you aren’t relying upon an e-mail match.

Thanks for all your effort on this plugin.

@adam_jack,

Those additions in a desktop browser are not HTML valid. I think I can use the wp_is_mobile() function to get that on mobile devices only.