Hi All,
can we fix this somehow so the WP-Admin-Toolbar is not overriding the rest of the site…i saw some generaly cwicyl-styles who are leading to this behaviour…we might override them with CSS for admin only…but is there a more general way to avoid this?
Also this bevahiour also causing one more element to be renedered falsly…here you can see in comparison: its not only the overriding of the main body it is also causing the slider element to have a wrong margin-top…
thanx so much
timo
Hi,
It is very weird, because this issue has been fixed a long time ago (not sure if it was a WP/Gutenberg or Cwicly issue).
Which versions of WP and Cwicly are you using?
I used this CSS on my header block when I had the issue:
body:not(.block-editor-iframe__body) .blockclass {
top: var(--wp-admin--admin-bar--height, 0);
}
But today we don’t need it anymore, because this CSS has been added to html element (WP or Cwicly?):
Note that now, we still need some fix for mobile admin view with fixed header:
Issue:
Fix:
@media screen and (max-width: 600px) {
#wpadminbar {
position: fixed;
}
}
Hi yankiara,
thanx a lot. We have cwicly 1.0.3 and WP 6.3.2…
best
timo
i see thanx…we dont need admin for mobile yet thanx but its good to know!
oh we have 1.3.1 if i check version number in plugins-area…but in themes-area it says: 1.0.3…i think this is a bug right? so we have 1.3.1…
OK so you’re up to date.
There might be some other CSS conflicting, maybe another plugin.
hmm strange no even with Cwicly-only…this happens…and no individuall CSS …
i have another cwicly project and here only cwicly is installed in the plugin area…we have the same problem there…
This is WP behaviour, since like forever, and has been discussed a couple of times here already - feel free to use the search function.
Please consider @yankiara suggestion, as this is the proper way in this case for now.
I don’t understand, I personally don’t use the fix any more, it must have been corrected, either by WP or Cwicly.
Noone else can see the margin-top on html tag?
i am bit confused for now…i dont see this problem on other projects yet…no matter if elementor, UX Builder, bakery whatever 
That’s because they provide in-built solutions, like a dedicated header builder, etc.
They include this rule for the header element on front-end as well:
.header-builder.header{
top: var(--wp-admin--admin-bar--height, 0);
}
In Cwicly, you are creating your header directly on the canvas, in no dedicated environment.
So the user must take care in that regard.
Please refer to this solution @Timo , since fixed elements obviously do not respect this rule.
Hope that helps.
PS:
I’m not aware of any added rules in the recent past and I didn’t check things out in detail either. So I can’t exclude if things might interfere now.
ok thx so much all!
even if i completely display:none the wpadmin bar this gap still remains…we just using some very basic layout stuff here and the internal Navigator Module…
strange…
both CSS above didnt work out for me i am sorry…
that’s because of this (WP default):
Why do you want to remove it?
What you want to achieve is to display your page property beneath the admin bar.
Everything is done by this rule, except your header, because fixed elements are always positioned relative to the viewport, not to any element.
I just checked things on my side. Nothing has been changed. Neither by WP, nor by Cwicly.
There are no issues I can find on my side; everything works as expected when going the recommended route.
This is the only tweak you want to apply.
ok i see so our “fixed” header-area is the problem so we must re-think our concept…i thought this “fixed” header came from the cwicly-navigation-element? so we are multipled developers so someone set this up apart from your “route” right?
OK so I remember now why I didn’t need the fix any more… It has not been corrected by WP or Cwicly, but I found out that for a fixed positioned element, default top position is NOT 0 from VIEWPORT top, but zero from CONTAINER top.
So if you don’t set top: 0, you don’t need the fix, because the fixed header will be positioned at 0 pixel from the header container, which probably is the .wp-site-blocks div, which is contained in html element, which has a 32px top margin, hence not covering admin bar.
So you’re issue is that you probably set top: 0 on your fixed header, which you shouldn’t.
(NOTE: If you need to offset the fixed header, don’t use top but margin-top, so that you still work inside the container viewport.)
This is correct @yankiara. If you don’t set a direction, like top, a fixed element behaves like an absolute positioned element.
But!
Cwicly, depending on your general approach, places blocks outside of the .wp-site-blocks element, so one must keep that in mind when building the site.
Especially with global elements like the header, one needs to be aware of that.
The recommended route remains the same.
ok cool i see thanx! for now we dont fix it at all…we must sort some things out now…later we want a normal sticky-automatism. for what i see now Cwicly is really more for developers intended and not for “end users” without real indepth developing knowledge despite their marketing
I don’t understand, maybe library fixed blocks have top: 0, set, but then you can just unset it.
Maybe I’m missing something but how Cwicly would put elements outside of wp-site-blocks?
