Most WYSIWYG editors use <textarea>, but since this one uses <div>, it's very difficult to integrate with existing CMSes (such as Drupal). Any chance <textarea> support could be added?
You can easily solve this with a bit of javascript, just use the serialize method and some hidden inputs.
I have personally wished for this feature as well. Since most of the projects I work on have a need for a rich text field inside a <textarea>
:+1:
I also want this too! Although I understand that by using div I can still submit forms using Javascript/AJAX, many of my codes I work on are still using the old html form method. It will save me a lot of troubles if I can use the editor in
As @daviferreira this is how Im doing it.
$(function() {
var editor = new MediumEditor('.editable');
$(".js-form").submit(function( event ) {
event.preventDefault();
var contentObj = editor.serialize();
$(".js-content-hidden").val(contentObj['element-0'].value);
this.submit();
});
});
For developers concerned with progressive enhancement, using a textarea element should be the recommended usage. The documentation says :
The above code will transform all the elements with the .editable class into HTML5 editable contents and add the medium editor toolbar to them.
... it should at least work with the html element meant for long texts. I'll try to provide a quick example on how to turn textareas into divs before calling the function.
That issue aside, big bravo and 'thank you' for this script.
Here is a working example (using jquery).
In your html:
<textarea id="description" name="description" class="editable" placeholder="<?php _e('Enter text ...');?>"></textarea>
In your javascript:
$(function() {
$('.editable').each(function(){
var params = {
'placeholder': $(this).attr('placeholder')
}
$('<div class="editable">' + $(this).html() + '</div>').replaceAll(this);
var editor = new MediumEditor('.editable', params);
});
});
@pixeline Thanks for posting that, it allowed me to use a textarea instead of nasty hacks with hidden inputs. My question is, does this work with form submitting? When i submit the form my page refreshes with a blank div with only the placeholder where there used to be content. Do I need to add additional JS to make the submit work?
@zetas yes, i just realized the same thing. I'm going to switch to another wysiwyg editor, as i 'm too short on time to patch this. Plus it would be a javascript-only solution, which does not suit my project's criteria.
Note that a solution would be to inject the produced html into the textarea on form submit.
Well, i had to give it a shot. Here is a proof-of-concept (using jquery):
$('.editable').each(function() {
var $this = $(this);
var styles = $this.attr('style');
if (typeof styles != 'undefined') {
styles = ' style="' + styles + '"';
}
$this.wrap('<div class="editable-wrapper"/>');
var $w = $(this).parent();
$w.prepend('<div class="editable" ' + styles + ' data-placeholder="'+$this.attr('placeholder')+'">' + $this.val()+'</div>');
$this.hide();
var editor = new MediumEditor('.editable-wrapper');
});
$('form').submit(function(){
$('.editable-wrapper').each(function(){
$(this).find('textarea').val($(this).find('.editable').html());
});
});
+1 for using a textarea as this is the most natural thing to do and it degrades gracefully
It's very easy to make it work for textareas, it's about 3 lines:
jQuery( "#MyForm" ).submit(function( event ) {
value = jQuery('#divWithEditableContent').html();
jQuery("#myHiddenTextarea").val(value);
});
I'm not sure if this should be posted in a different thread as it has to do with addons more than anything but I ran into an issue using medium-editor-insert-plugin where the data being saved to the server included all the markup inserted by the plugin when just grabbing the .html() using jquery. So I had to use the editors serialize function to make sure that extra markup wasn't included like so:
Note: This does use hidden inputs to pass data back and forth using a traditional form. It was the easiest way I could find to do it and have it be rock solid.
<div id="body_editable" class="editable" data-placeholder="Start typing your paper...">
{# Editable body div #}
</div>
<form method="post" id="paper_form">
<input type="hidden" id="body_field" value="" />
</form>
//On Page Load we insert data from the server into the editor to facilitate a previously existing entity:
$('#body_editable').html($('#body_field').val());
//On save event:
$('#body_field').val(editor.serialize().body_editable.value);
//Instead of:
$('#body_field').val($('#body_editable').html());
I can't express how mind boggling it was to diagnose issues with that plugin when I'd make a change to something and it wouldn't update except with new, empty editors.
P.s. I'm also going to post this on their issues list just so people are aware. Not so much a bug but an implementation issue.
@zetas lifesaver! I have spent hours trying to figure out how to implement it in a rails form and this worked perfectly. Really should be in the documentations, cheers again.
Hmm, nice Zetas but still its a bit odd that you have to use hidden fields for that.
It would be an amazing upgrade if this texteditor could use textarea and not a div as most of us are using textarea.
:+1: I'm using rails and I it is very awkward to create an hidden field to store the content.
quick/dirty POC extension:
@phiggins42 This is a great feature, I would definitely submit that as a pull request. I've also commented on the gist for some possible suggestions on things to consider with this extension, let me know what you think.
@nmielnik I responded in gist. Would call out to others above for implementation requirements / ideal usecase coverage. I like both directions, and don't care personally which direction it goes. This was just a POC seeing if the existing editor provided enough hooks to tie into element instantiation and whatnot to do these kinds of "magic" things in extension-land.
That's a good point about the <textarea> already existing inside the form. I think you covered the solution though, but basically have a data attribute on the <div> which specifies the id of it's linked <textarea>, and if the extensions sees that this already exists, it doesn't generate it.
I think we've basically just agreed that our best initial case is just to setup an extension that just "links" together a medium-editor div and a hidden input/textarea. From there, it seems like it wouldn't be a lot of work to then generate the <div> based on the <textarea> or the <textarea> based on the <div>.
I think that behavior should be native, it's quite trivial. If the element passed is a textarea, we just hide it and link it.
+1
Most helpful comment
As @daviferreira this is how Im doing it.