Forum Replies Created

Viewing 15 replies - 91 through 105 (of 154 total)
  • Thread Starter Pat K

    (@blackcapdesign)

    I don’t know how much more information I can provide. The currencies/amounts paid in all cases were correct; the business owner got paid in the correct currency. The problem was the currency code CAD / USD included in the “Thanks for your Order” email notifications issued by WC. Normally there is no currency code in these messages…it’s added dynamicall by the currency switcher plugin.

    In my case, the default currency in WC was CAD. The currency switcher converts to USD and EURO.

    When a USD order was placed there were no problems. The email notification indicated the value with the USD currency code, e.g. $100 USD.

    When a CAD order was placed, the email notification gave the correct dollar value in CAD, but the currency code in the email was USD, e.g. $100 USD when it SHOULD have been $100 CAD.

    Example: Mr. Foo Bar buys a widget for $100 CAD. The owner gets paid $100 CAD. But, when Mr. Bar receives his Thanks for your Order email notification, he is told that he paid $100 USD even though he actually paid $100 CAD. Very confusing for Mr. Bar, who contacts the owner to complain.

    Disabling the PayPal component that ships with WC and enabling express checkout using the PayPal for WooCommerce plugin resolved the issue. But I suspect this is going to be an issue for others using PayPal Standard that ships with WC.

    It will be interesting to see what happens when you test this live (not in the PP sandbox).

    Hope that helps…
    pk

    Thread Starter Pat K

    (@blackcapdesign)

    Hey xolite – you were 100% correct! Thanks again for the information & tip.

    I installed & configured PayPal Express Checkout using this plugin: https://wordpress.org/plugins/paypal-for-woocommerce/

    and deactivated PayPal Payments Standard that ships with WooCommerce, and it appears to have resolved the problem. I ran a series of test purchases and the WooCommerce generated email notifications were correct in each test (they show the correct currency codes – USD for US funds, CAD for Canadian funds and EUR for Euros).

    Although I’m marking this as “resolved” there still appears to be a problem somewhere with the default setup that warrants a closer look by the developer.

    Cheers,
    pk

    Pat K

    (@blackcapdesign)

    Hmmm. I’m Canadian, eh? And we spell it “cheque” regardless of whether you’re left or right of centre, or the colours in your particular rainbow.

    And despite having localization (with a “zed”) set to English (Canada), WooCommerce still wants me to accept checks, not cheques.

    Lorro – thanks for the plugin link!

    PK

    Thread Starter Pat K

    (@blackcapdesign)

    Hi xolite – thanks for checking! I’m still testing. On the advanced tab, I changed Price Conversion Method to Save Prices in Array and did a test purchase using a coupon I set up – and the email notifications generated by WooCommerce included the correct currency code. BUT since the order didn’t actually go to PayPal, as you pointed out, it may be a problem on the PayPal end (not returning the correct currency code).

    Unfortunately, the guy running the shop is away on holidays this week, so I can’t test it through PayPal until he gets back. He’ll have some orders by then so I’ll know whether changing the Price Conversion Method or PayPal is the culprit and I will report back.

    Thanks very much for the info…it confirmed my suspicion that it could be a PayPal problem!

    Thread Starter Pat K

    (@blackcapdesign)

    Hi Joe,
    Quick follow up on this. I finally found time to update and fix the missing event popup close icon.

    I have My Calendar installed on 3+ sites. On one, after the update, the dashicon showed up fine in red (parent theme Twenty Fourteen). On two others, (different parent themes: GeneratePress and Genesis) the icon was not visible (white font-color on a white background).

    In all 3 cases the rule is set in my-calendar/reset.css with the following ruleset:
    button.mc-toggle {
    color: #a00 !important;
    }

    But on 2 of the sites, the ruleset (oddly) was being overruled by the default button color (white) despite your !important declaration.

    I added the following to the child theme style.css file and the buttons are showing on both sites now:
    .dashicons-dismiss:before {
    color: black;
    font-size: 1.2em;
    }

    Hopefully this will help someone else whose close buttons have gone “missing”.

    Cheers, …and thanks Kilzac for the suggestion!
    PK

    Thread Starter Pat K

    (@blackcapdesign)

    Thanks xolite! Yes – all of that checks out, so it must be something else. Hopefully the developer can shed some light on this.
    pk

    Thread Starter Pat K

    (@blackcapdesign)

    Thanks for the response! One payment type: PayPal Payments Standard.

    There are no plugins manipulating the order emails. The following plugins for WC are in place:
    WC Products Slider (pickplugins)
    WC Menu Cart (Jeremiah Prummer, Ewout Fernhout)
    WC Extended Coupon Features (soft79)
    WC Canada Post Webservice Method (Jamez Picard)

    Also no custom functions in the theme/child theme that mess around with email notifications. And no template overrides.

    Parent theme is GeneratePress.

    Any suggestions are welcome!

    Thanks!!
    pk

    Thread Starter Pat K

    (@blackcapdesign)

    Thanks for that Joe. I ran the update and the popup and invisible close button renders the same as it did in v3.0.5. I haven’t had time to troubleshoot this yet but as soon as know why it’s doing this, I’ll report back.

    Thread Starter Pat K

    (@blackcapdesign)

    Thanks Joe,
    I didn’t have ample time to troubleshoot, so I rolled it back to v2.5.17, so sharing a link wouldn’t do any good. I’ll run the update again when I have time and will report back. Thanks for the CSS tip.

    Any thought on why the code is different in the new version. v2.5.17 shows an image icon; v3.0.5 showed a dashicon and no image (as the close button). Is that structural change part of the version 3 modifications?
    PK

    Pat K

    (@blackcapdesign)

    RE: “Please update BackWPUp to latest 3.5.1 version, the new version is just about 5mb”

    To clarify, the compressed file is 5mb, but unpacked it’s still 22mb.

    By comparison, version 4.5 of this plugin was 2mb compressed and under 5mb unpacked.

    I’m with David Decker in his original post; if this bloat continues, I will also be looking to replace BackWPup with a lighter, less bloated alternative.

    I will wait to see what happens with the next release.

    Pat K

    (@blackcapdesign)

    Yes, if you visit the plugin page (https://wordpress.org/plugins/wc-fields-factory/) and click “Advanced View”, at the bottom look for ‘Previous Versions’. Click the select arrow and you’ll see a list of all previous versions. V 2.0.7 is the one you want.
    Hope that helps…

    Pat K

    (@blackcapdesign)

    I am having the same problem. After processing the plugin update, the form can no longer be submitted. Error indicates ‘required fields’ must be filled although they were filled. Rolled back to previous version until this has been fixed.

    PK

    Thread Starter Pat K

    (@blackcapdesign)

    Excellent – thanks Barry! I look forward to it.
    PK

    Thread Starter Pat K

    (@blackcapdesign)

    Update! I double-checked the all the settings again after adding the custom function and noticed the Discount Type had changed to Percentage Product Discount. As soon as I changed it back to Percentage Cart Discount, it suddenly started working. Yay!

    I think this is resolved, but it would be great if you could confirm that the code snippet I added is required for this to work. This may come in handy for others with similar requirements.

    Cheers,
    PK

    Thread Starter Pat K

    (@blackcapdesign)

    I don’t mind at all; I’m happy to contribute.

    Cheers

Viewing 15 replies - 91 through 105 (of 154 total)