HTML API: Move into 6.2 Compat Folder since inclusion in Core #47749
Conversation
Since the merge of the Tag Processor into Core in [55203][55203] it's no longer needed in Gutenberg in the experimental directory. In this patch we're moving a version of the Tag Processor which was updated during the Core merge into the `lib/compat` directory so that we can continue to provide it where necessary while avoiding conflicts that might otherwise arise by leaving it where it was. [55203]: https://core.trac.wordpress.org/changeset/55203
dmsnell
force-pushed
the
html-api/move-to-compat-layer
branch
from
0ce3a5c
to
9e8d9ba
Compare
|
This looks right to me! Looks like the lint errors are due to not passing Are there any changes that were made to the tag processor in Core before being committed that should be copied back into the plugin? |
GitHub CLI is oversensitive in this case. We need to apply the same exceptions as we already use for core blocks that accept translations without the second argument. This place: Lines 28 to 30 in 862fe67 In fact, I don't think there are many cases where we want the second argument to be |
@noisysocks the code in this PR/branch diverges significantly from its merge base and those changes are coming back from Core. If it looks like there's nothing different it's likely because GitHub recently decided to hide the most important parts of PR diffs so they could prune out some DB calls 🙃 try clicking on "Load Diff" and you will see it. |
|
@gziolo @noisysocks it'd be nice to get this in soon before it starts causing conflicts with Core, but do we need to resolve the linter issues here? is there a clear directive on what needs to happen before merging? I don't understand if I should be appeasing the linter or filing an exception or fixing the linter's rules. |
`WordPress.WP.I18n.MissingArgDomainDefault` should not trigger for code that polyfills features present in WordPress core.
I'm trying 6765520 to see if that silences the linting "issues" that are false positives. Again, there should be no second param for the translations used in the code that polyfills functionality present in WordPress core. If that causes trouble, I will try to improve it on my local machine 😅 |
gziolo
added
Backport from WordPress Core
|
Flaky tests detected in 6765520. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/4112194725
|
juanmaguitar
added
the
[Type] Code Quality
During preparation for the WP 6.2 release, the HTML Tag Processor files inside the Gutenberg plugin were [moved](WordPress/gutenberg#47749) from `lib/experimental/html/` to `lib/compat/wordpress-6.2/html-api/`. This PR updates the import locations accordingly, and sort of "centralizes" them, so we only reference the external dependency in one file (and can potentially later to point to e.g. `lib/compat/wordpress-6.3/html-api/class-gutenberg-html-tag-processor-6-3.php`, which has some features added after the WP 6.2 Feature Freeze, if needed).
Status
Is there any guidance on moving PHP support into
lib/compat? I ran around like a self-driving taxi without its sensors trying to mimic what I saw, the worst kind of imitation. This is probably all wrong.What?
Moves the HTML Tag Processor out of
experimentaland intocombat/wordpress-6.2Why?
The Tag Processor was merged into 6.2. It needs to load only when not already present from WordPress itself.
How?
Copies files from the merged Core code into
lib/compat/wordpress-6.2and updates theload.phpfile to conditionally load the compatibility class.Testing Instructions
Since code in Gutenberg relies on the Tag Processor tests should start failing if something goes wrong. Given that this is merged in Core, ensure that the files copied over are the appropriate files and do not differ from what's in Core. Ensure that they load when running on pre-6.2 versions of WordPress.