Font Library: Avoid running init functions when font library is available in core.

[matiasbenedetto]

What?

Avoid running init functions from the plugin when the font library is available in core.

Why?

• Avoid creating repeated endpoints.
  If the Gutenberg plugin is installed on WordPress core trunk (6.5-alpha) the font collection endpoints are created twice each, one by core and one by the plugin. This PR avoids that.

How?

Checking the WordPress version before running the endpoints creation function.
If the WordPress core version is < 6.5-alpha, the font collection endpoints are not created by the Gutenberg plugin.

Testing Instructions

• Install and activate this Gutenberg PR on WordPress core trunk version.
• Check that the /font-collections/ and /font-collections/<slug> endpoints are not repeated.
• Check that the font collections load as expected.

• Install and activate this Gutenberg PR on WordPress 6.4.3 version.
• Check that the /font-collections/ and /font-collections/<slug> endpoints are not repeated.
• Check that the font collections load as expected.

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

Core SVN

Core Committers: Use this line as a base for the props when committing in SVN:

Props mmaattiiaass, youknowriad.

GitHub Merge commits

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: matiasbenedetto <mmaattiiaass@git.wordpress.org>
Co-authored-by: youknowriad <youknowriad@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[github-actions]

This pull request has changed or added PHP files. Please confirm whether these changes need to be synced to WordPress Core, and therefore featured in the next release of WordPress.

If so, it is recommended to create a new Trac ticket and submit a pull request to the WordPress Core Github repository soon after this pull request is merged.

If you're unsure, you can always ask for help in the #core-editor channel in WordPress Slack.

Thank you! ❤️

View changed files

❔ lib/compat/wordpress-6.5/fonts/fonts.php

[github-actions]

Flaky tests detected in 20693ca.
Some tests passed with failed attempts. The failures may not be related to this commit but are still reported for visibility. See the documentation for more information.

🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/7820836576
📝 Reported issues:

• [Flaky Test] aria-disabled is correctly hydrated for different values #54370 in /test/e2e/specs/interactivity/directive-bind.spec.ts

[youknowriad]

I agree that this is something we could do. It will clarify that any changes to the controller for future versions need to happen on a new compat/wordpress-6.6 instead.

But I'd like to note also that most other controllers that were added to Gutenberg were actually being registered twice during that transition period.

[desrosj]

👋 Hi @matiasbenedetto! Just a friendly reminder to manually review, update as needed, and include the Co-authored-by trailers in the merge commit message. In case it was missed, here's the announcement post and the accompanying handbook page with the specific details.

If it was on accident, no big deal! But just trying to make sure everyone is aware as we retrain our brains. 😄

[matiasbenedetto]

Hi @desrosj, yep, sorry I did that on several PRs, but I forgot to do that on others; my bad.
I have 2 questions:

1. Is it possible to fix the error on an already merged PR?
2. Is it possible to automate the inclusion of the new Co-authored-by credits automatically on the merge commits messages? that would be very useful.

[desrosj]

@matiasbenedetto There's no way to go back and change the commit message without changing the commit SHA and breaking things. But, in the long scheme of a release, that's OK. As long as everyone that contributed has other credits in the release! The overall counts for contributions are not a huge deal and being off by one or two is ok.

The process cannot be 100% automated for a few reasons. But mainly, if it were fully automated we would potentially incentivize behavior that we do not want to see, ie. commenting on lots of issues just to accumulate lots of credits. It also would not give the opportunity for someone to add a contributor who did not directly interact in GitHub. Maybe a designer, or someone that gave important feedback during a Slack conversation.

The goal is to make this as friction-less as possible, but some level of human interaction is necessary. If you have ideas how to further improve the process, please do share them in the https://github.com/WordPress/props-bot-action/ repo. We've already implemented several suggestions in the short week since the tool was merged!

[matiasbenedetto]

Thanks for the detailed answer