freeaanzee

I’ll chime in on this thread: the folders with exported files in /wp-content/uploads/wpallexport/exports/ seem to get deleted after a certain amount of time …

You’re welcome, enjoy the sabbatical! Code is never finished :P.

Hi,

I ran into the same problem. A quick fix is to add a meta_query for the stock status to the get_giftwrapped_products() function in woocommerce-gift-wrapper.php (L280):

$args = array(
	'post_type' => 'product',
	'post_status' => 'publish',
	'posts_per_page' => '-1',
	'tax_query' => array(
		array(
			'taxonomy' => 'product_cat',
			'field' => 'slug',
			'terms' =>  $giftwrap_category_slug->slug
		)
	),
	'meta_query' => array(
		array(
			'key' => '_stock_status',
			'value' => 'instock'
		)
	),
);

It would be better to use the new WooCommerce 3.0 product getters, and include some extra checks on e.g. backorders, but this does the trick :).

Thumbs up for the nice plugin, by the way!

• This reply was modified 7 years, 4 months ago by freeaanzee.

Wow, thanks for this solution! I got pretty frustrated by these ‘checked terms’ jumping to the top of the hierarchy in custom taxonomies. Didn’t make any sense.

I’ve wrapped an ‘is_admin()’ check around it. All seems fine!

All sync rows are gone, problem solved!

You’re right,

I should have mentioned we regularly set up a copy of our site in a development environment, whose access is IP restricted through an .htaccess file. As I forgot to disconnect my account on that site, we indeed saw some syncing errors with your external servers popping up there.

Jetpack has now been disconnected on that environment and I enabled development mode to maintain the widget visibility feature. (Awesome tip, I didn’t know that existed!) This probably explains why I saw the dev site title in my stats on WordPress.com … Visits were still tracked correctly so I didn’t bother, but I clearly should have :). Guess this explains the 400 error too, because the Jetpack servers tried to contact our restricted dev site.

Next, I reconnected our production site to WordPress.com. At first I received a “cURL error 28: Operation timed out after 1001 milliseconds with 0 bytes received” but disabling WP All Export for a while did the trick. (Thanks @nikkoboy for his reply in this topic.)

Result: the ~5k ‘jpsq_sync’ rows have been deleted automatically. On the other hand ~6k ‘jpsq_full_sync’ rows have now been generated, but I guess that’s normal after an initial handshake. It has already automatically fallen to ~5k again, so I guess we’re good. I’ll check how the numbers evolve over the next few days and mark this topic resolved if it stays under control. (I now remember we ran into some problems launching cron jobs on our server, but if that’s the cause I think lots of other plugins would have filled up the options table too.)

Anyhow: thanks a lot for your patience! This really is top notch support, Jeremy.

Greetings,

Frederik

• This reply was modified 8 years, 5 months ago by freeaanzee.

A lot has changed to shipping in WC 2.6, so I guess the plugin will need some rebuilding to make the ‘Hide shipping’-checkboxes available again on the new screens. Let’s hope Ronald finds some time to dive into the problem!

Ask the admin to co-select ‘Shop Manager’ in the ‘Allowed Roles’ at the top of the settings page … Don’t forget to hit save!

Second that!

I’m not the developer, but let’s try sorting this out … Could it be that the plugin searches for the PARTIAL filename in the media library and automatically assigns the first ‘hit’ (= oldest/newest uploaded image)?

In that case the metal ones are always correct (because it is the longest filename, there’s only one match possible) but the plastic ones CAN be wrongly assigned because the string ‘blk-cga.gif’ is also present in the URL of the file ‘m-blk-cga.gif’.

I’m just guessing out loud, I didn’t dig into the code, but you might want to try giving your images mutually exclusive filenames, i.e. ‘p-blk-cga.gif’ (for plastic) and ‘m-blk-cga-gif’ (for metal). Good luck!

Glad I could help!

Looks like my last comment has been ignored.

Your code in class-woocsv-product.php should read:

if ( empty ( $this->body['ID'] ) ) {
	$this->meta['total_sales'] = 0;
}

Solved my problem at least!

I tried your developer version, but it didn’t work for my new products. You should drop the exclamation mark before the empty function. Now you reset ‘total_sales’ if body[‘ID’] is set, which means … the product already exists! I combined the fix with your ID block:

//fill in the ID if the product already exists
//if the product is new add total_sales to show it in the front end
//some themes needed total_sales for popularity sorting
if ($id) {
	$this->body['ID'] = $id;
} else {
	$this->meta['total_sales'] = 0;
}

Great! Looking forward to it. Thanks for the fast feedback!

Even using the latest version and UTF8-encoding on the CSV I still experienced this problem. Newly imported products show up in the back-end and I can navigate to them manually but they don’t show up on the product collection pages. Only the category totals indicated they were there somewhere. But as described by paulc8712: once you re-save the product (without making any actual changes) they magically appear!

In the wp_posts table I compared a ‘visible’ and ‘invisible’ product side-by-side, but I couldn’t find any meaningful differences. But then I checked the wp_postmeta table. I could see some rows were added to the re-saved product. Amongst them: the infamous ‘total_sales’ field. And then I remembered my standard product sorting method was ‘popularity’ (based on … total sales!).

Adding the same row for other post_id’s (screenshot) immediately fixed the problem. So if the ‘total_sales’ metatag of a product isn’t set, it doesn’t show up in the popularity grid (screenshot) but it does if you sort e.g. by date (screenshot).

So in a way this is a small glitch in WooCommerce (or the Storefront theme). But it can be easily circumvented by letting your plugin automatically add the particular custom field ‘total_sales = 0’ to new (!) products in the CSV import. I hope this helps in fixing it.

I’m not planning to click the re-save button 5000 times anyway :P!