[Resolved] Padding has gone awry with latest version

[Dan]

Hi. In the past week, I have updated the theme and plugins. Current versions are:
GP = 3.1.0
GB = 1.4.0
GBP = 1.1.1
GPP = 2.1.1

After this upgrade, I started noticing that the site was visually broken. After researching, I found this thread here:
https://generatepress.com/forums/topic/padding-issue-on-edit-after-update-to-gp3-1-0/

Sounds like there was some sort of internal padding fix being made between versions that has affected my site. It also sounds like the fix should be the snippet on this page:
https://community.generateblocks.com/t/change-the-default-container-padding/287

I’ve tried that, but it doesn’t seem to fix all. I currently have issues now where controls have no gutters in certain containers on mobile. And other visual oddities like visually-broken discounts and FAQs.

There are over 200 pages on my site and desktop/tablet/mobile versions, so it does not feel practical to manually go through every page and click on every container, then click the “Spacing” accordion for each, then determine if any of the “40” values in the “Padding” textboxes are what I had put in or what GeneratePress/Blocks just defaulted to.

I am seeking guidance to fix, make the process to update more efficient and error free (in terms of a human going through and not missing something), or if neither of those can happen, instructions on the safest way to rollback the offending plugin/theme.

Related – are you able to color the numbers in the padding control (or any control) differently if it’s a default value?

Thanks for your time.

[Tom]

Hi Dan,

I’m curious, have you actually opened up these pages and saved them after updating to GenerateBlocks 1.4.0?

The known issue only happens in the editor once you load it using GB 1.4.0, and then will happen on the frontend if you save it without altering the fields.

If you’ve already updated these pages using GB 1.4.0, it will be difficult to fix.

If you have, is it possible to roll back using a backup taken before the update? If so, we can likely run a search/replace in your database to try to explicitly set your padding values to 0.

Do you have any idea how these padding fields were emptied? We’ve seen this issue happen twice now (with almost 40% of users having updated to 1.4.0), but we haven’t been able to figure out how these fields were emptied in the first place.

Let me know 🙂

[Dan]

Thanks for the response, Tom.

For the page I sent in the private area, I have not explicitly saved it (although, there is a WP-generated autosave). However, I did have a padding problem on the front page that I noticed after saving it the other day, which is what triggered this investigation and ultimately, this ticket.

I saw your screencast on the Padding textboxes here:

But I feel like I’ve always been able to delete the numbers without the 0 coming back. But, I could be wrong. My workflow has been to edit the Padding numbers for desktop (and sometimes deleting numbers), then cycling to tablet, then to mobile (again, sometimes deleting numbers) to ensure that the derived values still looked good on all device widths.

I did notice in the other thread that someone called out templates. If it helps pinpoint, I used GB/GP templates as a skeleton for several of my elements when initially designing the site.

All this said, I have both GenerateBlocks and GenerateBlocks Pro. Can you confirm that you think the possible issue is related to GenerateBlocks? And if so, I’d like to rollback the plugin to the previous version to see if the visual errors still occur. And if there are no visual issues with the previous version, then I can tell you more knowledgeably what the behavior on the Padding textboxes are.

If I rollback (I don’t do this often), do I want to use something like this?
https://wordpress.org/plugins/wp-rollback/

Or do you have a better suggestion (or something internal in GP/GB) to change between versions?

Thanks for your time.

[Tom]

Strange, the issue as we know it only happens once the editor is loaded using the new version and then saved. I would love to see how it looks using 1.3.5 (you can download it at the bottom here: https://wordpress.org/plugins/generateblocks/advanced/).

It should have never (at least since v1.0) been possible to simply remove the padding values – the plugin specifically prevented that from being an option, which allowed us to implement this method to remove defaults in 1.4.0.

If your pages haven’t been saved since the update it should be possible to simply install 1.3.5 and things should go back to the way they were.

If at all possible, it would be great if we could do this on a staging site that I have access to. That way I could look at how it’s supposed to look (and how it’s set up) in 1.3.5, and then look at what happens once updated to 1.4.0.

Let me know if that’s possible at all 🙂

[Dan]

Hi Tom.

Funny thing, I have a staging version of the site from a couple months ago that I never deleted. Here’s what the staging site is using:
GP = 3.0.4
GPP = 2.0.3
GB = 1.3.5
GBP = 1.0.4
WP = 5.8.1

Here’s what I’m seeing on the staging site.
– I can click on some containers and see that their Padding values are blank.
– If I put a value in the Padding textboxes and try deleting those values, then they are forced to 0 in the textboxes.
– If I make a new container, then it defaults to 40 in each of the Padding textboxes.

In this case, I believe that the Container that is starting with blanks was, at some point, based on a template.

I left instructions in the private area on how to reproduce the above behavior. Hope that explanation made sense. Thanks for your time.

[Tom]

Thanks for the additional info!

When you say based on a template – was this a Site Library site, or templates from the GB Pro Template Library?

We did run into this issue in some of our library sites which are now fixed, so that would explain it if you used those existing blocks and just updated their contents.

Ok, so a solution. The only true solution I can think of here is doing a find/replace in the database to turn these blank values into 0 values.

However, this would be an issue if you’re using Global Styles (from GB Pro), as they empty the padding fields.

If that’s not the case, let’s try it (on a staging site first):

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

Now when you update to 1.4.0, the migrator will leave these fields alone when you load the editor.

Let me know – and sorry for the inconvenience here!

[Dan]

Hi, Tom. I’ve executed the process you’ve described and it looks like the “0” values have been populated now. I’m back on GB1.4 and spot-checked a couple pages. Things look better, thanks for the direction.

Two follow-up questions.

1. When I go in to edit a page/post, then I try to exit immediately, I am still greeted with the “Changes you made may not have been saved” dialog. Is GB/GP altering another value somewhere?

2. I noticed that the Header block exposes padding too and those values do not appear to have been changed nor did anything seem affected. I’m guessing that wasn’t touched in this 1.4 update AND the names of the padding values are something different than “paddingLeft”, “paddingBottom”, etc?

Regards.

[Tom]

Glad that worked!

1. Yes, in 1.4 we update the block version for each of our blocks when you load the editor. This will make it so the migration doesn’t happen anymore once those blocks have been saved after migration.

2. Are these using GenerateBlocks as well? If so, they should have been affected like any other Container block inside your content. They have the same attribute names.

[Dan]

Hi Tom. To close the loop on this ticket.

1. Understood.
2. I was referring to the Headline block from GB. There is a Padding section for Headlines.
3. To answer an earlier question – I looked back and IIRC, it was the GB Template Library that I based some of my layouts upon months ago.

Thanks for your time and effort on this issue.

[Tom]

Ah, Headline padding hasn’t changed at all – it’s always had empty padding values. Only the Container padding changed as the default used to be 40px.

No problem, I’m glad we were able to find a solution 🙂

[Author]

Posts