WP Tavern › Forums › Create Topic
Tim Hey Mark, Thanks for replying back I appreciate you taking the time to do so! I don’t place blame on you or anyone in particular, for communication. It’s not just your responsibility, or even the team involved with Gutenberg’s responsibility. The lack of communication also comes from theme and plugin authors who are sometimes afraid to say things, or unsure where to go. It’s a two way street, and I hope more authors do get involved. I mean I have rendered some controls using react, and even managed to get some section/panel stuff implemented, but this will become a sensitive spot for theme authors. As mentioned by Frederike in his comment above, completely replacing this API or even heavily changing it’s underlying structure will severely impact a lot of themes. Theme authors – and I don’t think this is soley the fault of Gutenberg – were VERY unprepared for Gutenberg. Like you mentioned, “clarity is kindness,” and I believe Gutenberg is usually pretty open with it’s code, but it’s also enormous, and not a very welcoming place for outside collaborators. Theme authors just didn’t connect with it, and I think it’s pretty safe to say a lot of them were aware changes would be coming, but they also didn’t understand a lot of the changes. Many of them felt unheard when they tried working with integration as they noticed several things broken but didn’t really know how or where to report inside of Gutenberg’s repo. Even now authors are stating to their end users to use the classic editor, recommending the classic editor plugin in their themes, and flat out ignoring Gutenberg theme support stuff since most of the stuff is “opt in”. One thought I had to aide in this process was taking features that are present in Gutenberg and starting with some of those things. Yes, widgets are one area, but honestly there’s not many themes that are attempting to ever modify settings inside of widget controls via the customizer API. I think this is mostly because they are dynamically created, and they are unsure how things get where they need to be. Nav menus are the same way, authors seem to always build out their socialicon menus and not use WordPress’ built in handling for menus. They end up creating something custom for their own controls instead of utilizing the customizer’s menus like shown here: https://ps.w.org/customizer-social-icons/assets/screenshot-1.png While Widgets make a lot of sense from a block standpoint to actually get Gutenberg editor features into the customizer area, I think there’s more that needs to be considered with the level of knowledge and actual usage of the customizer’s API by theme and plugin authors first. I understand where the blocks angle comes from, but fundamentally authors use the customizer to provide settings for their themes. It would be much more beneficial to start with that simple fact for authors(not suggesting at all to discard Widgets though, more of a supplement to them). Gutenberg’s implementation for themes when it was introduced into core starts with specifically asking theme authors to opt in to support particular parts of the editor system. One area I think would be an immediate win and a minor feature to introduce then would be colors and the controls that relate to them. I believe that these points will help show how this would be beneficial: 1. Introduces authors to react based controls. A lot of authors are still resistant to diving into JS, and this starts to force them to think this way more. More importantly it gives them some examples of how they can begin preparation on migrating their own custom controls into react driven components, which will help smooth the transition period for them. 2. Fixes one of the most requested features for authors who embrace the customizer. I haven’t done much study on this topic, but I have witnessed 3 different authors who’s first custom control they added was an IRIS color picker with RGBA in their themes. I can only assume that it’s something that is commonly needed by others based on that. This would also reduce the dozens of various (and badly implemented) libraries used to add alpha sliders I’ve seen in .org hosted themes. Implementations ranging from random websites where they copy and pasted the code from, unlicensed repos, to large frameworks just to add this one simple feature since it’s not built in to IRIS. 3. It’s an easy implementation, less work is always nice :) 4. It begins to unify the experience between the editor and customizer. This is probably the one I consider to be the most important, and combine this with adding in the theme’s palette via theme_support that theme’s add for Gutenberg support, this could provide an interface for globally allowing users to edit the theme’s color palette. This will begin an important step in theme authors untangling some hardcoded colors per selector, and give users an easy way to change the palette for the whole site in a uniform way to maintain a set “style guide” for their colors. This palette could be available in the customizer, and would be the same palette that’s updated in their editor instances. In theory, the array of colors for add_theme_support could even become defaults the theme sets for number of colors and initial values this way, which would be a step towards not even needing to declare theme_support on this feature as it could be supported by default with a predefined palette, or even chosen via a random palette to provide variety for initial values in the future to help backfill themes that don’t supply a palette with a “prettier” set of defaults when the authors hasn’t supplied one. 5. It will highlight some of severity of impact to theme authors (and customizer based plugin authors) without completely forcing a change at the beginning (if there’s any planned changes to the underlying API). I think about all the progress to the customizer’s JS API, and the time it took to get there. It wasn’t just getting there, but the time it took for theme authors to slowly ease their way in to utilizing the features it provides, and there’s still a large amount who are afraid to delve in. 6. It would fix some wp core unresolved issues: An initial feature request for this: https://core.trac.wordpress.org/ticket/39681 I believe this would also be resolved, but might need some adjustments in ColorPicker from @wordpress/components (haven’t looked at this in component in 6+months so I don’t know for sure): https://core.trac.wordpress.org/ticket/42078 Introducing something like this now, or in the very least before/at the same time as widgets is something that should be considered. Aside from the things above doing something like this will provide a better user experience and solid expectation as UI elements become more unified not only for end users but also for developers of themes and plugins. As it stands, Widgets is a good entry point, but the only thing it realistically accomplishes is unifying that interface making for a better end user experience (which is still important). However, it really doesn’t help any of the authors/developers who rely on the customizer’s current state out. It’s possible I may have a misunderstanding, and maybe you can clarify on this a little if I am. The other possibility I have gathered from this is that widgets being the introductory point for blocks being integrated within the customizer are really only the starting point for testing the waters, and that’s all Phase 2 is now (in relation to the customizer). The goal for this change was only to get scripts setup, but we wanted to impact an area that is known to not have many modifications by plugins and themes via the customizer’s API to reduce any noticeable footprint. Then the next phase would completely remove any existing control pane (ie replaced by inspector) from the customizer and bring all controls into an inline editing experience. I don’t think you mean this though as you’ve mentioned about easing into things, and this way wouldn’t provide authors much in the way of preparation against such a leap. PS: Sorry if this isn’t the right place to ask for clarification. I can send something on the core-customize slack channel if that is preferred :)
Tim
Hey Mark, Thanks for replying back I appreciate you taking the time to do so! I don’t place blame on you or anyone in particular, for communication. It’s not just your responsibility, or even the team involved with Gutenberg’s responsibility. The lack of communication also comes from theme and plugin authors who are sometimes afraid to say things, or unsure where to go. It’s a two way street, and I hope more authors do get involved.
I mean I have rendered some controls using react, and even managed to get some section/panel stuff implemented, but this will become a sensitive spot for theme authors. As mentioned by Frederike in his comment above, completely replacing this API or even heavily changing it’s underlying structure will severely impact a lot of themes. Theme authors – and I don’t think this is soley the fault of Gutenberg – were VERY unprepared for Gutenberg. Like you mentioned, “clarity is kindness,” and I believe Gutenberg is usually pretty open with it’s code, but it’s also enormous, and not a very welcoming place for outside collaborators. Theme authors just didn’t connect with it, and I think it’s pretty safe to say a lot of them were aware changes would be coming, but they also didn’t understand a lot of the changes. Many of them felt unheard when they tried working with integration as they noticed several things broken but didn’t really know how or where to report inside of Gutenberg’s repo. Even now authors are stating to their end users to use the classic editor, recommending the classic editor plugin in their themes, and flat out ignoring Gutenberg theme support stuff since most of the stuff is “opt in”.
One thought I had to aide in this process was taking features that are present in Gutenberg and starting with some of those things. Yes, widgets are one area, but honestly there’s not many themes that are attempting to ever modify settings inside of widget controls via the customizer API. I think this is mostly because they are dynamically created, and they are unsure how things get where they need to be. Nav menus are the same way, authors seem to always build out their socialicon menus and not use WordPress’ built in handling for menus. They end up creating something custom for their own controls instead of utilizing the customizer’s menus like shown here: https://ps.w.org/customizer-social-icons/assets/screenshot-1.png
While Widgets make a lot of sense from a block standpoint to actually get Gutenberg editor features into the customizer area, I think there’s more that needs to be considered with the level of knowledge and actual usage of the customizer’s API by theme and plugin authors first.
I understand where the blocks angle comes from, but fundamentally authors use the customizer to provide settings for their themes. It would be much more beneficial to start with that simple fact for authors(not suggesting at all to discard Widgets though, more of a supplement to them).
Gutenberg’s implementation for themes when it was introduced into core starts with specifically asking theme authors to opt in to support particular parts of the editor system. One area I think would be an immediate win and a minor feature to introduce then would be colors and the controls that relate to them.
I believe that these points will help show how this would be beneficial:
1. Introduces authors to react based controls. A lot of authors are still resistant to diving into JS, and this starts to force them to think this way more. More importantly it gives them some examples of how they can begin preparation on migrating their own custom controls into react driven components, which will help smooth the transition period for them.
2. Fixes one of the most requested features for authors who embrace the customizer. I haven’t done much study on this topic, but I have witnessed 3 different authors who’s first custom control they added was an IRIS color picker with RGBA in their themes. I can only assume that it’s something that is commonly needed by others based on that. This would also reduce the dozens of various (and badly implemented) libraries used to add alpha sliders I’ve seen in .org hosted themes. Implementations ranging from random websites where they copy and pasted the code from, unlicensed repos, to large frameworks just to add this one simple feature since it’s not built in to IRIS.
3. It’s an easy implementation, less work is always nice :)
4. It begins to unify the experience between the editor and customizer. This is probably the one I consider to be the most important, and combine this with adding in the theme’s palette via theme_support that theme’s add for Gutenberg support, this could provide an interface for globally allowing users to edit the theme’s color palette. This will begin an important step in theme authors untangling some hardcoded colors per selector, and give users an easy way to change the palette for the whole site in a uniform way to maintain a set “style guide” for their colors. This palette could be available in the customizer, and would be the same palette that’s updated in their editor instances. In theory, the array of colors for add_theme_support could even become defaults the theme sets for number of colors and initial values this way, which would be a step towards not even needing to declare theme_support on this feature as it could be supported by default with a predefined palette, or even chosen via a random palette to provide variety for initial values in the future to help backfill themes that don’t supply a palette with a “prettier” set of defaults when the authors hasn’t supplied one.
5. It will highlight some of severity of impact to theme authors (and customizer based plugin authors) without completely forcing a change at the beginning (if there’s any planned changes to the underlying API). I think about all the progress to the customizer’s JS API, and the time it took to get there. It wasn’t just getting there, but the time it took for theme authors to slowly ease their way in to utilizing the features it provides, and there’s still a large amount who are afraid to delve in.
6. It would fix some wp core unresolved issues: An initial feature request for this: https://core.trac.wordpress.org/ticket/39681 I believe this would also be resolved, but might need some adjustments in ColorPicker from @wordpress/components (haven’t looked at this in component in 6+months so I don’t know for sure): https://core.trac.wordpress.org/ticket/42078
Introducing something like this now, or in the very least before/at the same time as widgets is something that should be considered. Aside from the things above doing something like this will provide a better user experience and solid expectation as UI elements become more unified not only for end users but also for developers of themes and plugins. As it stands, Widgets is a good entry point, but the only thing it realistically accomplishes is unifying that interface making for a better end user experience (which is still important). However, it really doesn’t help any of the authors/developers who rely on the customizer’s current state out.
It’s possible I may have a misunderstanding, and maybe you can clarify on this a little if I am. The other possibility I have gathered from this is that widgets being the introductory point for blocks being integrated within the customizer are really only the starting point for testing the waters, and that’s all Phase 2 is now (in relation to the customizer). The goal for this change was only to get scripts setup, but we wanted to impact an area that is known to not have many modifications by plugins and themes via the customizer’s API to reduce any noticeable footprint. Then the next phase would completely remove any existing control pane (ie replaced by inspector) from the customizer and bring all controls into an inline editing experience. I don’t think you mean this though as you’ve mentioned about easing into things, and this way wouldn’t provide authors much in the way of preparation against such a leap.
PS: Sorry if this isn’t the right place to ask for clarification. I can send something on the core-customize slack channel if that is preferred :)
Name *
Email *
Website:
Topic Title (Maximum Length: 80):
Forum: — No forum —AI and WordPress Articles Blocks Showcase Discussions Events Introductions Jobs and Working in WordPress Podcast Episodes Site and Block Editor
Enter your email address to subscribe to this blog and receive notifications of new posts by email.
Email Address
Submit
Enter the destination URL
Or link to existing content
