-
Notifications
You must be signed in to change notification settings - Fork 2.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Style engine: migrate functions, classes and tests #3199
Style engine: migrate functions, classes and tests #3199
Conversation
97019a1
to
d88d4a0
Compare
e8e00c6
to
c0c64de
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As this review is becoming quite large and the comments are quite similar, I'll submit it now.
The feedback on the tests applies to all other test files, as do documentation comments in source files.
A couple of general things:
- Test class names should have the format
Tests_Folder_Name_ThingInTitleCase
. - Ensure all test methods have the
@ticket
annotation. - Ensure all test methods have the
@covers
(or@coversNothing
if it doesn't cover something) annotations, as this will allow us all to see where coverage may be great/need improvement. - As shown in the review,
@coversDefaultClass
can be used in the class docblock for a file that tests a single class, which allows for shortercovers
annotations using simply the method name like::method_name
. - Where possible, try to start test methods with
test_should_
/test_should_not
. Usingtest_method_name
ortest_function_name
is typically only useful for small source functions, or for test methods that use a data provider.
tests/phpunit/tests/style-engine/wpStyleEngineCssDeclarations.php
Outdated
Show resolved
Hide resolved
tests/phpunit/tests/style-engine/wpStyleEngineCssDeclarations.php
Outdated
Show resolved
Hide resolved
tests/phpunit/tests/style-engine/wpStyleEngineCssDeclarations.php
Outdated
Show resolved
Hide resolved
tests/phpunit/tests/style-engine/wpStyleEngineCssDeclarations.php
Outdated
Show resolved
Hide resolved
tests/phpunit/tests/style-engine/wpStyleEngineCssDeclarations.php
Outdated
Show resolved
Hide resolved
src/wp-includes/style-engine/class-wp-style-engine-processor.php
Outdated
Show resolved
Hide resolved
src/wp-includes/style-engine/class-wp-style-engine-processor.php
Outdated
Show resolved
Hide resolved
0166739
to
5116e16
Compare
Thanks @costdev for volunteering and taking the time to review the code, and also for explaining the required changes 🙇 I think I've covered just about everything, but will take another sweep over later to spot if I've missed something. The final failing test should pass once https://core.trac.wordpress.org/ticket/55966 has been committed. |
dadfd4d
to
e2e6323
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the updates @ramonjd! I've reviewed the other files as well in this one.
* @access private | ||
* @since 6.1.0 | ||
*/ | ||
class WP_Style_Engine_CSS_Declarations { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
While this is intended to be private, it's open not just for instantiation, but extension.
Some thoughts:
- Should this be considered private? Why?
- If so, should this be a
final
class to at least block extension, or do we extend/plan to extend this class? - What else could be done? (I appreciate that something like an allowlist using an optimized
debug_backtrace
for the caller of the constructor is essentially the only way to "properly" lock it down though, so not suggesting that).
Same applies to all instances in the PR.
@peterwilsoncc do you have any thoughts here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
or do we extend/plan to extend this class
I'm not sure of the strategy right now.
I expect that there is no plan to extend. Since this comes from a Gutenberg package, we expect to version it.
Backwards compat will foil that I guess. 🤷
Happy to take any advice onboard!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@azaozz Do you have any thoughts on this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@costdev thanks for the ping.
If this is intended to be private, "core use only", it will perhaps have to be locked in a closure like the current Webfonts code is. That will ensure it can be updated in the future without concerns about backwards compatibility.
If not locked, back-compat will have to be maintained, even if the class is final
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @azaozz! If it's not locked and back-compat has to be maintained, I don't think there would be any benefit in having @access private
. Would you agree?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it will perhaps have to be locked in a closure like the current Webfonts code is.
Thanks for the advice here.
I think the class in question (WP_Style_Engine_CSS_Declarations
), and the following, other, new classes:
WP_Style_Engine_CSS_Rule
WP_Style_Engine_CSS_Rules_Store
WP_Style_Engine_Processor
should be fairly stable. Maintaining backwards compatibility will be expected and, I hope, not overly tortuous.
I'll remove @access private
from these.
WP_Style_Engine
, on the other hand, is the primary integration point and provides the bulk of the functionality.
I expect it will have to be updated more frequently, especially given that this is a new API.
In that case, do folks think it's safer to refactor WP_Style_Engine
to something similar to what's happening in webfonts? https://github.com/ramonjd/wordpress-develop/blob/bb0cbe3f557d16714ca109a28c2877d178adc94f/src/wp-includes/script-loader.php#L3059-L3058
cc @aristath and @andrewserong for thoughts
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
WP_Style_Engine, on the other hand, is the primary integration point and provides the bulk of the functionality.
I think even this one is pretty stable, and good for us to commit to maintaining for backwards compatibility. The protected methods can be added to or rearranged safely in future versions, but the public methods appear to be ones that have been pretty stable in Gutenberg lately, and I think would be good to commit to in the long-term. I'd lean toward keeping this PR as-is.
src/wp-includes/style-engine/class-wp-style-engine-css-declarations.php
Outdated
Show resolved
Hide resolved
src/wp-includes/style-engine/class-wp-style-engine-css-declarations.php
Outdated
Show resolved
Hide resolved
tests/phpunit/tests/style-engine/wpStyleEngineCssRulesStore.php
Outdated
Show resolved
Hide resolved
tests/phpunit/tests/style-engine/wpStyleEngineCssRulesStore.php
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Left some nit pick reviews.
src/wp-includes/style-engine/class-wp-style-engine-css-declarations.php
Outdated
Show resolved
Hide resolved
I'll fix up those failing tests later. Last commit was a bit rushed. Thanks for the reviews, folks. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the updates! I think these are the last round of changes from me. 🙂
As mentioned in the comments below, watch out for the array<string, string>
to string[] An associative array
changes causing alignment issues for @param
annotations.
Also, the GHA failures don't seem to be test failures, but workflow failures, so it looks like your last commit was clean 🙂
- Migration of the style engine classes and unit tests from Gutenberg to Core.
Updating test function names and annotations.
Updating php doc params
…is used in a test method.
Testing for WP_Style_Engine_CSS_Rules_Store in WP_Style_Engine_Processor->add_store
Counting calls to mock filters executed in safecss_filter_attr() (kses.php)
Removing duplicated test (we were already testing context below)
Good to know! I was on my phone so wasn't sure. I see red and 😱 |
bb87fe4
to
0ecd3a0
Compare
8c54963
to
57d81bc
Compare
I might not be around next week. cc @andrewserong in case this PR and related PRs need any attention, though I think we should be sound 👍 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM pending the result of this discussion. 👍 Thanks @ramonjd!
New style engine does not emit spaces between attributes and values. See WordPress#3199.
That link doesn't seem to be working for me 😕 @costdev -- did you mean this discussion (about I'd love if we could land this PR soon, as it blocks a number of other Style Engine related PRs 😊 |
That's right @ockham, not sure why the original link isn't working. I think we're waiting on feedback from @aristath and @andrewserong on that topic. Not sure if @azaozz has anything more to add as well. |
For my part, I've been thinking about this, and I'm pretty confident that the function signatures and method names are fine for now. The classes have been running in Gutenberg for some time. Ultimately the purpose of all this code is to accept block style input and output compiled CSS. I expect there'll be updates to the body of some functions, and probably unforeseen future conditions that will require new methods, and later, deprecations, but that's the story of WordPress. The unknowns will remain unknowns :D I'd lean on @aristath's and @AndrewSong's opinion though. |
Thanks for pings!
I agree, and like you mention in the thread, maintaining backwards compatibility is expected for the style engine classes. One of the things I believe @aristath had in mind with these classes was the eventual use cases of plugins and themes, so we ultimately do want these to be stable and well-supported classes with consistent public methods. The structure and naming of the public methods went through lots of iterations in the Gutenberg plugin and appears to be pretty stable now from my perspective. I think this PR looks in a good shape to land, personally. |
As mentioned above, the Style Engine classes went through a lot of iterations and discussion. What we ended up with is a hierarchy and structure that is solid, stable, makes sense, and I feel it can withstand the test of time 👍 |
Committed in https://core.trac.wordpress.org/changeset/54156 |
New style engine does not emit spaces between attributes and values. See WordPress#3199.
Spaces are stripped between properties and values since WordPress#3199.
This PR migrates the Style Engine PHP functions, classes and tests into Core for 6.1.
It reflects the latest changes from WordPress/gutenberg#43840
See tracking issue: WordPress/gutenberg#43440
Backport PRs blocked by this changeset (that I know of)
Trac ticket: https://core.trac.wordpress.org/ticket/56467