![(please configure the [header_logo] section in trac.ini)](/chrome/site/your_project_logo.png){kind=logo}
#3196 closed defect (bug) (fixed)
Grammar in first comment
| Reported by: | davidhosier | Owned by: | |
|---|---|---|---|
| Priority: | lowest | Milestone: | |
| Component: | General | Version: | 2.0.4 |
| Severity: | trivial | Keywords: | grammar install setup has-patch |
| Cc: | Focuses: |
Description
The grammar in the default first comment (in wp-admin/install.php) is a little off. "Hi, this is a comment. To delete a comment, just log in, and view the posts’ comments, there you will have the option to edit or delete them." It should probably read, "Hi, this is a comment. To delete a comment, just log in and view the posts’ comments. There you will have the option to edit or delete them." I'm a card-carrying grammar Nazi.
Attachments (2)
Change History (47)
#7
@
20 years ago
- Resolution fixed
- Status closed → reopened
It's still a run-on sentence. You should really separate it into 3 separate sentences.
"Hi, this is a comment.
To delete a comment, just log in and view the post's comments.
There you will have the option to edit or delete them."
I agree with changing posts' to post's. Good point.
This ticket was mentioned in PR #3529 on WordPress/wordpress-develop by @Bernhard Reiter.
4 years ago
#11
Fixes https://github.com/WordPress/gutenberg/issues/40808.
The Gutenberg PR that fixed this was flagged for inclusion in WP 6.1 a month ago, but we missed that these are PHP changes, which thus require a manual backport 😞 This was recently brought up by #3196 to us.
More details and Trac ticket to follow.
4 years ago
#12
I can confirm this issue using my custom Icon Block.
Reproducing the issue
To reproduce, set a custom border style in Global Styles.
Add an icon in the Editor and the border will appear correct.
However, on the Frontend, the global style is not applied.
After the fix is applied
With this fix, everything appears correctly on the frontend.
4 years ago
#13
I can confirm that this is a regression.
| Global Styles - Editor Side | Global Styles - Frontend Side - WP 6.1 | Global Styles - Frontend Side - WP 6.0 |
|
|
|
|
Reproduce issue
- Install WooCommerce. Import products from the CSV that is attached at the bottom.
- Open the FSE Editor.
- Edit the Product Catalog template.
- Add a WC Blocks (e.g.: Product Categories List).
- Customize the global styles related to the block.
- Save.
- Go to on
/shoppage. See that the customizations aren't applied (on WP 6.1)
@Bernhard Reiter commented on PR #3529:
4 years ago
#14
FWIW, I can also repro the issue and the fix with @ndiego's Icon block 😊 (using a 10px red border with 20px rounded edges).
On the frontend:
| trunk | This branch |
| 
| 
|
@Bernhard Reiter commented on PR #3529:
4 years ago
#15
Noting here that the Gutenberg fix has been part of Gutenberg 14.1 and all subsequent GB releases:
@Bernhard Reiter commented on PR #3529:
4 years ago
#16
Verifying that styling did work in 6.0.3 for the Icon block ✅
@cbravobernal commented on PR #3529:
4 years ago
#17
I can reproduce it also and check that is a regression with a really simple block plugin.
https://www.loom.com/share/72856d7db45b40ce9f12e225ea0f8f05
@Bernhard Reiter commented on PR #3529:
4 years ago
#18
To recap:
- This is a regression from WP 6.0 (see here, here and here) ✅
- The fix has been part of Gutenberg since v14.1.0, published about a month ago ✅
- We marked the fix for inclusion in WP 6.1 but missed to file a backport PR at the time 😕
- This PR backports the fix. It has been shown to fix the issue ✅
4 years ago
#19
Could we please add some unit tests here? Especially this late in the cycle, it would be great to include these.
@Bernhard Reiter commented on PR #3529:
4 years ago
#20
Could we please add some unit tests here? Especially this late in the cycle, it would be great to include these.
Yeah, makes sense! I’d have to look a bit where this would best fit in; I guess we probably have some unit test coverage for Global Styles already 🤔
I guess the test should be for wp_add_global_styles_for_blocks since that’s what we’re modifying here. And we'd need to check the output of wp_add_inline_style for the presence of the relevant styling 🤔
@Bernhard Reiter commented on PR #3529:
4 years ago
#21
Looks like there's no test coverage for wp_add_global_styles_for_blocks yet. However, there's e.g. `wp_get_global_stylesheet` in the same file, which has coverage in a dedicated `tests/phpunit/tests/theme/wpGetGlobalStylesheet.php` file.
So I guess we need to add a new tests/phpunit/tests/theme/wpGetGlobalStylesForBlocks.php file.
@Bernhard Reiter commented on PR #3529:
4 years ago
#22
I haven't figured out yet how to write a unit test for this; specifically, how to programmatically set some Global Styles for a block.
Pinging @oandregal @scruffian @ramonjd @andrewserong in case you're able to help with this 🙏 😊
On the assertions side, if I read the code correctly, we should ideally cover two different scenarios -- core/ and non-core/ blocks (see). In either case, they should check if wp_add_inline_style's output contains the expected styling.
(For non-core/ blocks, the assertion should fail without the fix in 1885efc00b11f7c374658a54f50d6a590021c90a.)
@ramonopoly commented on PR #3529:
4 years ago
#23
I haven't figured out yet how to write a unit test for this; specifically, how to programmatically set some Global Styles for a block.
Apologies in advanced if this is not anywhere near what you asked, but here's what I know without thinking too hard:
If you want to set styles for blocks in theme.json, there's the option of creating a test theme and styling your blocks in theme.json. Here's an example: https://github.com/WordPress/gutenberg/blob/963d836b290ce5ec002de2027a8011d492c20420/phpunit/block-supports/typography-test.php#L39
If it's user-defined global styles (those added in the site editor) we want to test, then maybe we could hook into wp_theme_json_data_user to update the underlying data and styles in a unit test?
In the function wp_add_global_styles_for_blocks() we're calling $tree = WP_Theme_JSON_Resolver::get_merged_data();, which gets the merged theme.json data, including styles, and including user customisations.
To get user data for the merge, get_user_data() is called. That's where wp_theme_json_data_user lives.
That is all theoretical, I haven't tried it yet. If I get time today I will, but the universe has conspired against me so leaving these notes here in case they're helpful.
@andrewserong commented on PR #3529:
4 years ago
#24
Thanks for the ping! Unfortunately I can't think of much else add other than what Ramon mentioned, where sometimes adding a test theme to themedir1 can be a good way to handle things that call global functions that gather theme data.
Although, maybe there's an option to filter the theme data via the wp_theme_json_data_blocks filter within a test (passing in some placeholder blocks in the structure there to match what needs to be tested), now that it exists? Then after calling wp_add_global_styles_for_blocks() look up the global $wp_styles to see if the inline style has been added as expected?
I'll be AFK for the rest of the week so unfortunately can't dig any further right now, but happy to help test / review on Monday if this is still being worked on.
@oandregal commented on PR #3529:
4 years ago
#25
:wave: I've taken a look and this is the gist we need to do for a test:
- Add styles for a 3rd party block in any test theme. We can reuse one of the existing themes. Because the block won't be registered for the other tests, it'll be ignored. Something like this in the
theme.jsonof any test theme:
{{{json
{
"styles" : {
"blocks" :{
"my/third-party-block": {
"color": {
"background": "hotpink"
}
}
}
}
}}}
- Write a test that retrieves those styles and previously registers the block called
my/third-party-block. Something along these lines:
{{{php
function test_third_party_styles( ) {
$name = 'my/third-party-block';
$settings = array(
'icon' => 'text',
'category' => 'common',
'render_callback' => 'foo',
);
register_block_type( $name, $settings ); Register the block, so the theme.json styles are not ignored.
wp_add_global_styles_for_blocks();
unregister_block_type( $name ); Unregister it, so it does not affect other tests.
TEST STYLES HAVE BEEN INLINED: HOW DO WE TEST THIS?
}
}}}
@ramonopoly commented on PR #3529:
4 years ago
#26
how to test inline styles?
Not sure either.
Could we assert against registered styles?
wp_styles()->registered['some-inline-styles']->extra['after'],
@oandregal commented on PR #3529:
4 years ago
#27
Added a single test https://github.com/WordPress/wordpress-develop/pull/3529/commits/55212745fc4f074097553ab63a384d770ad9c91c We can iterate from here.
@Bernhard Reiter commented on PR #3529:
4 years ago
#28
Hmm, looks like the test is passing on trunk 🤔 (I've cherry-picked 55212745fc4f074097553ab63a384d770ad9c91c to trunk locally and ran npm run test:php -- --group=themes.)
@oandregal commented on PR #3529:
4 years ago
#29
I've executed the test without the fix (npm run test:php -- --filter Tests_Theme_wpGetGlobalStylesForBlocks) and it's passing. I'm trying to understand why.
@oandregal commented on PR #3529:
4 years ago
#30
Pushed a change https://github.com/WordPress/wordpress-develop/pull/3529/commits/1099bce4b1ee13395181a78f67acf5e47c9495e0 that makes the test fail on trunk. According to the how the test passed without that, I understand this is the issue without this patch:
- when block styles are loaded as part of the
global-styles-inline-cssstylesheet, 3rd party blocks styles worked fine. How to test: use a theme that disables separate block assets viaadd_filter( 'should_load_separate_core_block_assets', '__return_false' );. - when block styles are inlined to the own block stylesheet, this didn't work. My understanding is that block themes load assets separately, by default. This condition can be forced via
add_filter( 'should_load_separate_core_block_assets', '__return_false' ).
@Bernhard Reiter commented on PR #3529:
4 years ago
#31
Pushed a change 1099bce that makes the test fail on
trunk.
Great, thank you very much!
According to the how the test passed without that, I understand this is the issue without this patch:
- when block styles are loaded as part of the
global-styles-inline-cssstylesheet, 3rd party blocks styles worked fine. How to test: use a theme that disables separate block assets viaadd_filter( 'should_load_separate_core_block_assets', '__return_false' );.- when block styles are inlined to the own block stylesheet, this didn't work. My understanding is that block themes load assets separately, by default. This condition can be forced via
add_filter( 'should_load_separate_core_block_assets', '__return_false' ).
Yeah, I think that matches this logic here: https://github.com/WordPress/wordpress-develop/blob/b71a7bfcfff6532d6f83b38dbe52bcb24208d37f/src/wp-includes/global-styles-and-settings.php#L216-L219
@oandregal commented on PR #3529:
4 years ago
#32
I understand this is the issue without this patch:
Yeah, the issue only happens in trunk when the styles are loaded per block. Tested by:
- using TwentyTwentyThree
- added an icon block
- go to the global styles sidebar and add a border
Using trunk and the existing theme, the border is not rendered in the front end.
Then, I did the following:
- create a
functions.phpfor the theme - add this:
{{{php
<?php
add_filter( 'should_load_separate_core_block_assets', 'return_false' );
}}}
And the border is properly rendered.
So, yeah, the test is covering the issue we had.
@Bernhard Reiter commented on PR #3529:
4 years ago
#33
Update, I'm working to isolate the test to wp_add_global_styles_for_blocks (see).
@Bernhard Reiter commented on PR #3529:
4 years ago
#34
So I've replaced the call to wp_enqueue_global_styles with wp_add_global_styles_for_blocks:
{{{diff
diff --git a/tests/phpunit/tests/theme/wpGetGlobalStylesForBlocks.php b/tests/phpunit/tests/theme/wpGetGlobalStylesForBlocks.php
index 627c4fc82d..350f6a0e06 100644
--- a/tests/phpunit/tests/theme/wpGetGlobalStylesForBlocks.php
+++ b/tests/phpunit/tests/theme/wpGetGlobalStylesForBlocks.php
@@ -83,7 +83,7 @@ class Tests_Theme_wpGetGlobalStylesForBlocks extends WP_UnitTestCase {
'render_callback' => 'foo',
);
register_block_type( $name, $settings );
- wp_enqueue_global_styles();
+ wp_add_global_styles_for_blocks();
unregister_block_type( $name );
$this->assertStringContainsString( '.wp-block-my-third-party-block{background-color: hotpink;}', get_echo( 'wp_print_styles' ), '3rd party block styles are included' );
}}}
I've then debugged what `wp_add_inline_style( $handle, $data )` is doing. It's basically an alias for wp_styles()->add_inline_style( $handle, $data ). The wp_styles() function gives access to the global wp_styles object, which is of course of class WP_Styles. That class in turn is derived from WP_Dependencies.
Turns out that down in the call stack, this function is called : https://github.com/WordPress/wordpress-develop/blob/b71a7bfcfff6532d6f83b38dbe52bcb24208d37f/src/wp-includes/class-wp-dependencies.php#L288-L294
with the following args:
$handle: global-styles
$key: after
$value: Array
(
[0] => .wp-block-my-third-party-block{background-color: hotpink;}
)
Turns out that ! isset( $this->registered[ $handle ] ) returns false for `$handle === 'after'.
I'll try to find out why after is not registered (and what the heck that even means).
@Bernhard Reiter commented on PR #3529:
4 years ago
#35
I'll try to find out why 'after' is not registered (and what the heck that even means).
If I'm not mistaken, the only way to register a handle with WP_Dependencies is via its `add()` method (rather than add_data()). So I'm thinking some other code must be doing that somewhere in the callstack of wp_enqueue_global_styles, which would explain why the test works for that, but not with explicitly calling wp_add_global_styles_for_blocks.
@Bernhard Reiter commented on PR #3529:
4 years ago
#36
@Bernhard Reiter commented on PR #3529:
4 years ago
#37
Ah, or not. 😕 I think I need to step away from this for a moment. Upon re-running the test, I don't even see global_styles not being registered anymore. Maybe I was looking at the wrong thing 🙄
@Bernhard Reiter commented on PR #3529:
4 years ago
#38
Oh, this actually does register global_styles in time for the add_data call 🤔
The test still isn't passing with this, though 😕
{{{diff
diff --git a/tests/phpunit/tests/theme/wpAddGlobalStylesForBlocks.php b/tests/phpunit/tests/theme/wpAddGlobalStylesForBlocks.php
index c3286f813e..92d8dfcddf 100644
--- a/tests/phpunit/tests/theme/wpAddGlobalStylesForBlocks.php
+++ b/tests/phpunit/tests/theme/wpAddGlobalStylesForBlocks.php
@@ -83,7 +83,8 @@ class Tests_Theme_wpAddGlobalStylesForBlocks extends WP_UnitTestCase {
'render_callback' => 'foo',
);
register_block_type( $name, $settings );
- wp_enqueue_global_styles();
+ wp_register_style( 'global-styles', false, array(), true, true );
+ wp_add_global_styles_for_blocks();
unregister_block_type( $name );
$this->assertStringContainsString( '.wp-block-my-third-party-block{background-color: hotpink;}', get_echo( 'wp_print_styles' ), '3rd party block styles are included' );
}}}
@hellofromTonya commented on PR #3529:
4 years ago
#39
@ockham I tweaked your example:
{{{php
wp_register_style( 'global-styles', false, array(), true, true );
$actual = wp_styles()->get_data( 'global-styles', 'after' );
$actual = is_array( $actual ) ? $actual : array();
$this->assertNotContains(
'.wp-block-my-third-party-block{background-color: hotpink;}',
$actual,
'Third party block inline style should not be registered before running wp_add_global_styles_for_blocks()'
);
wp_add_global_styles_for_blocks();
$actual = wp_styles()->get_data( 'global-styles', 'after' );
$this->assertSame(
'.wp-block-my-third-party-block{background-color: hotpink;}',
$actual[0],
'Third party block inline style should be registered after running wp_add_global_styles_for_blocks()'
);
}}}
This fails before the fix and passes after the fix. I'll do a little cleanup and push changes shortly.
@Bernhard Reiter commented on PR #3529:
4 years ago
#40
Ah, I guess it’s the argument to wp_styles()->get_data() that’s key! If I’m reading WP_Dependencies::do_items() (called from wp_print_styles), WP_Dependencies::all_deps(), and friends correctly, the class is a bit picky if no $handles arg is passed to those methods. Seems like without that arg, do_items only prints styling for handles that were previously enqueued: https://github.com/WordPress/wordpress-develop/blob/b71a7bfcfff6532d6f83b38dbe52bcb24208d37f/src/wp-includes/class-wp-dependencies.php#L121-L126
@hellofromTonya commented on PR #3529:
4 years ago
#41
https://github.com/WordPress/wordpress-develop/pull/3529/commits/19f62712f1bc0287127560cc119c7ff025bede46 improves the tests to focus on the scope of this PR and isolated the integration tests to wp_add_global_styles_for_blocks() function.
Running locally:
- Removing the bugfix, tests fail ✅
- Adding the bugfix, tests pass ✅
These 2 states are the expected behavior ✅
@Bernhard Reiter commented on PR #3529:
4 years ago
#42
Running locally:
- Removing the bugfix, tests fail ✅
- Adding the bugfix, tests pass ✅
These 2 states are the expected behavior ✅
Confirmed!
@hellofromTonya commented on PR #3529:
4 years ago
#43
Whoopsie, accidentally pushed my revert of the patch when testing the tests fail without the patch 🤦♀️ Reverted that temporary code and force pushed test only changes.
@davidbaumwald commented on PR #3529:
4 years ago
#44
Thanks everyone! Merged into Core in https://core.trac.wordpress.org/changeset/54703.
@Bernhard Reiter commented on PR #3529:
4 years ago
#45
Merged into Core's 6.1 branch in https://core.trac.wordpress.org/changeset/54705.
Hm, the use of posts' (as opposed to post's) is also fuzzy. A specific comment cannot belong to more than one post, but when editing comments, you view all of the posts' comments together.