-
Notifications
You must be signed in to change notification settings - Fork 4.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Migrated button markup causing rendering problems #28957
Comments
Thanks for the report @fullofcaffeine. I did some testing and noticed that if the inner button block is pasted on its own into the code editor it works ok: <!-- wp:button {"align":"center"} -->
<div class="wp-block-button aligncenter"><a class="wp-block-button__link">Contact</a></div>
<!-- /wp:button --> So I think it's rather than being caused by a deprecation, it's caused by new styling on the I think there's a simple fix, which would be to make any aligned blocks in a buttons container use the This should also be added to WordPress 5.7, so adding this issue to the project. |
This is a bit harder than I thought, the problem with |
The issue here is that you shouldn't be able to add alignments to the inner button block unless there's no wrapper. So the question is here is how did you manage to get that markup? Did you write by hand? |
@youknowriad I think that's only true since #26380, but buttons created before that may have had alignment on the inner button block. edit: I may be wrong though—would have to check out quite an old version of the code. |
Buttons created before aren't supposed to have a wrapper and if there's a migration in place somewhere it should move the "align" to the parent wrapper instead. (The linked PR just refactors the block to disable alignments in a different way, the alignments were still disabled) |
I just got bitten too by this. And although I wasn't able to find the reason in code I am 99% confident it is caused by by a migration since I tracked down the change in the affected post:
got transformed into
I was then also able to reproduce it by creating the un-wrapped legacy button above and then migrating it to the wrapped new version via the UI. Which resulted in the broken markup. |
From what I understand, there isn't any code that would automatically migrate a button block to be wrapped in a buttons block. |
This shouldn't be a problem though, the question is how to get a button with alignment inside a button wrapper. |
I manually transformed it via the "Transform to" function in the UI. |
@kraftner Makes sense, that's the issue than, the "transform" should move the "align" attribute to the wrapper instead of keeping it in the child. 👍 |
In trying to replicate this, I reused the mark up above, added it into a post via the code editor, and transformed it to a buttons block:
Here's a video: transform.button.movI think this replicates the initial problem of a button block not having alignment but I'm not quite sure. Is this issue still ongoing from everyone else's point of view? Testing with WordPress 6.6.1 and Gutenberg 19.1 using a simple WordPress Playground instance. |
Description
I have a somewhat old block buttons/button markup that looks like this:
Upon upgrading to the latest Gutenberg, I noticed some unexpected rendering behavior upon reloading one of my posts:
right
;I tried to debug this and I suspect there's something fishy in one of the deprecations. I'm not entirely sure how they work, but it seems that the culprit is somewhere around here (might be wrong!).
Step-by-step reproduction instructions
{"align":"center"}
to "right". Exit the code editor;Expected behavior
I expect the old markup to correctly deprecate and migrate to a newer version that matches the latest and doesn't cause any rendering problems. This can be problematic as buttons stop respecting the previous align setting and end up breaking the layout.
Actual behavior
Something is wrong somewhere in the deprecation/migration pipeline that generates an inconsistent markup and ends up causing rendering issues as I described above.
Screenshots or screen recording (optional)
Peek.2021-02-11.17-55.mp4
WordPress information
Device information
The text was updated successfully, but these errors were encountered: