• Resolved simon171

    (@simon171)


    Hi

    Hoping you can help. A year or so ago I contributed to, and then took from, a support thread here a very useful code snippet (below) that prevents the GB default 40px padding around every container. It has worked well.

    BUT… now suddenly the padding is returning – to existing posts which were designed without it. Maybe it’s something in a recent GB update that has stopped the code snippet working? I can’t think of another reason.

    So I’m wondering if you can help in identifying why, and help me to continue to prevent it as before. (One question about the code below is whether it should apply to the container or inside-container? – but either way, it worked before.)

    Thank you.

    // This works to cancel the automated 40px padding.   
    add_filter( 'generateblocks_defaults', function( $defaults ) {
        $defaults['container']['paddingTop'] = '0';
        $defaults['container']['paddingRight'] = '0';
        $defaults['container']['paddingBottom'] = '0';
        $defaults['container']['paddingLeft'] = '0';
    
        return $defaults;
    } ); 

    (The linked page is one of those where the padding has suddenly reappeared. It was not there before.)

    The page I need help with: [log in to see the link]

Viewing 5 replies - 1 through 5 (of 5 total)
  • Plugin Support ying

    (@yingscarlett)

    Hi Simon,

    In GB 1.4.0 we changed the padding defaults from 40px to0px.

    In order to do this, we had to add migration to make sure that users who were using the 40px don’t lose their padding. When you load the editor, it will check to see if no value exists (which means it was using the old default). If no value exists, it adds the old 40px default. This prevents users from losing their Container padding.

    This is the opposite of what is happening to you. The issue here is you’ve somehow made it so these padding values are empty even though it wasn’t possible to do prior to 1.4.0: https://www.screencast.com/t/TwTU3KKirAQc

    The editor would automatically add a 0 value if it was emptied.

    Since they have no value at all, the system assumes the old default is being used, so it adds it for you (thinking it’s doing you a favor).

    The only potential solution here is to disable the migration by telling it your default was already empty. However, this will make it so any Container blocks you have that are using the old 40px default will now have no padding.

    You can do that using this snippet: https://community.generateblocks.com/t/change-the-default-container-padding/287

    Sorry for the inconvenience here – the migration was built to minimize issues like this, especially as it was previously very difficult to actually have an empty value like you do here.

    Let me know if the default change works for you.

    Thread Starter simon171

    (@simon171)

    Hi Ying

    Thank you for the response and explanation.

    What I don’t understand is the code I was using seems exactly what Tom is offering in the link you gave. It’s not working any more.

    In case it helps find a solution, I have no posts using the old 40px default. The zero worked, so any padding was added either in Additional CSS, or occasionally manually.

    So can I get the defaults back to zero? Please advise.

    I guess one question is now what triggers GB to add the 40px back in? Is it when I edit a post? ie Can I trust unedited posts to remain intact? I ask because I have two sites with a lot of posts with the zero default.

    I would appreciate your help. (I do have GB pro – Leo just directed me here when I asked on the GP forum.) Thank you.

    Plugin Author Tom

    (@edge22)

    Hi there,

    GenerateBlocks should not have added the 40px of padding back into your blocks with that code active – it should have simply bypassed the migration and moved on.

    I’m wondering if it’s because the 0 is being passed instead of an empty '' string.

    Have you already saved those pages since the update?

    If not, doing this should fix it:

    add_filter( 'generateblocks_defaults', function( $defaults ) {
        $defaults['container']['paddingTop'] = '';
        $defaults['container']['paddingRight'] = '';
        $defaults['container']['paddingBottom'] = '';
        $defaults['container']['paddingLeft'] = '';
    
        return $defaults;
    } );

    If you have loaded the editor for those pages and saved them (the migration has already been completed), we will likely have to do a database search/replace in order to remove those values.

    It’s best to do the below on a staging site first just to make sure.

    1. Install this plugin: https://www.ads-software.com/plugins/better-search-replace/
    2. Search for: "paddingTop":"40","paddingRight":"40","paddingBottom":"40","paddingLeft":"40"
    3. Replace with: "paddingTop":"","paddingRight":"","paddingBottom":"","paddingLeft":""
    4. Search the wp_posts table (or whatever you db prefix is)
    5. Run as a “dry run” first to make sure it’s going to do what we want it to do.

    Let me know – and sorry for the inconvenience!

    Thread Starter simon171

    (@simon171)

    Wow Tom. Thank you!

    To answer your question I tested this out also on a previous site which was created entirely with that no-padding snippet in place. And yes, when I open a page in the editor, suddenly 40px padding is added to every container! So I exited without saving, and it remained OK.

    I then noticed… that on both sites the code snippet was set for the front end only. I cannot imagine why, or when. It cannot have been set like that when we were creating all the pages and posts.

    So of course, even when I replaced the snippet with your code above, the 40px padding was still then added in the editor. When I then set the snippet to function at the backend too, the padding was not added. So I then retried the original code, and it still works. The problem was in that front-end only setting.

    So thank you, and major apologies. You were right in saying that the update should not have added the 40px back in – it didn’t. The problem as ever was when the brilliant system met human error…

    Plugin Author Tom

    (@edge22)

    Aha – that makes sense. What a relief ??

    Really glad it’s all working now, thanks for letting me know!

Viewing 5 replies - 1 through 5 (of 5 total)
  • The topic ‘Automated padding of 40px – it returns!’ is closed to new replies.