[wp-trac] [WordPress Trac] #58555: Backport: Duotone changes, refactor, enhancements and fixes

WordPress Trac noreply at wordpress.org
Mon Jul 17 15:59:17 UTC 2023


#58555: Backport: Duotone changes, refactor, enhancements and fixes
-------------------------------------------------+-------------------------
 Reporter:  onemaggie                            |       Owner:
                                                 |  isabel_brison
     Type:  task (blessed)                       |      Status:  reopened
 Priority:  normal                               |   Milestone:  6.3
Component:  Editor                               |     Version:
 Severity:  normal                               |  Resolution:
 Keywords:  has-unit-tests gutenberg-merge       |     Focuses:
  needs-patch                                    |
-------------------------------------------------+-------------------------

Comment (by ajlende):

 > Why are their three deprecated methods in this new class?
 get_filter_svg_from_preset, get_filter_css_property_value_from_preset and
 get_filter_id_from_preset. It is very strange to me to introduce and then
 deprecated a method in the same release. This should be removed no?

 [https://github.com/WordPress/wordpress-
 develop/pull/4619#discussion_r1231967359 This was discussed on GitHub].

 TL;DR While refactoring, pieces of the implementation were moved into
 private methods, so in order to keep the deprecated functions available
 they were added as deprecated public methods for the class.

 > Why were functions like `wp_register_duotone_support` deprecated? As a
 developer API, it seems much cleaner to have a function.

 `wp_register_duotone_support` and the other functions were never meant to
 be part of the developer API and should ''only'' have been called via
 hooks that were replaced.

 > Why does the `WP_Duotone` use all static methods? I feel like having all
 static methods, basically makes it pointless of it being a class. It is
 just a namespaced function at that point. Either go back to functions and
 make this use methods. It should be simple enough to convert to none
 static with no downsides.

 I had a discussion with @hellofromTonya and @azaozz about this earlier.

 TL;DR Many of the static methods are private to hide implementation
 details, and we have a couple static properties for caching some
 computation. Doing it this way was simpler than the alternatives when the
 public methods are intended to ''only'' be used with the hooks.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/58555#comment:30>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform


More information about the wp-trac mailing list