Support for conventional, form based usage

[Padam87]

Hi,

Users (admins really) became accustomed to this editor and there were scenarios (especially on our backend system), when a form based editor was needed. Eg editing a product desctiption on the admin instead of the frontend.

Also, using another, standard WYSIWYG editor led to some conflicts due to the HTML generated, so I had to cobble up a solution.

        $('.js-content-tools-form').submit(function (event) {
            let editor = ContentTools.EditorApp.get();
            editor.removeEventListener('saved');
            editor.stop(true);

            let $form = $(event.target);

            $form.find('[data-editable]').each(function (i, element) {
                let $element = $(element);

                let $input = $('<input type="hidden"></input>');
                $input
                    .attr('name', $element.data('name'))
                    .val($element.html())
                ;

                $form.append($input);
            });
        });

        $('.form-content-tools').click(function () {
            let editor = ContentTools.EditorApp.get();

            if (!editor.isEditing()) {
                editor.start();
            }
        });

It would be nice to have some kind of form support built in.

[anthonyjb]

@Padam87 so we use CT with a CMS backend which provides form based administration of data models (like products) for the reasons you've described. CT is used primarily for rich content like pages, articles, and on occasion rich media fields for things such as products. Even when we have content such as a page or blog we still typically have requirements for form fields such as title, slug, and they myriad of SEO settings. At the moment this works well for us, that is having a CMS which we integrate CT into.

Are you suggesting that we look to add a form based editor within the in-page editing environment (such as in a side bar or popup)? If so I think that this is something that could be perhaps added as an extension (as I am hoping to vastly improve the UI toolkit for CT to make it far easier to use and extend CTs UI), but it's probably out of scope to look to introduce a form editor to the CT core.

[Padam87]

Definitely not a form editor, I'd say form compatibility.

For us, the editor itself was not the issue. It took some time for the admins to get used to it, but once they did, they wanted it everywhere. Altough I think a traditional one would appeal to a lot of people. Have you looked at CK editor 5? They offer like 4-5 different editor types with the same HTML parser.

The core of the issue for us was: Lets say we have a form with 10 fields... text, selects etc. One of them used to be a WYSIWYG editor (summernote) based on a textarea. The form was submitted with a simple POST.

<form method="POST">
<input ...>
<input ...>
<input ...>
<textarea>
</form>

By replacing the textarea with CT, we lose that data from the submit. That is why I wrote that listener, that adds it as a hidden field.

IMO the ideal solution would be something like this:

<div data-editable data-name="content" data-form>
    <h1>Content</h1>
</div>

By adding data-form CT should add a hidden field, with the value of the editable bound to it.

[ikkez]

The way how contenttools currently works does not make it very attractive to use it as a real-text editor for textarea. It simply doesnt make much sense to do so, as contents tools is more for page contents instead of single input fields/area, which is absolutely fine for me. I use a different editor for such occasions, like summernote or Trumbowyg. I think that @Padam87 means is, to optionally use the contenttools editor as a single input field editor, just like this github answer input field - put the toolbar horizontally on the top and stick to one textarea field in the background. It would probably make things easy in a system, when you only need to implement one editor for all things, incl. image upload within the editor and such things.

[anthonyjb]

@ikkez @Padam87 ah ok I get it now so a text area field that supports rich content, yeah CT is not set up for that, however, moving forward I don't see any reason why we shouldn't be able to provide a minimal UI that's restrained to a container like a div so that the editor behaves as described, and it should be possible to automatically update the contents of a hidden field whenever the edited content changes.

I'll add to the road map feature list - thanks for the input :+1:

[anthonyjb]

@ikkez in line with your comment I think CT may struggle to compete still with some dedicated rich text field editors because it will always focus on full page editing, even more so now that page layout will also be part of CT2 core (e.g ContentFlow). But I like the idea that it can be used in this way (with limitations) so that you don't have to use 2 separate libraries if you'd prefer not to.

[kriskenyon]

I am so happy to see this added to the roadmap. I seriously need this and forgot to ask :)