we sometimes have huge discrepancies btw. the Front-End and the Editor-View…we mean mainly dimensions and paddings /margins btw elementes like below…is there any known bug or advision how to avoid this? the differences are so big that we can not just ignore and use a try and error way to make the pages look like intended layoutwise…
thanx so much
It is not possible to diagnose based on your screenshot alone, but most differences between the frontend and admin editor are usually due to the fact that position: relative; is set by Gutenberg by default in the backend for blocks containing other elements.
So depending on the specific issue, setting position: relative; on the block may fix many issues. Please note, this is not a catch all fix, it just happens to be a common issue with the Gutenberg editor.
ok i see thx. i will test this. so to work near gutenberg (instead of oversized old page builders) result in haveing a certain amount of uncertainty in the results front- and backend and it has not really to do with Cwicly or other gutenberg based siteEditors…we also have this problems with GenerateBlocks and stackable with exakt this problems…we initially thought in cwicly one doesnte have this shortcoming as it is much more integrated, deeper integgratedd and much more complex than those two more “addon” like editor boosters…
Yes, Gutenberg, on rare occasions, has its finger in the pie.
No, I can’t confirm your experiences - nor did I read this from other users here to this extent.
For me, it seems plausible that it’s rather on the users’ side than on the software side.
Please document these cases in the most detailed way, preferably with screenshots from the back- and front-end which show all relevant elements.
Also consider a quick screencast which, in such cases, saves time on both sides.
Sorry to hear you’re experiencing trouble with this.
Unfortunately, it is difficult to determine what might be going wrong from the screenshot.
To investigate further, could you possibly provide a temporary access?
If this is possible, for security and privacy reasons, kindly send the details using our paste website, by sharing the link generated through email to firstname.lastname@example.org.
Please follow these steps:
- Visit our designated paste website: https://paste.cwicly.com/
- Input your installation details into the provided text field.
- After entering the information, the website will generate a unique link for your submission.
- Share this generated link with us through email.
Thank you in advance.
thanx for you pro-support, that pastBin solution seems awesome also from the data-safety point. Thanx so much. I added and send it.
Thank you for providing access so promptly, @Timo!
As mentioned by email, the Image block discrepancy is due to it being in .webp format.
Cwicly relies on WordPress information as-is, and problems may arise if a third-party plugin optimizes or supports webp without proper calculation.
Please check your webp images, and consider contacting the ShortPixel Image Optimizer author for insights.
Thank you for your understanding.
ok thanx crazy never thought about that possibility i will check. many thanx!
yes we have some examples, i dont think its good to post all of them here…if you like i can pm some…
thx a lot!
we deactivated Shortpixel and the WebP CDN now…now its served as JPG and we still have that issue…i will find now some CSS so make this proper ok…i think in this case at the end it was a CSS override which only took place in the front-end…
Don’t hesitate to share your examples here, I think this thread is the perfect place
we have for example Probleme to Layout for Mobile Screenwidth…somewhere from Columsn derive discrepancies leading to overflow on the right edge…we can not find out why:
ok i did with a better example as own topic i think its better thank you.
You mention discrepancies between the backend and the frontend, but only show the backend…
Could you possibly share the link (by private message or to email@example.com) so I can see what’s happening?
Thanks in advance.
yes sure thank i will sent it now
Thanks for the access.
I’m not sure if you have added custom style definitions or it is a third-party plugin, but the example you have sent us clearly shows that there is a
.card class conflicting with the
.card class applied to the block. The culprit
.card class is loaded on the backend only with the following properties:
padding: 0.7em 2em 1em;
border: 1px solid #c3c4c7;
box-shadow: 0 1px 1px rgba(0,0,0,.04);
Once removed, the discrepancy disappears. This isn’t related to Cwicly.
If you have other examples, please don’t hesitate to let me know.
hmm we found out now what stretches the content…it was the separator element of Gutenberg… in that mix of gutenberg / WP and cwicly one must know at the end a awesome amount of possible details to avoid problems its not very versatile. It was a long journey to find this out…we substited the seperator gutenberg element (the gray lines) with handcrafted DIV-Elements with the same layout. The separator (HR) element is something odd since ever…here it broke our design, this is solved now.
The .card-Stuff you are mentioning: i can not see it in any way, nor in the front-end or either backend…there is no such css classname. i put the old separator from gutenberg in but that also doesnt have this class stuff. have you entirely removed that card-class? but where exactly?
On the pages where we still have this problem there is not .card stuff either…
thanks a lot
here again one very servere discrepancies…we found out after long long testing what the issue is: if you build layouts with Column-Module AND use any slider-element…you get distorted layout…moviing stuff stretching to the right outside the (mobile) viewport…if you use just slider or just columns (image and text only) then its ok…but as soon as you use columsn PLUS slider…you get this problem. But only at Front-End…(!)…in teh Backend it looks good…see below…
Did you resolve this?
This is what I see (desktop and mobile device):
Did you also search the DOM via dev tools in the back-end?
Your screenshot shows front-end, when it was explicitly pointed out that is a backend only occurrence.