[wp-trac] [WordPress Trac] #30062: Add Hooks to Image Editor UI

[WordPress Trac]

#30062: Add Hooks to Image Editor UI
---------------------------------+---------------------------------
 Reporter:  ericmann             |       Owner:
     Type:  enhancement          |      Status:  new
 Priority:  normal               |   Milestone:  Awaiting Review
Component:  Media                |     Version:  4.0
 Severity:  normal               |  Resolution:
 Keywords:  has-patch has-tests  |     Focuses:  ui, administration
---------------------------------+---------------------------------

Comment (by tomauger):

 Sorry I have been absent from this ticket for longer than I had intended.
 Thanks Eric for the detailed and considered responses.

 Replying to [comment:7 ericmann]:
 > No. This doesn't make things easier, it introduces a very rigid and
 inflexible API against which each existing edit group must be rewritten.
 It also means we're keeping our code strictly in the backend and moving
 away from the ability to do more with a front-end (i.e. Backbone) view.

 I see your point - your approach provides greater flexibility in the end.

 > This means we keep most of the existing code (which is less of a shift
 for reviewers/maintainers, etc) while still moving to a far more flexible
 editor interface that allows developers to add in new sections where
 necessary.

 I'm completely on-board with this. I think you will find that I approached
 the problem with the same philosophy and that in both of our patches, the
 core code is very much the same.

 > > Furthermore, my `do_imgedit_groups()` function makes things a little
 more DRY and keeps the Image Editor Group boxes more consistent. In your
 approach, you're forcing the theme/plugin dev to grok the complete
 structure of the Image Editor box, including the show/hide help
 javascript, the correct classes, etc.
 >
 > Yes. Forcing a developer to grok the complete structure of a UI element
 they're adding to WordPress, including dynamic interactions and class
 names, is a good thing and was very intentional. This shouldn't be hidden
 from the developer as future changes in core will change the way things
 function at a core level.

 I wonder whether the reason we disagree on this point is because we are
 considering different types of "developer"? is it possible that I'm
 envisioning the plugin/theme developer and you are considering the more
 hardened core contributor?

 I always feel that helping less involved developers create compliant and
 well-integrated extensions to WordPress is of benefit to everyone.

 Let me put it this way: consider writing the Codex entry for adding editor
 groups - with your approach, the documentation will need to go into great
 detail about the HTML structure the developer would need to create in
 order to match the existing UX; if we actually create the HTML structure
 (including the Help piece) and allow them to focus on the functionality of
 their editor group, I think this makes for a better developer experience
 and will probably lead to more consistent UIs for those that decide to
 extend the editor in this way.

 > If WordPress makes fundamental changes to the markup structure and JS
 interactivity of these edit boxes in the future, it will fundamentally
 change the way the edit screen works.

 Not sure about this - for example, since 3.8 there has been a slight
 update to the HTML structure that changed the way the Help text was
 wrapped. Had the Editor Groups been in place at that time, and the
 structure left up to the developer, then that change would have broken the
 Help feature for any custom editor groups.

 On the other hand, I can appreciate your desire to give the developer
 maximum flexibility - if they don't want their editor group to look like
 the rest of the UI, then they should be allowed to over-ride the default
 HTML structure.

 I can envision a `before_title` and `after_title` type action that injects
 the standard WordPress markup & styles, but can be left out by a developer
 who wishes to over-ride the entire structure.

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