Forum Replies Created
Hi,
thanks for the feedback.
” it is controlled by the container class, which uses margin and max-width attributes to adjust page width”
Can you explain the logic/thinking behind this approach? It works well for some screens, but for others, it squashes all the content in the centre, leaving massive white space on either side. Most visible on mobile devices. I can understand if this is a mechanism to keep content centred in the body section of the page, but don’t understand why it applies to the header and footer as well. I have attached screenshots of an extremely bad case example and a good out-of-the-box example, granted that they are not both tablets or mobile.
I hope to utilise the white space better and stretch all the content while leaving minimal side-to-side white space on mobile devices. Then if any content within a page is offset left or right, I’m hoping to mitigate by centring that container/column and to re-centre the content that cannot be stretched, like woo new products on the front page for example.
I would greatly appreciate the help. I’m willing to pay a 1-time fee for your time to create the custom CSS for me. I would like to achieve as follows:
For all mobile screens including tablets I would like to stretch the content to reduce the white space from side to side, this includes the header (logo and menus) and the footer content as well as the body content throughout. The specific values I think may work towards my vision of the layout are:
Desktop (1025px and up) = untouched.
Mobile (tablets 1024px to 768px) = 30px left + right margin.
Mobile (phones 767px and down) = 15px left + right margin.
Kind regards
Hello, on further investigation of my layout concerns, it looks like the theme’s responsive.css and bootsrap.css files are acting on the layout for the following elements:
margin-left: auto;
margin-right: auto;
These elements are reactive to another element(s) which defines the screen width:
max-width: xxxxpx;
min-width: xxxxpx;
Depending on the screen width, the margin is calculated at some ratio automatically, but it’s unclear where this variable is defined. It is the ratio I wish to modify so the change applies site-wide (including the header menu/content and footer content) across all responsive layouts, excluding only the desktop view.
Attached are a couple of screenshots narrowing down the effect and elements responsible for it within the content-container (.container).
Any advise on this would be welcome.
Kind regards
Hello,
sorry for the delay. I have now updated the theme.
I have good news and bad news.
The good news is, that the theme updated the previously outdated templates.
The bad news is, that the goalposts have since moved, and since the latest WooComemrce update, now two new templates are also outdated. See the attached screenshot.
On a separate matter, may I ask where in the theme, or how (with CSS or another means) the Mobile layout margins (left+right) of the Theme can be modified globally? I’ve spent considerable time trying to establish how to achieve this, but all CSS customisation appears to apply at the individual container level (e.g. header, body, etc), not globally for all objects in the Mobile layout. My objective is ti trim the current margins, to maximise usable screen space for text and images (e.g. remove useless white space side to side from 30px to 5px). Any pointers in this area would be appreciated. thanks in advance.
Regards
Hello,
I’m somewhat disappointed to find out that the Woo templates were not updated in the new v5.9 Theme release after mentioning this in this ticket trail over a month ago and you acknowledged that the template updates will be included in the next release.
🙁
Hello,
that’s a negative.
The image you have tested is a JPG, the issue resides with WEBP format images.
If you try https://www.gkauthentic.com/?s=Gauvine&post_type=product
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.
Regards
Hello,
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?
Regards
George
Hello,
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?
Kind Regards
George
Hi,
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?
Regards
Sorry, did not realise the image attachment would be rejected.
Now added in a zip. Attaching again.
Hello,
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?
Men’s Underwear store – https://gkauthentic.com/
Hello again,
I am just bumping my query as it’s been a few days and I have not received any feedback on this matter.
kind regards
Hello,
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.
kind regards
Hello sir’s,
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. 🙂
Hello Sir,
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.
Regards
George
Hello,
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.
Kind Regards
George
Hello,
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.
Regards
George
Hi,
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?
Regards
George
