Recent Updates Toggle Comment Threads | Keyboard Shortcuts

  • Mike Jolley 1:44 pm on August 19, 2014 Permalink | Reply
    Tags: ,   

    2.2 Prowling Pangolin Beta 2 

    Work continues on 2.2 and we’re getting closer to an end-of-month release. 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:

    • Prefixed get_order() to make wc_get_order()
    • Prefixed get_product() to match – wc_get_product() (soft deprecated)
    • Added info about the refunder in the backend refund system
    • Fixed stock logic for parents and children variations
    • Added some backwards compatibility for the new shop order statuses to prevent old style get_post queries breaking
    • max amount option for coupons
    • Deprecated Mijireh gateway
    • Added Simplify Commerce gateway
    • Added a 3rd parameter on the process_refund() method for $reason
    • Refund API

    Help translate 2.2

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

    Thanks to everyone who submits a translation!

    Download the latest beta

    We’re happy to hear your feedback about 2.2 and would appriciate any bug reports going directly to Github.

    Download 2.2 Beta 1

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

    Thanks again.

     
  • Mike Jolley 3:06 pm on August 7, 2014 Permalink | Reply
    Tags:   

    WC 2.2 order statuses: plugin compatibility 

    Orders can have several statuses in WooCommerce; completed, processing, on-hold, pending to name a few.

    In WooCommerce 2.1, statuses were associated with orders via a taxonomy called shop_order_status. The shop_order_status taxonomy is no more in 2.2.

    Instead, 2.2 uses post_status for the order status. In terms of usage, this makes more sense – regular post statuses are of little use for orders (since when did you have a non-published order?). For performance, using post status has several benefits, particulary to queries and reporting which can now contain less table joins.

    How does this affect developers? If you query shop_order posts via a get_posts() function, or DB query, you will need to modify your code to fully support 2.2. Otherwise you’ll either get a notice, or no results.

    If you are calling get_posts() for the shop_order post type

    Here is an example of a 2.1 order query:

    $orders = get_posts( array(
            'post_type'   => 'shop_order',
            'post_status' => 'publish',
            'tax_query'   => array( array(
                    'taxonomy' => 'shop_order_status',
                    'field'           => 'slug',
                    'terms'         => array( 'processing', 'completed' )
            ) )
    ) );

    This query uses shop_order_status which will no longer work in 2.2 without throwing a notice. For 2.2 you’d change this to be:

    $orders = get_posts( array(
            'post_type'   => 'shop_order',
            'post_status' => array( 'wc-processing', 'wc-completed' )
    ) );

    If you wanted to get all orders, of any status, 2.2 has a function wc_get_order_statuses() which returns all registered order statuses:

    $orders = get_posts( array(
            'post_type'   => 'shop_order',
            'post_status' => array_keys( wc_get_order_statuses() )
    ) );

    If you are doing $wpdb queries on shop_order posts

    Like above, you’ll need to change the taxonomy part of your query. Here is an example from 2.1:

    $sales = $wpdb->get_var( "SELECT ID FROM {$wpdb->posts} as posts
                LEFT JOIN {$wpdb->term_relationships} AS rel ON posts.ID=rel.object_ID
                LEFT JOIN {$wpdb->term_taxonomy} AS tax USING( term_taxonomy_id )
                LEFT JOIN {$wpdb->terms} AS term USING( term_id )
                WHERE   posts.post_type     = 'shop_order'
                AND     posts.post_status   = 'publish'
                AND     tax.taxonomy        = 'shop_order_status'
                AND     term.slug           IN ( '" . implode( "','", array( 'completed', 'processing', 'on-hold' ) ) . "' )
            " );

    In 2.2, this becomes:

    $sales = $wpdb->get_var( "SELECT ID FROM {$wpdb->posts} as posts
                WHERE   posts.post_type     = 'shop_order'
                AND     posts.post_status   IN ( '" . implode( "','", array( 'wc-completed', 'wc-processing', 'wc-on-hold' ) ) . "' )
            " );

    Direct queries on the database will need to be updated, or no results will be returned.

     
  • Mike Jolley 3:55 pm on August 5, 2014 Permalink | Reply
    Tags: refunds, transaction ids,   

    WC 2.2 payment gateways: Adding refund support and transaction IDs 

    Payment Gateways in WC 2.2 can be improved with the introduction of two new features; being able to store a transaction ID in a standardised format, and being able to programatically handle refunds.

    Storing transaction IDs

    Storing transaction IDs is useful because these will appear in the order interface:

    2014-08-05 at 16.41

    If your gateway makes use of the $order->payment_complete() method, storing your transaction ID is a simple process. Simply pass the transaction ID to the method:

    $order->payment_complete( $transaction_id );

    WooCommerce will then store the ID as post meta.

    If you need to do this manually for any reason, you can set it directly using add_post_meta:

    add_post_meta( $order->id, '_transaction_id', $transaction_id, true );

    Turning the transaction ID into a link

    You’ll notice in the screenshot above, the transaction ID is a link – in this case linking the the transaction on the PayPal site. If you want to do this for your gateway, in your constructor set a “view_transaction_url” property, e.g:

    $this->view_transaction_url = 'https://www.paypal.com/cgi-bin/webscr?cmd=_view-a-trans&id=%s';

    WooCommerce will substitute the %s for the transaction ID during output.

    Supporting refunds

    To support refunds you need to create a process_refund() method in your gateway class. Without showing the refund code itself (which you’ll be writing) your method should look something like:

    public function process_refund( $order_id, $amount = null ) {
      // Do your refund here. Refund $amount for the order with ID $order_id
      return true;
    }
    

    This method should return a bool (true or false, if the refund was successfull or unsuccessfull) or a WP_Error object if something went wrong.

    As well as created this method, you need to define support for refunds. To do this, set the “supports” property in your constructor, e.g.:

    $this->supports = array(
      'products',
      'refunds'
    );
    

    This will let WooCommerce know that your gateway can handle refunds.

     
    • Emyr Thomas 9:55 am on August 6, 2014 Permalink | Reply

      This is fantastic – excellent work! I assume the bundled PayPal gateway will be one of the first to support refunds. Will your official Stripe gateway support refunds by the time WC 2.2 is released?

      • Mike Jolley 10:56 am on August 6, 2014 Permalink | Reply

        PayPal has it yes – it does require some extra API details, but once setup it works well.

        I’ll be looking at adding this to Stripe and a few others over the next few weeks.

    • Lee Willis 7:06 pm on August 10, 2014 Permalink | Reply

      Hi Mike,

      I’m just adding support for refunds / transaction IDs to the Paymill gateway – can you confirm what an amount of “null” – means – is it “no refund”, or (As the bundled PayPal gateway code implies) that a “full” refund should be attempted. If so – would it be better if WC core sent the amount needing to be refunded, rather than having the gateways try and work it out?

  • Mike Jolley 9:48 am on August 1, 2014 Permalink | Reply
    Tags: , , ,   

    2.2 Prowling Pangolin Beta 1: Release and highlights 

    This week we’re happy to announce WC 2.2 “Prowling Pangolin” beta 1 is available for testing.

    
                 ,___,           ╭────────────╮
          ╭╴╴╴╴/ ⏖ ⏖ \╴\╴\╴╮    ┃  Woo! 2.2  ┃
       ╭╯⏖ ⏖ ⏖ ⏖ ⏖ ⏖ ( ⦿\    ╰─y──────────╯
     ↜╯╯    ‴▾▾LL▾▾▾▾▾LL   \\   
                               *
    

    Since 2.1 we’ve had a whopping 1401 commits. You can view the changelog here and see what we’ve been busy working on: https://github.com/woothemes/woocommerce/blob/v2.2-beta-1/readme.txt#L129

    Before going into the features, developers should be aware of the following changes:

    1. Order statuses are no longer taxonomy based – the post status is used. This makes order queries lighter, but custom order queries may need to be updated.
    2. Orders can now be retrieved using the get_order() wc_get_order() function.
    3. Orders can be created using the new wc_create_order() function.
    4. Gateways can now handle refunds by declaring support for the ‘refunds’ feature, and including a process_refund() method (see PayPal Standard in WC core for an example).
    5. Gateways can pass the payment_complete() method a transaction ID to have it stored in a standardized format.
    6. v2 of the API which includes PUT/POST/DELETE methods is included. v1 of the API is still present until v3 is eventually released.

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

    Rest API v2

    Version 2 of the API introduces PUT/POST/DELETE support for Coupons, Orders, Products and customers and will really widen the possibilities of integrating with WooCommerce from external apps. Full documentation for v2 of the API should be ready soon, but it’s there if you want to play.

    Massive props to SkyVerge (Max and Justin in particular) for their contributions to the API.

    Refunds

    Refunds has been a feature we’ve wanted to tackle for a long time, but has been put back due to it’s scope a few times. We’re proud to finally have this feature built.

    Refunds consists of two parts;

    1. An API for Payment Gateways to handle refunds directly though code.
    2. An interface to handle refunds from the orders UI.

    The greatest challenges with refunds were;

    1. Keeping reports accurate after partial refunds.
    2. Having a simple interface to handle the refund process…
    3. …which led us to redesign the order item and order totals panels and combine them.
    4. Modifying our data structures (particulary for line items) to support the above.

    Here is an example of the new UI for order totals and items:

    2014-08-01 at 10.05

    You’ll notice shipping, taxes, fees are all displayed in the same area which should improve usability.

    This is what the UI looks like when doing a refund:

    2014-08-01 at 10.06

    Unfortunetely, due to the structure of data in 2.1 and below (particulary the way in which taxes were stored, never at line level) we’ve had to sacrifice the tax columns and partial refund functionality for legacy orders – but going forward, all new orders will benefit from the new functionality.

    We’re keen to hear your feedback about refunds in 2.2!

    Improved language file handling

    One thing we started noticing with recent releases was that the filesize for WooCommerce was huge. 2.1.12 was over 8mb. This can make updating difficult for example if there are upload limits.

    The reason for the size; localisation files. Uncompressed we’re talking 32mb of PO and MO files in core.

    To resolve this, 2.2 includes a language pack downloader. PO and MO files will no longer be bundled with the plugin – they will be downloadable from your dashboard if you have the WPLANG constant set, or from a git repository if you wish to grab them manually.

    Give us your feedback and get involved

    We’re happy to hear your feedback about 2.2 and would appriciate any bug reports going directly to Github.

    Download 2.2 Beta 1

    If you find a bug with the beta, please ensure you prepend the ticket title with [2.2] 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!

     
    • Cristian Tala S. 12:19 pm on August 1, 2014 Permalink | Reply

      Great news guys !,

      Do we need to change the way we change the order status in our plugins, or it is compatible ?

      • Mike Jolley 1:14 pm on August 1, 2014 Permalink | Reply

        If you are querying ‘publish’ status orders, yes you’ll need to adapt your queries.

        • David Anderson 10:14 am on August 2, 2014 Permalink | Reply

          It would be handy for each listed item to have more detail on the impact, and more specifics of what needs changing. Otherwise, with the very terse descriptions we currently have, all the developers are going to be duplicating that task a lot, or at least duplicating the task of doing more research.

          • Mike Jolley 5:51 pm on August 2, 2014 Permalink | Reply

            I’d hope that developers know what a post status and taxonomy is if they are querying orders :) Testing the beta it should be apparent what this change affects – custom order queries only.

            The #1 item listed is the only change devs may need to tweak code to accommodate.

    • Joe 4:19 pm on August 1, 2014 Permalink | Reply

      What’s the ETA on the release of 2.2 — we have about 40 something sites to get fixed due to the decision to remove order status taxonomy… so we need to know how much time we have to do that

    • Mike 7:24 pm on August 7, 2014 Permalink | Reply

      Would be great if the Continue Shopping bug gets fixed without the need to edit the woocommerce-functions.php. Also great if we could add additional fields to collect more data rather than just Notes.

    • fatma 3:44 pm on August 22, 2014 Permalink | Reply

      Hi,
      Don’t know if you’re receiving so many requests but we need to use 2 terms6conditions page at least in Turkey. One should have order details as well for each customer. There is no plugin for this purpose. If there is a page/blog to check for information, I will try to configure it from files

    • Danny 7:46 am on August 26, 2014 Permalink | Reply

      I see that Joe already asked when 2.2 will be released, but I’m not sure if he’s talking about a beta version or an “actual”, public release. Is it the actual public version 2.2 that you aim to release late August? Or when do you think that would happen?
      Thanks!

      Danny

  • Mike Jolley 1:18 pm on July 1, 2014 Permalink
    Tags:   

    WooCommerce 2.1.12 fix release is now available 

    The WooCommerce 2.1.12 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 are only a few changes in this release which can be found in the changelog. A total of 22 commits made it into this fix release.

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

     
  • Mike Jolley 12:23 pm on June 9, 2014 Permalink
    Tags:   

    WooCommerce 2.1.11 fix release is now available 

    The WooCommerce 2.1.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 are only a few changes in this release which can be found in the changelog. A total of 6 commits made it into this fix release.

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

     
  • Mike Jolley 2:49 pm on June 3, 2014 Permalink
    Tags:   

    WooCommerce 2.1.10 fix release is now available 

    Whilst work continues on Prowling Pangolin, the team at WooThemes are still fixing bugs for 2.1 as they are reported. Today, the WooCommerce 2.1.10 release is  available via WordPress.org or automatic update in your administration panel. Thanks to all of our contributors who’ve been helping out.

    All the changes are relatively small and can be found in the changelog. A total of 31 commits made it into this fix release.

    Thoughts? Feedback? Tell us on the forums.

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

     
  • Mike Jolley 1:23 pm on May 14, 2014 Permalink
    Tags:   

    WooCommerce 2.1.9 fix release is now available 

    The WooCommerce 2.1.9 release is now available via WordPress.org or automatic update in your administration panel. This fix release is the result of the continued effort of our contributors who provided fixes and bug reports. Thank you for helping out!

    All the changes are relatively small and can be found in the changelog. A total of 38 commits made it into this fix release.

    One thing we did add for the devs out there was an option in System Status > Tools for disabling shipping method/rate caching. Useful when debugging shipping.

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

     
  • Coen Jacobs 12:23 pm on April 30, 2014 Permalink
    Tags:   

    WooCommerce 2.1.8 fix release is now available 

    The WooCommerce 2.1.8 release is now available via WordPress.org or automatic update in your administration panel. This fix release is the result of the continued effort of our contributors who provided fixes and bug reports. Thank you for helping out!

    All the changes are relatively small and can be found in the changelog. A total of 55 commits made it into this release, making this a decent fix release.

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

     
  • Coen Jacobs 2:32 pm on April 10, 2014 Permalink
    Tags:   

    WooCommerce 2.1.7 fix release is now available 

    The WooCommerce 2.1.7 release is now available via WordPress.org or automatic update in your administration panel. This fix release is the result of the continued effort of our contributors who contribute code and others who have reported issues with the plugin. Thank you for helping out!

    All the changes are relatively small and can be found in the changelog. A total of 73 commits made it into this release, bundling them into one larger release makes it a decent fix release.

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

     
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