PKP Bugzilla – Bug 6759
Investigate TinyMCE or similar for single-line entries
Last modified: 2012-03-12 10:12:33 PDT
Investigate TinyMCE or similar for single-line entries e.g. article titles. Some of these fields permit limited HTML but require the tags to be entered manually.
TinyMCE is not an option in the title field.
I can add html codes in the title field and they are not visible in the table of contents in OJS, but after exporting to DSpace or the DOAJ the title contains the html codes for example 'The <i>Universal Review</i> (1888-1890)'.
Our system administrator says we should avoid using italic in the title field (even with TinyMCE, if that was an option) for it would (still) cause this sort of trouble in all kinds of external databases.
Thank you for your kind help anyway.
Best wishes, Erika
(In reply to comment #0)
> Investigate TinyMCE or similar for single-line entries e.g. article titles.
> Some of these fields permit limited HTML but require the tags to be entered
Erika, if we did fully support HTML in titles, we would definitely need to properly strip any included HTML out of titles for use with external tools that don't expect HTML.
Specifically tested TinyMCE in case it works for single-line text fields (but somehow wasn't documented) to no avail. Also, I have not located any examples of a single-line text field with any sort of rich text editor attached to it.
Immediate answer seems to be that if visible rich text was desired for single line fields they will need to be converted to text areas. Other options might include:
2) simply adding help text beneath fields noting allowed tags and perhaps an example
3) implement barebones set of icons that wrap selected text in (visible) html tags -- basically like #2 w/ assist.
Erika notes that, when exporting field titles containing tags, the tags remain. This is an issue with the current support of html in titles, which seems to be allowed in some cases, but not compensated for universally.
Joe, option #1 sounds like the best solution to me -- and would be best suited for contribution back to the TinyMCE community. We could convert <input type="text" /> into <textarea>...</textarea> in our templates, but that seems a little clumsy. Mind investigating a little further?
Hrmph. When reading through the the docs I misinterpreted the "mode" setting. Turns out TinyMCE does allow what is being asked for here, namely, applying the text area to an input (or any other html element for that matter) -- though I'm not sure why my search yielded no examples of this.
Here's an example:
mode : "exact",
theme : "simple",
<input type="text" id="textfield" />
(In reply to comment #4)
> Joe, option #1 sounds like the best solution to me -- and would be best suited
> for contribution back to the TinyMCE community. We could convert <input
> type="text" /> into <textarea>...</textarea> in our templates, but that seems a
> little clumsy. Mind investigating a little further?
Better still, Joe -- I guess all that remains is to selectively configure TinyMCE to display a small input for those fields.
Yes, but should it always appear?
Joe, I guess you're asking whether we should accordion out the rich-text editor when the field is clicked? I suspect that's not necessary as long as the editor doesn't look too clunky for these fields; there isn't so many of them that we have to optimize it too heavily IMO.
Alec, as I understand, once the TinyMCE plugin is enabled it is "on" for certain textareas throughout the system -- but the user does not have a mechanism to disable/enable this editor for specific textareas, i.e., there is no 'settings' page for the TinyMCE plugin.
My thought is that even if they have enabled the plugin (because they wish to have tinymce applied to textareas) the user may not wish to have rich-text controls available for single-line entries.
Gotcha, Joe. The ability of a text field to accept HTML vs. plain text is cooked into the system, beyond whether or not TinyMCE is presented; we've never hard someone complain that rich text was available somewhere they didn't want it (though we have had to add code to strip tags from places they shouldn't appear). I'm not worried about that.
Created attachment 3663 [details]
TinyMCE config to enable rich text on title fields
In that case the next step is to identify pages where title field appears and assign the field in /plugins/generic/tinymce/TinyMCEPlugin.inc.php. Attached is my first attempt, but someone with a deeper knowledge of workflows should check to make sure none have been overlooked.
Presumably we'll also have to designate a distinct set of buttons for title fields as there isn't much sense allowing bullet-ed lists -- will look into this next.
Joe, can you upload your modifications as .diff files, either using GNU diff or "git diff"?
Created attachment 3664 [details]
Adding title fields to tinymce plugin
Joe, make sure you check the "patch" box when you upload the attachment. Looks good so far. See if you can crack the button set / formatting issues next.
Created attachment 3665 [details]
builds 2 separate tinymce inits for variable formatting options between fields
i've extended the $fields array to be multidimensional. each set of arrays off the root represents a unique set of fields which corresponds to unique tinymce configurations.
Deferring. I'm also not entirely sure why this is assigned to me, but I can certainly take a look at it.