anterys

Thanks John. Appreciate the quick response.

I think a lot of folks are waiting for the fix from Rachel. I’ve had to revert to a pre-4.7 version.

Thanks

The first command results in an error.

;; connection timed out; trying next origin
Host xxxx.com not found: 3(NXDOMAIN)

The second does produce a good result, namely the correct IP address.

Ok. I have done your suggestion and it worked. Thanks for the prompt feedback.

Thanks for the tips Yorman. I am not sure I completely understand the issue. If I ping both the www and non-www versions of the domain, the IP address is the same. Not sure how the DNS setup I have for this domain is any different than any of the other domains we manage.

I ran your script and received the same error (below) for both the www and non-www versions of the domain.

{
"action": "register_site",
"messages": [
"Invalid domain. Not accepted."
],
"output": {},
"request_time": 1433344337,
"status": 0,
"verbose": 0
}

I figured out the issue. The priority of the add_action for registering the event post type was 100. Setting it back to 10 resolved the error in your plugin.

Old:
add_action('init', 'sc_setup_post_types', 100);

New:
add_action('init', 'sc_setup_post_types');

I’ve been hacking at this all day as I need to get this working. It seems like the problem is between this plugin and wpMandrill so the issue may not be with wpMandrill.

The order of events when you WooCommerce attempts to send an email.
1. WooCommerce creates its payload (with template if applicable).
2. WP Better Emails wraps the WC payload with its theme.
3. wpMandrill sends the WP Better Emails message.

To troubleshoot this issue, I wrote out (to the log) the payload right before Mandrill sends it (via the mandrill_payload filter). I see the WBP template code and it looks good. The problem is that the WC payload within has a bunch of “
” tags littered throughout it, within tags and completely invalidating the HTML that WC produced. It almost seems like a wierd version of wpautop was applied to it. Here’s an example.

<p>An order has been created for you on Houston Psychological<br />
Association. To pay for this order please use the following link: <a<br />
href="https://stg.jawdropdesign.com/psychologyhouston.org/checkout/order-pay/591?pay_for_order=true&key=order_54db9a9d79e32"<br />
style="color:#505050; font-weight:normal;<br />
text-decoration:underline">pay</a></p><br />
<br />
<br />
<br />
<h2 style="color:#505050; display:block; font-family:Arial;<br />
font-size:30px; font-weight:bold; margin-top:10px; margin-right:0;<br />
margin-bottom:10px; margin-left:0; text-align:left;<br />
line-height:150%">Order: #591 (<time<br />
datetime="2015-02-11T12:07:00+00:00">February 11, 2015</time>)</h2><br />
<br />

You will see that most of the tags are split with these HTML breaks. Obviously, this will prevent the email from looking right. The very temporary fix is to, within the mandrill_payload filter, remove these. Note that this will also remove any intentional breaks. It’s a much better workaround than I posted above but I’d prefer a permanent fix.

add_filter('mandrill_payload', 'my_mandrill_payload');
function my_mandrill_payload( $message ) {
        $message['html'] = str_replace( "<br />", '', $message['html'] );
        return $message;
}

A workaround is to change the email type in each of the WooCommerce emails to “Plain text”. It doesn’t look nearly as good but at least it is readable.

I too am having an issue. If I disable wpMandrill, the emails look fine. The way I configured WooCommerce is to copy the WP Better Emails template code to the WooCommerce emaail_header.php and email_footer.php. It works fine. The problem come ins when I enable wpMadrill. I don’t think this is a WP Better Emails problem, rather a wpMadrill problem.

I have the same problem with one of my sites. I’ve pinpointed the issue to WPML, my multi-language plugin. I will submit an issue to them to get it resolved. Will post the solution here if I get one.

You may try clearing your cache and deleting your cookies to fix the issue with the persistent cart still appearing.

Hopefully the WooThemes guys also find it a good solution.

Hi Dynadata. I did but not in any way that is recommended. I never got a response to this question and the requirement was firm with the client so I was forced to update the WooCommerce core files. It was a simple change that could be quickly and easily redone with new versions of the plugin.

The fix is to simply comment out any an all calls to the function update_user_meta within the plugin. And just to be safe, I commented out the persistent cart action (the following line in woocommerce-hooks.php.

add_action( 'wp_login', 'woocommerce_load_persistent_cart', 1, 2 );

I’m a little surprised that it’s not possible to turn this off in the options although I have not researched it in 7 months so it might be now.

I’m also interested in a solution for Dasha’s question.

Came here to post the same solution. Glad it’s already there. For me the results were mostly right which threw me for a look. @djmaskell, that makes some sense as to why it was mostly working.

Hey Steven,

Great post. Was searching around everywhere for this. The use of the pre_user_query was mentioned but never code examples.

I’ve gotten this to work but there’s a slight glitch. That being that if there is no data in the meta field, that record falls out of the table when you sort it (i.e., certain records disappear). Have you seen this and, if so, do you have any ideas on how to ensure all records are returned?