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.
If you find your Suffusion theme custom CSS stops working then this post may help.
We recently updated a website using Suffusion 4.4.7 to WordPress to 4.3.1 from 4.1.8. After doing this there was a problem with the display of the website in particluar the NextGEN plugin photo galleries which are heavily customised.
We were using the Suffusion theme Custom Includes facility to apply our custom CSS but it seemed some (maybe all) of it was being ignored after the upgrade. Using the Firefox browser add-in Firebug to check the CSS on the fly against the website showed the custom CSS we had was still correct but it was being ignored or not applied. Clearing cache etc didn’t fix the problem.
On several other websites we look after we use the Simple Custom CSS plugin to add our own styles to override the default CSS of a plugin or theme. So, given we were in a hurry, as a test, we simply installed the Simple Custom CSS plugin and then cut/pasted the custom CSS from Suffusion into the Simple Custom CSS plugin. Refreshing the browser page/s showed that the dislay of the website was back to normal.
What the root cause of the problem was we don’t know. We like Suffusion but as we’re planning to move that website off the Suffusion theme to another one (to implement WooCommerce) we weren’t inclined to spend much time looking into the problem and so went for a quick fix.
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
In the process of upgrading a test e-Commerce website I came across a small issue with the WordPress SEO Plugin by Joost de Valk and the WP e-Commerce Plugin by Instinct Entertainment / GetShopped.
The site was running with the following software versions, WordPress 3.5.52 (http://wordpress.org), shopping cart WP e-Commerce 184.108.40.206 (http://getshopped.org/), SEO plugin WordPress SEO 220.127.116.11 (http://yoast.com/wordpress/seo/), and the Elegance Theme 1.4.5 (http://storefrontthemes.com/) in a custom grid view.
After updating to WordPress SEO 1.4.13 the WP e-Commerce Products Page on the website was blank / empty except for the header (with menus/navigation), the footer and sidebar. No products were displayed and no “Products Page” banner was displayed – the Products Page was effectively empty.
All the WP e-Commerce category pages, and individual product pages were correctly showing the products. We had a look for differences between the working pages and the non-working Products Page and saw that there was one apparent difference.
It appears that the WPEC blank Products Page was occurring on our test site because the Products Page in WordPress did not have a meta description set by us.
After entering a meta description and publishing the update the Products Page on the website correctly displayed the sites product grid view. I don’t know if the root cause of this issue lies with the WordPress SEO plugin, the WPEC plugin or the Elegance theme but the circumvention is thankfully nice and easy.