Forum Replies Created
-
Posts
-
Thanks for your answer! Just to make it clear, you have already introduced a bug that breaks existing layouts. I’m not in any means saying you should change what thumbnail is being used. My fix is a quick and dirty solution to fix a urgent problem for me and some others that have updated to a newer version of Enfold and then got this problem. But I don’t want to change what thumbnail is being used as a permanent fix.
Have you looked into why this problem occurs. Why the 450×450 px image is being favoured over the settings Enfold provides regarding cropping/ratio of product catalogue images? No settings have been changed after updating and all of a sudden 450×450 px is being displayed even though the setting is set to display uncropped images if a 450×450 px is generated for the product.
If you will not do anything more about this, then is there a way for me to see what changes have been made in the last three (or so) versions of Enfold? Can I get access to other versions than the latest?
Best regards,
MartinHi Ismael,
Thank you, that sounds good!
Nope, novellix.se/butiken is just the WooCommerce shop page (set in WooCommerce -> Settings -> Poducts -> Shop Page) so we can’t use the Advance Layout Builder to edit anything (the layout builder is disabled by default on that page). novellix.se/butiken/bokstod/ and so on are just the default product category pages so they also use the default WooCommerce shop page and no layout builder is used.
Best regards,
MartinHi,
Please see https://kriesi.at/support/topic/bug-in-enfold-for-woocommerce-prduct-images/. I’m quite sure it’s the same issue you are experiencing, @flylanddesigns.
Best regards,
MartinHi,
Yes Corina, it sounds just like the same issue I’m having. Have seen others also reporting it today.
Ismael or someone else at Enfold, I tried to understand why the problem is not consistent but why we get mixed cropped and uncropped images. It looks to me like the cropped version is displayed if a 450×450 version of the image has been generated, otherwise the image is displayed uncropped.
I wrote a short snippet of code that works for me:
add_filter( 'avf_wc_before_shop_loop_item_title_img_size', 'temp_thumbnail_size_fix', 10, 1 ); function temp_thumbnail_size_fix( $thumbnail_size ) { return 'woocommerce_thumbnail'; }But there is apparently a bug in Enfold when it comes to using the settings from Appearance > Customize > WooCommerce > Product Images so please let a developer have a look at this.
Hi Jason,
What setting do you have for cropping in Appearance > Customize > WooCommerce > Product Images? If you have “uncropped” it sounds very much like the same problem I and several others have reported.
Best regards.
MartinHi Ismael,
No, not 174×245 px. The woocommerce_thumbnail has been set to 173 and i tried changing that to 174 and then uploading one of the product images that is currently displaying incorrectly. A 174×238 image was generated but then it still displays the product thumbnail using 450×450.
The uncropped registered image sizes are currently (after changing 173 to 174 in the Appearance > Customize > WooCommerce > Product):
- medium – 300 x 300
- medium_large – 768 x 9999
- large – 1030 x 1030
- product-image-mini – 50 x 0
- 1536×1536 – 1536 x 1536
- 2048×2048 – 2048 x 2048
- extra_large – 1500 x 1500
- masonry – 705 x 705
- shop_single – 450 x 999
- shop-hi-res – 320 x 470
- double-full-width – 2420 x 0
- woocommerce_thumbnail – 174 x 0
- woocommerce_single – 450 x 0
And all the generated images with the current setting are (including cropped images):
- omslag-suburbanweekend-resized-100×100.jpeg
- omslag-suburbanweekend-resized-1096×1500.jpeg
- omslag-suburbanweekend-resized-1123×423.jpeg
- omslag-suburbanweekend-resized-1123×430.jpeg
- omslag-suburbanweekend-resized-1123×630.jpeg
- omslag-suburbanweekend-resized-120×120.jpeg
- omslag-suburbanweekend-resized-174×238.jpeg
- omslag-suburbanweekend-resized-180×180.jpeg
- omslag-suburbanweekend-resized-219×300.jpeg
- omslag-suburbanweekend-resized-260×185.jpeg
- omslag-suburbanweekend-resized-301×301.jpeg
- omslag-suburbanweekend-resized-320×438.jpeg
- omslag-suburbanweekend-resized-36×36.jpeg
- omslag-suburbanweekend-resized-450×450.jpeg
- omslag-suburbanweekend-resized-450×616.jpeg
- omslag-suburbanweekend-resized-495×400.jpeg
- omslag-suburbanweekend-resized-500×225.jpeg
- omslag-suburbanweekend-resized-50×68.jpeg
- omslag-suburbanweekend-resized-515×705.jpeg
- omslag-suburbanweekend-resized-710×375.jpeg
- omslag-suburbanweekend-resized-753×1030.jpeg
- omslag-suburbanweekend-resized-80×80.jpeg
- omslag-suburbanweekend-resized-845×321.jpeg
- omslag-suburbanweekend-resized-845×684.jpeg
- omslag-suburbanweekend-resized.jpeg
Sorry, we do not have a staging site but I have a local installation and can do tests if you want to.
Best regards
MartinHi Mike,
Thanks for the response! The fix works great for us. We have already implemented our own workaround, same as this but we have temporarily set the users email as a session variable, but your solution is a bit more clean.
I would kindly ask you to handle it as a bug that modifying the sender email of the form breaks the auto response function. I see it as two separate things and would not reuse the variable in the auto response section of the code.
I will consider adding a feature request to make it possible to set the sender email of all forms to a specified address. It’s an extremely boring feature, but necessary to a lot of people if one goes through years of support threads where emails not being sent or ending up in the spam filters (due to sender email set to something else than the websites domain). Currently the Request Feature button is not working for me though. Have tried both Chrome and FF and cleared my browser cache.
Thanks!
MartinDon’t want to hijack the thread but I’m just wondering if this fix will go into the main theme? To me it looks like a bug that the $from in
$from = apply_filters("avf_form_from", $from, $new_post, $this->form_params);is also used as the recipient address of the auto response mail.
We run a online shop using Enfold and WooCommerce and relying on Mandrill (Mailchimp) to handle our email sending. They reject emails where we don’t have our domain as the sender address. Hence we rely on this work-around until there is another way.
Hi Victoria,
Thank you for your response. Well I can agree that icons may be more appropriate since “greater than” in this case does not make any sense in a purely semantic meaning. However, my customer wanted the text of the button to be “Read more >” and apparently several others had the same need and found the same problem with the Enfold theme since then.
Greater than is very much a valid character if handled correctly and escaped. You can see from my initial question that I wondered if it’s a conscious decision to not handle angle brackets like it is usually handled in texts but instead letting it pass unescaped and breaking the html. The response I got was “can i get access to your site”, which was not really the response i was hoping for. I guess this is not really leading anywhere but if people continue to reply to this thread I hope you can consider escaping angle brackets correctly (eg converting them to & gt; on save).
Best regards
Martin…and how I eventually solved it back in 2015 was to use the character » instead of > or & gt;, but that’s still just a workaround and not a solution to the real problem that angle brackets are not handled correctly within the button module.
Hi Victoria, Rikard and others that reply to this thread. The proposed fix was already in my original message from 2015. However I also state that this fix is temporary, it will work once but in any later updates to the page the & gt; will be read as an angle bracket character and we are back to square one…
This has nothing to do with any local installation (so don’t bother asking for a login to my site). It can be tested in any installation of the Enfold theme (just tested it in the most recent version 4.0.5 and the problem is still there). The correct fix is to make a code change in the themes Button module to convert angle brackets to html entities.
And the ampersand character is not escaped in this form so my second paragraph is suppost to be:
I’ve suggested that the customer uses [ampersand]gt; instead of “>” and it works fine the first time he/she updates the page but the second time a change is made to the page the “>” is back and the html breaks again.
