[wp-trac] [WordPress Trac] #19103: Add editor settings filter to wp-includes/class-wp-editor.php

[WordPress Trac]

#19103: Add editor settings filter to wp-includes/class-wp-editor.php
-----------------------------------------+-----------------------
 Reporter:  amereservant                 |       Owner:  nacin
     Type:  enhancement                  |      Status:  accepted
 Priority:  normal                       |   Milestone:  3.3
Component:  General                      |     Version:  3.3
 Severity:  normal                       |  Resolution:
 Keywords:  has-patch reporter-feedback  |
-----------------------------------------+-----------------------

Comment (by amereservant):

 Replying to [comment:2 azaozz]:
 > What is the user case for that filter? If it's only to change the
 textarea height, this can be done in many different ways, probably best
 with css. BTW when TinyMCE is active the editor height is set in a cookie
 when the user resizes it and restored on the next page load. Only the
 initial height can be set from PHP.
 >
 > This is a question of priority of plugins. Not convinced it's a good
 idea since it would make plugins interfere with each other and probably
 break one of them.
 >
 > If a plugin defines the editor in a particular way, IMHO it has the
 priority and we should output it that way. There are plenty of filters
 that would let other plugins to set up different aspects of the editors
 and all can still be changed from JS before the editors init.

 Being able to alter the editor's settings server-side allows developers
 who want to utilize existing functionality greater flexibility in
 customizing WordPress to suit there needs.  To make corrections client-
 side means the downloading of more data and leads to slower download
 times, which is counter-productive in terms of speed and efficiency.
 When it comes to plugins, they can sometimes offer a particular
 functionality and yet alter additional settings that may or may not be
 desired.  And multiple plugins attached to the same hook can conflict with
 one another on pretty much any existing hooks, so that's hardly a reason
 to not add this.

 Me personally, I rarely use plugins since I use WordPress for very
 specific purposes and plugins will often not offer the exact functionality
 I'm looking for, add extra stuff/alterations that I don't want, or can be
 inefficiently written costing speed and performance.  I know that's
 probably a minority thing, but yet still a valid reason for those who
 would utilize this hook and others that are more of a "special-purpose"
 hook and likely not to be a commonly-used one.

 Just like one can fully customize the front-end through action and filter
 hooks, I feel the admin area should include this same level of flexibility
 apart from having to rely on JS to make those changes.

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/19103#comment:4>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software