Fatal Error WPSC_Countries

website is http://www.swgameproduction.com and it is hosted by godaddy. tried to install the pugin but couldnt. i keep getting an error. I am not really a backend software guy…. any chance you could access it and take a look for yourself?

all of the above is complete giberish to me. I would have no idea on how to approach fixing any of these issues.

Like squbrossi, I used the site check-up plug-in and got some similar results, plus an ominous warning at the top. Also like squbrossi, I have no comprehension of these results:
Warning: Memcache::connect(): Can’t connect to 127.0.0.1:11211, Connection refused (111) in /home/content/p3pnexwpnas01_data02/22/2223122/html/wp-content/plugins/site-check-up-for-wp-ecommerce/cleanup-actions.php on line 249
Could not connect to memcache server
WP-e-Commerce
WPeC Products 17
WPeC Variations 0
Orphaned WPeC Variations 0
WPeC Pages Permalinks
[productspage] http://plymouthcraft.org/?page_id=1256
URL is OK 4.0 seconds
[productspage] secure https://plymouthcraft.org/?page_id=1256
URL check failed SSL: certificate subject name ‘*.gdhperf.com’ does not match target host name ‘plymouthcraft.org’
[shoppingcart] http://plymouthcraft.org/?page_id=1258
URL is OK 1.9 seconds
[shoppingcart] secure https://plymouthcraft.org/?page_id=1258
URL check failed SSL: certificate subject name ‘*.gdhperf.com’ does not match target host name ‘plymouthcraft.org’
[transactionresults] http://plymouthcraft.org/?page_id=1259
URL is OK 1.6 seconds
[transactionresults] secure https://plymouthcraft.org/?page_id=1259
URL check failed SSL: certificate subject name ‘*.gdhperf.com’ does not match target host name ‘plymouthcraft.org’
[userlog] http://plymouthcraft.org/?page_id=1260
URL is OK 1.3 seconds
[userlog] secure https://plymouthcraft.org/?page_id=1260
URL check failed SSL: certificate subject name ‘*.gdhperf.com’ does not match target host name ‘plymouthcraft.org’

Any ideas?
Thanks

hi tmjea,

I did some more work on your site this morning. What I did was add some code to WP-eCommerce that checked for corrupted data reading from the object cache. We would expect that this should never happen

When corrupted data is found WP-eCommerce throws away the suspect data and re-creates it from the database.

As part of doing this work I also added some logging that writes informative messages to the debug.log file in your wp-content directory. I also enabled debug logging so that WordPress would record any errors it detects. The object cache in your installation has been re-enabled.

Here are some things to note:

1. the file WP-e-Commerce\wpsc-includes\wpsc-countries.class.php has been updated. If you install an update of WP-eCommerce you will overwrite the updates.
2. The underlying cause of the problem is still present.
3. WP-eCommerce should not be as susceptible to the error when it occurs, but other areas of your site might be.
4. Even though WordPress object caching is enabled, WordPress is reporting that it is not enabled. I know this because the function wp_using_ext_object_cache() seems to be returning false all of the time. It should be returning true
5. The site checkup plugin provides file called fatal-errors.php in your wp-content directory. It will record any really bad stuff. A number of fatal errors are being recorded.

   2015-04-12-02-52-36
   Fatal Error processing uri: /
   Item	Description
   Error	Undefined variable: htmlcod
   Errno	8
   File	/home/content/p3pnexwpnas03_data02/88/2349788/html/wp-content/plugins/wp-e-commerce-product-showroom/wp_e_showrp.php
   Line	113
   Trace
   ...n/a at line n/a function n/a ()
   
   $_REQUEST
   array (
   )

I have a suspicion that whatever the issue is the trail starts with the wp_using_ext_object_cache() not telling us that the object cache is enabled.

Jef

OK everybody, I have a theory on the bug.

Take a look at the object-cache.php for APC that is on your GoDaddy sites.

Any time the HTTP request is for an admin, ajax, rpc or cron the object cache is disabled. That would mean that if I log in as an admin, update a product, perhaps by changing the inventory, the WordPress meta cache would not be updated, But the database would be. So inventory would be incorrect on a purchase. This problem of leaving an old copy of the data in the object cache would happen for any post meta, transient, user meta, etc.

So when we are logged in as an administrator, cached copies of data are not updated or cleared. This would be really problematic during a plugin update. For example, we do a version update of WP-eCommerce, as an administrator. The update routine clears the transient containing the country data. When this happens, because we are an admin, the database version of the transient gets cleared, not the version in APC. When a user accesses the site they get the now invalid, and potentially unreadable because of a code change, version of the transient from the object cache.

$oc_blocked_page = ( defined( 'WP_ADMIN' ) || defined( 'DOING_AJAX' ) || defined( 'XMLRPC_REQUEST' ) || defined( 'DOING_CRON' ) || 'wp-login.php' === basename( $_SERVER['SCRIPT_FILENAME'] ) );

if ( 'cli' !== php_sapi_name() && function_exists( 'apc_fetch' ) && ! $oc_logged_in && ! $oc_blocked_page ) :

See object-cache.php::24

The change to wp-content/object-cache.php line 25 being tested is this…

from:

if ( 'cli' !== php_sapi_name() && function_exists( 'apc_fetch' ) && !$oc_logged_in && !$oc_blocked_page ) :

to:

if ( true ||  'cli' !== php_sapi_name() && function_exists( 'apc_fetch' ) && !$oc_logged_in && !$oc_blocked_page ) :

You could also replace the line with

if ( function_exists( 'apc_fetch' ) ) :

or

if ( extension_loaded( 'apc' ) ) :

-jeff