Fix the TinyMCE init array

[azaozz]

closes #10966, #11147, #7942, #8670

• Added "manual" convert from php to js, same as in class-wp-editor.php.
• Reformatted the code there so it's more readable.

[ellatrix]

Why shouldn't we pass editor if we want it to be as close as possible like the old editor?

[azaozz]

That is (supposedly) the editor id and is intended to identify the TinyMCE instance when more than one on the same page. The classic editor passes content there, but thinking it's no good to reuse that as the classic block editor instance is quite different and plugins should be able to identify it from php.

Passing editor is a bit too generic :)

[ellatrix]

Added "manual" convert from php to js, same as in class-wp-editor.php.

Is it not possible to compose the right PHP object, then JSON encode?

[azaozz]

No, because that breaks some of the functionality. The TinyMCE init is supposed to be written in (pure) js. It is in our (WordPress) implementation that we set it as php and then "convert" to js before output.

Several settings in the init object accept js functions. If it is JSON encoded, that breaks. Example: init_instance_callback. To test can use the mini WP plugin from here: #10966 (comment).

Currently when using that plugin we get this in the console:

Uncaught TypeError: Cannot read property 'apply' of undefined
    at Editor.execCallback (tinymce.js?ver=4800-20180716)
    at initEditor (tinymce.js?ver=4800-20180716)
    .....

Happens because the init js is outputted by wp_localize_script() which is meant only for strings and JSON encodes the output.

With this pr we get:

Editor: editor-7ffd9aaf-ae66-47f1-a160-1820fe202478 is now initialized.

i.e. works as expected.

[azaozz]

Also, this pr adds another (custom) option to the TinyMCE init object: 'classic_block_editor' => true,. It would be nice to be able to identify the TinyMCE instance from js based plugins. Will add similar option to the Classic editor's instance, probably 'content_editor' => true, (or maybe that should be classic_editor?).

[azaozz]

Heh? Tests failing because... the code is more readable? :)

     |         |     expected 13 space(s) between "'toolbar1'" and
     |         |     double arrow, but found 1.

This seems contrary to the WP coding standards. So when defining arrays they should look like:

'long-array-key-that-would-make-for-a-long-line-and-there-is-no-way-to-wrap-it-up' => 'value',
'key'                                                                              => 'long-array-key-value-that-is-not-easy-to-read-as-it-makes-the-line-too-long',

The spacing looks so "borked" :) How is that easy to read? :)

Opened WordPress/WordPress-Coding-Standards#1513 as follow up.

[danielbachhuber]

Note: this doesn't quite yet solve #11147 (comment)

[azaozz]

Also opened https://core.trac.wordpress.org/ticket/45221 for core.

This is a regression and a blocker for WP 5.0.

[azaozz]

Fixed in core https://core.trac.wordpress.org/changeset/43867. The fix needs to be merged here too.

[youknowriad]

Is this ready to land? Can we rebase and merge @iseulde @azaozz ?

[youknowriad]

LGTM 👍

[youknowriad]

These changes are already in Core, so no need to backport.

[azaozz]

Ughhh, PHPCS forcing ugly code formatting :(
(I should have fixed that, sorry).