adam_jack

This just hit a site managed/updated by a less-than-technical relative, no clue how. That said, downloading the missing file from github worked perfectly. Thanks @autotutorial … very helpful.

I was using the built in one. Right now it is turned off but I am struggling to get details from the hosting provider. Without them I don’t know where to start looking, or what to think.

I mainly wanted to reach out in case this was a new addition and see if it were a likely candidate, but it seems not. It could be a coincidence that this spamming started shortly after I added it, however much as I don’t like believing in coincidence they can occur.

I’ve not taken a look at the code but if this was a potential target I was wondering if spammers could inject SMTP commands/extras into the e-mail field and somehow trick the local sender into doing more than sending to the subscriber. I don’t see any cruft in the database, but wondered if the widget code parsed the e-mail address for more than just the domain lowercasing (such as looking for <CR> or whitespace or ; or extra @ and such.) I don’t know WordPress internals to know if they do this. Any thoughts on that?

I’ll update this if I get any information.

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

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

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”

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

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.

BTW: I changed themes in case there was some conflict and the error went away, but the sliceshow still does not show.

Forgive me, wrong forum.