Forum Replies Created

Viewing 15 replies - 31 through 45 (of 49 total)
  • Thread Starter simooo

    (@simooo)

    Thanks guys – great that you’re able to fix it so soon, looking forward to the update.

    Will let you know if I spot anything else.

    Thread Starter simooo

    (@simooo)

    Hi,

    After a bit of digging I managed to figure out that this was caused by a container with a width of auto.

    What really stumped me was how random the behaviour was and that the problems only happened after moving several slides. But it seems having a non-set width on the container messes with the calculations somewhere along the line.

    Hope this was useful information!

    Cheers,

    Simon

    Thread Starter simooo

    (@simooo)

    Hi Pearl,

    Thanks for checking in. Apparently I have received a reply from MailChimp support, but I haven’t been able to read it due to email trouble.

    Will post an update as soon as I’m able to read the reply.

    Simon

    Thread Starter simooo

    (@simooo)

    Hi Pearl!

    Just wanted to let you know that I’ve updated to the new version of the plugin (as well as the new version of WooCommerce) but that the orders still aren’t syncing.

    The manual sync button came back though.

    Any progress on your side?

    Cheers!

    Simon

    Thread Starter simooo

    (@simooo)

    Absolutely. My error log actually seems weirdly empty, but I did find this entry:

    [Fri Mar 24 14:43:04.015651 2017] [:error] [pid 30512] [client ::1:64969] PHP Fatal error: Uncaught Error: Call to a member function set_job() on boolean in /Applications/mampstack-7.0.13-1/apache2/htdocs/challenge/chancetochallenge.com/wp-content/plugins/mailchimp-for-woocommerce/includes/vendor/queue/classes/worker/wp-worker.php:48\nStack trace:\n#0 /Applications/mampstack-7.0.13-1/apache2/htdocs/challenge/chancetochallenge.com/wp-content/plugins/mailchimp-for-woocommerce/includes/vendor/queue/classes/worker/wp-http-worker.php(63): WP_Worker->process_next_job()\n#1 /Applications/mampstack-7.0.13-1/apache2/htdocs/challenge/chancetochallenge.com/wp-includes/class-wp-hook.php(298): WP_Http_Worker->maybe_handle('')\n#2 /Applications/mampstack-7.0.13-1/apache2/htdocs/challenge/chancetochallenge.com/wp-includes/class-wp-hook.php(323): WP_Hook->apply_filters('', Array)\n#3 /Applications/mampstack-7.0.13-1/apache2/htdocs/challenge/chancetochallenge.com/wp-includes/plugin.php(453): WP_Hook->do_action(Array)\n#4 /Applications/mampstack-7.0.13-1/apache2/htdocs/challenge/chancetochallenge.com/wp-admin/admin-ajax.p in /Applications/mampstack-7.0.13-1/apache2/htdocs/challenge/chancetochallenge.com/wp-content/plugins/mailchimp-for-woocommerce/includes/vendor/queue/classes/worker/wp-worker.php on line 48, referer: https://localhost:8080/challenge/chancetochallenge.com/wp-admin/admin-ajax.php?action=http_worker&nonce=37bf53bb56

    I should say this only seems to have happened a couple of times, and the sync process has run after this without generating any log entries, but maybe the above could provide a clue.

    I reinstalled the plugin again. Here are screenshots of the process and the sync result. Please note that I left US as country by accident (and changed it immediately afterwards) but didn’t do that in the previous installs.

    https://postimg.org/gallery/31qwwfdmi

    Thread Starter simooo

    (@simooo)

    Hi Pearl,

    Just to be clear, the Sync button only disappeared after I reinstalled the plugin, so I’m not sure if it was related to the sync originally not working.

    However I can confirm that all store settings fields were filled out both before and after the reinstall, so in my case that probably wasn’t a part of the problem.

    I should mention again that it is syncing, it’s only the orders that are failing. Unfortunately this means that all customer appears as having never bought anything, so I’m worried this will mean I won’t be able to use MailChimp at all since it’s crucial that we can customise campaigns based on past purchases.

    Is it possible to log the syncing process? Maybe that way I can see what’s going wrong.

    Thanks!

    Thread Starter simooo

    (@simooo)

    Oh no worries!

    I was using the Twenty Seventeen theme which ships with WP.

    Just to be sure I’ve also done a narrower test case – I was previously using variable products with a booking add-on, plus PolyLang. Even though I ran tests with those plugins turned off, I’ve run additional tests with products created while they were turned off, i.e. just vanilla WooCommerce. Unfortunately the sync will still not process any orders, so the issue doesn’t seem plugin related.

    Let me know how it goes. Also, is it possible for me to activate any error logging or diagnostics on my side?

    Thanks!

    P.S. weirdly, after deleting and reinstalling the MailChimp for WooCommerce plugin the manual sync button is gone. Any idea why this could happen?

    Thread Starter simooo

    (@simooo)

    Hi Pearl,

    I’ve tried switching to the default theme and deactivating all the plugins bar WooCommerce and MailChimp for WooCommerce, but no luck unfortunately.

    Anything else I could try? You mentioned running some tests – any details or info I can send you to make that happen?

    Cheers,

    Simon

    Thread Starter simooo

    (@simooo)

    Hi Pearl,

    Thanks for the reply. Yes, the missing “for” was a typo (the full name of the plugin was in the full list of plugins at the bottom of the post).

    I’ve updated the plugin to the new version 1.1.1 and re-run the manual sync, however orders are still not syncing. Looking at a specific subscriber which should have an order associated with it I can see that the subscriber was updated in the last sync, but the e-commerce tab is empty.

    It’s my understanding that MailChimp support is only available for paid accounts, but maybe you could give me some pointers to where I can start digging on the plugin side to find the problem. Since most of the syncing (minus the orders) work I’m hoping it’s a small problem.

    Are there any conditions under which orders would not be synced? Is it possible that payments with price set to zero or that are paid through PayPal Sandbox are ignored?

    All the best,

    Simon

    Thanks so much Pearl. I’ve spoken to support and they confirmed that it is not possible to affect the language preference through a signup form field.

    If I can just quiz you for one more moment about what the plugin actually stores in the MailChimp database when a customer subscribes from the checkout form:
    It seems to me that it’s only name and email address, is that correct?

    Has there been any movement on this by any chance? Could really do with this feature too!

    Is there any way you could point me to a hook or filter, or anything I could use to include language in what’s imported to MailChimp from WooCommerce?

    A useful workaround would be if Country could be imported. That’s what I would use to create the language preference from anyway.

    EDIT: Or is there a way to have a hidden field in the checkout form (which I populate myself) that sets the language preference?

    Thanks!

    • This reply was modified 7 years, 8 months ago by simooo. Reason: Added the note about country
    • This reply was modified 7 years, 8 months ago by simooo.
    Thread Starter simooo

    (@simooo)

    Thanks!

    That code didn’t actually work for me, until I removed ‘parent’ on L59:

    59 if ($order->product->parent->product_type == 'registrations') {

    59 if ($order->product->product_type == 'registrations') {

    Not sure what could have changed to cause this.

    Either way can confirm that the formatting is applied to emails but, like you said, not to admin order screen and also not to PayPal checkout.

    Thread Starter simooo

    (@simooo)

    That’s great! In what file/files did you apply the fix? I was looking at the commits in the last month in github and couldn’t make out what the relevant commit was.

    Today I realised that another place where this happens is on the PayPal payments page (on PayPal’s site), but hopefully that’s already covered by your fix.

    Thread Starter simooo

    (@simooo)

    Turns out it was Polylang breaking the routing. It seems to be battling with WooCommerce and resulting in 404:s. For now using subdomains instead of “/en” etc at the end of the URL seems to solve the problem.

    Thread Starter simooo

    (@simooo)

    Fantastic, thank you!

Viewing 15 replies - 31 through 45 (of 49 total)