webbernaut

Can you let me know what version of WordPress you are using?
Also did your email that you added have any special characters in it? outside the @ of course.

So I now see the “Used for variations” checkbox, jumped the gun. This accomplishes this case scenario, which I can use to test performance. I am still curious about the nature of how “Used for variations” is queried compared to the actual variation attributes added under products > attributes (which are variations attributes).

Actually it looks like all your javascript is wrapped in an HTML comment…

<script>
<!--
	// Find ALL <form> tags on your page
	jQuery('form').submit(function(){
		// On submit disable its submit button
		jQuery('input[type=submit]', this).attr('disabled', 'disabled');
		jQuery('input[type=image]', this).attr('disabled', 'disabled');
		jQuery('#pmpro_processing_message').css('visibility', 'visible');
	});

	//iOS Safari fix (see: https://stackoverflow.com/questions/20210093/stop-safari-on-ios7-prompting-to-save-card-data)
	var userAgent = window.navigator.userAgent;
	if(userAgent.match(/iPad/i) || userAgent.match(/iPhone/i)) {
		jQuery('input[type=submit]').click(function() {
			try{
				jQuery("input[type=password]").attr("type", "hidden");
			} catch(ex){
				try {
					jQuery("input[type=password]").prop("type", "hidden");
				} catch(ex) {}
			}
		});
	}

	//add required to required fields
	jQuery('.pmpro_required').after('<span class="pmpro_asterisk"> <abbr title="Required Field">*</abbr></span>');

	//unhighlight error fields when the user edits them
	jQuery('.pmpro_error').bind("change keyup input", function() {
		jQuery(this).removeClass('pmpro_error');
	});

	//click apply button on enter in discount code box
	jQuery('#discount_code').keydown(function (e){
	    if(e.keyCode == 13){
		   e.preventDefault();
		   jQuery('#discount_code_button').click();
	    }
	});

	//hide apply button if a discount code was passed in
	
	//click apply button on enter in *other* discount code box
	jQuery('#other_discount_code').keydown(function (e){
	    if(e.keyCode == 13){
		   e.preventDefault();
		   jQuery('#other_discount_code_button').click();
	    }
	});
-->
</script>

As mentioned in original post I had already disabled all plugins with no luck on fixing the problem. I didn’t think to disable my theme.

After much trouble shooting (you really need a better error message system), I finally figured out the issue. It was not a javascript error or conflict. This was the first thing I was changing in my theme after TwentySeventeen worked fine on checkout. Removing all enqueued javascript files in my theme didn’t change anything on error message.

I have a custom theme with a few security functions. One particular function strips out all html comments on code output. For some reason this was causing your plugin to spit out the javascript error message on checkout.

Some html comments display the version numbers of plugins, which I feel is very bad practice with vulnerabilities being discovered daily. (I also strip out version numbers on scripts but this didn’t seem to be an issue the error I was getting).

This seems to have resolved the issue, but curious as to why I can’t strip out HTML comments with your plugin. I would really like to do that for security purposes…

Not a support question really. Marking resolved.

• This reply was modified 6 years, 4 months ago by webbernaut.

If you are using the shortcode as intended.
[email] or
[email name=”cfe-john”]
The “view source” on the code, which is the source code for the page will display.
<a href=”#”><span class=”cfe-jsemail”>loading…</span></a>.

The email is pulled dynamically into the page via javascript. Dynamic javascript is not rendered as source code, therefore cloaking the email from scrapers. The plugin also detects headless browsers (phantomjs and slimjs) that will render javascript, but the plugin stops the email address from being retrieved by javascript if those headless browsers are detected therefore not displaying your email address.

By design the mailto code is meant to open your email client to send an email. Adding _target_blank isn’t going to change it’s behavior. (and in fact will just open a blank tab that navigates away from your site) If you are referring to a mobile device it might have a slightly different behavior but it will still open an email application and bring that application to the “front”.

If you don’t want people navigating away from your website (to an email client) when sending a message I would suggest using an email form. The email gets sent from the back end and the user never leaves your website.

It’s behaving as it should. My email client (Mac mail in my case) pops up with the email in the “email to” field when I click on your test server email link. I don’t think your issue is the code from the website but more so your computer configuration. Do you have a mail client installed on your computer (Outlook, Thunderbird or other)? If not, then mailto: will not work, the mailto: is looking to open an application on your computer. If there is no default email application configured, someone would need to copy and paste the email into their webmail.

The mailto: function is tied to opening an email client(software). Just as the tel: function is tied to calling a number (mobile or maybe skype).

target=”_blank” opens a new tab for whatever the link is. So in this case you will get blank page that has the “url” as mailto:[email protected] which isn’t useful at all.

You can see what I mean here:
https://jsfiddle.net/d2gm1t0o/

Sorry I think I figured out what you were doing.
You can’t put the shortcode in the href. That’s not how shortcodes are intended. Shortcodes write code for you and in the case of this plugin, it’s not just returning an email address it’s outputing a handful of code, so it wouldn’t work inside an html href.

I did wrap it in a span tag with yellow:
<span style="color:yellow;">[email]</span> and since the span is not the parent tag of the mailto link <a href="mailto:[email protected]">, it is not being applied. It registers the website’s global css for all <a> tags, as it should being the cascade of how CSS works.

So at the moment there is no way to apply span styles outside some custom css in your style.css in your theme or the custom css module inside WordPress.

You can apply html elements like strong or em ect, but not style attributes.

Each email has a custom html class assigned to it so you could add css styles to your style sheet for each specific one (you would have to inspect the code in the browser to see what class is added, it’s dynamic so will depend on the email). Or you can set the global style using the following:

.cfe-wrapper a {color:yellow;}

PS I will put on my to do list on retaining span styles wrapping the short code.

• This reply was modified 6 years, 7 months ago by webbernaut. Reason: code wrap
• This reply was modified 6 years, 7 months ago by Steven Stern (sterndata).

Text being [email]?
So<span style="color:yellow;">[email]</span> ?

• This reply was modified 6 years, 7 months ago by Steven Stern (sterndata).

I can put it on my todo list if other people suggest it, Im trying to keep the plugin pretty simple. The subject line option made a whole lot of sense as I think some people would like that option. But the other email fields like body or cc, and bcc Im not sure that many people would use those. And if someone is trying to get that elaborate on their messaging system I feel an email form would be better than the mailto link.

Great suggestion. Ive updated the code to give the option of a subject line in version 1.7, update the plugin and you can utilize a subject line.

Shortcode is as follows [email name=”cfe-example” subject=”My Email Subject Line”]

No most WordPress plugins do not use the WordPress API, if that were the case my security code to block the API would break all the plugins I have on multiple sites, and it only breaks Contact Form 7.

Hi Dennis,
First thanks for using the plugin.

As for the mailto functionality. By default a mailto link on a web page will automatically launch your computer’s default email client as a new mail message. (unless you have configured it not to do so)

Example: If you use outlook it should launch outlook with a new message window with the email address auto filled with the mailto link. This new window is actually from your email software on your computer.

With that being said, what exact functionality are you looking for?

The URL didn’t change it was a straight server transfer. Besides I used backupbuddy to do the transfer so if there was a different URL then backbuddy would of taken care of it.

I did go into settings just now and hit save just to be sure and it’s still showing the wrong url path to the checkout page.