Pat Gilmour

Mike – Thanks for the speedy reply. Sounds like what we need. Will look into it.

Is there maybe a way to coerce the nofollow parameter into doing what I need?

As of WooCommerce 2.4.6 we are no longer seeing the bug listed above.

Thanks!

Thanks Mike!

Thanks Mike – that sorted it!

For anyone with a similar issue still using woocommerce_process_product_meta_variable to update variation meta fields…

The article Mike links to says you’ll have no issues if you use: woocommerce_save_product_variation for saving instead.

I changed my code to use that hook and now it works.

If you’re looking for a gist to get started using woocommerce_save_product_variation instead, then take look here:
https://gist.github.com/gbyat/c1bcc9f47ef9e661fc6f

Very simple and easy to use.

The issue was with neither WooCommerce or WordPress but with the PHP config parameter: max_input_vars

By default it accepts 1000 items. Our large records have more than that. We went with a value of 3000 and it fixed it.

You can add this to PHP.ini:
max_input_vars = 3000

Or this to .htaccess:
php_value max_input_vars 3000

I discovered this page after the fact. Very useful:
https://docs.woothemes.com/document/problems-with-large-amounts-of-data-not-saving-variations-rates-etc/

And from the PHP documentation:

max_input_vars integer
How many input variables may be accepted (limit is applied to $_GET, $_POST and $_COOKIE superglobal separately). Use of this directive mitigates the possibility of denial of service attacks which use hash collisions. If there are more input variables than specified by this directive, an E_WARNING is issued, and further input variables are truncated from the request.

I tried the solution that @bobbito suggests above with .php as an extension and it works (thanks!).

I’m not sure of the security implications of this, but we trust all our Store Managers so, in our case, I think we’re covered.

@bobbito – many thanks for the post. Looks good. Will try with .php extension and feedback start of the week on whether this works!

Hi, the .ZIP solution should work if you host the file within WordPress, but what about when you simply want to link to an external file, like a software installer on a 3rd party site?

For example, we sell licenses to software then point the customer to a visitor’s website to download the installer. The links are like this:

https://www.acmesoftwarecompany.com/scripts/getNewDownload.php?id=8ff1f4be56de2c556540d0e0c73c2385433556dd6945bdad114aaeae

We get the same error as nycholas.bruckmann does.

We can’t host all the installers ourselves so we need a way to bypass this warning. Is there an option to do so?

For anyone interested, you can do the above with a filter:

/**
 * Email: Change Text of Paid Invoice Heading
 *
 * By default, paid invoices don't have "Invoice" in the heading, but some customers request this.
 *
 * see https://docs.woothemes.com/document/change-email-subject-lines/ for how to do it with subject lines
 * which points to /wp-content/plugins/woocommerce/includes/emails/class-wc-email-customer-invoice.php
 *
 * the filter hook is in there: woocommerce_email_heading_customer_invoice_paid
 *
 */
add_filter( 'woocommerce_email_heading_customer_invoice_paid', 'xcsn_woocommerce_email_heading_customer_invoice_paid', 10, 2);
function xcsn_woocommerce_email_heading_customer_invoice_paid ( $heading, $order ) {

	$order_id = $order->id;

	$heading = 'Invoice for Order Number #' . $order_id ;

	return $heading;

}

This is over my head, but if you need any help testing, I’m happy to help out.

Hmmm, I’m using HTML5, yes – in Genesis. Wonder if it’s related.

Here’s the answer for this particular hook:

add_action( 'woocommerce_order_items_table', 'xcsn_woocommerce_order_items_table');
function xcsn_woocommerce_order_items_table ( $order ) {
	echo $order->id;
}

Still open to any suggestions as to how do this reliably!

Digging around in the HTML. Will post back if I discover the issue. Thanks for taking the time to reply! Appreciated.

Thanks for getting back to me.

I can disable Warnings but I was hoping to get rid of the actual warnings instead!

Looking at the error messages, I thought the error was in the plugin. But I think you’re suggesting it’s actually the way the pages are rendering, is that correct?