simonmm

The minification of Woocommerce structured data issue has been fixed by Woocommerce v3.5.6 (which removes HTML tags from the product description when preparing the JSON-LD structured data).

We have been using WC Store Exporter fine for the last 10 months under PHP 7.2.

After updating to PHP 7.3 (and WordPress 5.1), it continues to work, although we do get some PHP warnings:

PHP Warning: “continue” targeting switch is equivalent to “break”. Did you mean to use “continue 2”? in /var/www/html/wordpress/wp-content/plugins/woocommerce-store-exporter-deluxe/includes/product.php on line 1423

W3TC 0.9.7.2 has not fixed the minification of Woocommerce structured data issue.

Create a Woocommerce product description containing just x<br />x

Without minification, this is fetched by the browser as
<script type="application/ld+json">{......"description":"x<br \/>x".....</script>

With minification, this is fetched by the browser as
<script type="application/ld+json">{......"description":"x<br \>x".....</script>
i.e. minification has removed the forward slash, which is OK, but it has left the preceding backslash, which then escapes the following “>” and causes a JSON-LD error.

(Just for completeness: WordPress 4.9.9, WooCommerce 3.5.4, PHP 7.2.14)

• This reply was modified 6 years, 1 month ago by simonmm. Reason: Added vsn info

This update also appears to have broken the structured data that Woocommerce places on (some) single product pages.

Viewing via https://search.google.com/structured-data/testing-tool gives
JSON-LD Bad escape sequence in string.
(example test URL is https://mindmachine.co.uk/product/cn459-60375-hp-assy-duplex-module )

Unless HTML minify settings: is disabled.

The above change to HTML.php does not seem to help.

• This reply was modified 6 years, 1 month ago by simonmm. Reason: Added example URL

WordPress 4.9.8
Woocommerce 3.5.0
PHP 7.2.11
Theme Storefront 2.3.5

GDPR CC v1.6.10 has not prevented the PHP error message appearing every time a user who does not have the Settings option in their left side menu logs in.
We don’t see the line 1126 error that tobyy did though – only the line 159 error.

We use the Members v2.1.0 plugin to create a “View Orders/Contributor” role which can see Woocommerce orders, so is only granted:

General -> Read
Posts -> Edit Posts
Posts -> Delete Posts
Posts -> Read
Pages -> Read
Orders -> edit_shop_orders
Refunds -> edit_shop_orders
Users -> List Users
Custom -> read_shop_order
Custom -> view_woocommerce_reports

So when they log in, their side menu just contains:

Dashboard
Home
 Admin Search
Posts
Comments
Orders
GDPR Cookie Consent
Sales Reports
Users
Tools

A quick diff on the un-minified (use csstidy) style.css in storefront v2.3.4 and v2.3.5 shows the following was removed in v2.3.5:

.woocommerce-active .site-header .site-branding img {
max-width:100%;
}

Just add it to your child theme’s style.css to restore the previous behaviour (I haven’t checked for any side effects though).

• This reply was modified 6 years, 4 months ago by simonmm.

A quick diff on the un-minified (use csstidy) style.css in storefront v2.3.4 and v2.3.5 shows the following was removed in v2.3.5:

.woocommerce-active .site-header .site-branding img {
max-width:100%;
}

Just add it to your child theme’s style.css to restore the previous behaviour (I haven’t checked for any side effects though).

We were on:
WordPress 4.9.4
Woocommerce 3.3.2
WooCommerce AdWords Conversion Tracking 1.4.7
WooCommerce SagePay Form and SagePay Direct Gateway 3.10.3
Theme:Storefront 2.2.8
PHP 7.0.25

But since applying Woocommerce 3.3.3, things appear to have returned to normal.

Oops, missed the critical bit of info – Vevida Optimizer v1.1.2

I deleted the current version and reloaded v3.0.5
Settings were retained.
Our data load is now back to 50 records in 25 seconds (compared with 82 seconds using v3.1.3)

Should I delete the current version before loading v3.0.5 ?

(and if so, will it retain import settings such as custom fields and headers?)

Is it possible for us to safely revert to v3.0.5 of the plugin?

The 3x slow-down in load times of v3.1.3 is not workable for us.

Config:
WP 4.4
WC 2.4.12
Apache 2.4.7
PHP 5.5.9
MySQL 5.5.46

Currently using v3.1.2 of Woocommerce CSV Import.
We also use v3.0.1 of the paid-for “Woocommerce CSV import custom fields” plugin extension.

Note this is a daily price update of existing products already loaded into WooCommerce.

Imported 7200 records from a CSV with 5 columns:
sku, regular_price, costprice (a custom field), stock, backorders

With v3.0.5 import took 60 minutes (batch size set to 50 products)

With v3.1.2 import now takes 180 minutes
(automatically increasing batch size started at 6 and was at over 200 by the end of the import)

So we are seeing a 3x slowdown with v3.1.2 compared with the faster v3.0.5

This morning’s test shows that it was the update to v3.1.2 that fixed things for me (and not browser caching issues).

So that just leaves the 3x slowdown – which I’ll follow up on the speed thread which is already open.

I updated plugin to v3.1.2 and imports now succeed.

I am testing from a different PC though, so I’m not sure until tomorrow whether this was a browser caching issue, or a result of v3.1.2 itself.

The load is running 3x slower than v3.0.5 did however.
Which is no good operationally – half the day would be over before we can get the daily price update in (and that’s with just 7,200 products – this will grow – a lot)

At the moment we don’t have an externally accessible test system for you to examine – I will look into this tomorrow.