Wordpress backoffice topbar overlap cwicly fixed header

kindly report one thing i met:
wordpress backoffice topbar and cwicly fixed header overlap, when login out, everything is perfect.

Hey @qiang814k,

maybe this is what you are looking for:

thanks a lot, i get understood. :clap:

as a most powerful FSE solution plugin, i would suggest that cwicly plugin need embed this inside by default, because this common issue will be met by all the cwicly user when they set fixed header.

cheers

Too many variables that could cause even more issues.

The only issue I currently have, I’m not able to insert the rule top: var(--wp-admin--admin-bar--height,0); directly inside the FSE environment to my fixed header block.
That’s because the admin bar is present; even if it’s not visible.
So there is an adminbar height offset but no adminbar.

Maybe there is something that didn’t cross my mind yet.

This seems to work for me:

body:not(.block-editor-iframe__body) header {
  top: var(--wp-admin--admin-bar--height, 0);
}

I tried a lot in that regard and faced too much inconsistencies.
If it’s working out for you, it’s fine.
I think there is no right or wrong.

This approach isn’t something I would use personally.
Especially since there is the possibility using multiple header tags on a page.

Come on, it’s an example, of course header selector can be replaced by whatever you need.

And I was not saying it was the right way, but that it worked for me.

I was just trying to help you with the FSE issue and how I personnally resolved it.

Thanks for trying to provide some hints, it’s appreciated.

What I was looking for, as I clearly stated, is the opportunity to apply the rule directly to my header block.

You were providing some custom snippet, which probably won’t work throughout the various editor environments.
At least, I couldn’t make it work out of the box - but didn’t investigate further.

I’m pretty sure there is a solution somehow, but I’m currently not interested, as I’m using the widely used standard rule, which fits my needs, until or if there is a better solution available, which Louis hinted some time ago.

It was not that clear that you wanted it in the exact top input field :wink:

But honestly, what difference does it make to put this in the CSS box?

I’m just a big fan of no-code and like to have everything in its intended place.
I don’t want to see rules on front-end, which includes back-end rules, to make them actually work.
And again, this code isn’t something one can use as an universal solution, as it’s not working inside every editor instance.

Cwicly is already very close to a full no-code solution, and I have no plans to not utilize all the great functionality, just to write custom CSS all over the place, because Cwicly does not force me to do so due to the non-existent massive lack in that regard, like all the other tools do.

In this particular case, it’s a WordPress issue, so I highly appreciate the fact that Louis generally tries to find proper solutions and fix things for us which aren’t even related to the tool itself.