Only apply the social links block migration if there's a need for a migration #38561
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
youknowriad
added
[Type] Bug
|
Size Change: -70 B (0%) Total Size: 1.15 MB
ℹ️ View Unchanged
|
|
@ntsekouras It seems we have a problem here (see the failing unit test). Basically, for blocks created with the old itemJuistification thing, there's no way for us to know whether the block need migration at the moment where isEligible is called :( because that information is not yet in any attribute (not even Maybe we could accept that social icons blocks created with justification applied in WP 5.8 become invalid. I'd appreciate any ideas. |
|
We could potentially add the "rawBlock" as a third argument of the |
|
isEligible function is very bad right now, it receives "raw attributes" (comment attributes) and "parsed inner blocks". It's not really coherent. The ideal solution potentially would have been to receive both |
You mean these two and loose the current second param(innerBlocks), correct? That would make sense and for back compat we could make an enhancement to just add a new object with the extra data. Having said that, even if we add this info I don't see how it can solve our problem. It seems more to me we would need an API with
This deprecation was added without taking into account that the
So IMO this deprecation could be deleted and accept the fact that blocks with the old |
youknowriad
force-pushed
the
fix/social-links-migration
branch
from
7dc353c to
d53cb8f
Compare
|
@ntsekouras I removed the deprecation, I think that's fine, blocks won't be invalid right? since it will be just a custom class if I'm not wrong. |
ntsekouras
approved these changes
Feb 11, 2022
There was a problem hiding this comment.
LGTM! Thanks!
I tested with the removed now markup(core__social-links__deprecated-1.html) and some variations - different classes. My observations in my previous testing are still the same. No invalidations and the only view that get's affected is in the editor.
Mamaduka
removed
the
Backport to WP Minor Release
Mamaduka
pushed a commit
that referenced
this pull request
Feb 16, 2022
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
closes #38549
closes #37542
By default all social links blocks were running through a block deprecation even if they were valid and didn't need the said migration. That's because the migration was checking if layout is undefined, but the layout is undefined by default (default value). The migration running was causing the
styleattribute to get removed because when the migration was added, the style attribute was not present on the "social links" block yet.This PR fixes by only running the migration on the blocks that really need it (old blocks with old justification classnames).