Topic: Block editor adds 28px top/bottom margin to every block

evomentum
May 28, 2026 at 12:54 am
Hi,

I’m running GeneratePress + GenerateBlocks Pro and noticed a WYSIWYG discrepancy in the block editor: every block has visible top/bottom margins in the editor that do not exist on the frontend.

WordPress Core injects the following rule via load-styles.php:
```
html :where(.wp-block) {
  margin-top: 28px;
  margin-bottom: 28px;
  max-width: 840px;
}
```
The max-width: 840px part is already overridden correctly — presumably by GP or GB styles. But the margin-top and margin-bottom are not, and they apply to every .wp-block element in the editor, including GenerateBlocks containers.

In the editor, every GB container and its children show 28px top/bottom spacing that doesn’t exist on the frontend. This makes it impossible to judge vertical spacing and proportions while editing.

Screenshots:

Related issue I already worked around

A similar pattern caused incorrect margin-left: auto; margin-right: auto centering inside GB containers in the editor. I fixed that with a block_editor_settings_all override:
```
.editor-styles-wrapper :where([class*="gb-element-"]) > .wp-block {
  margin-left: 0;
  margin-right: 0;
}
```
I could apply the same workaround for the top/bottom margins, but since the max-width part of the same rule is already being neutralised somewhere in the GP/GB stack, I wanted to check: is the margin override intentionally left in place, or is this a gap that should be fixed natively?

Thanks!
George
May 28, 2026 at 4:40 am
Hello,

Thanks for the detailed report. I’ve been digging into the editor styles and can’t reproduce the discrepancy on my end — the .wp-block margins from the core rule appear to be overridden correctly in my testing, and the spacing I can see in your screenshots isn’t showing up for me.

Could you share:
1. Your GP, GP Premium, and GB Pro version numbers
2. Which block structure you’re using — specifically, are the four feature boxes GB Containers inside a Grid, or a different setup?
3. The computed margin-top and margin-bottom values from DevTools on one of the affected blocks (Computed tab, not Styles)
That’ll help narrow down whether this is environment-specific or something in a particular block configuration.
evomentum
May 28, 2026 at 10:46 pm
Hello George,

thanks for getting back to me!
1. I am using GB Version 2.2.1 | GB Pro Version 2.5.0 | GP Version: 3.6.1 | GP Premium Version 2.5.5
2. The four boxes are in a grid and synced patterns with overrides. Inside the pattern is a GP Container and Vanilla Gutenberg Text-Blocks.
3. The computed styles are margin-bottom: 28px and margin-top: 28px.
I think it’s easier if you login and check for yourself. I shared the login information in this thread.

I deactivated the snippet (“Editor Fixes”) fixing the margins that’s why the boxes look a little different from my screenshots in the backend (centered heading).

I made some adjustments with snippets and design tokens. Maybe I accidentally deactivated the GP Overrides? Although I tested it without the snippets as far as I could and still had this issue. The only snippet I can’t really test/deactivate is the “Design Tokens” one – which might be the one breaking your overrides? But it should only insert CSS variables.

If you need anything else or have any questions, let me know!
George
May 29, 2026 at 3:43 am
Hello,

Thanks for the additional details — I can see what’s happening now.

The extra spacing in the editor is coming from the synced pattern wrappers (core/block). WordPress gives these a wp-block class in the editor, which picks up a margin-top: 28px; margin-bottom: 28px rule from WordPress core. On the frontend, pattern wrappers don’t render as DOM elements at all — the inner content is output directly — so those margins simply don’t exist there.

This is a WordPress core inconsistency rather than a GP/GB issue, which is why it wasn’t being neutralised automatically.

The fix is to add this to your “Editor Fixes” snippet:
```
add_filter( 'block_editor_settings_all', function ( $settings ) {
    $settings['styles'][] = [
        'css'    => '
            .editor-styles-wrapper .wp-block-block {
                margin-top: 0;
                margin-bottom: 0;
            }
        ',
        'source' => 'evo-editor-fixes',
    ];
    return $settings;
} );
```
Another thing I noticed on your grid: You have a global style named .u-grid with which you are setting the container layout to a grid with repeat(2, minmax(0, 1fr)) grid template columns. Then on the local style, you are setting those two again (not needed since you have the global style doing the work).
evomentum
May 29, 2026 at 3:57 am
Ahh I see! Thanks for looking into that!

—

Another thing I noticed on your grid: You have a global style named .u-grid with which you are setting the container layout to a grid with repeat(2, minmax(0, 1fr)) grid template columns. Then on the local style, you are setting those two again (not needed since you have the global style doing the work).

Thanks for pointing that out. This is actually not me putting additional css settings there but the grid blocks default settings there. It comes prefilled with those settings, same as column-gap and row-gap. I remove the default gaps but didn’t remove the other defaults.

When I remove the [block]-style tag in global styles the block looses it’s icon (which I don’t really understand why). Which I wanna keep for usability.

So my workflow currently is:
1. Adding the grid
2. Giving it the u-grid class
3. Removing the gap-settings
4. Styling it as I need.
Which is honestly a bit frustrating: I don’t really like step 3. I’d love to be able to set the default settings for the GB-Blocks but afaik that’s not currently possible. Or at least have it inserted without any default values. (Same goes for Accordeon, …). Are you guys working on that? Am I overlooking a solution?
George
May 29, 2026 at 5:04 am

Hello,

When a Container block is inserted and display is set to grid, the styles object starts completely empty — values are only written when you explicitly set them in the editor. There’s currently no PHP filter or JS hook that allows you to pre-populate those style values on insertion.

The most direct path to getting this changed would be a feature request at feedback.generatepress.com. If you can describe the use case there — being able to define default grid styles for newly inserted Container blocks — it gives the team something concrete to consider.

In the meantime, the quickest workaround is saving a synced or unsynced pattern configured the way you want it, and inserting from there rather than the block inserter directly.
evomentum
May 29, 2026 at 5:08 am

I’ll provide feedback and will look into a unsynced help-pattern. Synced wouldn’t work since the contained elements are always different.

Thanks!
George
May 29, 2026 at 5:13 am

Ok, no problem!
evomentum
May 31, 2026 at 11:09 pm

Hey there again. I submitted my feedback post on feedback.generatepress.com. But I can’t see it in my profile. I guess it has to be manually approved?

I was a bit confused since I submitted my post on friday last week and didn’t see it today and submitted it again. There’s no help Text or indication why my post isn’t showing up. It would be great to see it with “in review” or “submission pending” or something like that.

https://feedback.generatepress.com/post/264/ & https://feedback.generatepress.com/post/263/ are the posts I submitted. Found it by decrementing the post id. Sorry for the confusion and double posting. You can delete the newest 264.

Have a great day!

Viewing 9 posts - 1 through 9 (of 9 total)

You must be logged in to reply to this topic.