Plugin to convert p- and br-tags to newlines
| Project: | Wysiwyg |
| Version: | 6.x-2.x-dev |
| Component: | Code |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | needs work |
Have there been any discussion about converting p- and br-tags to newlines when saving or switching to plain text mode? And convert the other way around when loading text to the editor. This is how Wordpress currenly does it.
An example:
Tinymce outputs <p>A paragraph</p><p>Another paragraph</p>. Before the text is saved to the database it's converted to
A paragraph
Another paragraphWhen Tinymce is editing the content again it's converted back to <p>A paragraph</p><p>Another paragraph</p>.
The advantages is that plain text and wysiwyg can co-exist much easier.
Attached is code adopted from Wordpress that I've used with Tinymce on a site. I tried writing a proper plugin for it but failed so on that site I hacked in setup: 'Drupal.wysiwyg.plugins.linebreaks.setup' to Drupal.settings.wysiwyg.formatX.
Thoughts?
| Attachment | Size |
|---|---|
| linebreaks.js.txt | 4.84 KB |
#1
That - as a Drupal plugin - would most probably make sense to add to Wysiwyg module. It would be the companion plugin for the Auto-paragraph filter in Drupal core, which is usually enabled for the "Filtered HTML" input format.
#2
Thanks for the quick input.
Exactly, the point is to have it to work cleanly with "Line break converter". wpautop() is basically a javascript version of _filter_autop() in filter.module, and it probably makes sense to rename wpautop() to _filter_autop() and have it match Drupals PHP line break converter instead of a straight Wordpress port.
Any pointers or help to get this into a proper patch for Wysiwyg module would be much appreciated. I looked at the break plugin already included, but got stuck on how to use the API for this case. And this should be a setting under "Cleanup and output", right? Something like:
Line break converter support
- If enabled, the output from the editor will be converted to work with the line break converter filter.
#3
@fajerstarter
I'd like to test this, but can you give a little more detail for how to apply the extra code? It is not clear how to load this new file.
#4
I got it and will post below.
Here's what I added:
-- Saved the above as linebreaks.js
-- Add the following to wysiwyg_load_editor():
<?phpdrupal_add_js($path . '/wysiwyg.init.js', 'core'); // Existing line
drupal_add_js($path . '/linebreaks.js');
?>
-- Add to wysiwyg_add_editor_settings():
<?php// to use a string instead of the format id.
$config['setup'] = 'Drupal.wysiwyg.plugins.linebreaks.setup';
?>
From this, we can roll a proper patch as a first step.
#5
That's one way I guess, but I have a feeling that there should be a better one. sun mentioned a "Drupal plugin". I looked through the wysiwyg code related to plugins but never got to a working implementation.
Here is how I hacked this in in a custom module:
<?phpfunction MODULE_wysiwyg_plugin($editor, $version) {
static $add_js = TRUE;
if ($add_js) {
drupal_add_js(drupal_get_path('module', 'MODULE') .'/linebreaks.js');
// Hard-code settings.
$setting = array(
'setup' => 'Drupal.wysiwyg.plugins.linebreaks.setup',
);
drupal_add_js(array('wysiwyg' => array('configs' => array('tinymce' => array('format1' => $setting)))), 'setting');
drupal_add_js(array('wysiwyg' => array('configs' => array('tinymce' => array('format2' => $setting)))), 'setting');
$add_js = FALSE;
}
}
?>
#6
For more information on Drupal plugins, see
http://cvs.drupal.org/viewvc.py/drupal/contributions/modules/wysiwyg/plu...
http://cvs.drupal.org/viewvc.py/drupal/contributions/modules/wysiwyg/wys...
http://cvs.drupal.org/viewvc.py/drupal/contributions/modules/wysiwyg/wys...
#7
I'm not should why this would be a plugin and not a setting as part of the API module.
#8
Here's a quick example of how a Drupal plugin implementing that code would work. The framework to do this kind of editing is already there in the form of these plugins, and using it requires less changes to the module itself. A Drupal plugin won't work with an editor unless the editor implementation has the necessary features, but that's usually not too hard to implement. Wysiwyg module currently assumes a Drupal plugin is supposed to have a button, but that button doesn't need to do anything.
The files should be placed at wysiwyg/plugins/linebreaks.inc and wysiwyg/plugins/linebreaks/linebreaks.js, then you'll have a 'Force linebreaks' button on the profiles page for editors supporting Drupal plugins. Currently, that is TinyMCE, FCKEditor, CKeditor (apply last patch from #610132) and jWYSIWYG (apply last patch from #483452).
It should not be hard to turn this into a proper patch if anyone's interested.
Btw, I noticed that it inserts   when there are multiple spaces at the end of the contents.
#9
Interestingly, this plugin implementation makes clear that we missed "Support for extensions" (as already existing for native editor plugins) in the 3.x roadmap. ;)
#10
Yeah, that's why I brought it up. Inserting whitespaces using a Drupal plugin and comparing the output to what's expected might also be a good testcase to see things are done in the correct order...
Another good thing about a plugin like this is that there would no longer be a need to convert old content to using paragraph and break tags when assigning an editor to a format where the linebreak converter was enabled.
#11
Ok, so Sun and TwoD, is #8 the recommended approach in this case?
I still think that from a usability point it's better to have this under "Cleanup and output", which would be more towards agentrickards approach, right?
#12
Yes, given the current situation. I don't think we should introduce more settings to "Cleanup and output" or the other fieldsets which are the same for all editors before we have fixed #313497: Allow to configure advanced editor settings. There is already too many settings on the profile page which only works for a few editors. Because the editor implementations are incomplete, there's no reliable way to get and set the editor contents for editors not supporting Drupal plugins.
#13
Here's a patch of TwoD's version
#14
It works for Fck editor but not TinyMCE, I'll try to fix that right now.
#15
Patch fails on FCKEditor 2.6.x, giving a JS error that the button is undefined.
On a larger note, this should not be a button plugin. It needs to be a global setting, like "Remove linebreaks".
#16
Here's the working patch. Move linebreaks.js to its own folder called linebreaks once you apply the patch.
#17
We have this patch working properly with FCKEditor, if that helps. Need to test on TinyMCE and others.
#18
The commented out lines should be removed from the patch. It could also be a good thing to merge in any changes from Wordpress (2.8.6), if any.
Update:
The relevant file on Wordpress Trac: http://core.trac.wordpress.org/browser/trunk/wp-admin/js/editor.dev.js
and the revision log: http://core.trac.wordpress.org/log/trunk/wp-admin/js/editor.dev.js
#19
Subscribe.
#20
Need the same thing for TinyMCE. Any working code coming out soon?
That apart does any one where to put
tinyMCE.init({forced_root_block : false,
force_br_newlines : true,
force_p_newlines : false
});
#21
@kaakuu, you can try the method described in #313497-30: Allow to configure advanced editor settings (comment #30) to inject those settings (that's probably a better place for discussing this). You could also modify tinymce.inc to include those options in the settings callback, but then you'd have to do those modifications each time you update Wysiwyg.
#22
Thanks TwoD - I saw that but was/am confused about "formatN should match the numerical id of the Input format for which the editor is enabled" - what is the value of N ? I am using "Wysiwyg" and from where do I get the value of N ?
I posted here for actually I wanted to do a +1 to have the feature in "Wysiwyg" as a configurable option like FCK.
#23
You can see the numerical id of your input formats if you go to admin/settings/wysiwyg and click or hover over the Edit link for the corresponding format/profile.
The numerical format id is seen in the last part of the path (admin/settings/wysiwyg/profile/N/edit). The editor profile id currently corresponds to the format id. For technical reasons we can't use just the number in the editor settings arrays/objects when they are sent to the browser, so we prepend 'format' and turn it to a string. Note the last post of that issue, it seems we can't override already set settings, only add new ones using this method.
Most configurable settings which are part of the editor library are to be given a GUI as part of that other issue. The implementation should also allow this GUI to be extended by Drupal plugins and by the hook for native plugins. Essentially, we're trying to remove as much as possible from the 'default' profile page and keep only that which is common to as many editors as possible (enabling/sorting buttons f.ex.).