Will Hawthorne

Good to know. Was just looking to see if this issue known.

Thanks Gioni for the response, and dev version link.

I had primarily disabled it 1- in the case it was leaking anything private and 2- it may have affected caching on search queries.

• This reply was modified 6 years, 10 months ago by Will Hawthorne. Reason: mark resolved

Thanks a bunch.

I found my problem. The form-pay.php template is for the Checkout shortcode. What I was looking for was in the payment.php template file, which is the template for the checkout page. Why there is a need for WooCommerce to be WET here I do not know.

The filter in payment.php is ‘woocommerce_order_button_html’

And in case anyone tries to use the above function, I ended up not using str_replace, instead just rewriting the html button. Hopefully this will not break anything in future updates, or maybe they will include more variables to filter on.

Thanks Donncha & webaware. The newest update covers this issue.

Yea it seems like freight calculation a pretty big thing to handle, but the multiple origins for woo commerce shipping per product seems pretty nice. Thanks.

WP SMTP by BoLiQuan, for which I have also submitted another issue with escaping inputs. I believe the WP SMTP plugin is now dead plugin with an unfortunate amount of high reviews.

Resolved.

I have found the issue. It is coming from an SMTP plugin which is adding things to the reply-to field.

When I say by default, I do not mean the template. I mean when the email is sent out it is being stuffed in there, despite the template. I’ve looked through the code some and I do not see where it is coming from.

I’ve noticed that, very beneficial, it’s not the issue though.

I’ve had

Reply-to: [your-name] <[your-email]>

in the Additional Headers field for the forms I’ve created for a while. The actual header info being sent for the Reply-To now seems to be including the From field address by default as well, without me setting it.

Is this not coming from the plugin’s code?

Also make sure that you have settings all correct as well…stuff like the consistency between Selling Locations (under General tab) and Restrict Shipping to Locations (under Shipping tab), and the Country restrictions on the specific shipping methods.

I spent around 3 hours trying to figure this out last week, and after digging through code (mine, Woo’s), and messing with tons of settings, I think I found the culprit, at least in my case (and by testing on another site):

WooCommerce->Settings->Shipping->Flat Rate-> Change “Costs Added” to “Per Order” if it was on “Per Item”

There must be some bug with it. Note: I didn’t have any items of the shipping classes available in the cart (or in the whole store, and I even deleted the classes as part of my testing) so maybe that somehow ties in?

It does not, and if you are using a cacheing plugin that uses htaccess then this plugin will be bypassed.

Good find moshiurmix, that might be where the problem lies.

On line 283 in abstract-class-tracking.php, Yoast requires the WordPress pluggable functions file:

require_once( ABSPATH . 'wp-includes/pluggable.php' );

I believe this removes them from being pluggable functions, breaking the WordPress feature.

——Edit—–

OK I just went to github to make note of it, and daveagp already has.

https://github.com/Yoast/google-analytics-for-wordpress/issues/271