Add rich text as a potential field

[danielbachhuber]

For shortcodes where you might want to grant the user basic HTML, it would be helpful to apply TinyMCE to a field and grant basic WSYWIG access.

[hirejordansmith]

Yes Please!

[chrisvanpatten]

Ooooh yes this'd be great!

[mattheu]

I think that this is a blocker for this one: https://github.com/fusioneng/Shortcake/pull/179

[mattheu]

Pusing to 0.4.

Perhaps we could encode this data in order to work around the complications with nested HTML in shortcodes.

[danielbachhuber]

We can now support this for inner_content

[ghost]

@danielbachhuber - just taken my first look at Shortcake and think it looks great!

WYSIWYG would be great (& enable me to use Shortcake on client projects). Is it still in the pipeline? (& is there anyway to get HTML in inner_content now?) edit: already possible!

Thanks!

[ryanboswell]

So wondering if there was someone working on this already and if it was anywhere near ready for release for the v0.5.0 milestone it's currently tagged to, I don't see any open PRs or released code for it so far. I'm considering helping out on this and submitting as a PR, but wanted to check before diving in.

[danielbachhuber]

I think #322 is the latest and greatest attempt. Now that core has fixed itself, we can easily support HTML for inner_content. I'm still wary of committing to an encoded attribute approach for everything else though.

Can you share your use case in a bit more detail?

[ryanboswell]

Ah, wasn't sure where that one stood.

The use case I'm thinking of is a shortcode that wraps rich text (aka. HTML markup) in specific markup that applies custom styling. The idea being that we want to grant some level of custom styling allowance to editors/writers, but currently don't allow them to add in-line style attributes in post content. So we accomplish that with a shortcode that hand holds them through the process and keeps them from breaking things design-wise. You can think of it kinda like a blockquote shortcode on steroids. Ideally we'd be able to allow them to edit the contents of the shortcode using a TinyMCE editor, since many editors/writers aren't all that familiar with writing HTML.

[danielbachhuber]

Cool, makes sense. It seems like you'd be able to do that with inner_content

[ryanboswell]

So after playing around, I've got a pretty lightweight bit of tinyMCE init code that works ad-hoc (dropping it into the console once the edit form is showing) and clones the default post editor config and adjusts the field selector to #inner_content.

I'm now thinking about how to indicate that inner_content should be a tinyMCE editor since I expect most of the time it won't be. The shortcode registration config is the easy answer, maybe supporting something like:

'inner_content' => array(
    'label' => 'Content',
    'type' => 'tinymce',
),

Next up is actually triggering the tinyMCE init code. I'm less confident on the approach here since I'm only slightly familiar with the setup here. My first two ideas are either merging it into the Backbone code after the inner_content field is rendered and doing our 'type' check there, or possibly having an event fire after each field is rendered with the field data passed on so we can put the init code elsewhere and trigger it then, checking the field type then. I'm leaning a little more towards the second option, since it potentially opens up Shortcake a little more to plug-ability on the client-side.

Thoughts?

[mattheu]

Firstly - having a 'type' => 'tinymce' argument seems like the way to go. Other options: wp_editor or wysiwyg?

Initializing TinyMCE in a situation like this is something I've done before - but its not straight forwards really. Simply initializing TinyMCE is one thing, but there are a few steps I've had to wrestle with to get a proper WP style editor working:

• somehow get the markup WordPress uses for wp_editor into a template we can use. In the past I used output buffering on the wp_editor function using placeholder ID, name and value.
• calling wp_editor adds all the args for that editor to a variable tinyMCEPreInit.mceInit. This gets used when you initialize the editor. I've had to write some hacky code to clone the placeholder editor args when initializing a new editor.
• Initialize the editor sometime after it has been created in the backbone view.
• Handle quicktags too - similar to above.
• Probably best to destroy the editor when hiding it, and reinitializing later - doesn't play so nicely if you try to show/hide/move it around.

See here for further reference - https://github.com/humanmade/Custom-Meta-Boxes/blob/master/js/field-wysiwyg.js

If you're at a dead end - open a Pull Request with what you've got and I can take a look at the MCE Init part.

[ghost]

@ryanboswell, @mattheu, @ryanboswell - just wondering what's needed to get this moving again? (WYSIWYG in inner_content). I had a discussion with @goldenapples re. this the other day, sadly I don't have the technical chops needed to implement, but willing to consider contributing towards someone's development time if it would get it done... or anything else I can do to help?

[cggit]

Sad to see this removed from v0.5.0 milestone. Plans for it to be re added?

[danielbachhuber]

Bump. Sad to see this removed from v0.5.0 milestone. Plans for it to be re added?

It will come when its time comes. Bumping the issue won't make it happen faster.

[cggit]

Apologies, I've retract my bump. I just wanted to know where this was on the priority list because i see it was removed from the milestone a month ago without a comment.

[danielbachhuber]

Requested again in the support forums: https://wordpress.org/support/topic/add-tinymce-to-inner-content-textarea

[rickalee]

Any update or known workarounds for this?

[roborourke]

@mattheu did you have any work in progress I can pick up here?

[mehigh]

Since TinyMCE is so heavy and comes with a big list of dependencies, I decided to spin out and try a different, simpler approach. Most of the times the ones wanting rich text editing don't need all of the offerings of TinyMCE, and that's how I ended up toying with http://summernote.org

I'm explaining the steps I've taken just in case it might help others get ideas.

First of all, I didn't want to trigger it to all of the textareas, so I've applied a meta class attribute to them: 'meta' => array( 'class' => 'shortcake-richtext', ),

And then I've made use of this textarea.shortcake-richtext selector when loading / displaying the shortcake forms:

var richText = {};

/**
 * Loads summernote rich text editor.
 *
 * @param {string} selector
 * @returns {boolean}
*/
richText.load = function( selector ) {
    if ( ( 'undefined' !== $.fn.summernote ) && ( $( selector ).length ) ) {
        $( selector ).summernote();
        return true;
    } else {
        return false;
    }
}

And before we submit the form, I'm setting the value of the textarea via the editor API before destroying it:

/**
 * Unloads summernote rich text editor.
 *
 * @param {string} selector
 * @returns {boolean}
*/
richText.unload = function( selector ) {
    if ( ( 'undefined' !== $.fn.summernote ) && ( $( selector ).length ) ) {
        $( selector ).each( function() {
            $( this )
                .text( $( this ).summernote( 'code' ) )
                .trigger( 'input' )
                .summernote( 'destroy' );
        });
        return true;
    } else {
        return false;
    }
}

This unload also opens the possibility to do some manual handling of the double quotes for example - if they're part of an element attribute to be changed to single quotes (turn <div class="something"> into <div class='something'>), and if it's actual text to be turned into their html entity (turn I quote "e=mc2" from Einstein into I quote "e=mc2" from Einstein and therefore clean up after ourselves and have this work properly even without the 'encode' => true setup in the Shortcode UI model.

Since this feature might arrive into core only as TinyMCE and just for the_content, if people show interest in having some more basic text editing to any number of textareas, I might be able to publish this as a standalone shortcake basic extension.

[mehigh]

@danielbachhuber I've just published a plug-in which allows you to add this to your own project. The readme is self-explanatory on how to make use of it: https://github.com/xwp/wp-shortcode-ui-richtext

This is a quite basic implementation using SummerNote as a rich text editor, but can be improved / contributed to if someone else has a stronger TinyMCE affinity.

This makes use of the latest event trigger additions which were merged into master 2 weeks ago.

[robrecord]

I would dearly love to see TinyMCE implemented here as my client is finding SummerNote difficult to use - indeed, I am too.

[goldenapples]

Paging @rahulsprajapati, who has a working or nearly-working implementation of a TinyMCE field but was coming up against a bug in this plugin (#679) that was preventing the tinymce editor from working after closing and reopening the modal, because of duplicate markup that's being added and not cleaned up properly here.

[tillkruss]

I'd love to see rich text support for the inner_content field. Are there any updates on this?

[pyronaur]

+1 Shortcake looks awesome, but we really need rich text edit options for the users.

[webdados]

This is a serious drawback because WordPress natively supports rich content on the shortcode content.

I propose that this is implemented ASAP, using TinyMCE (and not SummerNote ou any other editor), only on the 'inner_content' field.

[tillkruss]

100% agreed.

[bengreeley]

I've got a pull request in for the WP Shortcode UI Richtext Editor plugin to implement tinyMCE instead of Summernote. It seems to work pretty well. If this helps anybody, the PR is at https://github.com/xwp/wp-shortcode-ui-richtext/pull/8

[mehigh]

Thank you for the contribution @bengreeley ! I'll test it and then release it in the next version of the wp-shortcode-ui-richtext plug-in.

[pyronaur]

Ohh yesss! Thank you @bengreeley

[mehigh]

Now that the feature plug-in I created has TinyMCE support, maybe there will be interest to merge that functionality into shortcode-ui core? (with a separate field type instead of the class road I took for simplicity's sake)

[goldenapples]

maybe there will be interest to merge that functionality into shortcode-ui core

I think that would be great to see, as it's been a fairly common request! Any other opinions here?

[szepeviktor]

Maybe I am all alone with my opinion:

1. Storing HTML in a shortcode's attribute is hard
2. using blokk-s and [my_shortcode content="$POSTID"] is easy

*of course you may [my_shortcode]$HTML[/my_shortcode] but it is not reusable

[tillkruss]

Yeah, no need for HTML in attributes, but definitively inside the tag:

[my-shortcode]
    <h1>footer</h1>
[/my-shortcode]

Using Post IDs is easy for tech savvy people, but not your average editor.

[szepeviktor]

I allow my users only the <br/> tag which should be input as double space, even in a one-line input.

[mehigh]

szepeviktor On #1 -> I was still not able to make it work (with url encoding) when someone wants to make use of the "%" sign. It covered most of the use cases though. Without url encoding it would break on quotes, which appear often enough in HTML. On #2, is easy for people knowing to look for post IDs. So depends on the audience.

@tillkruss The feature plug-in adds the rich text functionality out of the box for the inner_content, it's just the attributes where the encoding and the extra class was required to differentiate from standard textareas. As for 'no need in attributes' -> it depends widely on the type of project and website these things are worked on. I sort of prefer [2col first="Rich text" second="Rich text"] to a set of multiple shortcodes one inside another to achieve a 2 column layout, like many theme builders do.

[szepeviktor]

On #2, is easy for people knowing to look for post IDs. So depends on the audience.

I use post_select as the content field. The user has to know only the title of the content blokk.

*BTW We build our content blokk's HTML, editors may only edit them not restructure them.

[szepeviktor]

I think most of the people would like to build structure from shortcakes not fill in prebuilt content block templates.