that’s a negative.
The image you have tested is a JPG, the issue resides with WEBP format images.
You will see a combination, images with the background removed have been photoshopped and exported in JPG format (originally in WEBP), and images with background have been imported in the native format they were received (WEBP). The images with the background do not scale down or resize to fit within the preview window bounds. This is my issue.
I’m currently forced to going through a process to Photoshop and convert WEBP images to JPG, but this is a backward step for which I will also pay with SEO penalties compared to similar websites employing WEBP images, as well as suffer with the UX in terms of speed and page load.
thank you. I do appreciate the support.
Coming back to the original issue I raised within this request, I have now installed a copy on a staging instance, allowing me some flexibility to test.
I have disabled ALL plugins apart from WooCommerce, but the behavior of the WEBP images remains unchanged in preview mode. You previously suggested that the reported behavior is likely due to a plug-in compatibility/interference-related problem. I can prove now that this is a red herring.
I switched the Theme to Avada (same with all but WooCommerce enabled) and the rendering of the webp image in preview mode is scaled within the viewport and the preview frame is not rendering a zoomed-in image requiring slide bars to scroll to view…
Please see the attached evidence and examples.
I’m not sure what the solution is here, but surely this proves that it is not a plugin-related issue?
I was finally able to update the WPBakery plugin, but the successful method was different from your suggested options, which all failed due to a minimum version dependency of WPBakery required to be 7.1.x (in my case it was the previous major version 6.13.x). This dependency caused a failure loop, where the plugin would not update and be deactivated following attempts to do so. Also, if the plugin was deactivated first, then it will still fail to update and remain deactivated from that point on, causing display issues with pages built with WPBakery.
The successful method was to deactivate + delete the WPBakery plugin from the site! Then, reinstall the Beta Theme version which reinstalls WP Bakery at the required 7.1.x version, after which the plugin can be reactivated and the WPBakery-built pages are then restored to their configured state.
In doing so I also noted the following:
1.) Woo Template Thank you.php is out of date (v 3.7.0) – the current version is 8.1.0.
2.) WPBakery is already at v7.2 – The Jevelin Theme version 5.8 is at WP Bakery v7.1.
May I request, please, to include the updated versions of the highlighted items in the next theme release?
I’m running the latest 5.8 theme that has been published by you. I haven’t used a beta for a long while.
I followed your recommendation of updating WP bakery with poor results. Capture 1 shows the update failing prior to the WP-bakery plugin being disabled. Capture-2 shows the update status after the WP-Bakery plugin was disabled then the update carried out. However, returning to the plugins page (Capture-3) shows that the update did not take place, whats worse the WP bakery plugin then cannot be enabled again so half the website using this plugin for page layout becomes a mess on the front end. Not the best integration with this plugin. What’s worse you don’t know if you can rely on the feedback provided regarding the update status/outcome.
If it wasn’t for my All-in-One backup/restore solution I would be pretty messed up right now.
Before you suggest it is the WP Rocket plugin, I cleared the cache before and after the updates and disabled the plugin or one update attempt with the same outcome.
That will take a while to achieve. I have no staging environment, unfortunately.
I have noted a separate issue, but I am unsure if I should raise a new request for this. It is related to updating the WP Bakery plugin via the facility provided within the theme Plugins section. I get the error as attached in the screenshot. Is this a known issue or something unique as well?
thank you for getting back to me.
The answer is no, I’m not converting JPEGs to WEBP. Simply uploaded a webp format image to the gallery and linked the image to the product. Attached are a screenshot of the page and image being rendered and a copy of the image being served.
Also, Link to the public product page – https://www.gkauthentic.com/product/gauvine-underwear-2011-second-skin-brief/
The behaviour is the same for all webp images only.
I have cleared both the WP Rock cache and the Cloudflare cache and disabled both temporarily, but it doesn’t change the behaviour.
It seems connected to the iframe within this div, If I change the height from 500px to 1200px the image displays outside of the div frame but does not scale to fit within the frame.
<div id=”lightcase-content”><div class=”lightcase-contentInner” style=”opacity: 1; width: 800px; height: 500px; max-width: 100%;”><iframe src=”https://www.gkauthentic.com/wp-content/uploads/2023/09/2011-gauvine-second-skin-brief-burgundy-front.webp” width=”800″ height=”500″ frameborder=”0″ style=”width: 800px; height: 500px; max-height: 1058px;”></iframe></div></div>
What behaviour do you experience on your end? Can you use the attached image to test and verify your environment is different?
I am just bumping my query as it’s been a few days and I have not received any feedback on this matter.
thank you for pointing out how to maintain WP-Bakery compatibility with my instance. Appreciated.
Regarding the maintenance of Woo templates, I appreciate that this is a constantly moving target, as with all product maintenance within a framework. I do appreciate the effort and was only suggesting that you consider adding this check/verify/update actions as part of your workflow within your publishing roadmap for the theme, to avoid having to be pointed out via support requests.
Proactive maintenance goes a long way to justifying support/subscription investment to support you in continuing to support us as end users.
thank you for previously providing a temporary solution to Woo templates compatibility update (last message above).
However, your current public theme update release (v5.7), doesn’t include said fix. Also, I noted that the WP Bakery (theme bundled) plugin is not being updated with Theme releases. See attached.
I’m not asking for immediate action from your side, but it would be beneficial for all if you are able to add these small compatibility updates to your theme update roadmap so we do not have to regularly point out these repetitive maintenance items.
Thank you in advance and I hope that the next Pibli theme release will include these maintenance fixes. 🙂
I’m resurrecting an old ticket on the same subject. The last fix was excellent, hence the radio silence, sorry for not following up.
We are back in the same situation with the WooCommerce update to v 7.8.0 (major version).
May I kindly request that you add the templates highlighted in the attached screenshot to your roadmap for the next Jevelin theme release?
Many thanks for considering my request.
I will, Thank you.
I will also let you know the outcome.
thank you for the response.
Before I go ahead with this, can you please confirm if this is a one-time change, e.g. can I roll back to the production theme version if this beta causes other issues following the update?
Also, some explanation of the solution would be welcome.
I’m not sure what you mean by that statement. The code I submitted was made in the built-in editor box. Once any formatting is added the tags are automatically inserted and viewable in the HTML tab of the editor. I simply copied and pasted from there.
For the record, the same formatting/code was in use for over 2 years as it was functional across all platforms when originally configured. The only change that is made is to manually uplift the calendar year value in the copyright statement in that section every year (as the theme does not support more advanced code that can be used to automatically do this, as the Avada theme supports for example).
Anyway, this issue has been present for more than 6 months. I just haven’t had time to look at it/report it until now. I’m not sure which theme version made the change but if I was to guess I would say it is more than 2 theme versions ago, likely towards June 2022 or earlier. Sorry I can not be more accurate. Perhaps you can look back to when the social icons were added to that section even when Option 1 has been selected, as these were not present previously and now appear to be enforced with no option to remove them without CSS hacks.
thanks for the feedback. Can you please clarify one statement for me, I quote it below…
“Also if you had installed a demo content before (as a base for your website), you can install WPBakery page builder made demo content to make it even easier.”
What is the impact of doing this? Any customizations that may have been made from the base are likely to be overwritten in this scenario?
So I found the plugin and went ahead with the upgrade.
Looks like quite a few elements on my home page as well as probably other pages are now not being rendered or have their layout completely messed up. So I guess Unyson was in use to place content and elements in more places than I was aware.
I had to revert to the backup to restore the look and feel. What are my options here?
I want to migrate but it looks like I have to review and rebuild a lot of my pages with the WPBakery layout editor, before I can upgrade so I know I have something already in place to take over once upgraded. This could take a while.
Any recommendations on the approach? I have left the theme’s “shop” layout mostly intact and it looks like it was heavily utilizing Unyson. Deactivating that plugin pretty much removes all layout settings and leaves the content residing on a blank page. Not a good look.
seems pretty straightforward, however, according to the framework upgrade page “the plugin” is installed (Redux?), but I cannot see “Redux” anywhere in the plugins list. See attached screenshot of the current upgrade status. The theme is on v 5.3.3.
Looking for “Redux framework” leads me to = https://extendify.com/pricing/?utm_source=redux&utm_medium=web&utm_campaign=redux-redirect
Is this what I need? I’m not certain if this prerequisite is a separate task or part of the upgrade workflow and happens transparently to me.
Also, I was asked to install Elementor at a point in time, I don’t recall the specifics but I think it came through as a Jevelin requirement/recommendation.
I don’t use Unyson or Elementor, so have no specific need for them.
Happy to proceed once clarified on the Redux prerequisite component.
thank you for the prompt response.
If there are no consequences for the site/theme health migrating to Redux then I’m happy to do it.
When I first noticed about the framework upgrade it was a beta and your documentation states that it was experimental. Because of this and because my site is live and the only instance, I chose not to risk it and wait until that change matures.
Would you be kind enough to point me to a checklist or documentation I must go through to upgrade?
thanks for the suggestion, but I do not want to change the parameter, I want to remove the padding parameter completely, so then my form customisation is displayed properly.
Very strange that you say this parameter has been in the theme for a long time. I had the Woocommerce customer login/register (/my-account) page customised with CSS earlier in 2021 to suit the styling I wanted and that was working fine for most of the year until very recently. No recent plugins have been added either.
What I don’t know how to do is to remove the padding parameter when it has the !important declaration added to it.