_WP_Editor class is currently marked as final

[Marko-M]

Revision [19420] turned

class _WP_Editors{}

from wp-includes/class-wp-editor.php into

final class _WP_Editors{}

I'm aware that editor API is currently under large changes but it would be great if plugins could extend _WP_Editors class by removing "final" keyword.

[nacin]

The reason for this change is that _WP_Editors should be re-architected to be a WP_Editor class that is individually instantiated for each editor. Right now it is a singleton, and makes avoiding OOP an art form.

I'm -1 on just making this not final, but +1 on making it not suck for extensibility purposes. :-) A WP_Editor class would not be final.

[Marko-M]

Replying to nacin:

The reason for this change is that _WP_Editors should be re-architected to be a WP_Editor class that is individually instantiated for each editor. Right now it is a singleton, and makes avoiding OOP an art form.

I'm -1 on just making this not final, but +1 on making it not suck for extensibility purposes. :-) A WP_Editor class would not be final.

Yes I see that it's half-baked right now and I understand the reasons for making it final. It would be great if final class could give developers ability to easier get editor without WordPress releted plugins like wplink. Right now if you want any "link" button on quicktags this pulls in jquery-ui. This way WP_Editor would be more appropriate for frontend (more light weight) because placing jquery-ui (wplink dependency) on frontend is a bit too much for some sites. I can offer help in doing the work on re-architecting WP_Editor but you've done a lot of work on it and I guess you don't need another developer getting in the way?

[chriscct7]

Thinking maybelater on this?

[helen]

I think realistically the response to this ticket summary is "yep, it sure is" :) If some intrepid soul wants to think about a real WP_Editor someday we can revive and reframe this.