Add unit test for get_user_data_from_wp_global_styles.#63721
Add unit test for get_user_data_from_wp_global_styles.#63721
Conversation
This adds a unit test to demonstrate that `WP_Theme_JSON_Resolver_Gutenberg::get_user_data_from_wp_global_styles` returns an empty array when no `$create_post` param is passed after being previously called with the `$create_post` param set to `true`.
|
Warning: Type of PR label mismatch To merge this PR, it requires exactly 1 label indicating the type of PR. Other labels are optional and not being checked here.
Read more about Type labels in Gutenberg. Don't worry if you don't have the required permissions to add labels; the PR reviewer should be able to help with the task. |
|
Failing test that demonstrates the issue can be seen here: https://github.com/WordPress/gutenberg/actions/runs/9997910616/job/27636197439?pr=63721 |
|
I'm not very familiar with the inner workings of |
|
Thanks @andrewserong. You're exactly right that this is just demonstrating the issue. Before attempting to suggest a fix, I wanted to confirm whether this is actually a bug, or if I'm misunderstanding something about how this method is meant to work. Generally speaking, when the initial post type gets created for custom styles, it happens through a REST endpoint, and I'm uncertain if this method is actually even used in that process (I suspect not). What I'm mostly unsure about is whether the code in this method that creates the post is missing something, or whether the query that returns the post is incorrect. |
aaronrobertshaw
left a comment
There was a problem hiding this comment.
I had a bit of a look into this. I believe get_user_data_from_wp_global_styles is intended to return the global styles custom post type as this test suggests.
The catch is if the current user does not have the capabilities to assign terms, they are not added when the post is inserted. The subsequent query then fails to match on the taxonomy.
In the proposed test, if the user is set to an administrator, the test passes (see inline comment below).
I would suspect that in the case of global styles, the taxonomy term needs to be set regardless of user capabilities so the post relates to the appropriate theme. Whether the user has caps to create the global styles post itself might be a different question.
If the above suspicion is correct, then a small tweak to manually call wp_set_object_terms( $cpt_post_id, array( $stylesheet ), 'wp_theme' ); instead of relying on tax_input in the args for wp_insert_post makes the test pass as well.
diff --git a/lib/class-wp-theme-json-resolver-gutenberg.php b/lib/class-wp-theme-json-resolver-gutenberg.php
index a2153e639d..98c4912081 100644
--- a/lib/class-wp-theme-json-resolver-gutenberg.php
+++ b/lib/class-wp-theme-json-resolver-gutenberg.php
@@ -504,12 +504,10 @@ class WP_Theme_JSON_Resolver_Gutenberg {
'post_title' => 'Custom Styles', // Do not make string translatable, see https://core.trac.wordpress.org/ticket/54518.
'post_type' => $post_type_filter,
'post_name' => sprintf( 'wp-global-styles-%s', urlencode( $stylesheet ) ),
- 'tax_input' => array(
- 'wp_theme' => array( $stylesheet ),
- ),
),
true
);
+ wp_set_object_terms( $cpt_post_id, array( $stylesheet ), 'wp_theme' );
if ( ! is_wp_error( $cpt_post_id ) ) {
$user_cpt = get_object_vars( get_post( $cpt_post_id ) );
}
Co-authored-by: Aaron Robertshaw <60436221+aaronrobertshaw@users.noreply.github.com>
What?
This adds a unit test to demonstrate that
WP_Theme_JSON_Resolver_Gutenberg::get_user_data_from_wp_global_stylesreturns an empty array when no$create_postparam is passed after being previously called with the$create_postparam set totrue.See: #63722
Why?
While attempting to write a unit test to confirm that caching added to
wp_add_global_styles_for_blocks()would get cleared if user data changed (related issue), I noticed that after callingWP_Theme_JSON_Resolver_Gutenberg::get_user_data_from_wp_global_styles()and passing a value to the second parameter to create a post, the next time that method is called, the created post is not returned.How?
This PR demonstrates a possible bug. If valid, the PR would need to be updated to fix the issue.
Testing Instructions
Review the Unit test failure on the PR or run the test locally:
npm run test:unit:php:base -- --filter test_get_user_data_from_wp_global_styles_returns_created_postTesting Instructions for Keyboard
n/a