Hi all! We’re excited to share that we have three new extensions for WooCommerce that were just released yesterday. Quick, grab them for 35% off within the next couple days!
First, Admin Custom Order Fields has deployed, which takes you one step closer towards using WordPress and WooCommerce as a CRM rather than just an eCommerce platform. Admin Custom Order Fields (ACOF) will allow you to create text field, drop-downs, checkboxes, and more within orders so that you can keep track of relevant customer information directly in WooCommerce. For example, let’s say you sell tours – now you can assign guides, dates, times, and other info to orders and view these fields from the order admin. You can also optionally display selected fields to customers from the “My Orders” page. Never again worry about using WooCommerce, Excel, and multiple other platforms to keep track of customer details! Keep that information where it belongs — directly with the relevant WooCommerce orders.
Next up, we have two more payment gateway integrations released. We know many of you have been waiting for Intuit QBMS (QuickBooks Merchant Services), and it’s finally come to WooCommerce. It’s being joined by a payment gateway integration for NETbilling as well. Not only do both of these integrations allow for maximum customizability and integration with your site by keeping the customer on site for the checkout process, but each fully supports WooCommerce Subscriptions and WooCommerce Pre-Orders to ensure viability for multiple businesses and billing needs. Want this to get even better? The WooCommerce NETbilling extension also supports eChecks so that you can get paid by virtually any means the customer wants; take away every excuse for the customer to say no!
Want some more info or purchase information? Check out each new extension at WooThemes.com!
The post New WooCommerce Extensions! appeared first on SkyVerge.
Your choices for easy payment processing just increased by one. SkyVerge has just released the WooCommerce Amazon Simple Pay payment gateway extension! While this extension was in the WooCommerce Extension store until about 5 months ago, it was pulled by another developer, so we’ve redesigned it from the ground up to give you the quality and security that we ensure in all of our products.
Amazon Simple Pay will allow you to process payments on your WooCommerce store using credit cards AND your customers’ Amazon balance. You gain the trust that comes from associating with the #1 online retailer, and your customers get the ease of selecting their payment method and checking out with a familiar face (so to speak).
What are the benefits to using Simple Pay?
Aside from super easy payment processing, Amazon provides a straight-forward pricing structure for all of their payment gateways (maybe you’re familiar with this if you’ve seen or used our WooCommerce Amazon FPS Payment Gateway). You’ll only pay for the transactions that you process — no monthly fees or contracts. With transaction fees of 2.9% + $0.30, Amazon Simple Pay is very competitive with major payment processors.
Finally, with Amazon Simple Pay or Amazon FPS, you avoid all PCI security requirements, which means you don’t need an SSL certificate for your store. Customers are redirected to Amazon to make payments during your checkout process, so all security requirements are handled by the same secure servers that Amazon uses to process their payments.
In short, we designed Amazon Simple Pay to offer you even more easy, secure payment processing choices for your WooCommerce store!
The post Introducing Amazon Simple Pay! appeared first on SkyVerge.
We’re very excited to announce the release of another great WooCommerce extension! We’ve just released the WooCommerce Product Documents Extension, which allows you to create an accordion-style menu to display any supplementary documentation you want to post for customers for any product in your store. Want to post some sample chapters and images for an ebook? Use Product Documents! Need to post technical specifications or assembly instructions? It’s easy! The more information you can give customers, the fewer barriers exist in the way of purchasing. Why not give them all of the information they could need up front so they’re more likely to purchase your product?
With the Product Documents extension, you can create menus for any documents you need to share under the short product description, or can embed them anywhere that shortcodes are used. The tab and document names are completely customizable. Take a look:
Some display suggestions
The possibilities for displaying documents are endless. For example, in the above image, we used the WooCommerce Tab Manager to create a custom product tab, then displayed our documents in the tab we created. You can also display documents in sidebar on the product page using the Product Documents widget, share documents among many products using the shortcode [woocommerce_product_documents product_id="123" product_sku="ABC123" title="Product Documents"], put product documentation under blog posts, and more.
Get the full details on the WooThemes WooCommerce Product Documents Extension product page!
The post New WooCommerce Product Documents Extension! appeared first on SkyVerge.
We all know that Amazon is customers’ favorite online retailer. If you take payments using the WooCommerce Amazon FPS Payment Gateway or another Amazon payment service (stand by – we’ve got another one coming out next week!), you know that the trust you gain by associating with Amazon helps convert customers, and the simple pricing structure saves you headaches when it comes to your bottom line. Now we’ve made integrating Amazon payments into WooCommerce even better with the release of Amazon FPS 2.0!
What’s Different?
First, we rebuilt Amazon FPS from the ground up to improve performance and reliability. Our goal is fewer bugs and easier support with our complete redesign. Even though it may look the same, we’ve upgraded the engine under the hood! Second, the updated Amazon FPS Payment Gateway now offers full support for WooCommerce Subscriptions and WooCommerce Pre-Orders to offer you the flexibility you need for your business.
You can now take full advantage of the WooCommerce Subscriptions extension, which allows you to set up recurring billing for your customers so you get paid on time. The best part? You and your customers have one less thing to worry about (and who doesn’t love automated revenue?). WooCommerce Pre-Orders lets you take an order and charge the customer when that order ships, converting more sales for you since it reduces the hassle for the customer and encourages them to buy your product, regardless of release date. Business owners in need of a fully capable payment processor, meet the new Amazon FPS.
Keep an eye out next week for a new release we’re very excited about — we’ve built a new Amazon Simple Pay extension that we’re sure you’ll love!
Get more details on the functionality and new features we’ve added on the WooCommerce Amazon FPS Payment Gateway extension product page.
The post WooCommerce Amazon FPS 2.0 Release (and New Features!) appeared first on SkyVerge.
“Why, sometimes I’ve believed as many as six impossible things before breakfast.”
― Lewis Carroll, Alice in Wonderland
A few months ago, we were working on the WooCommerce Pre-Orders extension and had to think about how we wanted to store the release date & time. Like most concepts that look simple and easy at first, this turned out to be somewhat complex. Throughout development, I ended up learning quite a bit about working with timezones inside WordPress. This article should help you understand how to work with timezones inside WordPress better and give you some time-saving shortcuts.
So back to our Pre-Orders example. First, store admins expect the date & time to be displayed in the same timezone as they’ve set for the site, but this makes determining when a pre-order needs to be released (and automatically charging all those saved credit cards) complicated and potentially unreliable. If the site timezone is changed at some point, there’s no way to know what the old timezone was, unless we store it along with the date & time itself. If it’s stored, then we need to do some calculations each time we check if the pre-order needs to be released. Not really our best option.
Instead let’s save the release date & time as a unix timestamp, which has no timezone (technically it’s UTC, but not exactly). This really simplifies our process to check if a pre-order should be released — a simple call to time() and we can compare it against the release timestamp. Easy-peasy!
But wait, now we have to convert the release date & time entered by the admin for the pre-order into a unix timestamp. The first try was something like $timestamp = strtotime( $release_datetime );, but this is wrong because strtotime uses the default timezone set in PHP which may or may not be the same as the actual site timezone set within WordPress.
What we need to do is grab the site timezone and then create a unix timestamp of the release date & time:
try {
// get datetime object from site timezone
$datetime = new DateTime( $datetime_string, new DateTimeZone( get_option( 'timezone_string' ) );
// get the unix timestamp (adjusted for the site's timezone already)
$timestamp = $datetime->format( 'U' );
} catch ( Exception $e ) {
// you'll get an exception most commonly when the date/time string passed isn't a valid date/time
}
This makes use of the neat DateTime class, which is available in PHP 5.2+ (making it safe for use with WP) and works great except for one small problem. When the site timezone is set to a UTC offset instead of a timezone, get_option( 'timezone_string' ); is blank, which throws an exception. Argh. Now we need some reliable way to get the site’s timezone string even if it’s set to a UTC offset. It turns out that WordPress has no built-in function to make this happen. Let’s make one:
/**
* Returns the timezone string for a site, even if it's set to a UTC offset
*
* Adapted from http://www.php.net/manual/en/function.timezone-name-from-abbr.php#89155
*
* @return string valid PHP timezone string
*/
function wp_get_timezone_string() {
// if site timezone string exists, return it
if ( $timezone = get_option( 'timezone_string' ) )
return $timezone;
// get UTC offset, if it isn't set then return UTC
if ( 0 === ( $utc_offset = get_option( 'gmt_offset', 0 ) ) )
return 'UTC';
// adjust UTC offset from hours to seconds
$utc_offset *= 3600;
// attempt to guess the timezone string from the UTC offset
$timezone = timezone_name_from_abbr( '', $utc_offset );
// last try, guess timezone string manually
if ( false === $timezone ) {
$is_dst = date( 'I' );
foreach ( timezone_abbreviations_list() as $abbr ) {
foreach ( $abbr as $city ) {
if ( $city['dst'] == $is_dst && $city['offset'] == $utc_offset )
return $city['timezone_id'];
}
}
}
// fallback to UTC
return 'UTC';
}
Much better! Now we can just replace our code above with this new function:
try {
// get datetime object from site timezone
$datetime = new DateTime( $datetime_string, new DateTimeZone( wp_get_timezone_string() );
// get the unix timestamp (adjusted for the site's timezone already)
$timestamp = $datetime->format( 'U' );
} catch ( Exception $e ) {
// you'll get an exception most commonly when the date/time string passed isn't a valid date/time
}
Boom. A WordPress-friendly way to convert a date & time string into a unix timestamp. Let’s consider the opposite direction now. What if we need to convert a unix timestamp (remember unix timestamps are in UTC timezone) back into a timestamp adjusted the site’s timezone? We’ll need to add the timezone offset (in seconds) to the unix timestamp:
try {
// get datetime object from unix timestamp
$datetime = new DateTime( "@{$timestamp}", new DateTimeZone( 'UTC' ) );
// set the timezone to the site timezone
$datetime->setTimezone( new DateTimeZone( wp_get_timezone_string() ) );
// return the unix timestamp adjusted to reflect the site's timezone
return $timestamp + $datetime->getOffset();
} catch ( Exception $e ) {
// something broke
}
This works by creating a new DateTime object from the stored timestamp. The @ in this "@{$timestamp}" syntax means that the string is a timestamp. The timezone for the object is then set to the site’s timezone, which ensures that the DateTime::getOffset() method returns the proper offset (in seconds) for the site’s timezone. As an example, this will return -14400 when the site’s timezone is set to EST or UTC-4.
However, timestamps aren’t very useful for displaying to a customer, so let’s use the ever-useful date_i18n() and the date_format option to format the date properly for display:
date_i18n( get_option( 'date_format' ), $timestamp );
This will display something like “August 21, 2013″. If you wanted to add on the time, you could use the time_format option along with date() function:
date( get_option( 'time_format' ), $timestamp );
That’s it! Have questions about timezones and WordPress? Let us know in the comments!
Photo Credit: leoplus via Compfight cc
The post Down the Rabbit Hole: WordPress and Timezones appeared first on SkyVerge.
WooCommerce 2.0 introduced a lot of new features to the core plugin, one being a new class-based implementation for emails. This makes it really easy to add your own custom email types to WooCommerce. In this article, we’re going to create a sample custom email that’s sent when an order with expedited shipping is received. A lot of larger sites disable new order emails if they receive a lot of orders, but most will still want to be aware of orders that need to be shipped immediately. Feel free to skip to the completed plugin if you want to simply use it as a base for your own custom email 
First, add a folder to your site’s wp-content/plugins directory named woocommerce-expedited-order-email. Fire up your favorite text editor or IDE and then create a blank PHP file named woocommerce-expedited-order-email.php. Now add this code to the file and save:
<?php
/**
* Plugin Name: WooCommerce Custom Expedited Order Email
* Plugin URI: http://www.skyverge.com/blog/how-to-add-a-custom-woocommerce-email/
* Description: Demo plugin for adding a custom WooCommerce email that sends admins an email when an order is received with expedited shipping
* Author: SkyVerge
* Author URI: http://www.skyverge.com
* Version: 0.1
*
* License: GNU General Public License v3.0
* License URI: http://www.gnu.org/licenses/gpl-3.0.html
*
*/
if ( ! defined( 'ABSPATH' ) ) exit; // Exit if accessed directly
If you’ve never done this before, congrats on creating your first WordPress plugin We won’t cover much else about creating WordPress plugins in the rest of this article, so if you want to learn more about that, the best place to start is Writing a Plugin in the WP codex. Finally, browse to Plugins page in the WordPress admin and activate the plugin. Wheee, it’s aliiiveeeee! Sadly it doesn’t do anything yet. Deactivate the plugin and read on.
WooCommerce loads all the default emails inside the WC_Emails class. These class names are run through a the woocommerce_email_classes filter, which allows us to add our own custom email class, or even remove default ones that aren’t needed. We’re going to add a custom one using a simple function:
/**
* Add a custom email to the list of emails WooCommerce should load
*
* @since 0.1
* @param array $email_classes available email classes
* @return array filtered available email classes
*/
function add_expedited_order_woocommerce_email( $email_classes ) {
// include our custom email class
require( 'includes/class-wc-expedited-order-email.php' );
// add the email class to the list of email classes that WooCommerce loads
$email_classes['WC_Expedited_Order_Email'] = new WC_Expedited_Order_Email();
return $email_classes;
}
add_filter( 'woocommerce_email_classes', 'add_expedited_order_woocommerce_email' );
Add this code to your woocommerce-expedited-order-email.php after the above section. This simply adds our custom email class to the list of emails that WooCommerce loads. Note that if you tried to activate and run the plugin, you’ll get a fatal error because we haven’t actually created our custom email class yet. If you don’t quite understand how this works, read this article on using filters.
Now the real fun begins! We’re going to build our custom email class that will handle the actual email content as well as the trigger for when it should be sent. Create a new folder named includes inside the existing woocommerce-expedited-order-email folder and add a new blank PHP file named class-wc-expedited-order-email.php. Add this code which will act as a very basic skeleton:
<?php
if ( ! defined( 'ABSPATH' ) ) exit; // Exit if accessed directly
/**
* A custom Expedited Order WooCommerce Email class
*
* @since 0.1
* @extends \WC_Email
*/
class WC_Expedited_Order_Email extends WC_Email {
} // end \WC_Expedited_Order_Email class
This code creates a simple email class that extends the abstract WC_Email, which gives us access to all of the parent email class methods & members. We’ll override some of them to make the class specific to our needs. Note that the following code should all go inside the class we just created above. Let’s start with the constructor:
/**
* Set email defaults
*
* @since 0.1
*/
public function __construct() {
// set ID, this simply needs to be a unique name
$this->id = 'wc_expedited_order';
// this is the title in WooCommerce Email settings
$this->title = 'Expedited Order';
// this is the description in WooCommerce email settings
$this->description = 'Expedited Order Notification emails are sent when a customer places an order with 3-day or next day shipping';
// these are the default heading and subject lines that can be overridden using the settings
$this->heading = 'Expedited Shipping Order';
$this->subject = 'Expedited Shipping Order';
// these define the locations of the templates that this email should use, we'll just use the new order template since this email is similar
$this->template_html = 'emails/admin-new-order.php';
$this->template_plain = 'emails/plain/admin-new-order.php';
// Trigger on new paid orders
add_action( 'woocommerce_order_status_pending_to_processing_notification', array( $this, 'trigger' ) );
add_action( 'woocommerce_order_status_failed_to_processing_notification', array( $this, 'trigger' ) );
// Call parent constructor to load any other defaults not explicity defined here
parent::__construct();
// this sets the recipient to the settings defined below in init_form_fields()
$this->recipient = $this->get_option( 'recipient' );
// if none was entered, just use the WP admin email as a fallback
if ( ! $this->recipient )
$this->recipient = get_option( 'admin_email' );
}
This sets up the email and adds a title and description that’s displayed under WooCommerce > Settings > Emails. It also sets a default heading/subject for the email and defines the templates used when sending the email. Much of these defaults are the same as the default new order email. Finally, it adds the triggers for when the email should be sent. In our case we’re simply sending the email when an order moves from the “pending”/”failed” to “processing” order status. Let’s add the trigger method now, which is where the email is actually sent:
/**
* Determine if the email should actually be sent and setup email merge variables
*
* @since 0.1
* @param int $order_id
*/
public function trigger( $order_id ) {
// bail if no order ID is present
if ( ! $order_id )
return;
// setup order object
$this->object = new WC_Order( $order_id );
// bail if shipping method is not expedited
if ( ! in_array( $this->object->get_shipping_method(), array( 'Three Day Shipping', 'Next Day Shipping' ) ) )
return;
// replace variables in the subject/headings
$this->find[] = '{order_date}';
$this->replace[] = date_i18n( woocommerce_date_format(), strtotime( $this->object->order_date ) );
$this->find[] = '{order_number}';
$this->replace[] = $this->object->get_order_number();
if ( ! $this->is_enabled() || ! $this->get_recipient() )
return;
// woohoo, send the email!
$this->send( $this->get_recipient(), $this->get_subject(), $this->get_content(), $this->get_headers(), $this->get_attachments() );
}
This is where the magic happens! This method passes in the Order ID, which we use to instantiate a new WC_Order. With this object we can then check if the shipping method is expedited. In this example, simple flat rate shipping is used, but you could just as easily check the shipping ID if FedEx/UPS was being used. If the shipping method isn’t expedited, we return which prevents the email from being sent. We’re not quite finished with the class yet, we still need to define the content that is used for the email:
/**
* get_content_html function.
*
* @since 0.1
* @return string
*/
public function get_content_html() {
ob_start();
woocommerce_get_template( $this->template_html, array(
'order' => $this->object,
'email_heading' => $this->get_heading()
) );
return ob_get_clean();
}
/**
* get_content_plain function.
*
* @since 0.1
* @return string
*/
public function get_content_plain() {
ob_start();
woocommerce_get_template( $this->template_plain, array(
'order' => $this->object,
'email_heading' => $this->get_heading()
) );
return ob_get_clean();
}
These are copied from the default Admin New Order email because we’re using the same exact template. If you were using a custom template, these methods are helpers to pass whatever data you need to the custom template. Note here they are passing the order object and the email heading string.
Finally we need to define the settings for the email, so an admin can easily change the recipients or subject/headings, or disable the email altogether. This code is again copied from the default Admin New Order email class:
/**
* Initialize Settings Form Fields
*
* @since 0.1
*/
public function init_form_fields() {
$this->form_fields = array(
'enabled' => array(
'title' => 'Enable/Disable',
'type' => 'checkbox',
'label' => 'Enable this email notification',
'default' => 'yes'
),
'recipient' => array(
'title' => 'Recipient(s)',
'type' => 'text',
'description' => sprintf( 'Enter recipients (comma separated) for this email. Defaults to <code>%s</code>.', esc_attr( get_option( 'admin_email' ) ) ),
'placeholder' => '',
'default' => ''
),
'subject' => array(
'title' => 'Subject',
'type' => 'text',
'description' => sprintf( 'This controls the email subject line. Leave blank to use the default subject: <code>%s</code>.', $this->subject ),
'placeholder' => '',
'default' => ''
),
'heading' => array(
'title' => 'Email Heading',
'type' => 'text',
'description' => sprintf( __( 'This controls the main heading contained within the email notification. Leave blank to use the default heading: <code>%s</code>.' ), $this->heading ),
'placeholder' => '',
'default' => ''
),
'email_type' => array(
'title' => 'Email type',
'type' => 'select',
'description' => 'Choose which format of email to send.',
'default' => 'html',
'class' => 'email_type',
'options' => array(
'plain' => 'Plain text',
'html' => 'HTML', 'woocommerce',
'multipart' => 'Multipart', 'woocommerce',
)
)
);
}
You can add your own settings here by following the same array format as above. And with that, we’re finished! Head over to the Plugins page and click “Activate”. Assuming you haven’t made any errors, you should see “plugin activated”. Go to WooCommerce > Settings > Emails and you should see our new email added:
Woohoo! There’s a lot more to the WooCommerce email system and I encourage you to read through the different email types on the WooCommerce repository to more fully understand them.
The completed plugin from the walkthrough above is available on Github, or you can just download a zip.
Have questions or ideas for a custom email? Let us know in the comments!
The post How to Add a Custom WooCommerce Email appeared first on SkyVerge.
We know you’ve been waiting for a full-fledged WooCommerce API, and while that particular piece of greatness is still a few months away (see this Github issue for details), we’ve developed a simple XML-RPC API to help you start integrating WooCommerce with your backend systems today. This has been tested over the past few months with a handful of clients and we’re ready to release it to the world.
Currently it only supports updating order status and order tracking (most helpful when used with the WooCommerce Shipment Tracking extension), but we’re planning more API calls. To get started, just download and install the plugin and add a user with at least the “Editor” role. Follow the steps for testing on the comprehensive readme. We’ll be adding to the WordPress.org plugins repository in the future.
Want to contribute code or bug reports? Head on over to the WooCommerce XML-RPC API repo.
Go forth and integrate!
The post Introducing the WooCommerce XML-RPC API appeared first on SkyVerge.
UPDATE 2013-08-05: Since we published this, WooThemes has decided to offer the choice to existing customers whether they want to grandfather their unlimited licenses in or not. Read the update post
Full Disclosure: Our company derives the majority of its income from sales of WooCommerce plugins we’ve written, and by performing WooCommerce-related client projects. Still, we think we can be fairly impartial as it’s not like we have someone ordering us around to build WooCommerce plugins, we chose and continue to choose to focus the majority of our time on WooCommerce plugins and projects rather than pursuing some other opportunity.
Today WooThemes announced totally new pricing / licensing for their premium WordPress themes/plugins and WooCommerce extensions. With over 270 comments (and growing) on the announcement post, there is a clearly a lot of positive and negative opinions on the change. Let’s try and break it down and share our perspective as developers. We’re going to focus on extensions since that’s what we know.
All extensions have been raised by $20 (with a few exceptions) and a select few have been raised by $99 (most notably WooCommerce Subscriptions and Product CSV Import Suite). Since price increases fund development for new features and stability/performance fixes, let’s look at one of the most popular, and most complex WooCommerce extensions, WooCommerce Subscriptions, to give us a way of thinking about the pricing/licensing changes.
The Lifecycle of an Extension
Released in June 2012, the WooCommerce Subscriptions extension has been around for just over a year. In that time, it’s seen 21 minor updates and 3 major updates. That’s an update about once every two weeks. These updates have ranged from simple bug fixes to massive feature additions. Since we have some experience in estimating the time required to build and update WooCommerce extensions, let’s do some guessing at the time the developer spent (note we’ll be using the subscriptions changelog for reference, so feel free to follow along if you’d like):
Minor Updates — minor features and simple bug fixes typically require 1-3 hours, unless you’re including the time it takes to find and reproduce the bug. We’ll be conservative and say 2 hours per item. A quick glance at the changelog shows about 3 features/bug fixes per update. So, let’s guess each minor update required about 6 hours.
Note that we’re excluding testing, QA, communication with customers affected by the bugs, deploying the update, etc. These extra tasks are non-trivial and can easily double the total amount of time spent.
So overall, minor updates total 126 hours (21 minor updates x 3 features/bug fixes per update x 2 hours per feature/bug fix)
Major Updates — now were getting to the big stuff. Major updates typically involve rewrites to pieces of the extension in order to add features requested by customers that are complex to implement, as well as a long list of tiny features and bug fixes. As an example, the latest major release of the Subscriptions plugin included 25 items on the changelog, ranging from WooCommerce 2.0 support (not a simple task) to improving shipping strings.
Remember that the changelog doesn’t detail all of the actual changes, only the ones that are worth writing about, so the actual list of changes is much, much longer. Now let’s try to take a guess at the amount of time spent developing these updates.
Based on our experiencing writing major updates for our own extensions, a conservative guess is 50 hours of development time per update. So these 3 updates represent about 150 hours total.
So, with just updates alone, we’re estimating that the developer spent 276 hours. But wait, we’re forgetting the time invested to actually build the extension in the first place! Let’s make a rough estimate of 150 hours, based again on our own experience building an extension of similar complexity. Now comes the fun part. How much would it cost you to have a developer build and maintain an extension like this for you?
UPDATE: Brent Shepherd, the developer of WooCommerce Subscriptions extension, has confirmed the actual time spent for updating the extension is over 1,000 hours. See his comment below.
We’ve seen hourly rates for experienced WordPress developers in the $65 to $125 range, so let’s pick a nice even $95/hour. So we take the amount of time spent to develop the extension (150 hours), add in the time spent to maintain and improve the plugin over a year (276 hours), and come up with our total hours spent.
426 hours. Wow, that sounds like a lot. Like, working every day for almost 18 days without food or sleep (which we know we can’t do, even with Mountain Dew). Yikes. Ok, now let’s multiply that by our $95 per hour rate, for a grand total of $40,470.
Is the New Pricing Still a Good Value?
Clearly the new $199 price is still quite a bargain compared to paying a developer to build it (or even simply maintain it). When you factor in a year of support and automatic upgrades, it becomes even more compelling. But what about the renewal cost after the first year?
Let’s assume the next year follows the first year. The extension will see another 20 or so minor updates and 3 major updates representing about 275 hours of development time. The extension will work with the latest version of WooCommerce and it’ll have new features and fixes that have significantly improved it over last year’s version.
Now, in order to get access to the updates (and support), you’ll need to renew your license. The cost will be roughly 50% of the original cost, or $100. The cost of development time to maintain and improve the extension over time was roughly $26,125 (275 hours x $95 per hour), so you continue to get a significant bargain over what it would cost to build this yourself.
Obviously this is an extreme example of a very complex extension (many extensions are somewhat simpler to build and maintain, though not always support ;)), but the principle remains the same. The value that these extension provide far exceeds their cost, even when factoring in an annual cost.
Future with WooCommerce?
In spite of (and in some ways because of) the recent pricing and licensing changes we still believe WooCommerce is the best eCommerce solution out there in terms of functionality, ease of use, and yes — cost. The reality is that WooTheme’s policy of unlimited support and updates for a one-time price was unsustainable (see this comment), something we’ve been witness to first hand as a de-facto tier 2-3 support team for our roughly 40 extensions. Since each sale previously resulted in a one-time revenue for WooThemes, with a potentially unlimited support liability, it simply became an untenable situation.
Running a business is difficult, you start out with one idea or plan and before you know it you’re doing something else entirely, and you almost always have to make corrections along the way, sometimes even large ones. It’s going to be far better for shop owners that WooThemes charge a higher premium and still be around 5, 10, 15 years from now to continue to support merchants, than it would be for WooThemes to find themselves in an unsustainable position and have to shut the whole program down or take other drastic measures.
We realize how unfortunate and unexpected this is for people who previously purchased and expected unlimited usage or support, and there’s not a whole lot that can be said, besides that we truly believe WooThemes is doing what they feel they must in order to create a lasting business.
This can be seen in their honest disclosure that they don’t know how much of a discount they’re going to be able to provide for early renewals at this point, they want to base that on the level of support and maintenance costs actually incurred by a plugin, rather than saying that all plugins renew at say a flat rate of 80% of price.
In the end these changes will discourage some would-be and even previously loyal customers who will seek out other alternatives, and there’s nothing wrong with that; no single solution can or should serve everyone. The bottom line is we believe these changes will make WooThemes as a company, and WooCommerce as an ecosystem, stronger than it was before. Those who find sufficient value in the work that the 30-odd WooThemes employees, and roughly 50 third-party developers perform day-in and day-out, will continue to choose WooCommerce.
We won’t be going anywhere, and hope neither will the majority of WooThemes customers when all is said and done.
— Max & Justin
The post Our Thoughts on the New WooThemes Pricing appeared first on SkyVerge.
