Klaus69

@nikko73 I do not think that this will really be needed, see here:

https://www.it-recht-kanzlei.de/cookies-eu-datenschutz-grundverordnung.html

Also consider: Already at the very moment when somebody opens the website, session cookies are set. So the visitor would have to agree on the usage of cookies before opening the website at all…

Same problem. This is since WC 3.3.

After spending more hours on it, I have to provide an update:

What worked perfectly for me in the past was the plugin “simple image sizes”. I so got used to it, that I saw its functionality as WP-core, but it is not. It was this plugin, that took care of creating uncropped thumbnails fitting into a defined height/width frame.

Since WC 3.3. this plugin does not work for all shop images anymore. As result all of them are created with maximum height, matching to the defined width given in WC.

I will contact the plugin developers, but not sure if there is much that they can do about it, when WC is simply (accidentally) overriding their functionality.

If they cannot fix it, and WC does not support in enabling this external plugin-support again, I have really no idea what to do – beside staying with 2.6.0 forever.

A_G_Owen this is a new “feature” of Woocommerce since version 3.3. For me it lead to dramatically big issues.

I “fixed” it for the moment by stepping back to version 2.6.0, there you can define also maximum heights for uncropped thumbnails.

@lightscapes here I disagree. When they cause thousands of false alarms, they cause stress and useless work. My clients also get these emails, and are of course alarmed by it.

Strange anyway: On two of my websites it has access rights 660. On another one – but NOT the one for that the mail was sent! – it is 200, and this can therefore not be downloaded anymore.

Same here with 1&1. I think it is false alarm, I compared with files on other installations, one I found changed last time back in Jan., exactly same file sizes.

However, the content of the file looks very strange, as described by lightscapes.

OK, I (have to) see this as a bug in WC, and no support provided at all. I know that WC is for free, but I spent a lot of money for add-ons, wihtout them WC is pretty useless, as we all know.

Pity, to say at least.

However, I “solved” the issue by using hooks instead – although not everything can be solved with filters and hooks.

Anyone?

Same issue here. It is described in more detail already in this 2 years old thread – obviously this issue is still unsolved… ??

https://www.ads-software.com/support/topic/mediathumbnail-croppost-thumbnail-problem

Instead of exchanging the (150×150) thumbnail, the crop is creating new versions of it, with filenames looking like e.g. this:

117-e1423760859306-150×150.jpg

where the part beginning with “e…” is changing, based on what logic ever.

A halfway workaround is to manually delete the original thumbnail via ftp, and rename the newly created one (i.e. remove the “e1423760859306”).

Halfway, because then the thumbnail is shown correctly in the frontend, but is broken in the backend – I assume that in the database behind the information of the new filename is stored, and would also have to be updated.

Painful…

@bigneno: Nice one, works, thanks a lot!

@zonetrap: I added at the top of the page, no problem at all. Sure your syntax is correct?

Thanks a lot Chouby – with that my decision is clear, I will (have to) go for WPML, at least for the moment. Anything else would be too much effort.

Still I hope you will stay successful with polylang – please keep up your good work and support, really appreciated (and sadly not common).

Good-Bye donation is on the way!

Well… I changed now one part of the plugin for all evidence regarding “get_default_language” and “get_current_language”, seems so far so good.

But now I stumble over the next problem caused by:

$orginalid = $sitepress->get_original_element_id($product_id,'post_product');

It seems like there are many direct references to WPML functionality – changing it all might be quite some effort…

Is there some list of all WPML compatibility that polylang offers, i.e. like using “pll_default_language” instead of “get_default_language”?

But honestly, the more I think and learn about it, the more I believe to understand also their position. They cannot analyze and support all plugins offering multi language support. Like e.g. to use “pll_default_language()” they can only know once they analysed polylang. They could check if the function “$sitepress->get_default_language()” exists instead of just using it, but then again, they would know what to do instead of its usage only after further investigation.

Or are there completely “official”, i.e. documented ways for really all WPML functionality, that would work also with polylang without any knowledge of polylang, and therefore no specific adaptations?

Thanks in any case for pointing me to the right direction, learning…

Thanks a lot! I will give it a try this weekend, and get back here with the results!