Resources also include: REST API Documentation, Internal API Documentation, and End-User Documentation.

Release Notes

• 2.6.x to 3.0.0 Developer Migration Notes
• Enabling Product Gallery Features (Zoom, Swipe, Lightbox) in 3.0.0

CRUD & Data Descriptions

• Database Description
• CRUD Objects in 3.0
• Order and Order Line Item Data
• Coupon Data
• Customer Data
• Product Data
• Data Stores

Internal APIs

• Settings API
• Payment Token API
• Shipping Method API

CLI (Command line interface)

• WC CLI Overview
• WC CLI Commands

Examples / Guides

• How Taxes Work in WooCommerce
• Customizing Account Page Tabs
• End-to-end Testing
• Getting Started with the REST API

Contribution / Guidelines

• Our Git Flow
• How to Ensure SCSS and Scripts are Minified
• CSS SASS Coding Guidelines and Naming Conventions
• Core Testing Checklist
• String Localization Guidelines
• Template File Guidelines for Devs and Theme Authors
• Deprecation in core

The post WooCommerce Developer Wiki first appeared on CODIBU.

If you arrived at this page from the notice in your WooCommerce store, your store is running an outdated and unmaintained version of PHP. Not only is your website’s performance (a lot) lower than it should be, you may find that things do not work as you expect and be open to security vulnerabilities!

What is PHP?

PHP is a scripting language which most likely powers your WooCommerce webshop. PHP, like all software, gets updated over time to patch security issues and improve its features. And like other software, it’s important to keep your PHP version up to date.

Updating your PHP version

Contact your host

In most cases you cannot update the PHP version yourself and need to contact your host about this. The upgrade process is an easy process and should be something your host can do for you without impacting your website or charging you a fee. Here’s a letter you can send to your hosting company:

Dear host,

I’m running a WooCommerce webshop on one of your servers and WooCommerce has recommended using at least PHP 7.0. WordPress, the content management system that WooCommerce uses, has listed PHP 7.4 as the recommended version on n their requirements page: https://wordpress.org/about/requirements/

Can you please let me know if my hosting supports PHP 7.0 or higher and how I can upgrade?

Looking forward to your reply.

VPS Server

If you have a VPS server, see How to upgrade from PHP 5.

My host doesn’t support PHP 7.0

If your host doesn’t support PHP 7.0 or higher, we recommend you find a host that does. We have a list of WordPress hosting solutions we recommend and all support PHP 7.0 or higher. If you contact another host, be sure to ask them which PHP version your website will run on before purchasing.

More information

PHP has a list of unsupported version including dates on their website. If you develop WordPress plugins yourself you might want to check out the PHP library called WPupdatePHP.

The post How to update your PHP version first appeared on CODIBU.

Important: It’s an issue that is impossible to work around, until Microsoft fixes this bug in an upcoming fix release.

External software conflicts

There are also numerous reports about external software hooking into Internet Explorer, like “Free Download Manager” and “Download Accelerator Plus”. These claims have never been confirmed to actually be part of the cause of this issue.

Related information

1. #12790 ticket on jQuery issue tracker. jQuery closed this issue as ‘cantfix’ on their issue tracker, where it is discussed for a couple months now and provides a lot background information.
2. #3150 ticket on our issue tracker and before that also on the support forums.

The post AJAX problems in Windows 7/8 and Internet Explorer 10 first appeared on CODIBU.

Option 1: Get your host to update the rule set

This is by far the best option as everything will then work as by design. Contact your hosting provider for assistance.

Option 2: Rename files and update functions.php

Alternatively, you’ll need to change how WooCommerce handles the files. This change will need to be repeated whenever you update the WooCommerce plugin as the changes will be overwritten.

Rename these files:

wp-content/plugins/woocommerce/assets/js/jquery-cookie/jquery.cookie.js
wp-content/plugins/woocommerce/assets/js/jquery-cookie/jquery.cookie.min.js

to:

wp-content/plugins/woocommerce/assets/js/jquery-cookie/jquery_cookie.js
wp-content/plugins/woocommerce/assets/js/jquery-cookie/jquery_cookie.min.js

And add the following to your theme’s functions.php file:

Option 3: use a plugin to rename the files

If the first two options aren’t possible, then you can use a plugin, which renames the file being loaded:

• If you are using WooCommerce 2.6.14 or below: woocommerce-jquery-cookie-fix.zip
• If you are using WooCommerce 3.0.0 or above: woocommerce-js-cookie-fix

Note: Please remove any previous fixes you may have applied.

The post jQuery.cookie.js/jQuery.cookie.min.js scripts fail to load first appeared on CODIBU.

PCI-DSS (Payment Card Industry Data Security Standard) is a set of actionable rules defined by the Payment Card Industry Security Standards Council to encourage the broad adoption of consistent data security measures around the world with an aim to reduce credit card fraud.

These rules apply to anyone who is storing, processing or transmitting credit card data, therefore merchants who wish to take Credit Card payments on their sites directly need to be aware of PCI-DSS.

For more information about PCI-DSS see here.

Do I need to be PCI-DSS Compliant?

If you are transmitting credit card data; yes. Your site needs to be PCI-DSS compliant.

If, however, you are taking payments off site by using a gateway that uses its own servers to take payments (PayFast, PayPal Standard, etc.), you are not transmitting card data and do not need to take steps to comply. If you are not comfortable about becoming PCI Compliant, use a gateway which handles PCI for you.

PCI-DSS Core Requirements

The 12 core PCI-DSS requirements are as follows:

Reporting Compliance

Typically, PCI compliance reports are enforced by your payment processor – they may require that you fill out questionnaires (Self Assessment Questionnaire – or SAQ) or be scanned by an ASV (approved scanning vendor) of their choosing.

WooCommerce and PCI Compliance

Ultimately, PCI and all of the above points are the responsibility of the store owner, however, we can offer advice on compliance. It should be noted that WooCommerce is not PCI-DSS certified – however, this does not prevent your site from becoming PCI compliant. WooCommerce is written with security in mind with audits from WP core contributors and Sucuri.

Regarding the PCI-DSS requirements, many of the points above are beyond the scope of WordPress and WooCommerce – instead falling into the area of hosting and business policies/best practice for the website owner to abide by. Referencing the core PCI-DSS requirements above:

1. Out of scope. Firewalls would be the responsibility of the hosting provider or network administrator
2. Out of scope. Passwords would need to be set responsibly by yourself – use strong passwords at all times and ensure the hosting environment is 100% secure.
3. WooCommerce helps with this requirement by never storing card details. Our in-house payment gateways also never store more than 4 digits of a card number if storing payment tokens for re-use.
4. WooCommerce has options to enforce SSL on your checkout pages. You should of course ensure your hosting provider implements SSL to work with this.
5. Out of scope. Virus protection would be down to your hosting provider.
6. Out of scope. Maintaing a secure system to avoid threats would be down to your hosting provider.
7. WooCommerce uses the WordPress login system which can be used to give administrative access to whom you desire. Security best practices such as strong passwords and usernames would be your responsibility.
8. Out of scope. Work with the host/network admin to ensure all admin access to systems containing credit card details is logged and trackable. Users need to be traceable and accountable for their actions. Access should be limited to only those who need it.
9. Out of scope. Access to physical stored and transmitted data should be restricted by the hosting provider.
10. Out of scope. Monitoring access would need to be taken care by the network admin or hosting provier.
11. Out of scope. Use an ASV (approved scanning vendor) to regular scan your site for issues.
12. Out of scope. Creating, maintaining and distributing a policy on addressing the PCI-DSS requirements, as well as a risk assessment is the responsibility of the merchant/store owner.

Therefore, considering the above points, the following steps should be taken if you aim to achieve compliance:

1. Choose a trusted, secure hosting provider – preferably one which claims and actively promotes PCI compliance. Cheap, shared hosts are unlikely to cover this.
2. Use security best practices when setting passwords and limit access to your server.
3. Never store credit card details anywhere.
4. With the aid of your hosting provider, implement SSL to keep your checkout secure.
5. Keep installed plugins to a minimum; remember, compliance covers all installed software so that includes plugins and WordPress itself.
6. Keep plugins up to date to ensure latest security fixes are present.
7. Working with your payment processor, use an ASV (approved scanning vendor) to scan your site and find issues – fixing any identified issues until passing the scan.

Or alternatively, choose a gateway which handles this for you offsite.

The post PCI-DSS Compliance and WooCommerce first appeared on CODIBU.

Other useful resources relating to WC 2.0 include:

• Migrating your plugin to WC 2.0
• Beta 1 announcement post
• Beta 2 announcement post
• Coen on WC 2.0

Detecting WC version

If you need to conditionally handle WC 2.0, use the following:

if ( version_compare( WOOCOMMERCE_VERSION, '2.0', '<' ) ) {
  // Pre 2.0
} else {
  // 2.0
}

Changes affecting Payment Gateways

There are 2 main changes to gateways which will affect plugins;

1. The save hook
2. Dynamic loading

Save hooks have been tweaks so that only 1 gateway is shown and saved per page. To maintain compatibility with 1.6.6 and 2.0 use the following snippet:

/* 1.6.6 */
add_action( 'woocommerce_update_options_payment_gateways', array( &$this, 'process_admin_options' ) );

/* 2.0.0 */
add_action( 'woocommerce_update_options_payment_gateways_' . $this->id, array( $this, 'process_admin_options' ) );

This will ensure the save function kicks in on both versions of WooCommerce.

The second change is dynamic loading, and this can be a bit more involved. Basically, in the name of optimisation gateways are only loaded when needed. If you have an IPN like function (on ‘init’ for example) it may no longer be triggered. Therefore to get around this, use WC-API.

WC-API callbacks

Callbacks should be in the below format:

http://yoursite.com/?wc-api=WC_Gateway_Your_Gateway_Class

WooCommerce will see this callback, init the class passed to wc-api, and then trigger an action:

woocommerce_api_wc_gateway_your_gateway_class

Hook into that via your payment gateway and you can do your required actions.

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

Order statuses

If your gateway leaves an order in pending status you are #doingitwrong. Pending is unpaid, and as of WC 2.0, unpaid orders will be cancelled after x hours.

Changes to WC_Product classes

Probably the change most likely to break sites is the WC_Product class – this is now abstract and extended by specific product classes depending on product type. Do not initiate WC_Product – it will cause a fatal error in 2.0.

Instead use the get_product() function. This handles product types and returns a product object to you. Below is an example of backwards compatible code for loading products:

if ( function_exists( 'get_product' ) )
$product = get_product( $post->ID );
else
$product = new WC_Product( $post->ID );

If you only need 2.0 compatibility, just use get_product on its own.

Custom field data

product_custom_fields won’t be in the product classes as of 2.0 – you can get meta just like this:

$product_class->meta_key

The meta will be loaded dynamically.

Sessions with WC 2.0

In WC 2.0 we decided to stop supporting PHP SESSIONS – you can still use them, but you’ll need your own session_start(). Your choice. The alternative however, is our new session class (which at the time of writing uses cookies and transients/options).

To set session data just use:

$woocommerce->session->your_var = 'x';

To unset data use:

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

Theme Gotchas

[box type=”alert”]Some class names containing woocommerce_ or wc- have been renamed for consistency to woocommerce- (hyphenated). You will need to replace all instances of ‘.wc-‘ or ‘.woocommerce_‘ with ‘.woocommerce-‘ in your custom stylesheet(s).[/box]

Widgets have been renamed so if you call them directly in your template, they need to be renamed. E.G. WC_Widget_Cart becomes WooCommerce_Widget_Cart.

Pulling gallery images dynamically? Re-check this, the attachment ID’s are stored in meta now.

Pagination and sorting has received an overhaul. Sorting is now before the loop and accompanied by a product count. Pagination remains beneath the loop.

Star ratings are in the loop now

Quantity inputs now use input type="number" so you will need to choose whether to hide our plus / minus buttons (added via jQuery) or hide the browser default UI. Use the following to hide the browser default:

input::-webkit-outer-spin-button, input::-webkit-inner-spin-button {
display:none;
}

Checkout form is now validated in real time adding .woocomemerce-invalid or .woocomemerce-valid
to the respective .form-row You may want to style this.

Up sells are now hooked in ahead of related products on product details pages

If your theme uses custom loops, be sure to read this.

If your theme doesn’t declare WooCommerce support a message will be displayed in the dashboard. To declare WooCommerce support in your theme add the following to your functions.php file;

add_action( 'after_setup_theme', 'woocommerce_support' );
function woocommerce_support() {
add_theme_support( 'woocommerce' );
}

Template overrides

Check *all* template overrides if you have any – many files changed so custom template are likely to cause issues. And remember to only override what you need to edit, not all templates! Some theme authors do this and it causes nothing but trouble.

The post WooCommerce 1.6.6 -> 2.0 – Plugin and theme compatibility first appeared on CODIBU.

In older versions of WooCommerce, the PayPal gateway did not check the value returned from IPN. This meant that if someone changed the payment form code during checkout, they could modify the order cost sent to PayPal without affecting the order status after payment. This cost change would be obvious from the PayPal payment notifications, however could go unnoticed.

Patching this vulnerability or upgrading to 1.6.5.2 is highly recommended.

Affected version(s)

WooCommerce 1.6.5.1 and below are affected. This issue was patched in 1.6.5.2.

Affected file(s)

woocommerce / classes / gateways / paypal / class-wc-paypal.php

Manual Patch

On line 608 of the paypal gateway, the following check needs to be added to prevent the issue:

// Validate Amount
    if ( $order->get_total() != $posted['mc_gross'] ) {

    if ( $this->debug == 'yes' )
    $this->log->add( 'paypal', 'Payment error: Amounts do not match (gross ' . $posted['mc_gross'] . ')' );

    // Put this order on-hold for manual checking
    $order->update_status( 'on-hold', sprintf( __( 'Validation error: PayPal amounts do not match (gross %s).', 'woocommerce' ), $posted['mc_gross'] ) );

    exit;
    }

The post PayPal Gateway Vulnerability + Patch – WC 1.6.5.1 first appeared on CODIBU.

Moved the main loops

The most important change is that we have moved the location of where the loops are actually started. In versions prior to WooCommerce 1.6, the loops were a part of a function, including other files. This made perfect sense for developer and users with more than average knowledge of code, but for the majority it was a maze of files and functions.

The main loops have now been moved back to archive-product.php and single-product.php.

New content parts in template files

With the new loops in place, we enabled easier override of specific parts of the templates. That is where we introduced content-product_cat.php, content-product.php and content-single-product.php. These files will be used in all archive or single pages of products, moving the way these parts look to the exact same files. In other words, you only have to make changes to one file to change how a product looks on all archives.

Removed parts of the older templates

Because we have so many new ways to work with and override the templates, some parts of the template became obsolete.

Removed template files

We stripped out a couple of template files: loop-product-cats.php and loop-shop.php.

Deprecated functions

Because of the new way the template system works, three functions have been stripped out:

• woocommerce_single_product_content()
• woocommerce_archive_product_content()
• woocommerce_product_taxonomy_content()

These functions have no alternative available since they no longer have a use. The deprecated versions of these functions will call woocommerce_content() for now, providing reasonable backwards compatibility. You will not lose any functionality, but might want to polish up the looks of the files using these functions as there are better ways to do this available now.

The post Template changes in WooCommerce 1.6 first appeared on CODIBU.