Recent Updates Toggle Comment Threads | Keyboard Shortcuts

  • Barry Kooij 4:01 pm on December 16, 2014 Permalink  

    WooCommerce 2.2.10 Fix Release Now Available 

    The WooCommerce 2.2.10 release is now available via WordPress.org or automatic update in your administration panel.

    This release fixes the ‘stock status issue on quick and bluk edit’ bug and the ‘incorrect clearing of error messages on checkout’ bug both introduced in version 2.2.9. You can view the full changelog here. A total of 8 commits made it into this release.

    (As always, the comments on this post are closed because this is not the right platform for support requests.)

     
  • Barry Kooij 2:09 pm on December 15, 2014 Permalink  

    WooCommerce 2.2.9 Fix/Security Release Now Available 

    The WooCommerce 2.2.9 release is now available via WordPress.org or automatic update in your administration panel. Thanks to all of our contributors who’ve been helping out.

    There were several fixes in this release, including sanitizing data correctly during registration and minor tweaks related to taxes. Read more about the fixes in the changelog. A total of 66 commits made it into this release.

    (As always, the comments on this post are closed because this is not the right platform for support requests.)

     
  • Mike Jolley 4:49 pm on December 12, 2014 Permalink | Reply
    Tags: coupons, tax,   

    Upcoming Coupon Changes in WooCommerce 2.3 

    For 2.3, aside from UI, we’ve been looking at some long standing issues. One of these issues related to the display of coupons when prices include tax (#4848). Although complex, this issue has been resolved in 2.3 without too much change, however, this also got us looking at this point raised by Samuel Aguilera:

    Apply discounts after taxes is not legal. Discounts must be always applied before taxes, is the law, not user preference.

    If you’re not aware, up to now the coupon system has always had an option at coupon level called “apply before tax” which, as stated, makes sure a coupon is calculated before tax at line-item level. Leaving the box unchecked would take the discount off after all taxes – so in reality we had 2 different types of coupons (before tax – cart, after tax – order) each with their own methods and display related functions.

    In 2.3 we’ve decided to simplify this down, have 1 set of coupons, and always apply them before-tax. See #6830.

    So What Has This Been Changed?

    • Apply Before Tax option removed from coupons
    • WC_Cart::get_coupons() which used to allow you to pass either ‘cart’ or ‘order’ has deprecated the type arg. If you pass in ‘order’ an empty array is returned.
    • WC_Cart::remove_coupons() same as above.
    • Deprecated some coupon methods in the cart and orders class:
      • WC_Cart::get_order_discount_total()
      • WC_Cart::apply_cart_discounts_after_tax()
      • WC_Cart::apply_product_discounts_after_tax()
      • WC_Cart::get_discounts_before_tax()
      • WC_Cart::get_discounts_after_tax()
      • WC_Abstract_Order::get_cart_discount()
      • WC_Abstract_Order::get_order_discount()
      • WC_Abstract_Order::get_cart_discount_to_display()
      • WC_Abstract_Order::get_order_discount_to_display()
    • $discount_total variable in cart class is deprecated (was after tax discount total) and will always be 0.
    • templates/cart/cart-totals.php has been edited to remove the after-tax discounts
    • templates/checkout/review-order.php has been edited to remove the after-tax discounts
    • Removed the edit ‘discount’ row from the edit orders panel in the backend – discounts are applied per line item (before tax!)

    WC_Cart::get_total_discount() should be used if you need to get the discount amount, instead of the deprecated methods. This method exists in 2.2.

    WC_Cart::get_discount_to_display() should be used to display the discount amount. This is a new method in 2.3

    What Theme Developers Need to Update

    Themes will need to update their template files, namely:

    1. templates/cart/cart-totals.php
    2. templates/checkout/review-order.php

    They will need to remove the second coupon/discounts loops (order level coupons). Failure to update won’t break anything however, it will just show a deprecated notice.

    What Plugin Developers Need to Update

    Remove the use of dedicated methods, and avoid accessing properties directly where possible. This update has deprecated methods and thus shouldn’t ‘break’ plugins, but it will render some functionality useless, such as code which checks for after-tax discounts.

    If you do notice something not backwards compatible (in that it causes error) will let us know asap.

     

     
    • Simon 9:42 pm on December 12, 2014 Permalink | Reply

      Changing coupons like that is going to cause massive issues for people in Australia.

      Australians who buy retail (from Australian stores – online or otherwise) don’t even know what the pre tax price is.

      And any discount to a price is always off the total price – not pre tax.

      So Australian stores aren’t going to be able to upgrade until either –
      A) you implement a checkbox to apply to total price (effectively the reverse of what was previously implemented)
      B) someone else creates a plugin / snippet to have coupons apply to total pricing.

      Could you reply to this comment and let the Australian store owners what they should do as a matter of priority please.

      Simon

      • Gabriele 11:59 pm on December 12, 2014 Permalink | Reply

        I agree with Simon, the same in Italy (and I presume the whole EU) !
        Private clients, not business, don’t care about taxes (TVA), they always see the total price.

      • Simon 1:10 am on December 13, 2014 Permalink | Reply

        Or (though I doubt likely) even better just leave it the way it was so I don’t have to change anything or educate clients and make amendments to their sites.

        Ps my email was incorrect in the original post, it’s correct in this one.

      • Mike Jolley 9:38 am on December 15, 2014 Permalink | Reply

        > And any discount to a price is always off the total price – not pre tax.

        Maybe it would help if I clarify how ‘before tax’ coupons work with ‘prices inclusive of tax’. I don’t think it will be an issue for you. And if it is, you may be doing it wrong currently.

        Lets take a $10 product, inc tax. Tax rate for this example can be 10%.

        Ignoring coupons for the moment, that would give us a $10 sale with $0.91 tax (the sum for that is 10-(10/1.1)).

        Now lets use a $5 coupon. This time we’d have 10 – 5 = $5 sale, and then we’d work out tax at being $0.46.

        In the previous system, with an after tax coupon you’d be charging the same amount ($5) but tax would be miscalculated as 0.91 still, since that would be calculated before discount. This is wrong and thus removed.

        I think the confusion stems to the ‘before tax’ wording; we’re talking about where the discount and tax calculation take place, we are not talking about which price gets discounted initially. Another ++ for removing it.

        @Gabriele I am in the UK and our implementation is correct.

        • Simon 12:27 am on December 16, 2014 Permalink | Reply

          @Mike – perhaps the wording had me confused.

          If it works the way you put forward then that makes sense at a product level.

          Would it the. work the same way on total order amounts as well?

          That’s something I’ve had trouble with in the past – if a total order is $100 inc tax and a $10 coupon is applied to the order then the order total will be $90 inc tax of 8.18 as tax is applied to the overall order.

          … assuming all items are taxable – which sometimes they aren’t eg credit card fees. If there were credit card fees of $2 (and that was fixed for the sake of the example) on the above order the total would be $90, but tax would be only on $88 so $8 tax on the total order.

          Also we use store credit as per @Doug – it would be used toward the total order amount – not pretax. Eg $100 order inc tax paid for with a $100 store credit would yield a nil balance (ie not a $9.09 credit for unpaid tax component).

          • Mike Jolley 9:53 am on December 16, 2014 Permalink | Reply

            The store credit implementations I am aware of work like the before-tax coupons. So the actual discount is reflective of whether prices include tax or not, to avoid having to pay tax when there is a 100% discount.

            > That’s something I’ve had trouble with in the past – if a total order is $100 inc tax and a $10 coupon is applied to the order then the order total will be $90 inc tax of 8.18 as tax is applied to the overall order.

            A 100 – 10 order would be 8.18 tax. If you had extra non-taxable fees, these would need adding via the fee system where taxes are optional. Regardless of whether its a product or ‘cart’ discount, the discounts are applied at line-item level to accommodate this.

    • Sarah 4:13 am on December 13, 2014 Permalink | Reply

      I agree with Simon. The same applies in New Zealand – prices for all retail consumer goods are required to be displayed tax-inclusive, and any discounts would be presumed to apply to the after-tax price. Any company that advertised a discount coupon and then only applied that to the pre-tax price would be considered deceptive and probably to have breached our Fair Trading Act.

      However, I wonder if the intention is for the original functionality to be immediately available as a paid plugin, so that we will now have to pay extra for what was previously included functionality?

    • Doug Smith 9:04 pm on December 13, 2014 Permalink | Reply

      The coupon system can be used to offer different kinds of things with different tax requirements, depending on what extensions may be installed. For example, WooThemes sells the Smart Coupons extensions, which adds the ability to issue gift certificates, vouchers, and store credit.

      In the USA, we would apply a coupon before tax is calculated, as was described. That makes sense because the product is being sold at a lower amount and tax is based on that.

      However, a store credit is treated more like cash. It is sort of like a payment being applied toward the order rather than a discount of an item. So sales tax must be calculated before that credit is applied.

      Both of those scenarios are all handled by the coupon system so it sounds like this change would take away the ability to handle the latter correctly.

      • Mike Jolley 9:51 am on December 15, 2014 Permalink | Reply

        > However, a store credit is treated more like cash. It is sort of like a payment being applied toward the order rather than a discount of an item. So sales tax must be calculated before that credit is applied.

        Do you have anything to back that up? I don’t know if you can say they are “like” cash unless they are cash.

        I cannot find any particular US examples, but I think in logical sense these should still be handled before tax. Why? Sales tax was already taken for the original sale. Giving store credit isn’t a refund.

    • patrick 5:46 pm on December 15, 2014 Permalink | Reply

      @Doug – When I use gift certificates in the states they don’t charge sales tax. Last year I used a $200 Best Buy gift certificate to buy $200 in App Store gift certificates. No tax.

    • Doug Smith 3:26 pm on December 18, 2014 Permalink | Reply

      @Mike, You are correct in that we need to make sure not to double tax.

      However, when gift cards or certificates are sold they are not taxed in the United States. It is treated as an exchange of cash for cash equivalent. You are then taxed on the purchase of any items, based on the tax rates for those items and the tax rates of the state that has jurisdiction for that purchase.

      That is important because you could buy a gift certificate in one state and use it for a purchase in another state with a different tax rate. Or you may use a gift certificate to buy items that have different tax rates. For example, some states have a different tax rate for food items vs non-food items.

      The only way that can work out is if the tax is applied on the items purchased with the gift certificate treated as cash. I’ve quoted the rules from a few states below to show that is the case. As far as I know, this is the same in every state.

      @Patrick, You were using a gift certificate (cash equivalent) to purchase more gift certificates (cash equivalent) so tax would not be charged. You would be taxed when using either of those to later purchase tangible goods, just like if you purchased them with cash. Depending on the state having jurisdiction, you may or may not be charged tax if you use them to purchase digital, virtual goods.

      Samplings from a few states’ rules:

      Pennsylvania
      Gift certificates are treated the same as cash. At the time of purchase, the gift certificate is not subject to sales tax. If the gift certificate is used to purchase taxable items, sales tax will be charged in conjunction with this transaction.
      https://revenue-pa.custhelp.com/app/answers/detail/a_id/1921/~/is-the-sale-of-a-gift-certificate-taxable

      Washington
      Taxes are due when the gift card/certificate is redeemed by the holder. When the card/certificate is used, the taxes due on the sale depend on the nature of the item or service purchased
      http://dor.wa.gov/Content/GetAFormOrPublication/PublicationBySubject/TaxTopics/GiftCertLayaway.aspx

      Connecticut
      Cash equivalents are items purchased that entitle a person to redeem them in the future to receive tangible personal property or services. Examples of cash equivalents include, but are not limited to dine out cards, entertainment coupon books, vouchers, gift certificates, and trading stamps (whether or not the items are called coupons). Cash equivalents are deemed to be intangible rights to acquire tangible personal property or services in the future and thus are not taxed when acquired. However, the redemption of a cash equivalent is taxable based on the retail price of the tangible personal property or services for which the cash equivalent is redeemed.
      http://www.ct.gov/drs/cwp/view.asp?A=1511&Q=395808

      Illinois
      The sale of a gift certificate is not subject to Illinois sales tax. A gift certificate is an ‘intangible’ which is not taxed under the Retailers [sic] Occupation Tax Act. 86 Ill. Adm. Code 130.120(a). See also ST 02-0036-GIL (Feb. 7, 2002). Rather, if a gift certificate is redeemed for tangible personal property to be used in Illinois, Use Tax is due on the selling price of the tangible personal property purchased, whether partially or wholly funded by the gift certificate. ST 06-0125-GIL (Jun. [sic] 7, 2006), ST 02-0036-GIL (Feb. 7, 2002), ST 95-0331-GIL (Aug, 10, 1995).
      http://tax.illinois.gov/LegalInformation/LetterRulings/st/2004/sg040192.pdf

  • jameskoster 5:04 pm on November 19, 2014 Permalink | Reply
    Tags:   

    Attention theme authors. Frontend changes ahead in WooCommerce 2.3. 

    The Handsome Hippo is strutting along nicely and the release is beginning to take shape. As the name suggests the main focus for this release is UI and UX beautification which will result in some significant changes to the frontend design.

    Depending on how your theme integrates with WooCommerce, this could have a big impact on your product so we strongly recommend that you begin testing/playing with the bleeding WooCommerce version ASAP.

    In this post I’ll list many of the changes we’re making, but keep in mind that it’s not final. More things might change before release so please keep up to date. Check early and check often!

    For themes that provide a deep integration with WooCommerce (IE remove our CSS in favour of enqueueing their own) things will be simpler. But you may still wish to add some styles for new / tweaked elements.

    For themes that simply overwrite our bundled CSS (please stop doing this, guys) and/or template files, things could be more complicated. You will need to work through your theme accordingly paying close attention to all details.

    The list

    • All design elements now feature a ‘flat’ design ensuring WooCommerce provides a modern aesthetic that blends nicely with many theme styles. Check:
      • Messages
      • Buttons
      • Tabs
      • Demo store notice
      • Sale flashes
      • Price Slider widget
      • Payment box at checkout
    • Frontend style settings (allowing folks to change button colors etc) have been removed in favour of a separate plugin. If your theme interacted or relied on these settings keep an eye out for the upcoming plugin.
    • The increment and decrement buttons attached to quantity inputs have been removed now that support of input type="number" is more widespread. A separate plugin will be released for folks who want to add this back in.
    • The ‘Proceed to checkout’ button on the cart has been moved and is now located beneath the cart totals. Obviously this is a crucial design element so if your theme overwrites any cart template files please double check this. We’ve tried to make this change as backwards compatible as possible, though.
    • In the cart widget, it is now possible to remove products.
    • WooCommerce now loads dashicons for the animated loading graphic used by blockUI. Feel free to utilise this without enqueueing it separately.
    • Some tables have been made responsive such as the orders table on the my-account page. If you want to add style for this to your theme, activate Twenty Twelve and check the core CSS used to achieve responsive tables. The class .shop_table_responsive has been added for this purpose.

    Hopefully this gives you guys a heads up on what’s happening on the frontend of WooCommerce 2.3. I highly recommend that any theme authors start looking at this as early as possible, even before we enter the beta stage.

    As I said earlier, themes that simply overwrite our own CSS will be most affected by these changes. To re-iterate, this is a bad practise that we do not recommend. Why not make the switch and do things properly now? :-)

     
    • Rafael Angeline 9:54 pm on November 19, 2014 Permalink | Reply

      Hi!

      Do you guys have an estimative of when will it be avaliable to public download?! This way I can alocate my team properly to migrate to this new version.

      Kind Regards.

    • Bryce 1:25 am on November 20, 2014 Permalink | Reply

      Hey Rafael. You’d be able to download the latest working copy here – https://github.com/woothemes/woocommerce

      When the Beta Release is ready, we’ll post about it here.

      • Rafael Angeline 4:28 am on November 20, 2014 Permalink | Reply

        Thank you Bryce!

        Well, it’s better already prepare to do some work hehehe

        Kind Regards.

    • Haris 12:32 pm on November 20, 2014 Permalink | Reply

      Hey Bryce,

      Any timeframe for the final release ?

      • jameskoster 5:49 pm on November 20, 2014 Permalink | Reply

        Nothing definitive. We’ll say Q1 2015 for now :-)

    • Brian Krogsgard 10:07 pm on November 20, 2014 Permalink | Reply

      WooCommerce now loads dashicons for the animated loading graphic used by blockUI

      Can you explain this further or screenshot what you mean? Is this the only Dashicon used? And it’s front-end? Seems a wasted font load if so. I’d think SVG would be better if possible. unless I’m thinking of the wrong thing.

      • jameskoster 6:50 pm on December 2, 2014 Permalink | Reply

        Frontend and backend. We use a couple of the arrow icons on the frontend as well. You might be right that it’s not the best use of resources, could switch to svg if we don’t peruse any other icons during the design tweaks.

    • Janae 4:50 pm on November 22, 2014 Permalink | Reply

      I have a question regarding your statement:

      “As I said earlier, themes that simply overwrite our own CSS will be most affected by these changes. To re-iterate, this is a bad practise that we do not recommend. Why not make the switch and do things properly now?”

      I’ve only built a single theme, based on the design for my husband’s website. It was my first crack at it, and I’m not sure I did everything properly.

      For the CSS styles, I essentially copied the entire contents of the woocommerce.css file and pasted it at the end of my own styles.css file and just made adjustments as necessary to fit my overall theme design. Is that the bad practice you speak of? :) If so, how can I fix it?

      I’ve also copied certain template files and placed them in a ‘woocommerce’ folder in my theme folder to overwrite woocommerce plugin template files, again, to better fit my theme design. Is this also bad practice?

      I don’t pretend to be the best at theme development, or even code, but I do want to be sure I’m doing the best I can at doing it properly.

      • Janae 2:41 am on November 27, 2014 Permalink | Reply

        Anyone? :(

      • Mike Jolley 7:15 pm on November 28, 2014 Permalink | Reply

        I believe James was mostly referring to commercial themes which add/override styles rather than defining their own CSS and de-enqueueing ours.

        This doc shows hows to de-enqueue our styles completely http://docs.woothemes.com/document/disable-the-default-stylesheet/

        • Janae 5:53 pm on November 30, 2014 Permalink | Reply

          Thanks Mike! Still a newb. :)

      • jameskoster 6:54 pm on December 2, 2014 Permalink | Reply

        As long as you dequeued the WooCommerce core css (no point loading it twice) this is not bad practise. You should still check your site though as some elements have moved and your selectors might need a tweak.

  • claudiosmweb 3:00 pm on October 29, 2014 Permalink  

    WooCommerce 2.2.8 Fix/Security Release Now Available 

    The WooCommerce 2.2.8 release is now available via WordPress.org or automatic update in your administration panel. Thanks to all of our contributors who’ve been helping out.

    There were several fixes in this release, including a minor security fix for nonce check in form handler. Read more about the fixes in the changelog. A total of 25 commits made it into this release.

    (As always, the comments on this post are closed because this is not the right platform for support requests.)

     
  • patrick 8:00 am on October 23, 2014 Permalink | Reply
    Tags:   

    WC 2.3 Email Class Refactor and Enhancements 

    WooCommerce 2.3 is still a ways out, but one of the things we’ve been working on is a better email class system in core. Primarily, we’ve refactored how emails are sent through WooCommerce. Any extension can send a WC branded email by loading the mailer and calling the send method. Like so:

    // set subject
    $subject = 'WC Send Mail Test';
    
    // load the mailer
    $mailer = WC()->mailer();
    $mailer->send( get_option( 'admin_email' ), $subject, $mailer->wrap_message( $subject, 'a test message' ), '', '' );
    

     

    WooCommerce Test Email

    An email sent via the refactored send() method

    The wrap_message() function wraps the email in the WooCommerce branding. If you want to send an email without any WooCommerce branding you can do so by not using the wrap_message() function.

    WooCommerce Email Without Branding

    An email without any WooCommerce branding

    A CSS Inliner for Prettier Email

    If you’ve ever spent time customizing an email template you know how awful it is to work with different email clients and how none of them support regular CSS. This is a pain for developers and really confusing for end users. After refactoring the send methods we were able to add a CSS inliner. This will take regular CSS and rewrite it so that each element has the styles written inline. This prevents a lot of problems with email clients.

    A New Way to Customize Email CSS

    We used to have all of the CSS in the email-header.php template which was convenient programmatically but a bit confusing for users. We took all of this CSS and put it into it’s own template. An end user can now override the email-styles.php template.

    A New Way to Customize Email CSS for Developers

    Overriding templates is great for end users but it’s not great for developers. If you want to write a plugin that changes the email styles you can use the new woocommerce_email_styles filter. I’ve made an example plugin that shows how to use this filter.

    If you want to test this new functionality yourself it’s merged into the master branch of WooCommerce on GitHub.

    Happy emailing!

     
  • Mike Jolley 12:23 pm on October 22, 2014 Permalink
    Tags:   

    WooCommerce 2.2.7 Fix/Security Release Now Available 

    The WooCommerce 2.2.7 release is now available via WordPress.org or automatic update in your administration panel. Thanks to all of our contributors who’ve been helping out.

    There were several fixes in this release, including a minor security fix for an XSS issue when using product notes. Read more about the fixes in the changelog. A total of 58 commits made it into this release.

    (As always, the comments on this post are closed because this is not the right platform for support requests.)

     
  • Mike Jolley 8:53 pm on October 8, 2014 Permalink
    Tags:   

    WooCommerce 2.2.6 Fix Release Available 

    The WooCommerce 2.2.6 release is now available via WordPress.org or automatic update in your administration panel. This fixes a few small notices and a bug around editing order addresses in the backend.

    You can read more about the changes in the changelog. A total of 10 commits made it into this release.

    (As always, the comments on this post are closed because this is not the right platform for support requests.)

     
  • Mike Jolley 4:39 pm on October 7, 2014 Permalink
    Tags:   

    WooCommerce 2.2.5 fix release is now available 

    The WooCommerce 2.2.5 release is now available via WordPress.org or automatic update in your administration panel. Thanks to all of our contributors who’ve been helping out.

    There were several minor fixes in this release which you can read about inside the changelog. A total of 130 commits made it into this release.

    (As always, the comments on this post are closed because this is not the right platform for support requests.)

     
  • Mike Jolley 2:02 pm on October 7, 2014 Permalink  

    Roadmapping Core via Trello 

    Up until now ideas and roadmapping in general have been spread out across several places; todo lists, a GitHub Wiki page, within old GitHub issues, an ideas board, even private Google docs. As you can imagine, this was a nightmare to manage, let alone do any useful planning.

    In an attempt to rectify this, we’ve decided to unify our Roadmap into a single Trello board; the WooCommerce roadmap.

    The WooCommerce Roadmap

    The WooCommerce Roadmap

    Inspired by this post on the Trello blog, the board is public with voting enabled and can be used by anyone. Log ideas, comment, and vote on everything.

    So what will we use this Roadmap for? Many things!

    • Getting feedback from devs and power users
    • Prioritising things developers need via card voting
    • Interacting with the community
    • Submitting ideas to core
    • Giving brave developers some hardcore issues to work on, or think about which are not planned in the short term
    • Organising ideas into future milestones
    • Separating add-on ideas from core-worthy ideas

    How does this fit in with Github you ask? Well, Github should be used for issues we definitely need or want to work on short term. Bugs for example will still go to Github. Feature requests (or larger ideas for the medium to long term) can go to the Roadmap for feedback and voting.

    The Trello board is open now and has been populated with the old roadmap items from the (no defunct) Github wiki. See you there!

     
c
Compose new post
j
Next post/Next comment
k
Previous post/Previous comment
r
Reply
e
Edit
o
Show/Hide comments
t
Go to top
l
Go to login
h
Show/Hide help
shift + esc
Cancel