WordPress.org

Make WordPress Core

Opened 4 years ago

Closed 4 years ago

Last modified 4 years ago

#19103 closed enhancement (duplicate)

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

Reported by: amereservant Owned by: nacin
Milestone: Priority: normal
Severity: normal Version: 3.3
Component: General Keywords: has-patch reporter-feedback
Focuses: Cc:

Description

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!

Attachments (1)

class-wp-editor.diff (1.1 KB) - added by amereservant 4 years ago.
Proposed 'the_editor_settings' filter patch for class-wp-editor.php

Download all attachments as: .zip

Change History (9)

@amereservant4 years ago

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

comment:1 @nacin4 years ago

  • Milestone changed from Awaiting Review to 3.3
  • Owner set to nacin
  • Status changed from new to accepted

comment:2 follow-up: @azaozz4 years ago

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.

Last edited 4 years ago by azaozz (previous) (diff)

comment:3 @westi4 years ago

  • Keywords reporter-feedback added

comment:4 in reply to: ↑ 2 @amereservant4 years ago

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.

comment:5 @nacin4 years ago

Let's close this in favor of #19103?

comment:6 @nacin4 years ago

Sorry, I meant:

Let's close this in favor of #19320?

comment:7 @azaozz4 years ago

  • Resolution set to duplicate
  • Status changed from accepted to closed

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

comment:8 @ocean904 years ago

  • Milestone 3.3 deleted
Note: See TracTickets for help on using tickets.