Font Library: create post types on init hook

[creativecoder]

What?

Register font post types for all requests.

Why?

To ensure the post types are available to inspect or customize.

Found while working on #59294. $post_type = get_post_type_object( 'wp_font_face' ); did not work outside of REST API routes.

How?

Register wp_font_family and wp_font_face post types on the init hook.

Testing Instructions

Test with WP 6.4: ensure font library continues to work 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.

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: creativecoder <[email protected]>
Co-authored-by: mikachan <[email protected]>
Co-authored-by: matiasbenedetto <[email protected]>

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

[mikachan]

Changes look good to me and the Font Library still works as expected 👍

[matiasbenedetto]

An accurate way of testing this could be running get_post_types function and check if the wp_font_family and wp_font_face posts types are listed.

get_post_types();

Returns in trunk:

[
  "post" => "post",
  "page" => "page",
  "attachment" => "attachment",
  "revision" => "revision",
  "nav_menu_item" => "nav_menu_item",
  "custom_css" => "custom_css",
  "customize_changeset" => "customize_changeset",
  "oembed_cache" => "oembed_cache",
  "user_request" => "user_request",
  "wp_block" => "wp_block",
  "wp_template" => "wp_template",
  "wp_template_part" => "wp_template_part",
  "wp_global_styles" => "wp_global_styles",
  "wp_navigation" => "wp_navigation",
]

Returns in this branch:

[
  "post" => "post",
  "page" => "page",
  "attachment" => "attachment",
  "revision" => "revision",
  "nav_menu_item" => "nav_menu_item",
  "custom_css" => "custom_css",
  "customize_changeset" => "customize_changeset",
  "oembed_cache" => "oembed_cache",
  "user_request" => "user_request",
  "wp_block" => "wp_block",
  "wp_template" => "wp_template",
  "wp_template_part" => "wp_template_part",
  "wp_global_styles" => "wp_global_styles",
  "wp_navigation" => "wp_navigation",
  "wp_font_family" => "wp_font_family",
  "wp_font_face" => "wp_font_face",
]

I see that wp_font_family and wp_font_face posts types are listed so it look that the PR is working as advertised.
LGTM

[getdave]

I just cherry-picked this PR to the cherry-pick-wp-6-5-beta-3 branch to get it included in the next release: eba2b3c6d6

[getdave]

@mikachan I don't think these changes are required in trunk. Post type registration is handled in it's own way in WP Core and so porting this PR's changes to Core "as is" won't work.

[getdave]

I just cherry-picked this PR to the cherry-pick-wp-6-5-beta-3 branch to get it included in the next release: eba2b3c

I spoke to @matiasbenedetto and he confirmed that this PR does not need to be backported and is already handled in WP Core.

Therefore I will drop it from #59394

[creativecoder]

I just cherry-picked this PR to the release/17.8 branch to get it included in the next release: 1b5ae3c