Skip to content
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

Closed

Conversation

ramonjd
Copy link
Member

@ramonjd ramonjd commented Sep 6, 2022

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

Copy link
Contributor

@costdev costdev left a 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 shorter covers annotations using simply the method name like ::method_name.
  • Where possible, try to start test methods with test_should_ / test_should_not. Using test_method_name or test_function_name is typically only useful for small source functions, or for test methods that use a data provider.

src/wp-includes/style-engine.php Outdated Show resolved Hide resolved
tests/phpunit/tests/style-engine/styleEngine.php Outdated Show resolved Hide resolved
tests/phpunit/tests/style-engine/styleEngine.php Outdated Show resolved Hide resolved
@ramonjd ramonjd force-pushed the add/style-engine-classes-migrate-6-1 branch 4 times, most recently from 0166739 to 5116e16 Compare September 8, 2022 02:07
@ramonjd
Copy link
Member Author

ramonjd commented Sep 8, 2022

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.

@ramonjd ramonjd force-pushed the add/style-engine-classes-migrate-6-1 branch 2 times, most recently from dadfd4d to e2e6323 Compare September 9, 2022 03:16
Copy link
Contributor

@costdev costdev left a 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.

src/wp-includes/style-engine.php Outdated Show resolved Hide resolved
src/wp-includes/style-engine.php Show resolved Hide resolved
Comment on lines 17 to 20
* @access private
* @since 6.1.0
*/
class WP_Style_Engine_CSS_Declarations {
Copy link
Contributor

@costdev costdev Sep 9, 2022

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?

Copy link
Member Author

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!

Copy link
Contributor

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?

Copy link
Contributor

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.

Copy link
Contributor

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?

Copy link
Member Author

@ramonjd ramonjd Sep 9, 2022

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

Copy link
Contributor

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.

tests/phpunit/tests/style-engine/styleEngine.php Outdated Show resolved Hide resolved
tests/phpunit/tests/style-engine/styleEngine.php Outdated Show resolved Hide resolved
Copy link
Member

@mukeshpanchal27 mukeshpanchal27 left a 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.

@ramonjd
Copy link
Member Author

ramonjd commented Sep 9, 2022

I'll fix up those failing tests later. Last commit was a bit rushed.

Thanks for the reviews, folks.

Copy link
Contributor

@costdev costdev left a 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 🙂

src/wp-includes/style-engine/class-wp-style-engine.php Outdated Show resolved Hide resolved
src/wp-includes/style-engine/class-wp-style-engine.php Outdated Show resolved Hide resolved
- Migration of the style engine classes and unit tests from Gutenberg to Core.
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)
@ramonjd
Copy link
Member Author

ramonjd commented Sep 9, 2022

Also, the GHA failures don't seem to be test failures, but workflow failures, so it looks like your last commit was clean

Good to know! I was on my phone so wasn't sure. I see red and 😱

@ramonjd ramonjd force-pushed the add/style-engine-classes-migrate-6-1 branch 2 times, most recently from bb87fe4 to 0ecd3a0 Compare September 9, 2022 09:58
@ramonjd ramonjd force-pushed the add/style-engine-classes-migrate-6-1 branch from 8c54963 to 57d81bc Compare September 9, 2022 10:30
@ramonjd
Copy link
Member Author

ramonjd commented Sep 9, 2022

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 👍

Copy link
Contributor

@costdev costdev left a 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!

ironprogrammer added a commit to ironprogrammer/wordpress-develop that referenced this pull request Sep 12, 2022
New style engine does not emit spaces between attributes and values.

See WordPress#3199.
@ockham
Copy link
Contributor

ockham commented Sep 13, 2022

LGTM pending the result of this discussion. 👍 Thanks @ramonjd!

That link doesn't seem to be working for me 😕 @costdev -- did you mean this discussion (about @access private and classes being final)? If so, has that been sufficiently answered by @ramonjd?

I'd love if we could land this PR soon, as it blocks a number of other Style Engine related PRs 😊
@andrewserong maybe you can help out a bit? 🙏

@costdev
Copy link
Contributor

costdev commented Sep 13, 2022

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.

@ramonjd
Copy link
Member Author

ramonjd commented Sep 13, 2022

I think we're waiting on feedback from @aristath and @AndrewSong on that topic.

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.

@andrewserong
Copy link
Contributor

Thanks for pings!

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.

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.

@aristath
Copy link
Member

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 👍

@audrasjb
Copy link
Contributor

Committed in https://core.trac.wordpress.org/changeset/54156

@audrasjb audrasjb closed this Sep 14, 2022
ironprogrammer added a commit to ironprogrammer/wordpress-develop that referenced this pull request Sep 14, 2022
New style engine does not emit spaces between attributes and values.

See WordPress#3199.
ironprogrammer added a commit to ironprogrammer/wordpress-develop that referenced this pull request Sep 15, 2022
Spaces are stripped between properties and values since WordPress#3199.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
No open projects
Development

Successfully merging this pull request may close these issues.

8 participants