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.
I wonder if this is still doable with the new TT syntax vs the more simple placeholders we had before.
We're interested in this as well.
(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.
Closing this due to age. I'm unlikely to work on it again.
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.
Adding +1 to this.
(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.
Funny enough I just had a library ask for this...
(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. After a bit of reading, it looks like we could use TinyMCE's "protect" configuration option to allow both the TT syntax and the original <<>> syntax to be preserved (and not HTML entity encoded).
Since TinyMCE already uses an iframe for the WYSIWYG, we shouldn't need to do anything extra with iframes or shadow DOM... We could also use on of TinyMCE's CSS configuration options to include NoticeCSS...
(In reply to David Cook from comment #9) > After a bit of reading, it looks like we could use TinyMCE's "protect" > configuration option to allow both the TT syntax and the original <<>> > syntax to be preserved (and not HTML entity encoded). Ok, the "protect" means they're not handled by the TinyMCE at all, so they don't appear in the editor either. We could workaround that by providing both a source view and a HTML view, so that you could add your notice syntax and then sort of "preview" it, or add your HTML and then view what that's like in the source... Although technically the HTML view would still not be the same as a "rendered" view. -- TinyMCE also meddles heavily with pre-existing whitespace which can be important with Template::Toolkit in more complex notices. Also, you could enter <<whatever.whatever>> or [% stuff => stuff %] into the editor still and they would appear with the escaped HTML. That's not good.
I'm not a TinyMCE expert, so my guess is that there is code that could be written to make this work, but I'm guessing it would be a fair bit of code.
Actually, at Kohacon2024, maybe what we discussed was just improved preview options... those would be much more doable. -- With the WYSIWYG... perhaps we could do a plugin that lets you insert template syntax into the notice without it getting entity escaped. That might not be a terrible workaround... But we'd also need some code to prevent entity escaping at init/load time, which would be more difficult. (What we could do is pre-process, extract our notice syntax and replace with a safe magical tokens like a random custom element like <24t0824ht> or {{24t0824ht}}, init/load TinyMCE, and then replace those safe tokens with our notice syntax extractions programmatically. It would be hacky, but it could probably work.) The WYWISYG would make adding HTML more user-friendly but adding Koha notice syntax more difficult. -- But in any case... this would take a lot of experimenting and even then a TinyMCE upgrade could break it. More thinking to do here...
I tried out my ideas of extracting the problematic tokens and replacing with a safe token, letting TinyMCE init, and then replacing the safe tokens with the problematic tokens, but there doesn't seem to be a simple supported way of doing that without re-processing the content. -- The best bet might be to have the separate tabs. Say a CodeMirror on one tab, and a TinyMCE on another tab, and keep them synchronized, and use "protect" to stop TinyMCE from interfering with Template::Toolkit and <<>> notice syntax. That said... that's still going to be super error-prone, as TinyMCE is a pretty blunt instrument, which loves to mangle content. -- I vaguely recall someone wanting to support Mustache syntax instead of Template::Toolkit in the notices. But.. I think TinyMCE's messing with formatting would still be problematic. -- I don't know. The more I look at this, the more impossible it seems. We could do nicer previews, but I don't know about using a WYSIWYG editor... at least not with the complexity of notice templates we support.
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.
I really like grape.js though it would be a huge process. It would be helpful for the previewing as well.
(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 <<borrowers.firstname>> 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' => '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.
Hmm... take a look at the premium TinyMCE plugin called "Merge Tags". That sounds interesting... I just tried out its CodePen... and I couldn't get <<Client.Name>> to work but << Client.Name >> looks pretty good in the TinyMCE visual editor. That said, in the source code editor it looks like << Client.Name >> And [%Client.Name => 'stuff' %] gets turned into [%Client.Name => 'stuff' %] Maybe it does something fancy at load/save time, but I doubt it.
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!
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.
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.