Added new filter on qwc_front

[igorbenic]

Added a new filter on the qwc_front. I had the issue that the variations that were made with attributes such as [:en]Black Color[:].... were not being shown on the front end in the dropdown element.

By using this filter, they are shown with no issues.

[johnclause]

Thanks a lot Igor, Is priority '1' important? With priority 20, it would not work? We use 20, to let other plugins to change the values before they get translated. I guess, it is not important in most of the cases. It is also considered not polite to put a boundary value for a priority, because it is good to give other people chance to do something before your code in case of some special circumstances. We usually use number 5 in cases, when it needs to run before the default priority 10.

[igorbenic]

Hm I think it should work also with priority 20.

I have done some research today for the WooCommerce Variations dropdown for attributes on the product page. It seems that variations are not created because the array with those values is not filled with them.

With some research I have found where this happens: woocommerce/includes/class-wc-product-variable.php:437

There the if statement is not TRUE because _$textattribute is recieved as for example: [:en]Variation1[:hr]Varijacija1[:] but _$assigned_textattributes does come in the formatted text for example on EN site: Variation1 and so the function in_array does not validate as TRUE.

I have tried to find why the variable $text_attribute did not format to Variation1 and instead comes unformatted, but at the moment I did not come with a solution.

Don`t know if this is defined by plugin design but just to let also other users know if they come to a problem with that.

[johnclause]

I did not have a chance to try to reproduce what you are talking about. Is the problem you are solving, by any chance, described in the third item of page https://wordpress.org/plugins/woocommerce-qtranslate-x/other_notes/ ? Here is a copy for the sake of convenience:

Custom Product Attributes (which are entered directly on product edit page /wp-admin/post.php?post=xxx&action=edit) have to be entered in raw multilingual text, with values like [:en]EN Val1[:de]DE Val1[:] | [:en]EN Val2[:de]DE Val2[:], leaving separator '|' outside of language tags. This piece has not yet been integrated on admin side, but once all is entered in raw multilingual format, it should work well at front end. Delete and freshly re-create an attribute under this plugin, if it was created before installing this plugin and it misbehaves.

Does problem happen on newly created variations? Is your problem different than the described above? If it is the same, then I would really appreciate if you figure it out how to integrate it. Woo has quite a cumbersome code in that respect. I think I saw that they create an internal slug for variation, and later compare this slug to a the result of function, which creates slug, running on a current value of the variation. This means that if you ever change the value of variation, the slug does not get updated, and new value mismatch the old slug. When you make the value multilingual, then it gets broken because new slug value does not match the original one. I do not know how to fix it, unless you simply delete the variation and then create it again with multilingual value defined as needed at first place. Once that value is changed later it gets broken again.

It was the case a few months back. It is possible that they already improved something in that code by now.

[johnclause]

THis filter has been added in a bit more complex way. Thank you!