For a long time, cloning WYSIWYG fields is a big trouble. The WYSIWYG field is a WordPress editor field which is built on TinyMCE editor, a very popular rich text editor for the web. It allows you to add content, format the content, insert rich media into the content such as images, videos, audios or any HTML code and even shortcodes added by WordPress plugins. As a WYSIWYG editor, you will see how the content actual look right after you enter it in the editor.

Like other custom fields, WYSIWYG was supported by the Meta Box plugin since the beginning day. But it didn’t have the clone feature as other fields until recently. The clone feature allows users to add more inputs to the current field (in some other plugins, this feature is called repeatable field). This is very useful when you don’t know how many inputs the field should have and you want users to have the option to add more inputs or remove existing ones.

For example, you have a custom post type “book” and you want users to enter the name of chapters for each book. It’s best to have a cloned input for “chapter”.

Back to the WYSIWYG, many users have been requesting the clone feature for WYSIWYG. But we actually didn’t make a good development process. The reasons the clone feature didn’t work for it are so many and here are the main ones:

  • The complex output of the editor. Each WYSIWYG editor might have Add Media button, the toolbar, the switcher between Visual/Text mode, the quick tags bar, the main content area and the status bar. All of these elements are related and connected by TinyMCE’s JavaScript to make them work synchronized. There are plenty of ID and classes organized in a strict way that TinyMCE understands. It’s not just a single input or drop-down box.
  • The output of WYSIWYG editor is not generated by HTML, but WordPress’s function wp_editor(). We couldn’t just output a textarea and use JavaScript to render the editor. It’s not the way we work with TinyMCE. WordPress changes the behaviour of the editor to add its own stuff and force developers to use its API if they want to work with the editor.

For almost a year, we’ve been trying to replicate the process of initializing the editor but it didn’t work. We also forgot to mention that the JavaScript that WordPress uses to render the editor is changing over the time.

Until recently, we tried both replicate the HTML structure and JavaScript code of WordPress editor and it works! Technically, when users clone a WYSIWYG field in a meta box:

  • A cloned HTML structure of the editor is created and appended to the DOM. Of course, it doesn’t work right away;
  • The HTML IDs and classes of elements (media buttons, toolbar, etc.) are replaced with an appropriated ones;
  • The HTML of the editor is removed (it actually is an iframe and couldn’t be just updated to work); and
  • JavaScript gets the settings of the old editor and uses these settings to initialize the new editor. This makes sure the new editor is a true clone of the old one.

And it works!

Here is how it looks like:

clone wysiwyg field in meta box

In order to add clone feature to your WYSIWYG field, simply set 'clone' => true for the field, just like other fields.

If you’re using Group extension, we also made a new update for the extension which supports WYSIWYG in cloned groups as well. So you can have a group of some fields like this for a product in a bundle:

  • Title (text)
  • Short description (WYSIWYG)
  • Image (image_advanced)

And set the group clone if you want to add more products to the bundle. It would work with the version 1.0.6 of the Meta Box Group extension. Please update it if you haven’t done.

Although it took us countless hours of work, but winning a technical challenge is really a good moment in a developer’s life. We hope you enjoy it. And in case you want to add any suggestion or question, please let us know on Github.

Leave a Reply