The plugin WP eCommerce (WPEC) by default provides regions such as states or provinces for only a few countries, for example Canada and the US. This means that for countries like Australia which have no regions in WPEC, the user has to manually type in their state or territory name at checkout.
Checkout form without drop down list
The follwing post describes how we added regions for a country not provided for by the WPEC plugin. After these changes have been made we can select the state or territory name from a drop down list at checkout. It also appears to now be possible to set individual state or territory taxes – although we did not explicitly test this as it’s not applicable to the country we are configuring here.
In the example below, we’re adding the eight state and territory regions for Australia to the WPEC plugin. All database queries and updates were performed by logging into our web hosting cPanel and using the phpMyAdmin application to access the database.
(1) The first step is to make a backup of the website database.
The changes below include manual updates to the WPEC database tables so we need to ensure there’s a regression path if something goes wrong.
(2) Find the two digit region codes for the country to be updated.
Some countries have two digit region codes and some don’t seem to. We couldn’t find on the internet any for Australia so we used the 6 digit codes we found eg AUS-NS for New South Wales and just dropped the leading ‘AUS-‘ part.
Using this approach our two character region codes are :-
Australian Capital Territory = CT
New South Wales = NS
Northern Territory = NT
Queensland = QL
South Australia = SA
Tasmania = TS
Victoria = VI
Western Australia = WA
(3) Find out the ‘country ID’ for the country being updated.
Using phpMyAdmin to look in the table wp_wpsc_currency_list shows that the country ID for Australia is 137.
(4) Add the states and territories to the database.
Using phpMyAdmin the table wp_wpsc_region_tax needs to be appended to with 1 new row per state or territory. The table structure is:-
id – an incremental counter (in our installation was currently up to row 64)
country_id – the unique number allocated to each country in WPEC
name – the state name
code – a two digit region code
tax – defaults to 0
We entered data for the 8 new rows manually in alphabetical order (just in case WPEC doesn’t sort the table on selection). Here’s the sql that was generated by phpMyAdmin to add the Australian states and territories to the table.
INSERT INTO `enter-your-database-name-here`.`wp_wpsc_region_tax` (`id`, `country_id`, `name`, `code`, `tax`) VALUES (’65’, ‘137’, ‘Australian Capital Territory’, ‘CT’, ‘0’), (’66’, ‘137’, ‘New South Wales’, ‘NS’, ‘0’), (’67’, ‘137’, ‘Northern Territory’, ‘NT’, ‘0’), (’68’, ‘137’, ‘Queensland’, ‘QL’, ‘0’), (’69’, ‘137’, ‘South Australia’, ‘SA’, ‘0’), (’70’, ‘137’, ‘Tasmania’, ‘TS’, ‘0’), (’71’, ‘137’, ‘Victoria’, ‘VI’, ‘0’), (’72’, ‘137’, ‘Western Australia’, ‘WA’, ‘0’);
(5) Set two flags in the region table so WPEC knows to use the regions.
The wp_wpsc_currency_list table was updated so WPEC will use the new regions.
Changed the field `has_regions` to 1 (was 0)
Changed the field `visible` to 0 (was 1)
(6) Change the layout of the checkout forms so country comes before state.
On the checkout page the billing and shipping addresses usually (by default) show State followed by Country. However, state drop down selection is only available after a country is selected so we reversed those fields. In the WPEC back end (WP Admin, Settings –> Store –> Checkout) we moved the country field up above the state field and saved the change.
(7) Set the tax regions for the updated country.
In Australia the GST tax rate is the same in every state and territory so no region changes were needed in the tax settings. We just needed to save the Tax rate as 10% for ‘All Markets’ in the WPEC backend (WP Admin, Settings –> Store –> Taxes).
After the above changes were made Australian shoppers can now select their state or territory from a dop down list.
Checkout form with drop down list and Country moved above State
When we first made these changes they didn’t seem to work. Looking at the tables it seems that somehow the `visible` field in table wp_wpsc_currency_list was still set to the old value of 1 (i.e. don’t display). We changed that back to 0 and this time it all worked ok.
Like any change, we didn’t make this to a live system. We created a staging site where the changes were made and tested. They worked for us but that’s no guarantee they’ll work ‘as is’ for everyone. The changes were made and tested on a system running WordPress 4.2.2 and WP eCommerce (WPEC) 3.9.4.
It’s potentially possible our database updates might conflict with a WPEC upgrade at some later point if they (WPEC) decide to add regions for the country we’ve configured. We always test WPEC upgrades in a staging service so any problem should become apparent there and the manual updates removed if necessary.
Since installing the Elegance Theme from Storefront Themes on client sites the vistor statistics records show unusual URL’s being recorded.
We use the Visitor Maps and Who’s Online 184.108.40.206 plugin to provide basic site visitor stats on a customers USANA Canada and USANA NZ health product sites. Both sites use the Elegance 1.4.5 theme on top of WP e-Commerce plugin. The Canadian site has only ever been using Elegance while the NZ site was migrated to Elegance from Thesis a few days ago.
On looking at the visitor stats for both sites the field “Last URL” nearly always shows the URL /wp-content/themes/storefront-elegance-1.4.5/styles/default.css. On other sites we’ve built without the Elegance theme and on the New Zealand site prior to its migration to Elegance the “Last URL” field contains proper site URL’s, not the style sheet file being reported.
The following screen capture shows what our Vistor Stats look like with Elegance installed.
How Visitor Stats display with the Elegance Theme installed.
We are assuming that for now that this is an interaction issue with the Elegance Theme so will raise this with Storefront Themes support and post their response here when available.
Update: 14 Oct 2012.
I’ve been very remiss in posting the response that Elegance support gave to the query I raised on the issue detailed. They came back quickly (unlike my update here!) with the following suggestion to circumvent the problem.
“Try making the folder ‘styles’ and adding a CSS file ‘default.css’ to it. make sure it has a comment in it as Opera does not like completely empty CSS files. Just something like
/*deliberately empty css file*/”
They have subsequently advised that this issue will be addressed in the forthcoming update of the Elegance theme so thats good news. I have to say that the support team for Elegance (Mark and Matt) are excellent and can highly recommend the theme to other users of the WP e-Commerce plugin. Not only do they handle support queries promptly they also will help users extend/customise the theme. I’ve also seen in the support forum where they will answer a support request and then also offer advice on how to correct another issue unrelated to the theme. It’s very nice to see such a professional level of support being provided.
Update: 6 Nov 2013.
It appears that the level of support provided by the Elegance support team has diminished since our last update to this post in Oct 2012.
In the Elegance support forum there are many support requests that do not appear to be responded to in a timely manner. One person we work directly with is intending to move off Elegance due to a lack of support and similar comments appear in the support forum. We therefore can not recommend this theme to our site visitors and have removed our Affiliate links for the Theme from this site.
How we migrated off the Thesis WordPress Theme on a site using the WP e-Commerce Plugin.
Start point: Thesis 1.8, WPEC 3.7.8, WordPress 3.2.1
End Point: Elegance 1.4.5 , WPEC 220.127.116.11, WordPress 3.4.1
The Thesis theme and the WP-eCommerce plugin do not tend to work well together. As a result we’ve been unable to upgrade a clients ecommerce site using WPEC because of various issues encountered due to the incompatibilty of Thesis and WPEC.
In order to uprgrade we needed to select a replacement theme for Thesis to run the store. The essential requirement was that it is WPEC compliant. After looking at several themes we chose Elegance from Storefront Themes.
After upgrading the development site in the ‘normal’ manner we encountered problems where some CSS was being loaded from several places causing inconsistant page layouts (the page would be part old style part new style). This was particularily noticeable on the checkout page.
After investigating the problems we restored the service to its previous state and started again. The following process was followed and resolved all our issues (not all steps below are mandatory and there’s probably some flexibilty in the order)
(1) Activate theme 2010.
(2) In the WPEC settngs under the Presentation tab ensure the (WPEC) Theme is set to “Default Theme”.
(3) Remove Thesis theme and any Thesis specific plugins (eg. Thesis OpenHook)
(4) Flush theme cache and basic site check.
(5) Upgrade WPEC (decativate current version, ftp up latest version and activate)
(6) In webhosting (or using ftp) rename folder /uploads/wpsc/themes to another name (eg. themes-hide)
(7) Flush theme cache and basic site check.
(8) Install and activate new theme (Elegance 1.4.5 in our case).
(9) Flush theme cache and basic site check.
(10) Configure new theme.
(11) Upgrade to the latest WP release.
We tested this process twice and didn’t encounter any issues. If you find any broken links you should try re-saving your Permalinks settings (twice). The key steps for us seemed to be (2) and (6) – without those we were getting some CSS loaded by the theme and some loaded (iShop) by WPEC . After following the process above all CSS was loading from the correct locations. This worked for us but may or may not work for you. As always, before making updates take backups and test it first in a development service.
Problem: SEO Smart Links Corrupts HTML.
There appears to be a problem when using SEO Smart Links and WP eCommerce together where the H3 class statement formating the product names becomes corrupted on the Products Page. Instead of the class being defined as class=”product-name” with SEO Smart Lnks installed it becomes class=”\"product-name\"”. I tested the three themes below and the corruption appears in all of them.
WordPress Version: 3.3.1
SEO Smart Links Version: 1.1.7 (http://www.prelovac.com/vladimir/wordpress-plugins/seo-smart-links)
WP eCommerce Version: 18.104.22.168.2 (http://getshopped.org/)
Theme: Mazine 1.5.0 (http://transparentideas.com/)
Theme: Storefront Elegance 1.4.5 (http://www.storefrontthemes.com/)
Theme: Twenty Ten 1.4 (http://wordpress.org/)
Depending on the theme in use this corruption can cause the product names to appear styled incorrectly for the theme style. In Mazine for example it causes the product names to be displayed in large font and all in upper case. The problem does not appear on product category pages or on individual product pages.
The following screen shot shows the effect of this problem while using the Mazine theme. The product on the left has had its HTML edited using Firebug to restore the correct formating while the product on the right has been left as is showing the impact of SEO Smart Links on the product name.
SEO Smart Links Corrupts HTML
Adding your WP eCommerce products page (usually “products-page”) to the Ignore Posts and Pages setting in SEO Smart Links circumvents this problem.
We will query this issue with the SEO Smart Links developer and update the post with their reply when available.
WordPress Version: 3.3.1
WP-eCommerce Version: 22.214.171.124.2
Plugin Author: GetShopped / Instinct
WPEC Transaction Results Layout
When using WPEC 126.96.36.199.2 the Transaction Results Page is built from three different parts of WPEC – two from with-in WPEC configuration settings and one from WPEC code.
The following screen capture shows the three areas of the tranasaction results page and where the content for those areas is sourced from.
WPEC Transaction Results Layout
Having used WPEC on a number of sites I find that the way the layout of the transaction results is built to lack flexibility.
Issue 1: As the top section of the transaction results layout is hard coded in a php program it’s always present and its content is fixed. Given this content could simply be supplied by the user in either the gateway settings under the Payments tab or in the purchase receipt settings under the Admin tab I fail to see what possible use it serves and why the authors of WPEC would bother setting it up. It also tells the customer they will be receiving an email once the order clears but orders don’t clear, payments clear. It also assumes we will be emailing our customer at that time but that might not necessarily be the case.
Issue 2: The bottom section of the transaction results page is also somewhat of an issue because the content is set once and it then applies to all the payment gateways. It would be very useful if each payment gateway could have its own purchase receipt content. How would this be helpful? One example would be: a number of WPEC users (myself included) have wanted to use WPEC to allow users to request quotes for some products. Having unqiue settings would allow a ‘quote’ payment gateway to be setup which does nothing but send the site admin and customer an email.
Issue 3: Another issue I’ve run into is that sometimes you want the content to only be displayed on the WPEC transaction results page but presently the content is displayed on that page and also emailed to the customer.
These are pretty straight forward changes (especially the first one) so hopefully the WPEC team will look into implementing them in a future release.