Bug 11583 - Add WYSIWYG editor for HTML notices/letters
Summary: Add WYSIWYG editor for HTML notices/letters
Status: In Discussion
Alias: None
Product: Koha
Classification: Unclassified
Component: Notices (show other bugs)
Version: Main
Hardware: All All
: P5 - low enhancement
Assignee: David Cook
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-01-20 01:16 UTC by David Cook
Modified: 2025-01-13 05:23 UTC (History)
8 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:
Circulation function:


Attachments
Bug 11583: Add WYSIWYG editor to HTML notices/letters (14.12 KB, patch)
2024-11-21 06:04 UTC, David Cook
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description David Cook 2014-01-20 01:16:10 UTC
Currently, library staff need to handcode HTML notices/letters.

This enhancement will add a wysiwyg editor for notices/letters that are marked as "HTML", so that library staff can create HTML notices/letters without much knowledge of HTML and CSS.
Comment 1 Katrin Fischer 2020-01-05 12:24:04 UTC
I wonder if this is still doable with the new TT syntax vs the more simple placeholders we had before.
Comment 2 Martha Fuerst 2020-08-24 17:15:51 UTC
We're interested in this as well.
Comment 3 David Cook 2020-08-26 01:16:38 UTC
(In reply to Katrin Fischer from comment #1)
> I wonder if this is still doable with the new TT syntax vs the more simple
> placeholders we had before.

I was just thinking that. Could be interesting to try out.
Comment 4 David Cook 2022-12-06 06:43:55 UTC
Closing this due to age. I'm unlikely to work on it again.
Comment 5 Christopher Brannon 2024-02-06 20:01:12 UTC
I would like to see this.  If we select HTML in the template, we should be able to see it and format with tools like we can everywhere else.  This would be a very welcome enhancement.
Comment 6 Jessie Zairo 2024-10-21 13:34:55 UTC
Adding +1 to this.
Comment 7 David Cook 2024-10-21 22:36:36 UTC
(In reply to Jessie Zairo from comment #6)
> Adding +1 to this.

I had a nice chat with Jessie and some others about this at Kohacon. While it's not on my list of priorities, this would be a fun/interesting one to do.
Comment 8 David Cook 2024-10-23 00:07:23 UTC
Funny enough I just had a library ask for this...
Comment 9 David Cook 2024-10-23 00:55:53 UTC Comment hidden (obsolete)
Comment 10 David Cook 2024-10-23 01:00:00 UTC Comment hidden (obsolete)
Comment 11 David Cook 2024-10-23 02:11:19 UTC Comment hidden (obsolete)
Comment 12 David Cook 2024-10-23 02:20:55 UTC Comment hidden (obsolete)
Comment 13 David Cook 2024-10-23 02:43:06 UTC Comment hidden (obsolete)
Comment 14 David Cook 2024-10-23 03:42:01 UTC Comment hidden (obsolete)
Comment 15 Sally Lodico 2024-10-24 17:34:05 UTC
I rarely bother with TinyMCE. I find it to be more trouble than it's worth, but the newer template designers, like https://grapesjs.com/, would make creating responsive and email ready notices a dream. I'd much rather have a tool like this than a WYSIWYG.
Comment 16 Lisette Scheer 2024-10-24 19:26:31 UTC
I really like grape.js though it would be a huge process.

It would be helpful for the previewing as well.
Comment 17 David Cook 2024-10-25 01:21:56 UTC
(In reply to Sally Lodico from comment #15)
> I rarely bother with TinyMCE. I find it to be more trouble than it's worth,
> but the newer template designers, like https://grapesjs.com/, would make
> creating responsive and email ready notices a dream. I'd much rather have a
> tool like this than a WYSIWYG.

TinyMCE does drive me crazy...

I hadn't heard of GrapesJS but it looks interesting. It's actually like you read my mind. I was wondering what FOSS options there were for block content editing like this...

--

Unfortunately, at a glance, it would have the same problem as TinyMCE.

If you type in <<borrowers.firstname>> into a text block it will turn it into &lt;&lt;borrowers.firstname&gt;&gt;

It's not just the <<>> syntax; it's also the Template Toolkit syntax. There's times we do things like [% stuff = { 'this' => 'that' } %] which could be turned into [% stuff = { 'this' =&gt; 'that'} %]

But maybe GrapesJS is more customizable than TinyMCE. But I think it would be very challenging or impossible with GrapesJS too.

--

We were probably overambitious using Template Toolkit in Notices after all. 

Many email templates could be done using a simple token replacement system, but AUTO_RENEWALS heavily requires Template Toolkit logic.
Comment 18 David Cook 2024-10-25 01:51:26 UTC Comment hidden (obsolete)
Comment 19 David Cook 2024-11-20 06:17:10 UTC
I got another query about this today, so I decided to look at it again...

...and I appear to have figured out a workable solution.

My solution is really a minimal solution, and it'll probably grow over time, but it proves the basic concept. 

--

Alternatively, if we don't think it's robust enough for the mainstream, it could potentially be implemented as a Koha plugin.

--

Anyway, I'll post something soon. Watch this space!
Comment 20 David Cook 2024-11-21 06:04:34 UTC
Created attachment 174868 [details] [review]
Bug 11583: Add WYSIWYG editor to HTML notices/letters

This change adds a WYSIWYG editor to HTML notices/letters.

Test plan:
0. Apply the patch
1. In "Local use" system preferences, create "UseWYSIWYGinNotices"
and set it to "1"
2. Go to http://localhost:8081/cgi-bin/koha/tools/letter.pl
3. Edit any template
4. Open the "Email" tab
5. Toggle "HTML message" on/off and see the WYSIWYG editor appear
and disappear
6. Try adding content with the "Insert->" button
7. For notices like AUTO_RENEWALS_DGST, try the "View default"
and "Copy to template" button.
(NOTE: You'll want to wrap the AUTO_RENEWALS_DGST text with <pre></pre>
so that it doesn't destroy your whitespace when converting to HTML)

8. Try adding text and formatting using the WYSIWYG
9. Try adding text and formatting using the "<>" source code button

NOTE: If you click on a template token in the WYSIWYG, you should
notice that it's uneditable. You must edit it in source code mode.
This is because in the WYSIWYG the template token has been converted
to a HTML friendly placeholder.
Comment 21 David Cook 2024-11-21 06:15:13 UTC
Technically, this is ready for testing[1].

I'd love it if people could give this a try and give some feedback.

Since it's such a self-contained change, which can be easily toggled with a system preference, I'm actually thinking about trying this out locally for one of my libraries. Heck, even if the community doesn't like it, I might run with it locally anyway. 



[1] The only thing keeping me from marking this as "Needs Signoff" is the *.pref file update and the database update, which can be provided if people approve of this idea.
Comment 22 Lisette Scheer 2024-11-21 15:27:14 UTC
Overall I like it! 
The things I've noticed so far:

You can't resize the editing area. It will get loonger as you edit, but it would be nice if it would at least keep the expanded size if you changed it in non-html mode.

In the html editor, I select this line and make it bold:
Dear [% borrower.firstname %] [% borrower.surname %], 
then the Dear and the , show as bold, but not the TT placeholders. 
When I look at the source code it isn't including them in the bolding:

<pre><strong>Dear </strong>[% borrower.firstname %]<strong> </strong>[% borrower.surname %]<strong>, </strong><pre><strong>Dear </strong>[% borrower.firstname %]<strong> </strong>[% borrower.surname %]<strong>, </strong>

If possible a hint text like "placeholders must be edited in source code mode" so folks know they might need to switch would be helpful. 

It would be nice if it could know not to eat the whitespace without having to add <pre></pre> tags.

Overall I think this is a step in the right direction for users interested in a wysiwg!
Comment 23 David Cook 2024-11-21 22:32:35 UTC
(In reply to Lisette Scheer from comment #22)
> You can't resize the editing area. It will get loonger as you edit, but it
> would be nice if it would at least keep the expanded size if you changed it
> in non-html mode.

Oh that's interesting! Right before I uploaded, I enabled the "autoresize" plugin. Without it, you can resize. I'll have to look into that.
 
> In the html editor, I select this line and make it bold:
> Dear [% borrower.firstname %] [% borrower.surname %], 
> then the Dear and the , show as bold, but not the TT placeholders. 
> When I look at the source code it isn't including them in the bolding:

Yeah, I noticed that as well. Sometimes, it does include them, but usually it doesn't. If you edit in the source code, you can fix up the HTML, and it'll keep the fixed version. 

But yeah I'm not sure that there's a way around this one. Perhaps a hint/warning about that might be good?

> If possible a hint text like "placeholders must be edited in source code
> mode" so folks know they might need to switch would be helpful. 

Great idea!

> It would be nice if it could know not to eat the whitespace without having
> to add <pre></pre> tags.

Alas, I don't think that's possible. I hunted and hunted, and TinyMCE's built in DOM tools get rid of the whitespace.

I think part of the reason is that is as soon as you start using the WYSIWYG editor it'll be dynamically editing the DOM tree, so it does make sense for it to eat the whitespace.

But it's still annoying :/. 

> Overall I think this is a step in the right direction for users interested
> in a wysiwg!

Thanks so much for your feedback!

Last night, I was wondering if it might be good to have another checkbox to toggle the WYSIWYG on/off, because maybe you want to have an HTML email, and you have the WYSIWYG syspref turned on, but you don't want to use the editor for that particular notice?
Comment 24 David Cook 2024-11-21 23:01:21 UTC
Oh, I was also thinking... we could include NoticeCSS in the WYSIWYG editor?
Comment 25 Martin Renvoize (ashimema) 2024-12-16 06:37:22 UTC
Please look at bug 35267 if your thinking about CSS options
Comment 26 David Cook 2024-12-16 23:34:02 UTC
(In reply to Martin Renvoize (ashimema) from comment #25)
> Please look at bug 35267 if your thinking about CSS options

I'm not planning on adding in the CSS at the moment, but that's definitely something to keep in mind.