Just a quick note about the Recalculating SEO Scores tool in the Yoast SEO plugin 3.0.6.
We tried running this as part of an larger upgrade in our staging service but it hung so we needed to kill it. Working on the assumption that the hang was due to a quirk with the our web hosts staging system (there are some!) we were not concerned and even if it wasn’t we didn’t see it as an issue to worry about.
Once we upgraded the live system to Yoast SEO 3.0.6 we again initiated the “Recalculate SEO scores” function from the Yoast Tools tab. Once again it hung.
The site we upgraded is a simple one and we’ve only really used Yoast SEO to set up meta descriptions and page titles. Looking at the pages and posts it was immediately apparent that we had no Focus Keywords set. We added a few, reran the “Recalculate SEO scores” and it successfully worked.
It would be nice if the Yoast tool had originally simply said that it found no Focus Keywords so there were no SEO scores to recalculate instead of just hanging. Especially given it ‘told’ us to run it in the first place.
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.
This is just a short ‘heads up’ to anyone running either of the plugins NextGEN 1.9.3 (an old version) or Statpress 1.4.3 (not updated for 12 months) that neither appear to work since my host upgraded my sites to PHP 5.5.
This isn’t to say that there is any fault with PHP 5.5 or the plugins mentioned. Both plugins are old so upgrading to a later version if available would be the likely fix for any issues encountered.
In my case as Statpress has no later version I’ve deleted that plugin. With the NextGEN gallery plugin I can’t upgrade quickly as I’ll need to investigate migrating some custom code changes so for now have downgraded the PHP version for the site running the NextGEN plugin to PHP 5.3 which has resolved the issue there.
Review of the performance impact of the WP SlimStat Version 3.6.1 plugin on our WordPress website.
After moving several websites to a new server we were looking for a new WordPress statistics plugin to replace the kstats / kstats-reloaded / statpress-visitors plugins we’ve been using.
WP SlimStat is very popular and was updated recently so we decided to give it a try. While the plugin is impressive for its classy presentation and contains the statistical data you expect to find in such a plugin we do have concerns about its apparent negative impact on site performance.
We ran several tests using the PS Profiler plugin which is used to report on the performance of a sites installed plugins. The results from those tests do vary somewhat but all clearly showed that WP SlimStat has a large impact on page loading performance.
In the graphics below you’ll see that the all plugin load time was 0.189s without the SlimStat plugin and 1.734s with it installed. That may be significant enough to be visibly noticeable on the site. Plugin load time jumped to 87.4% with the plugin up from 40.5% without the plugin. MySQL queries jumped to 85 queries with the plugin from 61 queries without.
The site we tested the plugin on does use a lot of resources, so much so that it can exceed it’s host plan limits so we have to minimize overheads.
Performance is relative, for some people / sites it’s an issue and for others not as much. For ourselves, we’ve unfortunately decided to uninstall what is otherwise a cool plugin.
P3 Test Without WP SlimStat Plugin
P3 Test With WP SlimStat Plugin
This post offers a short review of our recent experience using the WP Shopping Cart Addon for the NextGEN Gallery.
The addon is a WordPress plugin (WP Simple Paypal Shopping cart) and a template file which allows you to add to your NextGEN gallery a simple shopping cart function to sell items.
Basically it provides the ability to set a price, a product description and an Add to Cart button which then appear in the caption for the NextGEN thumbnail/s. The user can Add to Cart any number of items then go to the Checkout page to review their selections and complete their payment in PayPal.
We’re not going to describe how to setup the shopping cart as that is well documented here http://www.wordpress-ecommerce.com/wordpress-shop-using-nextgen-gallery-and-wp-shopping-cart-7.
WP Shopping Cart is simple to install and easy to use, however, there are some things to be aware of.
The WP Shopping Cart Template.
The template is invoked by using shortcode [nggallery id=nn template=wp-eStore] on a gallery page (or post) and adding shortcode [wp_cart:the-product-name:price:the-product-price:end] in the Description field for the image.
Using the wp-eStore template makes the Description of the image it’s Caption and causes the Add to Cart button to appear as part of the thumbnail caption in grid view.
Whilst this is consistant with NextGEN’s – in our opinion, flawed – handling of using the Description for the Caption it can be problematic for two reasons.
(1) If like our client you use long Descriptions then that screws up the grid view appearance. The image below shows a simple version of this problem from our test site, the left hand thumbnail is what you get if you use short Descriptions, the right hand thumbnail is what you get with longer Descriptions. Our clients desciptions are in fact MUCH longer and MUCH wider than the sample shown and contain HTML formatting.
(2) If you’ve customised your NextGEN code (eg. gallery-caption.php) to facilitate having short captions and long descriptions by using the “Alt & Title Text” field (variable ‘alttext’) as the Caption rather that using the “Description” (variable ‘description’) field then the WP Shopping Cart template nullifies that change for any gallery its used on.
Essentially you can’t have long descriptions if you wish to use the WP Shopping Cart template and maintain a sensible grid view appearance. This is not a fault with the cart plugin but is unfortunately how NextGEN works by default.
WP Shopping Cart page corruption.
Most NextGEN gallery implementations work by displaying a group of thumbnails, the user clicks on one and the full size image for the thumbnail is displayed.
Our clients NextGEN galleries work slightly (and very usefully) differently to the norm. When you click on a thumbnail, you are taken to a page (generated by NextGEN) that shows a larger image and description of the image with details like the artist name, year it was taken, edition details (if applicable) and so on. Clicking on the larger image then takes you to the full sized image.
This ‘middle page’ is slightly corrupted by the WP Shopping Cart addon whereby the Add to Cart botton appears both above and below the image and the top one includes some extraneous visible HTML like characters. The image below shows an example of this (nb. the picture itself was shrunk by me to reduce the file size to make it more viewable).
WP Shopping Cart Addon and the WordPress Gallery System.
Although the WP Shopping Cart NextGen Gallery AddOn says “NextGEN Gallery” you can actually use it anywhere by installing plugin part and ignoring the NextGEN template for it. Then just put the [wp_cart…] shortcode on any page or post or other gallery you like.
We tested WP Shopping Cart Addon using the standard WP gallery system using the [wp_cart…] shortcode. It worked much better for us there than with NextGEN as WordPress uses Captions as Captions and Descriptions as Descriptions so it works perfectly.
The first image below shows an example WP gallery setting for an image using the [wp_cart…] shortcode, the second image shows the thumbnail grid view with Add to Cart button display and the final image shows what you see when a grid view thumbnail is clicked – very nice. This is really how NextGEN should work!
Overall the WP Shopping Cart Addon for the NextGEN Gallery works well for those gallery sites that use short Descriptions and where clicking a thumbnail takes you directly to the full size image. For the rest of us there are problems as note above. It works very well with the standard WordPress gallery system.
I expect the long Description problems are not easily solvable. Potentially NextGEN could be enhanced to allow shortcodes (eg [wp_cart…]) to be used in the “Alt & Title Text” field and fixed to correctly use the “Alt & Title Text” as the thumbnail caption. WP Shopping Cart could then be updated to also use the “Alt & Title Text” as its thumbnail captions. I might get keen and raise a bug report on the Caption/Description issue with NextGEN.
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.