Enable Lightbox

The first step is to ensure that the Lightbox is enabled by going to WooCommerce > Settings > General > Styles and Scripts, and making sure that “Enable WooCommerce lightbox on the product page” is checked:

WooCommerce > Settings > General > Styles and Scripts

Including Lightbox

If you want to use the lightbox on, say, a product page, you’re in luck, with the above setting enabled, the lightbox styles/scripts will be automatically included. If however you want to use the lightbox on a different part of your site, you will likely have to include those files with an action like the following:

add_action( 'wp_enqueue_scripts', 'frontend_scripts_include_lightbox' );

function frontend_scripts_include_lightbox() {
  global $woocommerce;

  $suffix      = defined( 'SCRIPT_DEBUG' ) && SCRIPT_DEBUG ? '' : '.min';
  $lightbox_en = get_option( 'woocommerce_enable_lightbox' ) == 'yes' ? true : false;

  if ( $lightbox_en ) {
    wp_enqueue_script( 'prettyPhoto', $woocommerce->plugin_url() . '/assets/js/prettyPhoto/jquery.prettyPhoto' . $suffix . '.js', array( 'jquery' ), '3.1.5', true );
    wp_enqueue_script( 'prettyPhoto-init', $woocommerce->plugin_url() . '/assets/js/prettyPhoto/jquery.prettyPhoto.init' . $suffix . '.js', array( 'jquery' ), $woocommerce->version, true );
    wp_enqueue_style( 'woocommerce_prettyPhoto_css', $woocommerce->plugin_url() . '/assets/css/prettyPhoto.css' );
  }
}

This can be added to your theme’s functions.php in the usual manner (theme-name/functions.php), or perhaps to your custom site plugin. Note that this will have the effect of loading the lightbox script/style on every page of your site; if you want to limit it to certain pages/sections you can make use of the wide array of conditional tags available.

Bring out the LIGHTBOX!

Now that lightbox (really prettyphoto) is enabled and included, we can start using it. If you just want to display one or more images in their own popup or little gallery, it’s as simple as wrapping them in an anchor tag and adding the “prettyPhoto” rel:

<a rel="prettyPhoto" title="My Picture 1" href="/path/to/image1.png"><img src="/path/to/image1.png" /></a>
<a rel="prettyPhoto" title="My Picture 2" href="/path/to/image2.png"><img src="/path/to/image2.png" /></a>

Advanced Usage

If you need more control over the lightbox behavior, and/or wish to display content other than an image, you can make full use of the api. You’ll just be responsible for injecting the relevant javascript into your page source, or including it in an external script, or whatever you prefer.

The post How to Use WooCommerce 2.0 Lightbox appeared first on SkyVerge.

Extracting Strings for Translation

Although I won’t delve deeply into all aspects of WordPress internationalization (i18n), it is important to note that it’s built on the excellent GNU gettext localization framework. The basic process for translating a plugin or theme is as follows:

1. Code the plugin/theme using the translation functions __('message'), _e('message'), etc. Include a call to load_plugin_textdomain() as I describe in my article Writing a Plugin That Can Be Localized by WPML.
2. Extract all translatable strings into a POT file
3. Provide the POT file to a translator who returns one or more PO files with the text translated
4. Convert the PO file into an MO file
5. Place the MO file into the directory within your plugin that you specify in your call to load_plugin_textdomain(), ie “languages”

Step 1 – Coding

While coding a plugin or theme it’s always good practice to use the special (and odd looking) localization functions whenever displaying text, with the two most common being: __('message') and _e('message'). Some additional useful functions to know include _x('message', 'context') which allows you to provide some context information for translators to provide them with additional comments needed to distinguish between the same word used in different contexts, for instance. Another one is _n('message', 'plural', $number) which is used to retrieve the singular or plural form of a string, based on the amount $number. There are a number of variations of these functions, as well as ones specialized for use with HTML attribute values for instance.

You should also use an appropriate text domain string based on your plugin name. If your plugin is called My-Plugin, your text domain might be ‘my-plugin’ for instance.

Step 2 – Extraction

If you have not already done so, start by exporting the WordPress translation tools:

$ svn export http://i18n.svn.wordpress.org/tools/trunk/

Update 2013.03.01: It looks like the current head (revision 21405) of the WordPress translation tools has a broken makepot.php. When I tried to use it today the POT file it generated only contained strings from the main plugin file and none from the other plugin source files. The previous revision does not have this bug, so until the issue is fixed I’d recommend exporting the tools like so:

$ svn export -r 20807 http://i18n.svn.wordpress.org/tools/trunk/

One of those scripts is makepot.php which is used like the following:

$ php makepot.php wp-plugin /path/to/my-plugin

Where /path/to/my/plugin/ is the path to the plugin you wish to localize and will generate a POT file named like: my-plugin.pot. Rename it to match your text domain, and add the language suffix you want (or let your translator do this): ie my-plugin-de_DE.pot.

Step 3 – Translate POT to PO

Send your POT file to the translator, or translate it yourself if you have the knowledge. If you need to edit the PO file you’ll probably want to do so with a tool with UTF-8 support, depending on your target language. I had good luck with Poedit for this.

Step 4 – Convert PO to MO

Convert your PO file to the MO required by gettext by using the msgfmt utility:

$ msgfmt -o my-plugin-de_DE.mo my-plugin-de_DE.po

Step 5 – Using the MO File

Finally, drop your my-plugin-de_DE.mo into the directory within your plugin specified by your call to load_plugin_textdomain(). So for instance, if you use the following:

load_plugin_textdomain( 'my-plugin', false, dirname( plugin_basename( __FILE__ ) ) . '/languages' );

Then your .mo file would go in my-plugin/languages/

Testing

Once you put your mo translation file into the plugin directory that you supplied in your call to load_plugin_textdomain() (as described in Step 5 above), you can test that your language file is being picked up by editing your sites wp-config.php. There you should find a line like:

define('WPLANG', '');

Just change this to the language abbreviation, for instance:

define('WPLANG', 'de_DE');

And visit your site to verify the translation is being picked up.

One possible stumbling point for developers: your translation files may not be picked up if you symlink your plugin into your webroot as I do.

Working with WPML, so that the site language isn’t hardcoded in your wp-config.php file and can for instance be selected by your site visitors, is a simple matter of making the load_plugin_textdomain() call in the correct place. See my related article Writing a Plugin That Can Be Localized by WPML for details.

Updating Your Translation

If you change text in your plugin and want to update your translation without re-translating everything, Poedit makes this a snap. Simply:

1. Follow the steps above to generate a new POT file with the current strings
2. Open your out of date PO file with Poedit
3. Go to Catalog > Update from POT file… and choose your new POT file
4. Poedit will show you the obsolete and new strings. You can choose to delete the obsolete strings, or leave them (they’ll be commented-out in your new PO file) and translate the new strings.
5. Save to generate the new PO/MO files

Bonus

For a tip on supporting WPML see my article on Writing a Plugin That Can Be Localized by WPML.

If you create new database tables for your plugin, ensure that the default charset is UTF8, otherwise accented and other special characters that get inserted into them will not render properly:

CREATE TABLE blah ( ... ) ENGINE=InnoDB DEFAULT CHARSET=utf8;

WordPress Globe Icon image credit: http://adminsuperwoman.com/wordpress-websites/globe-icon-wordpress/

The post Translating a WordPress Plugin on the Command Line Step by Step appeared first on SkyVerge.

This question comes in from blog reader Wilgert (thanks Wilgert!):

could you help me find some simple code to add a custom option field to the general settings tab of the woocommerce admin area? Trying to avoid re-inventing the wheel here.

Well, this may be more than you bargained for, but here we go! The WooCommerce settings can be found under the menu item WooCommerce > Settings and look like so:

Like a lot of WooCommerce these settings can be customized thanks to a variety of actions and filters. For the main settings tabs there are 7 important filters to consider:

• woocommerce_general_settings
• woocommerce_catalog_settings
• woocommerce_page_settings
• woocommerce_inventory_settings
• woocommerce_tax_settings
• woocommerce_shipping_settings
• woocommerce_payment_gateways_settings
• woocommerce_email_settings

As you can see, one for each of the major tabs, excluding the final “Integration” tab, which is handled elsewhere.

Each of those filters accepts and returns the same nested array data structure, which describes the options and headings shown on the Settings tabs, allowing you easily modify, remove and even add your own custom settings (and even whole new sections of settings). Here’s an example snippet showing some of the common types of settings fields: a dropdown, a text input and a checkbox:

array(

  array(

    'name' => __( 'Pricing Options', 'woocommerce' ),

    'type' => 'title',

    'desc' => __('The following options affect how prices are displayed on the frontend.', 'woocommerce'),

    'id' => 'pricing_options'

  ),



  array(

    'name'    => __( 'Currency Position', 'woocommerce' ),

    'desc'    => __( 'This controls the position of the currency symbol.', 'woocommerce' ),

    'id'      => 'woocommerce_currency_pos',

    'css'     => 'min-width:150px;',

    'std'     => 'left', // WooCommerce < 2.0

    'default' => 'left', // WooCommerce >= 2.0

    'type'    => 'select',

    'options' => array(

      'left'        => __( 'Left', 'woocommerce' ),

      'right'       => __( 'Right', 'woocommerce' ),

      'left_space'  => __( 'Left (with space)', 'woocommerce' ),

      'right_space' => __( 'Right (with space)', 'woocommerce' )

    ),

    'desc_tip' =>  true,

  ),



  array(

    'name'     => __( 'Thousand separator', 'woocommerce' ),

    'desc'     => __( 'This sets the thousand separator of displayed prices.', 'woocommerce' ),

    'id'       => 'woocommerce_price_thousand_sep',

    'css'      => 'width:30px;',

    'std'      => ',', // WooCommerce < 2.0

    'default'  => ',', // WooCommerce >= 2.0

    'type'     => 'text',

    'desc_tip' =>  true,

  ),



  array(

    'name'    => __( 'Trailing zeros', 'woocommerce' ),

    'desc'    => __( 'Remove zeros after the decimal point. e.g. $10.00 becomes $10', 'woocommerce' ),

    'id'      => 'woocommerce_price_trim_zeros',

    'std'     => 'yes', // WooCommerce < 2.0

    'default' => 'yes', // WooCommerce >= 2.0

    'type'    => 'checkbox'

  ),



  array( 'type' => 'sectionend', 'id' => 'pricing_options' ),

);

Which will render roughly like:

By inspecting the settings data structure we see that it consists of an array of arrays, where each child array represents an element (heading, field or section end) on the settings page. A section of settings starts with an array with a type ‘title’, containing a ‘name’, ‘desc’ description and unique ‘id’. Any subsequent arrays are part of that section until we hit a special array with type ‘sectionend’ and an ‘id’ matching that of the starting section element.

The individual settings fields are given as arrays with a number of common arguments, along with some optional ones depending on the field ‘type’:

type

(string) Required field type with some common options: ‘text’, ‘color’, ‘image_width’, ‘select’, ‘checkbox’, ‘textarea’. Also some special case options: ‘single_select_page’, ‘single_select_country’, ‘multi_select_countries’. And you can even define your own custom type, providing the implementation via the woocommerce_admin_field_{mytype} action.

Note: WooCommerce 2.0 introduces some new types: ‘email’, ‘pasword’, ‘number’, ‘multiselect’ and ‘radio’.

name

(string) The displayed field name

Note: In WooCommerce 2.0 ‘name’ is replaced by a new field ‘title’, however the new ‘title’ field defaults to ‘name’, so for now at least you’re safe using ‘name’ and compatible with both WC 1.6.6 and previous as well as WC 2.0+

title

(string) WooCommerce 2.0 only This replaces the ‘name’ field in WooCommerce 2.0+, but defaults to ‘name’ if that field is provided.

id

(string) Unique field identifier, used to retrieve the field from the database options table

class

(string) Optional field class names

css

(string) Optional field custom css

std

(mixed) Optional field default value if the field type is ‘text’, ‘color’, ‘image_width’, ‘select’ or ‘textarea’. This can be a string, numeric or array depending on the option field ‘type’

Removed in upcoming WooCommerce 2.0

default

(mixed) Field default value. This can be a string, numeric or array depending on the option field ‘type’

This more appropriately named argument is available only for WooCommerce 2.0 and is available for all field types. For now just use both ‘std’ and ‘default’ with the same value

desc

(string) Optional field description, displayed next to the input element, or used as the tooltip, depending on ‘desc_tip’

desc_tip

(boolean|string) If true and ‘desc’ is provided, ‘desc’ will be used as the field tool tip. If a string is used it will be set as the tool tip.

Note: With WooCommerce 2.0+ you can have both a description and tooltip by using strings for each.

options

(array) Associative array of option name to value, this is used for the ‘select’, ‘multiselect’ or ‘radio’ field types

checkboxgroup

(string) Optional for fields of type ‘checkbox’, value can be one of ‘start’, ” or ‘end’. This is used to create a grouping of checkboxes under a single title/name, and for purposes of showing/hiding some checkboxes based on whether another is checked or not. This allows you to create options that are only visible if another option is checked or not checked.

show_if_checked

(string) Show a checkbox if another is checked. Optional for fields of type ‘checkbox’ that are part of a ‘checkboxgroup’, value can be one of ‘option’, ‘yes’ or ‘no’ (default). Only one checkbox in a checkboxgroup should be marked as ‘option’: this is the checkbox that controls the visibility of the others which have a value of ‘yes’.

hide_if_checked

(string) Hide a checkbox if another is checked. Optional for fields of type ‘checkbox’ that are part of a ‘checkboxgroup’, value can be one of ‘option’, ‘yes’ or ‘no’ (default). Only one checkbox in a checkboxgroup should be marked as ‘option’: this is the checkbox that controls the visibility of the others which have a value of ‘yes’.

I know there are a lot of possible arguments, with all different values which can be confusing and compounded by the changes with upcoming WooCommerce 2.0, but if you ever have any doubts about how something works, or what options you have, take a look at the woocommerce_admin_fields() function found in woocommerce/admin/woocommerce-admin-settings.php. Also the full set of WooCommerce settings can be found in the woocommerce/admin/settings/settings-init.php file and is a great starting point to find an example close to what you want to do.

Remember that if the above standard fields don’t do quite what you’re looking for you can always define your own totally custom option type along with whatever custom arguments you want, by hooking into the woocommerce_admin_field_{mytype} action.

Any setting field value can be retrieved from the database by using the standard WordPress get_option() function with the option’s ‘id’. Ie:

$woocommerce_price_trim_zeros = get_option( 'woocommerce_price_trim_zeros' );

Example

Now with all the formalities and background taken care of, how do we actually add a custom setting option you ask? It’s a simple matter of hooking onto the particular settings filter depending on what tab you want, and adding the option in at the appropriate place in the settings array. Here’s some code from my Sequential Order Numbers Pro plugin which adds a text option named “Order Number Start” to the “General” tab before the end of the “General Options” section:

add_filter( 'woocommerce_general_settings', 'add_order_number_start_setting' );



function add_order_number_start_setting( $settings ) {



  $updated_settings = array();



  foreach ( $settings as $section ) {



    // at the bottom of the General Options section

    if ( isset( $section['id'] ) && 'general_options' == $section['id'] &&

       isset( $section['type'] ) && 'sectionend' == $section['type'] ) {



      $updated_settings[] = array(

        'name'     => __( 'Order Number Start', 'wc_seq_order_numbers' ),

        'desc_tip' => __( 'The starting number for the incrementing portion of the order numbers, unless there is an existing order with a higher number.', 'wc_seq_order_numbers' ),

        'id'       => 'woocommerce_order_number_start',

        'type'     => 'text',

        'css'      => 'min-width:300px;',

        'std'      => '1',  // WC < 2.0

        'default'  => '1',  // WC >= 2.0

        'desc'     => __( 'Sample order number: AA-20130219-000-ZZ', 'wc_seq_order_numbers' ),

      );

    }



    $updated_settings[] = $section;

  }

  return $updated_settings;

}

Which will look like:

Your custom option setting will be automatically saved to the database to the standard WordPress options table with the field ‘id’ as the option name. Retrieve it using the standard WordPress get_option() function. Just don’t forget that if you use a default value for your setting that you’ll have to either set that value with an “install” function, or use it as the second parameter when retrieving your option from the database. For instance:

$order_number_start = get_option( 'woocommerce_order_number_start', 1 );

The post Add Custom Options to WooCommerce Settings appeared first on SkyVerge.

Here’s a quick little snippet that you can make use of if you want to set a default stock quantity for any newly added WooCommerce product Variations. This can be useful when bulk-adding variations and you don’t want an initial quantity of ”.

add_action( 'admin_enqueue_scripts', 'wc_default_variation_stock_quantity' );

function wc_default_variation_stock_quantity() {
  global $pagenow, $woocommerce;

  $default_stock_quantity = 0;
  $screen = get_current_screen();

  if ( ( $pagenow == 'post-new.php' || $pagenow == 'post.php' || $pagenow == 'edit.php' ) && $screen->post_type == 'product' ) {

    ob_start();
    ?>
    $('.woocommerce_variations').bind('woocommerce_variations_added',function() {
      $('.woocommerce_variations input').each(function(index,el) {
        el = $(el);
        if(el.attr('name') && el.attr('name').substr(0,14) == 'variable_stock' && el.val() == '') {
          el.val(<?php echo $default_stock_quantity; ?>);
        }
      });
    });
    <?php
    $javascript = ob_get_clean();
    $woocommerce->add_inline_js( $javascript );
  }
}

Or, if you need a default stock quantity for simple products:

add_action( 'admin_enqueue_scripts', 'wc_default_variation_stock_quantity' );

function wc_default_variation_stock_quantity() {
  global $pagenow, $woocommerce;

  $default_stock_quantity = 0;
  $screen = get_current_screen();

  if ( ( $pagenow == 'post-new.php' || $pagenow == 'post.php' || $pagenow == 'edit.php' ) && $screen->post_type == 'product' ) {

    ob_start();
    ?>
    if ( '' === $( '#_stock' ).val() ) {
      $( '#_stock' ).val(<?php echo $default_stock_quantity; ?>);
    }
    <?php
    $javascript = ob_get_clean();
    $woocommerce->add_inline_js( $javascript );
  }
}

The post Set a Default Stock Quantity for WooCommerce Products appeared first on SkyVerge.

To get the column names for a MySQL database table in WordPress, use the following:

global $wpdb;



$table_name = $wpdb->prefix . 'posts';

foreach ( $wpdb->get_col( "DESC " . $table_name, 0 ) as $column_name ) {

  error_log( $column_name );

}

Which will result in something like the following being printed to your debug.log:

ID

post_author

post_date

post_date_gmt

post_content

...

You get the idea

The post WordPress Get DB Table Column Names appeared first on SkyVerge.

With the release of WooCommerce 2.0 becoming more imminent (well, maybe not quite imminent yet, but certainly drawing nearer), those of us with WooCommerce plugins need to start work on getting them ready for the big release. WooCommerce has never been one to hold back on making plugin-busting implementation changes with a new release, and they’re setting the bar quite high with 2.0. It’s chalk full of code changes and improvements plugin developers must be aware of and potential handle, and I’ve personally spent many hours already preparing my various WooThemes-listed plugins for WC 2.0, with yet more work ahead of me I’m sure. I figure with all the time I’ve already spent researching this stuff, there’s no need for you to have to do the same, and so I’m putting together this guide on migrating existing plugins to WooCommerce 2.0, which I plan to continue to update as I find new issues/fixes, and I hope you dear reader will do the same in the comment section below!

The intended audience for the guide would most likely be developers with custom plugins for clients which they want to get updated ahead of time, or at least be ready to update once 2.0 is released. I’d imagine other developers in the WooCommerce developers program will be aware of most of this already. The majority of the fixes and approaches I describe in this article are from actual code snippets that I’ve used to update my own WooThemes-listed plugins, and hence they are written to be both backwards-compatible with the current WooCommerce 1.6.6, and compatible with the upcoming WooCommerce 2.0. It also means that they cover only those issues I’ve encountered with my own plugins, and thus couldn’t hope to cover all potential issues. If you’re responsible for a custom plugin for a client or small number of clients and have more control over the environment in which they run, you can certainly simplify your plugin by targeting it solely for 2.0; though for the most part it’s not a whole lot more effort to be backwards compatible as well.

As always, I make no claims or guarantees about the correctness or efficacy of the code shown below, and if you use it you do so at your own risk. I won’t be held responsible if something blows up! WooCommerce 2.0 is also still very much a work in progress and a moving target, but I believe the fixes I’ve already come up with should hold as they come to a final release candidate.

Testing

The first and most important step is to test your plugin with the latest beta of WooCommerce, at time of writing called WooCommerce 2.0.0-beta3. Or, if you’re feeling lucky, just use the current head of the WooCommerce repository. With any luck your plugin will work just fine and your job will be done before it’s begun. Crack open a beer! (but don’t forget to continue testing with each beta and especially the final release)

Overview

If you’re still with me, then perhaps some part of your plugin is broken by the 2.0 beta. Well, you’re in good company. We’ll start with a listing of potential issues and then delve into them one-by-one:

1. Products
2. Sessions
3. Order Item Data
4. Payment Gateways
5. Odds and Ends

Additional Resources

Also see the WooThemes article WooCommerce 1.6.6 -> 2.0 – Plugin and theme compatibility, which identifies some of the same issues/approaches I outline below, as well as some things I didn’t cover, especially with regards to themes.

Products

The first and most likely spot of trouble is with the product class.

Instantiating WC_Product

Products have received quite an overhaul in WooCommerce 2.0, and if you ever did new WC_Product() in your code you’re going to have to make a few changes. With 2.0 the WC_Product class is made abstract, meaning that to try and instantiate it is to be hit with a Fatal Error. The fix is to use the new product factory class to retrieve a new product instance, which you can do in a forwards/backwards compatible manner like so:

/**

 * Gets the identified product. Compatible with WC 2.0 and backwards

 * compatible with previous versions

 *

 * @param int $product_id the product identifier

 * @param array $args optional array of arguments

 *

 * @return WC_Product the product

 */

function my_plugin_get_product( $product_id, $args = array() ) {

  $product = null;



  if ( version_compare( WOOCOMMERCE_VERSION, "2.0.0" ) >= 0 ) {

    // WC 2.0

    $product = get_product( $product_id, $args );

  } else {



    // old style, get the product or product variation object

    if ( isset( $args['parent_id'] ) && $args['parent_id'] ) {

      $product = new WC_Product_Variation( $product_id, $args['parent_id'] );

    } else {

      // get the regular product, but if it has a parent, return the product variation object

      $product = new WC_Product( $product_id );

      if ( $product->get_parent() ) {

        $product = new WC_Product_Variation( $product->id, $product->get_parent() );

      }

    }

  }



  return $product;

}

As you can see, we check for the current version of WooCommerce: if running under 2.0 or greater, we use the spiffy new get_product() function, otherwise we create a product or product variation as normal. This can be used as simply as:

$product = my_plugin_get_product( 15 );

Product Custom Meta Fields

The next product change we need to concern ourselves with is the handling of custom meta fields. Gone is the old product_custom_fields array (except for product variations!) from which all product wp_postmeta fields were available. In its place is the PHP magic method __get. This means that instead of say $product->product_custom_fields['_my_field'][0] we simply do: $product->my_field. Cool! Still, you have to make sure and make the change, and at least as of beta2 make sure you handle product variations correctly if you have a custom meta that you allow to be set in the parent product and potentially overridden in the child. Here’s a helper function to help you along if you want to support WC 1.6 as well as the new 2.0:

/**

 * Helper function to retrieve a custom field from a product, compatible

 * both with WC < 2.0 and WC >= 2.0

 *

 * @param WC_Product $product the product object

 * @param string $field_name the field name, without a leading underscore

 *

 * @return mixed the value of the member named $field_name, or null

 */

function my_plugin_get_product_meta( $product, $field_name ) {

  if ( version_compare( WOOCOMMERCE_VERSION, "2.0.0" ) >= 0 ) {

    // even in WC >= 2.0 product variations still use the product_custom_fields array apparently

    if ( $product->variation_id && isset( $product->product_custom_fields[ '_' . $field_name ][0] ) && $product->product_custom_fields[ '_' . $field_name ][0] !== '' ) {

      return $product->product_custom_fields[ '_' . $field_name ][0];

    }

    // use magic __get

    return maybe_unserialize( $product->$field_name );

  } else {

    // use product custom fields array



    // variation support: return the value if it's defined at the variation level

    if ( isset( $product->variation_id ) && $product->variation_id ) {

      if ( ( $value = get_post_meta( $product->variation_id, '_' . $field_name, true ) ) !== '' ) return $value;

      // otherwise return the value from the parent

      return get_post_meta( $product->id, '_' . $field_name, true );

    }



    // regular product

    return isset( $product->product_custom_fields[ '_' . $field_name ][0] ) ? $product->product_custom_fields[ '_' . $field_name ][0] : null;

  }

}

As you can see, regardless of the version, if $product is a variation, that variation is checked first, followed by its parent. You use this method in the following way:

$value = my_plugin_get_product_meta( $product, 'my_field' );

Perhaps not as snazzy as $product->my_field, but if you want/need that 1.6 compatibility, that’s the tradeoff.

There are a slew of other product changes of course, but nothing that’s given me problems in the plugins I’ve tested thus far.

Sessions

Next on the list is sessions. WooCommerce 2.0 no longer uses the PHP session_start function, instead it makes use of WordPress’ transients, which is great, unless your code happens to rely on $_SESSION. Of course one of my plugins did, so here’s a couple of functions to ease your migration to 2.0 and still support any 1.6 installs out there:

/**

 * Safely store data into the session. Compatible with WC 2.0 and

 * backwards compatible with previous versions.

 *

 * @param string $name the name

 * @param mixed $value the value to set

 */

private function my_plugin_session_set( $name, $value ) {

  global $woocommerce;



  if ( isset( $woocommerce->session ) ) {

    // WC 2.0

    $woocommerce->session->$name = $value;

  } else {

    // old style

    $_SESSION[ $name ] = $value;

  }

}



/**

 * Safely retrieve data from the session. Compatible with WC 2.0 and

 * backwards compatible with previous versions.

 *

 * @param string $name the name

 * @return mixed the data, or null

 */

function my_plugin_session_get( $name ) {

  global $woocommerce;



  if ( isset( $woocommerce->session ) ) {

    // WC 2.0

    if ( isset( $woocommerce->session->$name ) ) return $woocommerce->session->$name;

  } else {

    // old style

    if ( isset( $_SESSION[ $name ] ) ) return $_SESSION[ $name ];

  }

}



/**

 * Safely remove data from the session. Compatible with WC 2.0 and

 * backwards compatible with previous versions.

 *

 * @param string $name the name

 */

function my_plugin_session_delete( $name ) {

  global $woocommerce;



  if ( isset( $woocommerce->session ) ) {

    // WC 2.0

    unset( $woocommerce->session->$name );

  } else {

    // old style

    unset( $_SESSION[ $name ] );

  }

}

Hopefully you’ll agree these are simple enough that they don’t require a lengthy explanation or usage example.

Order Item Data

Order Item Data is no longer stored directly in the wp_postmeta table as meta attached to the order post row and serialized in an array, which is actually great news and should make for much more efficient and larger possible stores. Order items and item data are now stored in wp_woocommerce_order_items and wp_woocommerce_order_itemmeta respectively. Order items and item meta data can be added using the new functions woocommerce_add_order_item() and woocommerce_add_order_item_meta():

$item_id = woocommerce_add_order_item( $order_id, array(

  'order_item_name' => 'Product Title',

  'order_item_type' => 'line_item'

) );

woocommerce_add_order_item_meta( $item_id, 'my_item_meta', 'my_item_meta_value' );

There’s other new functions to delete items and meta, and update, etc. Also if you need to write custom queries against order items or item meta this will be much more efficient/possible now.

If you used the WC_Order_Item_Meta class previously, there have been a couple of changes therein:

1. WC_Order_Item_Meta::add() is gone
2. As is WC_Order_Item_Meta::new_order_item()
3. The internal meta storage has changed to key-value pairs, rather than pairs of ‘meta_key’ and ‘meta_value’. (take a look at the class if you use this, it’ll make sense)

Finally, of interest if you’re in the business of adding custom item meta to the cart (say with custom configurable products on the frontend) the woocommerce_order_item_meta action is gone, and in its place we have: woocommerce_add_order_item_meta. You can support both actions to get backwards/forwards compatibility:

add_action( 'woocommerce_order_item_meta', 'my_plugin_order_item_meta', 10, 2 ); // WC < 2.0

add_action( 'woocommerce_add_order_item_meta', 'my_plugin_add_order_item_meta', 10, 2 ); // WC >= 2.0

The implementations of my_plugin_order_item_meta() and my_plugin_add_order_item_meta() will probably be largely similar, you’ll just want to use the new woocommerce_add_order_item_meta() function mentioned above in the WC 2.0 version.

Deprecated order_item_meta Class is Gone

The deprecated order_item_meta class is now removed, so if you’re still using that class in your code, make sure to replace it with WC_Order_Item_Meta otherwise you’ll get a fatal error.

Payment Gateways

Don’t know how many of you out there will have payment gateways you’ll be needing to update, but just in case, there have been a few changes to be aware of.

Smart Loading

Payment gateways in WC 2.0 have gotten a treatment similar to what Shipping Methods received in WooCommerce 1.5.7. The big change is that rather than being instantiated on every request, they are now loaded only when needed. This one change is supposedly responsible for quite a saving of resources and server performance. Which is all well and good, unless of course your payment gateway actually needs to take some actions anywhere other than the admin settings page, checkout/pay pages, and API call. The solution I’ve used and developed alongside fellow WC developer Max Rice is to create a lightweight “main” class which is always instantiated and which manages and registers the payment gateway class responsible for communicating with the gateway, and registers any actions or filters where the payment gateway class might be needed.

No real applicable code samples or examples here, however those of you with redirect gateways, or any gateways that registers a WooCommerce API hook, you’ll need to ensure that the action you register contains the gateway class name. Here’s a sample API hook added from within a payment gateway class:

add_action( 'woocommerce_api_' . strtolower( get_class( $this ) ), array( $this, 'gateway_response' ) );

Without this your gateway will not not be created and will not be called to handle that API request. Of course you can use the same “main” class pattern described above to register any arbitrary API request handler you may require, and indeed I have to do this with two of my own gateways.

Saving Settings

The other gateway change is much simpler, there’s a new action required to save the gateway settings. You can easily support both WC 1.6 and 2.0+ by just adding the new hook alongside the existing:

if ( is_admin() ) {

  add_action( 'woocommerce_update_options_payment_gateways',              array( $this, 'process_admin_options' ) );  // WC < 2.0

  add_action( 'woocommerce_update_options_payment_gateways_' . $this->id, array( $this, 'process_admin_options' ) );  // WC >= 2.0

}

Odds and Ends

And then there’s all the little odds and ends we’ve run in to.

Admin Help Tip Image Elements

The Help Tip image has changed, so be sure to add a width/height of 16 otherwise it will look funky and large:

Media Browser
Although not strictly related to WooCommerce 2.0 it's recommended and a good practice to use the new WordPress 3.5 media browser.
Admin Product Data Tab CSS
The product data tabs have changed from a horizontal layout in 1.6:

To a much more efficient vertical layout in 2.0:

Requiring some annoying CSS changes if you want to have your tabs looking correct in both 1.6 and 2.0+.  Here's the best Max and I have come up with:

add_action( 'woocommerce_product_write_panel_tabs', 'my_plugin_product_tabs_panel_tab' );



/**

 * Adds the "Tabs" tab to the Product Data postbox in the admin product interface

 */

function my_plugin_product_tabs_panel_tab() {

	echo '
' . __( 'My Plugin' ) . '
';

}



add_action( 'woocommerce_product_write_panels', 'my_plugin_product_rates_panel_content' );



/**

 * Adds the tab panel to the Product Data postbox in the product interface

 */

function my_plugin_product_rates_panel_content() {



  $tab_icon = $this->plugin_url() . '/assets/product-data-icon.png';



  if ( version_compare( WOOCOMMERCE_VERSION, "2.0.0" ) >= 0 ) {

    $style = 'padding:5px 5px 5px 28px;background-image:url(' . $tab_icon . ');background-repeat:no-repeat;background-position:5px 7px;';

    $active_style = '';

  } else {

    $style = 'padding:9px 9px 9px 34px;line-height:16px;border-bottom:1px solid #d5d5d5;text-shadow:0 1px 1px #fff;color:#555555;background-image:url(' . $tab_icon . ');background-repeat:no-repeat;background-position:9px 9px;';

    $active_style = '#woocommerce-product-data ul.product_data_tabs li.my_plugin_tab.active a { border-bottom: 1px solid #F8F8F8; }';

  }

  ?>

  



  ...


Conclusion
Well, that about does it.  As I said in the intro, any more refinements I come up with I'll do my best to update/add here, and if you find anything feel free to mention it in the comments.  Hopefully WooCommerce 2.0 will be released before all too long and this guide will be one for the ages.
The post Guide to Migrating Your Plugin to WooCommerce 2.0 appeared first on SkyVerge.
]]>
			http://www.skyverge.com/blog/migrating-your-plugin-woocommerce-2-0/feed/
		16
		
		
		
		http://www.skyverge.com/blog/woocommerce-ups-shipping-now-available/?utm_source=rss&utm_medium=rss&utm_campaign=woocommerce-ups-shipping-now-available
		http://www.skyverge.com/blog/woocommerce-ups-shipping-now-available/#comments
		Fri, 11 Jan 2013 18:24:43 +0000
		Max Rice
				
		
		
		
		

		http://www.skyverge.com/?p=1068
		With the official WooCommerce UPS Shipping extension undergoing a rewrite, we’ve made our WooCommerce UPS Shipping extension available for purchase. This connects your WooCommerce store to UPS and displays real-time shipping rates and estimates. Some key features: Show Negotiated Rates Use simple Table Rates/Pack Tables to define how many products should be in different sizes [...]
The post WooCommerce UPS Shipping Now Available appeared first on SkyVerge.
]]>
				

With the official WooCommerce UPS Shipping extension undergoing a rewrite, we’ve made our WooCommerce UPS Shipping extension available for purchase. This connects your WooCommerce store to UPS and displays real-time shipping rates and estimates. Some key features:

Show Negotiated Rates
Use simple Table Rates/Pack Tables to define how many products should be in different sizes boxes.
Include delivery estimates (e.g. Delivers by Wednesday at 10:30 AM) with rates
And much more! See full list of features


Visit the WooCommerce UPS Shipping product page to learn more and purchase your copy now!
The post WooCommerce UPS Shipping Now Available appeared first on SkyVerge.
]]>
			http://www.skyverge.com/blog/woocommerce-ups-shipping-now-available/feed/
		0
		
		
		
		http://www.skyverge.com/blog/searching-custom-fields-woocommerce-order-admin/?utm_source=rss&utm_medium=rss&utm_campaign=searching-custom-fields-woocommerce-order-admin
		http://www.skyverge.com/blog/searching-custom-fields-woocommerce-order-admin/#comments
		Thu, 13 Dec 2012 04:26:33 +0000
		Justin Stern
				
		
		

		http://www.skyverge.com/?p=962
		The WooCommerce Order Admin allows you to search for ordres by the following fields: order key billing first name billing last name billing company billing address 1 billing address 2 billing city billing postcode billing country billing state billing email billing phone order items But what if you want to search by another order field? [...]
The post Tweaking the WooCommerce Order Admin: Searching For Custom Fields appeared first on SkyVerge.
]]>
				

The WooCommerce Order Admin allows you to search for ordres by the following fields:

order key
billing first name
billing last name
billing company
billing address 1
billing address 2
billing city
billing postcode
billing country
billing state
billing email
billing phone
order items

But what if you want to search by another order field?  Perhaps the order total?  Well it’s as easy as adding something like the following to your themes functions.php:

add_filter( 'woocommerce_shop_order_search_fields', 'woocommerce_shop_order_search_order_total' );



function woocommerce_shop_order_search_order_total( $search_fields ) {

  $search_fields[] = '_order_total';

  return $search_fields;

}


With that simple snippet active you can now search by order total.  Note that with the numerical fields like total, you’d need to search with no thousands separator, and a period for the decimal place holder, ie:  1000.50 regardless of how you have configured WooCommerce to display totals on the frontend.  That’s due to the way the numbers are stored within WooCommerce.  Using this technique you can even search by custom post meta that you may be adding to the order records.
The post Tweaking the WooCommerce Order Admin: Searching For Custom Fields appeared first on SkyVerge.
]]>
			http://www.skyverge.com/blog/searching-custom-fields-woocommerce-order-admin/feed/
		0
		
		
		
		http://www.skyverge.com/blog/overriddin-woocommerce-widgets/?utm_source=rss&utm_medium=rss&utm_campaign=overriddin-woocommerce-widgets
		http://www.skyverge.com/blog/overriddin-woocommerce-widgets/#comments
		Sun, 02 Dec 2012 03:41:56 +0000
		Justin Stern
				
		
		

		http://www.skyverge.com/?p=945
		While it’s not technically possible to override a WordPress widget (and remember WooCommerce widgets are nothing more than WordPress widgets), WooCommerce is just so extendable and pluggable and flexible, that some widget functionality can be nearly completely overridden just using the standard WooCommerce template files and/or template functions. For the widgets that aren’t as pluggable, [...]
The post How to Override WooCommerce Widgets appeared first on SkyVerge.
]]>
				

While it’s not technically possible to override a WordPress widget (and remember WooCommerce widgets are nothing more than WordPress widgets), WooCommerce is just so extendable and pluggable and flexible, that some widget functionality can be nearly completely overridden just using the standard WooCommerce template files and/or template functions.  For the widgets that aren’t as pluggable, or if you need greater control, you have the option to un-register a core WooCommerce widget and subclass it, or even duplicate it and change it wholesale, all without modifying a single core file, thus maintaining a clean upgrade path.
Your widget override options, listed in order of preference, starting with the most preferred, down to the least preferred but most powerful, are as follows:

Use the widget_display_callback filter to alter configuration details
Hook into any provided filters/actions
Override a WooCommerce template file
Override a pluggable WooCommerce template function
Subclass, modify and register a widget
Duplicate, modify and register a widget

The rest of this article will be devoted to describing, with code examples where applicable, these six options.  Note also that while this is written with WooCommerce in mind, most of the strategies described are completely applicable to any WordPress widgets.
Option 1 – Hook into widget_display_callback filter
You can hook onto the widget_display_callback filter to change the configuration settings of a widget on-the-fly.  Not really sure how useful this is, and I’m not covering it in great detail as this article is geared towards more substantial behavior overrides.  Still, a quick example of how you might use it, here changing the Cart widget title:
add_filter( 'widget_display_callback', 'rename_widget', 10, 3 );

function rename_widget( $settings, $widget, $args ) {

  if ( get_class( $widget ) == 'Custom_WooCommerce_Widget_Cart' ) {
    $settings['title'] = 'My Cart';
  }

  return $settings;
}

Option 2 – Hook into widget filters/actions
I didn’t include this method initially as I don’t know how many widgets actually provide their own action/filter hooks for modifying functionality, but there’s certainly no reason that they couldn’t, and if they should, this would be an ideal way to change the widget behavior.  I won’t cover the basics of using WordPress actions/filters, for that check out the WordPress Plugin API codex page.
Option 3 – Override a WooCommerce widget template file
This is the next most preferred means of changing a WooCommerce widget’s behavior, but it’s not always possible.  To determine whether you can use this method, you’ll have to inspect the widget class in question.  Lets use the WooCommerce Cart widget as an example, which produces a mini cart like the following when active:

The code for this widget can be found at woocommerce/widgets/widget-cart.php.  If we take a look at that file, we’ll find that it doesn’t contain much beyond the boilerplate widget code, though it does contain the following line:
$woocommerce->mfunc_wrapper( 'woocommerce_mini_cart()', 'woocommerce_mini_cart', array( 'list_class' => $hide_if_empty ? 'hide_cart_widget_if_empty' : '' ) );

Without diving into the specifics of what’s going on here, suffice it to say that this results in a call to the woocommerce_mini_cart() function, which will do most of the work of creating this widget on the frontend.  When we look at the woocommerce_mini_cart(), found in woocommerce/woocommerce-template.php, we see that it in turn does very little other than loading cart/mini-cart.php:
woocommerce_get_template( 'cart/mini-cart.php', $args );
Which you can find at woocommerce/cart/mini-cart.php and actually contains the code that renders that mini cart widget.
Now this may seem like a lot of effort or unnecessary code just to display a mini cart, but what this design provides is quite a lot of flexibility, with multiple avenues for modifying the widget behavior.  Thanks to all that flexibility we can completely change the look and feel of this widget by simply overriding the mini-cart.php template file.  This is something I’ve covered fully in another article, but the overview is to create a directory named woocommerce within your theme, copy over the template file in question, and modify things to our hearts content.  In this example we’d copy woocommerce/templates/cart/mini-cart.php to yourtheme/woocommerce/cart/mini-cart.php and change whatever we want in that file.  The template file in the theme will be used in place of the core WooCommerce template.
Option 4 – Override a plugable widget template function
This method is quite related to the template file method described in the previous section.  If you’ve read through and paid attention to Option 3, you’ll remember the function woocommerce_mini_cart(), found in woocommerce/woocommerce-template.php which loaded the mini-cart.php template file.  This function is known as a pluggable function because it can be replaced with your own custom version.  The full function looks like the following:
if ( ! function_exists( 'woocommerce_mini_cart' ) ) {

  function woocommerce_mini_cart( $args = array() ) {

    $defaults = array( 'list_class' => '' );
    $args = wp_parse_args( $args, $defaults );
    woocommerce_get_template( 'cart/mini-cart.php', $args );

  }

}

Thanks to that function_exists() check, we are actually given the opportunity to “plug-in” our own function implementation before this one is loaded; hence the term “pluggable”.  We can do so by simply copying this function to our theme’s functions.php and making whatever changes we might want, including loading the same or perhaps an entirely different template file.
Keep in mind that not all WooCommerce widgets are structured to use template functions and files, so you’ll have to actually look at the code for the widget in question and determine whether this override option is available to you.  If it is, and allows you to do what you need, that’s great as like the previous options it’s very easy, safe, and doesn’t impact WooCommerce upgrades.
Option 5 – Subclass, modify and register a widget
Among the benefits of this option are: the fact that we can do this with any widget regardless of whether it uses a pluggable template function, by subclassing we can inherit some behavior while overriding other, we can change anything about the plugin’s behavior, and this is quite upgrade-safe.  That is unless your child class depends on a part of the parent widget implementation which happens to change in a subsequent release; something that is possible but probably unlikely, and could be addressed with the final option, described after this one.
The basic recipe for the subclass method is as follows:

Subclass the widget in question in a new widget class, changing whatever functionality you desire.
Unregister the widget in question
Register your new widget
Use the new widget!

As an example, lets say we want to change the WooCommerce Best Sellers widget, which displays a list of the best selling products on your site.  What we want to change about this widget is immaterial, the basic steps will remain the same.  First we take a look at the widget code, which can be found at woocommerce/widgets/widget-best_seller.php to determine whether we can use one of the more preferred modes of overriding described above.  It’s pretty obvious that the bulk of code, both for accessing the database, as well as rendering the best sellers list, is contained right within the widget() method, and with no real filter/action hooks, options 1-4 are out.  In addition to the widget() method, there are a number of other methods such as the constructor and widget form display, which perhaps we don’t care about changing, hence making a subclass the ideal solution as we can rely on the parent for the implementation of those methods, and focus on just changing the main widget() method to do whatever it is we need.
So we’ll start by creating a new file in our theme named:  my-theme/widgets/widget-best_sellers.php, and containing a new class class that extends WooCommerce_Widget_Best_Sellers and copying in the entire widget() method from woocommerce/widgets/widget-best_seller.php:
class Custom_WooCommerce_Widget_Best_Sellers extends WooCommerce_Widget_Best_Sellers {

  function widget( $args, $instance ) {
    // copy the widget function from woocommerce/widgets/widget-best_seller.php
  }

}

Then add the following code to your theme’s functions.php to unregister the WooCommerce Best Sellers widget and register our custom one in its place:
add_action( 'widgets_init', 'override_woocommerce_widgets', 15 );

function override_woocommerce_widgets() {
  // Ensure our parent class exists to avoid fatal error (thanks Wilgert!)

  if ( class_exists( 'WooCommerce_Widget_Best_Sellers' ) ) {
    unregister_widget( 'WooCommerce_Widget_Best_Sellers' );

    include_once( 'widgets/widget-best_sellers.php' );

    register_widget( 'Custom_WooCommerce_Widget_Best_Sellers' );
  }

}

Now you’ll be able to use this new widget in exactly the same manner as the old one, and change any of the functionality you need in the widget() method.  There will be no confusion in the admin UI as there will only be one version of the Best Sellers widget shown; your custom version.  Future updates of WooCommerce should be relatively painless as you haven’t actually modified any core files.
Option 6 – Duplicate, modify and register a widget
This approach is exactly the same as option 5, except you’ll need to copy the entire parent widget file over, and you won’t be extending from it as we did in the previous option.  Here we’re literally creating an entirely new widget and swapping it in place of the old, so it’s fairly brute force, but on the other hand does not rely on any implementation details of the original widget.  The same basic code is used to unregister and register the widgets.
Conclusion
And so there you have it, 6 different ways of seamlessly and safely modifying widget behavior.  I’d be curious to hear if you end up overriding any widgets, WooCommerce or otherwise, which widgets you change and what for; let me know in the comments section below!
The post How to Override WooCommerce Widgets appeared first on SkyVerge.
]]>
			http://www.skyverge.com/blog/overriddin-woocommerce-widgets/feed/
		18
		
		
		
		http://www.skyverge.com/blog/dont-share-terms-between-wordpress-taxonomies/?utm_source=rss&utm_medium=rss&utm_campaign=dont-share-terms-between-wordpress-taxonomies
		http://www.skyverge.com/blog/dont-share-terms-between-wordpress-taxonomies/#comments
		Tue, 20 Nov 2012 22:18:25 +0000
		Justin Stern
				
		

		http://www.skyverge.com/?p=934
		By default WordPress will reuse terms with the same name and slug between different taxonomies. For instance, if you add the term ‘red’ as a tag, and then add the category ‘red’, the same wp_terms record will be shared between them. This is also true for any custom taxonomies you define (remember that despite their [...]
The post Don't Share Terms Between WordPress Taxonomies appeared first on SkyVerge.
]]>
				By default WordPress will reuse terms with the same name and slug between different taxonomies.  For instance, if you add the term ‘red’ as a tag, and then add the category ‘red’, the same wp_terms record will be shared between them.  This is also true for any custom taxonomies you define (remember that despite their seeming differences, WordPress tags and categories are both implemented as taxonomies).  Now, in general this is fine; if the name and slug are the same, then just given the fact that all term records are stored in a single table forces them to be shared across different taxonomies.

However, what if you don’t care so much about the slug, and want to be able to use the same term name within multiple taxonomies, but don’t want the wp_terms record shared?  I’ll admit this might not be a typical case, but it came up for me recently when doing some WooCommerce work, specifically because I wanted to be able to attach different term meta to each of the terms with the same name, so they couldn’t be shared between taxonomies.  (Side note:  WooCommerce allows you to attach meta information to term records, a really cool extension to WordPress with lots of uses, and I plan to cover that implementation in a future article.)  One simple way to stop the records from being shared is to make the admin user define a unique slug for each term that shares a common name with another taxonomical term, ie: ‘Red’, ‘red’ in taxonomy ‘A’ and ‘Red’, ‘red-2′ in taxonomy ‘B’, etc.  Obviously the drawback is that you have to remember to do this, have to remember how many different ‘red’ terms there are, all easy stuff to forget until it’s too late.  So, as usual I’ve put together a little modification that you can add to your theme’s functions.php, or to your very own custom site plugin and explained below.
The Code
The implementation is actually fairly simple:  we hook a filter to ‘pre_insert_term’ and temporarily rename the term as needed to generate a unique slug and thus a separate term record, then after the term is created we fix the name back to what the user originally specified.  This is done only if a term slug is not given; we assume the user had something special in mind if they went through the trouble of providing a slug.  And with that, here’s the code:

add_filter( 'pre_insert_term', 'foxrunsoftware_pre_insert_term', 10, 2 );



/**

 * This filter temporarily renames any terms to force a unique slug when they

 * would otherwise not be unique.  This is to overcome a "feature" with

 * WordPress, whereby terms are recycled among different taxonomies rather than

 * being created new with a unique slug.  As an example, if the term 'red'

 * exists in a taxonomy and 'red' is added to another taxonomy, it will be

 * temporarily named as 'red 2', which forces a unique slug to be created, then

 * we remove the name counter suffix after the term is created.

 *

 * @param string $term the term name

 * @param string $taxonomy the taxonomy name

 *

 * @return string the term name

 */

function foxrunsoftware_pre_insert_term( $term, $taxonomy ) {



  // if no slug was specified

  if ( empty( $_REQUEST['slug'] ) ) {

    $slug = sanitize_title( $term );



    // check whether a unique slug needs to be generated

    $new_slug = wp_unique_term_slug( $slug, (object) array( 'parent' => 0, 'taxonomy' => $taxonomy ) );



    if ( $new_slug != $slug ) {

      // append the unique slug counter to the end of the term name, to force uniqueness

      $term .= ' ' . substr( $new_slug, strrpos( $new_slug, '-' ) + 1 );



      // hook so we can fix the term name back to what it should be

      add_action( 'created_term', 'foxrunsoftware_created_term', 10, 3 );

    }

  }



  return $term;

}


As you can see, after changing the term name if needed, a second action is added to fix the modified term name.  The implementation of that function is as follows:

/**

 * This action removes the temporary counter which is added to terms to force

 * uniqueness.

 *

 * See the commends for the foxrunsoftware_pre_insert_term() function

 * for the full details.

 *

 * @see foxrunsoftware_pre_insert_term()

 *

 * @param int $term_id term identifier

 * @param int $tt_id term taxonomy identifier

 * @param string $taxonomy taxonomy name

 */

function foxrunsoftware_created_term( $term_id, $tt_id, $taxonomy ) {



  $term = get_term( $term_id, $taxonomy );



  // get rid of the temporary counter we added to the name

  $name = substr( $term->name, 0, strrpos( $term->name, ' ' ) );



  // update and we're done!

  wp_update_term( $term_id, $taxonomy, array( 'name' => $name ) );

}


And that’s the whole of it.  If there’s anyone else out there who did not want their terms shared between taxonomies, let me know in the comments below, I’d be curious to hear what you’re doing!
The post Don't Share Terms Between WordPress Taxonomies appeared first on SkyVerge.
]]>
			http://www.skyverge.com/blog/dont-share-terms-between-wordpress-taxonomies/feed/
		6