Recent Updates Toggle Comment Threads | Keyboard Shortcuts

  • Mike Jolley 4:09 pm on January 30, 2015 Permalink | Reply
    Tags:   

    2.3 Handsome Hippo Beta 3 

    Today we put out WC 2.3 Beta 3 which fixed several issues and oversights in beta 2. This should hopefully be the final beta before release.

    Changes Since Beta 2

    You can view a comparison between beta 2 and master here, but notable changes include:

    Help Translate 2.3

    The latest 2.3 POT files have been pushed to Transifex meaning you can get involved in the translations here: https://www.transifex.com/projects/p/woocommerce/

    Download the Latest Beta

    We’re happy to listen to your feedback regarding 2.3 and would appreciate any bug reports going directly to Github.

    Download 2.3 Beta 3

    If you find a bug with the beta, please ensure you prepend the ticket title with [2.3] when submitting the issue to GitHub, or at least mention what version you are using in the ticket description.

    Thanks again.

     
  • claudiosmweb 3:55 pm on January 29, 2015 Permalink  

    WooCommerce 2.2.11 Fix/Security Release Now Available 

    The WooCommerce 2.2.11 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 some fixes in this release, including escaping urls before display in admin and frontend to avoid XSS and minor tweaks. Read more about the fixes in the changelog. A total of 6 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 3:29 pm on January 26, 2015 Permalink | Reply
    Tags:   

    2.3 Handsome Hippo Beta 2 

    Work continues on 2.3 and we’re getting closer to the final release. We’re expecting to have a release candidate out within a week, so don’t forget to test your extensions and themes!

    Changes Since Beta 1

    You can view a comparison between beta 1 and master here, but notable changes include:

    • Added the WC Tracker (opt-in usage tracking)
    • Added additional filters/args to wc_price function and added functions to get things such as the decimal separator (wc_get_price_thousand_separator, wc_get_price_decimal_separator, wc_get_price_decimals)
    • Fixed issues showing variation prices when free
    • wc_format_content() function to work around some theme conflicts
    • PDT vs IPN option in PayPal standard

    We’ve also updated the API docs here: http://docs.woothemes.com/wc-apidocs/

    Help Document the REST API

    We now have a Github Repo for the REST API Docs where you are welcome to make contributions. We’re using Slate to generate the actual documentation from this repo.

    The generated REST API Docs can be found here: http://woothemes.github.io/woocommerce-rest-api-docs/

    Help Translate 2.3

    The latest 2.3 POT files have been pushed to Transifex meaning you can get involved in the translations here: https://www.transifex.com/projects/p/woocommerce/

    Download the Latest Beta

    We’re happy to listen to your feedback regarding 2.3 and would appreciate any bug reports going directly to Github.

    Download 2.3 Beta 2

    If you find a bug with the beta, please ensure you prepend the ticket title with [2.3] when submitting the issue to GitHub, or at least mention what version you are using in the ticket description.

    Thanks again.

     
    • Jami Gibbs 5:59 pm on January 26, 2015 Permalink | Reply

      Stoked! :)

      Just a head’s up that wooocommerce.php is still showing version as: 2.3-beta-1

  • Mike Jolley 1:10 pm on January 14, 2015 Permalink | Reply
    Tags: ,   

    2.3 Handsome Hippo Beta 1: Release and Highlights 

    This week we’re happy to announce WC 2.3 “Handsome Hippo” beta 1 is available for testing.

              ╭────────────╮
      ^oo^    ┃  Woo! 2.3  ┃
      (..)    ╰─y──────────╯
     ()  ()
     ()__()
    

    Since 2.2 we’ve had a humongous 1389 commits. You can view the changelog here and see what we’ve been busy working on: https://github.com/woothemes/woocommerce/blob/2.3.0-beta-1/readme.txt#L133

    Before going into the features, developers should be aware of the following changes which we’ve been covering in other posts:

    1. Changes to the coupon systemhttp://develop.woothemes.com/woocommerce/2014/12/upcoming-coupon-changes-in-woocommerce-2-3/
    2. Changes that affect theme authorshttp://develop.woothemes.com/woocommerce/2014/11/attention-theme-authors-frontend-changes-ahead-in-woocommerce-2-3/
    3. Changes in Email templateshttp://develop.woothemes.com/woocommerce/2014/10/2-3-emails/
    4. Chosen has been replaced with Select2 – Chosen is still registered in WooCommerce for now, but plugins should migrate to Select2 as soon as possible (select2 has a larger community behind it).

    Aside from the countless fixes and tweaks, here are a few of the key features in 2.3.

    An Overhauled UI

    James Koster has been busy closing UI related issues in 2.3, and UI was the main focus of the release. We’ve updated the user interface on both the front and backend of WooCommerce.

    On the backend, settings have been re-organised and perform better on hand-held devices for an all round improved user experience.

    On the frontend there are several UX enhancements such as the undo-remove-from cart link and responsive table design as well as a fresh, modern look which meshes more fluidly with the current design trends of default WordPress themes.

    Changes to the UI have been covered in more detail in this post.

    A UI for Webhooks

    Webhooks were introduced in our API in version 2.2 but where hidden from view (and only added via the API). Claudio Sanches has been busy fleshing out a UI for the Webhook system in 2.3 which will allow adding, removing, editing and viewing logs for webhooks.

    Webhooks make it easier for 3rd party apps to integrate with WooCommerce so the way should be paved for some interesting new services in the future.

    Geo-Location Features

    Whilst implementing solutions for the infamous EU VAT Changes, it became apparent that some users require that prices be shown to users with their local taxes reflected in the store. Therefore I began work on a geo-location solution for core.

    In 2.3 we’ve introduced a geolocation class which optionally allows you to set the default customer location to their actual location which will affect both:

    • Taxes shown to the user
    • The default state of the country selection box during checkout

    The class uses MaxMind’s geolite database, has fallbacks for several API based geo-location services, and works locally by using some IP lookup services when required.

    Unit Tests

    Although early days, some of our contributors, including new boy Barry Kooij, have been working on adding Unit Tests to WooCommerce. The code coverage should increase over time, but this is a big step forward in 2.3.

    Downloading the Beta

    Download 2.3 Beta 1

    If you find a bug with the beta, please ensure you prepend the ticket title with [2.3] when submitting the issue to GitHub, or at least mention what version you are using in the ticket description.

    Also when reporting anything to us:

    1. Describe the issue in detail, with a system status report
    2. Don’t report issues with extensions, only core
    3. Don’t report issues with themes
    4. Report bugs, not feature requests

    Thanks!

     
    • Dennis 4:13 am on January 15, 2015 Permalink | Reply

      Hi All,

      Is there a list with all of the deprecated functions/filters in 2.3? I just found that the “add_to_cart_fragments” filter has been deprecated, but I didn’t see that listed anywhere.

      Thanks!

    • Justin 2:04 pm on January 15, 2015 Permalink | Reply

      Any rough estimate for a release date?

    • Ross 5:18 pm on January 23, 2015 Permalink | Reply

      Any idea on when beta-2 will be released Mike? Cheers mate! :)

    • Vivian Vu 4:41 am on January 26, 2015 Permalink | Reply

      Hi Mike,
      Thank you for the sum up of new features in WC 2.3. However could you please explain to me what is Unit tests feature about as I’m going to write about WC 2.3 beta? I’m not really clear about what this features does.
      Thank you in advance!

  • 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

      • Mike Jolley 1:58 am on December 20, 2014 Permalink | Reply

        Do you use an extension for gift certs? If the above turns out to be the case, perhaps this should be handled in the gift cert extension. I’d much prefer that than keeping the 2 levels of coupon we have in 2.2. cc @patrick

        • Doug Smith 3:29 pm on December 20, 2014 Permalink | Reply

          Yes, I’m currently using the Smart Coupons extension for gift certificates and store credit. I believe the PDF Product Vouchers extension would also be affected by this. I’m sure there are other extensions outside of the WooThemes store that would have to be updated as well. I know there are several over at Code Canyon, for example.

          • Mike Jolley 11:15 pm on December 20, 2014 Permalink | Reply

            I’m going to double check with Nirav, but I think that extension already handles this outside of the coupon system.

    • Justin 2:00 pm on January 15, 2015 Permalink | Reply

      There is also a TON of custom plugin code written for various sites operating the USA and other countries to handle “same as cash” gift codes / store credit issuance via coupon codes.

      Sometimes the overall operation of such a coupon code needs to be changed due to changes in localized tax laws. Right now that is easy: Change the setting on the coupon for when to apply the credit: before tax or after tax.

      The overall problem, in the USA at least, is that government is structured so that there is a federal level with laws, then state level with laws, then counties with laws, then cities or municipalities with laws – and depending on the upstream laws the downstream entities may or may not have the right make changes. So for example, in one city in the same county a law might read “X” for example, while 1 mile down the road in another city that same law might have been amended to ready “Y” because that’s what the city decided as there was nothing in upstream laws preventing them from amending.

      It’s probably a good idea to leave the setting in place otherwise legislators might do something that causes an entire site to operate incorrectly resulting in some seriously pissed off WooCommerce users. In other words, give the site operators a choice via settings, even if you change the default behavior in the core code, at least the site ops can make a simple setting adjustment to meet ever changing legal landscape.

      The overall situation is this from a site operator’s perspective: Yes a developer can go in and change code, and subsequently charge a customer for that work. And invariably they get upset about having to constantly spend money on things that ought to exist in a simple setting – not to mention the fact that a developer can’t always adjust their code immediately. Which of course reflects badly on WooCommerce itself, particularly when they’ve been using a setting for 3 years that suddenly vanishes…

  • 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.

    • Dovy Paukstys 4:51 pm on January 20, 2015 Permalink | Reply

      Why not just put a conditional on your front-end JS for 3.8 so spinners are not destroyed for all? Here’s working code I just added, but I’d rather have it be part of Woo because it’s woo stuff. Much better than an extra “plugin.” https://gist.github.com/dovy/03bb1e04d5c3585a71c2

  • 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!

     
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