Add editor settings filter to wp-includes/class-wp-editor.php

[amereservant]

I propose adding the following patch which applies the new filter the_editor_settings to the array of editor settings just before it begins rendering the editor in WP_Editor::editor().

This would allow developers the ability to customize many attributes to how the editor renders including setting the textarea rows, etc.

I personally need this because I've chosen to use the Posts in a different way and the content will be much shorter than a standard WordPress Post, so an oversized textarea is too much.
Instead of writing my own form code, it makes better sense to customize the existing code and keep the overall code lighter.

Thanks!

[amereservant]

Proposed 'the_editor_settings' filter patch for class-wp-editor.php

[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.

[amereservant]

Replying to 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.

[nacin]

Let's close this in favor of #19103?

[nacin]

Sorry, I meant:

Let's close this in favor of #19320?

[azaozz]

Agreed, it's not complete duplicate but #19320 should handle this one too.