findshorty

Please ignore. Culprit found.

Which features described are you not seeing, may I ask?

Add product images of any size – Check
Embed and attach email images – Check
Easier selection of email header image (replaces the Woocommerce default functionality) – Check
Display product categories for each line item – Check
Display product SKU for each line item – Check
Test your emails either in your browser or emailed to your email address using data from real orders – Check, although it looks as though there is an issue with Email tests because the class name for the Woocommerce email abstract class has changed. I’ll fix that up, but most people use the preview in browser.
Filter to change the category separator – Check

So, out of all the features described, all but one are present, correct, and working with the latest version of Woocommerce (3.5.3).

If you’re going to add a 2* review, and then go on to advertise someone else’s plugin, at least have the courtesy of not lying about the plugin you’re reviewing. You can tell the community you think it’s not very good, and there are better alternatives, however telling them 75% of the features are missing is simply untrue, and I would appreciate a retraction.

What plugin are you using to create the custom emails?

I need to do a compatibility test for latest Woocommerce versions anyway, so I’ll check your situation out at the same time.

Cheers

Hi
This plugin is intended to give you an easy way to include product thumbnails and categories in your Woocommerce emails. It also provides a mechanism for previewing the emails using actual orders instead of blank data, or creating fake orders purely for testing your emails.
If you want to alter the actual textual content of the emails, you can still use this plugin for thumbnails and categories, but you will need to copy the individual email templates into your theme’s woocommerce folder and alter the text there.

Sorry for the delay in getting back to you.

Nothing to worry about really, it won’t affect the way the plugin works at all, but I’ll still get it fixed. Will be sorted in the next release!

Sorry for the delay in getting back to you!

Any idea what the error was? I’m not getting one for 4.7.

Did you try again?

Cheers

If you’re using the latest version it should allow you to choose the size of your image, which is probably set at “Medium” by default.

If you select an image, and scroll the right hand side of your attachment window down to the bottom, you should see the following:

Select the size you want and it should use that size.

Let me know if it doesn’t work for you.

Cheers

Hi Tristan

Apologies for the delay in getting back to you.

Did you chose the 600×300 image from the attachment window that opens up? You should be able to choose the size from your currently registered image sizes (you’re not just choosing the image, but the size too).

Let me know

Cheers

Don’t worry. There was a conflict with an output buffer that I’ve solved.

Cheers for a great plugin!

Resolved.

Which plugin are you using for stock notifications?

No, I haven’t had the time to do it.

Client is happy that address_1 and postcode aren’t required fields on both forms for now, as we’re not taking payment for anything just yet – it’s just a quote generation site for now.

Still planning on getting it to work somehow though, just not sure when!

No, the opposite. Any changes you make to woocommerce_shipping_fields and woocommerce_billing_fields will not work (on address fields), because woocommerce_default_address_fields builds the javascript array that reorders the address items.

You can use woocommerce_default_address_fields to control the params of each field, but I’m not sure about the ordering, and any changes you make will affect both billing and shipping.

The ajax call performs the recalculation of delivery charges based on country, I believe.

The only fragments that are updated directly via ajax are within the totals table – the address fragments are rebuilt after the ajax call using the (already set) javascript global var wc_address_i18n_params.

This is where the problem lies. The wc_address_i18n_params var is built without passing the fields through the filters we need to use. The only filter that affects the javascript is the woocommerce_default_address_fields, which as we know doesn’t discriminate between billing and shipping fields.

I wasn’t sure it was technically a bug to be honest, but then the behaviour does contradict what the docs say should happen, so perhaps it could be classed as one.

Will try and put together a bug report.

It’s the update_review_order ajax call that initiates the change, although the fields look like they’re preloaded via javascript because the ajax call doesn’t return the HTML for the form.

Very annoying quirk that needs sorting really. Doesn’t seem to be any reason the woocommerce_shipping_fields and woocommerce_billing_fields filters are ignored.

Will add a bug report and see how we go.