Oh sorry, you can check the livesite here: https://www.rayastro.com/
on a side note… I cant recall what settings I used to make the menu up top look spaced the way it is
You can try the following approach:
Text form:
<style>
.wp-site-blocks {
min-height: 100vh;
display: flex;
flex-direction: column;
}
</style>
Now, you can add either a rule to your section block or your footer block.
Option #1:
Option #2:
Text form:
<style>
footer {
margin-top: auto;
}
</style>
Let me know if it helps.
Where do I find the custom code snippet box?
Cwicly options in the back-end.
Thank you,
neither option appeared to have any effect.
I think that the menu design is broken… I cannot replicate my header, which I think was done before the recent update of the plugin. Please see the attached gif. I want to space the menu options out, similar to my header. However, the flex space between options and other options appears to do nothing.
Thanks! I had to add it to a section block because the footer block wouldn’t allow me to add the CSS to it. Probably because it is not a cwicly block. Also it did not update in the cwicly view even after saving but the site looks correct when I open it up.
Continuing this thread… When adding the provided code to my site, the footer does get pushed down, but below the browser window due to the 100vh or dvh rules. Any advice how to push the footer to the bottom on pages with little content? Thank you.
This only happens when your content is pushing down the footer.
Could you provide a demo of how you applied the styles to both the post content block and the .wp-site-blocks class?
An exception is when global parts are placed outside the .wp-site-blocks wrapper which depends on your general setup.
Could you please provide a screenshot of your DOM of the frontend then?
You might have to apply the rules differently then (body instead of .wp-site-blocks and .wp-site-blocks instead of the post content block).
Well, have added the wp-site-blocks as a global style. I have attached a screenshot (DOM) of a page with almost no content.
As for the post content - are you referring to the default post content block - because, no styles are applied to it.
I recommend treating the header like the footer, creating and placing them the same way to have them on the same DOM level.
Currently your header is inside the .wp-site-blocks wrapper, while the footer sits outside.
While this isn’t relevant for your current setup, this is how you would have to apply the flex property to Cwicly’s post content block, if header, post content and footer are all part of the .wp.site-blocks wrapper.
Here is the solution for your current setup, like mentioned above
body {
min-height: 100dvh;
display: flex;
flex-direction: column;
}
.wp-site-blocks {
flex: 1;
}
Please let me know if that helps.
1 Like
Sorry for the many follow up questions.
- Is it best practices to have the header and footer outside of the .wp-site-blocks?
- How can I move my header outside of the .wp-site-blocks?
- Is the .wp-site-blocks referring to the default “post content” block and should therefore be part of every template?
I was reading in another thread that the .wp-site-blocks can (should?) be tagged as “main” in order to achieve the following structure Header < Main > Footer>?
No worries, that’s what this Discourse is for @Alexander 
Well, I’m fan of a clear structure, like:
<body>
<header>...</header>
<main>...</main>
<footer>...</footer>
</body>
Gutenberg decided to introduce a little intruder here - the .wp-site-blocks wrapper.
Please check this topic for more info in that regard:
Gutenberg $content wrapper - General - Cwicly
Unfortunately, as far as I’m aware, we have no control of where to place the global elements, as they get placed on the root level, like where the .wp-site.blocks wrapper sits.
So, the best solution is to just ignore this wrapper and act like it’s not there.
To answer your question. Since we don’t have a choice, we need to work with what we get.
You should have a consistent approach though.
Like mentioned above,
if you create a footer as a global part, you also should do the same for the header.
Please share your current setup from the Themer if you have issues to follow my advice.
The Post Content block is an independent block and has nothing to do with the .wp.site-blocks wrapper.
It’s always (and only) required if you add content on a page or post level.
This, of course, also depends on your general approach and how you setup your site - also in terms of your template setup in the Themer.
In most cases, it’s recommended to apply the <main> tag to the Post Content block.
As mentioned above, just ignore the .wp-site-blocks.
It’s a meaningless element, DOM structure wise.
No one cares about it from a technical perspective.
1 Like
Hi @rrbailey89,
I’ve found a simple and clean solution for a sticky footer, a while ago at css-tricks.com/a-clever-sticky-footer-technique. One doesn’t have to mess around with flex and similar …
It consists in adding this few lines of CSS as a code snippet or within a global stylesheet:
html, body, .wp-site-blocks { height: 100%;}
body > footer {
position: sticky;
top: 100vh;
}
I find it simple, clever and effective … and it just works on all my sites. 
Hey @Marjan.
Thanks for adding this approach here, I wasn’t aware of that.
The problem I see with this, that it requires a specific DOM structure to work.
The provided solution above also requires a specific DOM structure, but depended on the case (which are actually only 2 to choose), it’s easily tweakable via CSS, where the approach you posted can’t be tweaked, since, as mentioned, relies on the actual HTML.
Please let me know your thoughts 
Hi @Marius,
I see what you mean (I think!?) and honestly, never thought of that.
You’right, it relies on the actual HTML structure … so one has to modify css selectors accordingly … but, since the base html structure hardly ever changes, one sets it up once and that’s it.
I use it with Generatepress, Bricks and Cwicly. Of course, each of these creates a different html structure, so selectors must reflect that … I do it at the beginning and then forget it … no hassle at all.
So, it’s not that one has to modify it constantly … if that is what you meant?
Of course, the ideal solution would be the totally automatic one - independent of the site’s structure, but I don’t know if that’s possible with css only … one just has to tweak/adjust things each and every time to make them work properly.
At least, this is how I see it.
Cheers
P.S. Perhaps Cwicly-team could add this as a feature, a global setting to turn sticky-footer on/off… 
Hey @Marjan.
Thanks for your feedback 
If you always have the same and consistent approach to how you build your site, then you are absolutely right.
As long as it’s working for you, it’s a solid solution, which doesn’t differ too much, as it’s quite the same amount of CSS one must add. It’s just not as flexible (due to the nature of how position: sticky; works in general), that’s it.
Exactly. If you always have the same basic DOM structure, it’s just set and forget.
In terms of my provided solution, it’s quite simple though not automated:
body /** footer outside .wp.site-blocks wrapper **/
.wp-site-blocks /** footer inside .wp.site-blocks wrapper **/ {
min-height: 100dvh;
display: flex;
flex-direction: column;
}
.wp-site-blocks /** footer outside .wp.site-blocks wrapper **/
.post-content-block /** footer inside .wp.site-blocks wrapper **/ {
flex: 1;
}
Although I would always recommend having header and footer at the same DOM level, it’s not necessarily required with this approach.
The solution you provided requires this specific structure, since the footer always sticks to its direct parent, so there is an actual dependency.
I think that would be quite easy to implement and can see that it’s useful for users.
However, I would always rely on my own solution for more flexibility, also in case I want to add or remove specific styles from this particular rule.
But that’s also rather a thing of being not a fan of such CSS “options”.
Thanks for your feedback over on Facebook @Alexander.
I’m glad you found the solution, which hopefully finds its place in all your future projects.
Just checked your site and works like a charm
In case there is still something unclear, don’t hesitate to reply to this thread.
Cheers!
Here’s what I do, however your mileage might differ.
First the structure of my websites is kind of different from what the Site Editor does by default, as I don’t include site parts in my templates. I’m not sure this is the best approach, however it works for me, and I’m comfortable with it.
By following the structure above, I end up with the following html structure:
<body>
<a class="skip-link screen-reader-text" href="#main-content">Skip to content</a>
<header id="site-header">...</header>
<div class="wp-site-blocks">
<main id="main-content">...</main>
</div>
<footer id="site-footer">...</footer>
</body>
With this structure I can use the following CSS in my reset:
body {
display: grid;
grid-template-rows: auto 1fr auto;
min-height: 100svh;
}
What this does is effectively always display header and footer at the top and bottom of the page respectively, and anything in between will always fill the entire available space.
There’s a catch though. For archive templates you’ll have to wrap everything inside a section/container/div (whatever fits your needs), change the tag to <main>, and give it an ID (although Cwicly will probably do it for you if you don’t do it, and handle the skip-link, which is really handy).
This works like a charm form me, and I’m very pleased with its simplicity. Also, the 100svh makes sure there are no jumps on mobile devices.
I hope this helps
1 Like
PS:
Semantically speaking there is nothing wrong in terms of HTML structure to have your <main> tag wrapped in a <div> the way I’ve shown. As long as you don’t have it nested inside the <header> or <footer>, and vice-versa (believe me, I’ve checked).
Now, in the literal meaning of the word semantic, it feels and looks off (and some may say wrong). My hopes were that at some point we would be able to change the HTML tag of the .wp-site-blocks element. This would definitely be more elegant and would mean less one level of nesting.
However, something tells me that’s exactly why the Gutenberg team decided to wrap everything inside this element, so you could have them all at the same level or something like that. Probably to allow to not include site parts in templates if we wanted to. But I don’t like this approach. I find having to add the site parts inside every template is counter-intuitive for me, and kind of bloated. Especially since everything always loads expanded in the Navigation panel, and it takes me ages to find where I’m at. It’s not a good workflow for me and my dyslexic alter ego. So I came into terms with having this not-so-optimal structure. I’m fine with it.
But if you don’t like it, you could definitely apply the same CSS to .wp-site-blocks if you wanted to.
.wp-site-blocks {
display: grid;
grid-template-rows: auto 1fr auto;
min-height: 100svh;
}