![(please configure the [header_logo] section in trac.ini)](/chrome/site/your_project_logo.png){kind=logo}
Changes between Initial Version and Version 1 of Ticket #34866, comment 1
- Timestamp:
- 12/06/2015 08:23:01 PM (11 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #34866, comment 1
initial v1 5 5 {{{_WP_Editors()::editor()}}} uses {{{wp_default_editor()}}} to set and empty value for `$default_editor` to either `'tinymce'` or `'html'` depending on user permissions and then the settings for the user via `get_user_setting('editor', 'tinymce');`. The allowed values there are `'tinymce'`, `'html'` and `'test'` and that is filtered by `apply_filters( 'wp_default_editor', $r );` 6 6 7 If nothing is passed, the default is called , and anything other than `'html'` is set, WordPress will change the value to `tinymce`.7 If nothing is passed, the default is called. If anything other than `'html'` is set by either method, WordPress will change the value to `tinymce`. 8 8 9 9 Theoretically, at this point, `format_for_editor` should be hooked to `the_editor_content` where it will receive both the content that gets filtered and the `$default_editor` value (not assured, but likely one of the two above options). The back-compat code seems to indicate that is the case: … … 29 29 }}} 30 30 31 Which means that `$default_editor` will (in practice) only ever take `html` or `tinymce`. Developers who turn off tinymce(even if they're using some other wysiwyg) and users without permission to use it will never see the `format_for_editor` filter fire. The only other case where this would apply would be if some plugin or theme is calling this function themselves and feeding in a different value? Is that an intended use? I don't know if this should matter for documenting, but I thought I'd note here that this might not be the intended execution, as indicated by the rest of the code. It's also weird, because it means that you can only filter `the_editor_content` if tinymce is enabled, though it can effect both html and tinymce modes.31 Which means that `$default_editor` will (in practice) only ever take `html` or `tinymce`. Developers who turn off TinyMCE (even if they're using some other wysiwyg) and users without permission to use it will never see the `format_for_editor` filter fire. The only other case where this would apply would be if some plugin or theme is calling this function themselves and feeding in a different value? Is that an intended use? I don't know if this should matter for documenting, but I thought I'd note here that this might not be the intended execution, as indicated by the rest of the code. It's also weird, because it means that you can only filter `the_editor_content` if tinymce is enabled, though it can effect both html and tinymce modes.
