module Textarea Preview

[owzim]

This module adds a preview and zoom button to InputfieldTextarea for live previewing the content after being formatted by the text formatters assigned to that specific field.

It's pretty alpha still but it already works.

For now I was only playing with the Parsedown formatter, but it should work with every other formatter as well, even with Hanna Code, not sure though, haven't tested it. It's restricted to regular textareas, meaning TinyMCE et al are not supported yet, because they need specific change listeners. Will look into it though.

The result is fetched via ajax from a process page, the default style sheet contains some Github-like styles but the style sheet is configurable, see module settings.

Github: https://github.com/owzim/ProcessTextareaPreview

Open for suggestions

[Martijn Geerts]

Wow this is great !

What about instructions how to use parsedown/markdown ? 

[owzim]

What about instructions how to use parsedown/markdown ? 

The module is not limited to markdown/parsedown, you can use any formatter. I just used it as an example.

Markdown: http://daringfireball.net/projects/markdown/

Parsedown: http://parsedown.org/

Parsedown formatter: https://processwire.com/talk/topic/6576-module-textformatterparsedown/

[apeisa]

It opens lots of interesting possibilities (thinking especially Hanna codes and the likes).

Oh, and seems to be very smooth implementation!

[adrian]

Looks brilliant - thank you!

[Beluga]

This module is "alpha" all right.. as in "alpha wolf"!

[Soma]

Great! This opens new possibilities to actually use markdown and alike. I was thinking a some time about having something like this, looks very nice.

[owzim]

Hi girls and boys, I just wanted to write some more details on this module, how it's working, why it's not implemented differently, downsides, how it could be improved and so on.

Why

Just recently I had an interesting chat with @marcus on how ProcessWire lacks of some markdown capabilities, for the editor in particular. Of course there is the markdown Textformatter (and now Parsedown) but the actual usability of entering Markdown was not yet taken care of in an extend I wished for.

The Ghost blog system ships with pre-installed side-by-side Markdown preview capabilities, the Atom editor by Github also has this feature built right in. All in all, Markdown seems to be on the verge, when it comes to have clearly structured text data in Databases and especially in CMSs or blog systems. The folks at Perch CMS even make it one of their core mantras to never ever store any HTML in the DB. RTEs like TinyMCE or CK Editor have their places but as we all know, editor tend to wreck all our carefully structured markup and CSS with their text pasted from Word and the like.

Why not client side parsing, upside of server side parsing

The initial idea was to merely preview Markdown, but then it came to me that any Texformatter should be able to be previewed, so client side parsing was out of the question pretty early on. Also a JS Markdown parsing implementation could be inconsistent with the actual server side parsing.

Downside of server side parsing

The major downside obviously is that any text data has to be sent to the server and back so latency is inevitable. Also, you would not want to send data back and forth on every single change immediately (that's why data is send at most once per second, or not at all if no changes are taking place).

Upside of current implementation with Ajax, downside of iFrame implementation

Since the parsed text is loaded via Ajax and just replaced when the request is finished flickering of the refreshing text is pretty minimal. You cannot prevent images from flickering since they will be re-rendered every time the parsed text is injected. If it would be implemented with an iFrame the thing would be refreshed and flickering would be dominant and annoying.

Downside of current implementation with Ajax, upside of iFrame implementation

Clashing of CSS rules. If you want to display the elements properly you either have to work with many !important statements or make the rules overly specific with lengthy selectors, otherwise your current admin theme could wreck the display. With an iFrame all the styles are scoped properly, and you could even use styles that are actually used on the site, so the preview would be way more accurate.

My questions

I'd love to hear some suggestions on how to tackle the listed downsides, or if those should even be considered downsides. Perhaps those are out of scope of this module. The scope could remain to merely preview basic markup, so the editor has an idea how the text would turn out, focused on Textfomatters like Markdown or Textile, Autolinker and so on (so a text-focused scope). Since there already is a great module by Nico which aims at full blown previews.

If so, the default hacky overwrite styles could stay as they are (could use some polish) and custom styles could be thrown out as a feature.

[netcarver]

@owzim

I really like the way you are developing this (and other) ideas for PW - really neat.

You definitely need server-side parsing - there are too many potential differences in the JS parsers from the server side PHP parsers (at least there is for Textile.) I'd also suggest making the refresh time configurable - I think that every second may be too much for some markup languages (I speak from experience with Textile) as they use a lot of regular expressions.

Is there any way you could get the minimal flicker + correct styling by having an iframe that uses Ajax for the updates?

[owzim]

@netcarver

I'd also suggest making the refresh time configurable - I think that every second may be too much for some markup languages (I speak from experience with Textile) as they use a lot of regular expressions.

Thought of that too, will implement that. Though it's worth noting that the refresh is not happening constantly but only when content changes in the textarea, and then at most once per second (it's implemented with underscore.js's toggle method).

Is there any way you could get the minimal flicker + correct styling by having an iframe that uses Ajax for the updates?

Thought of that too at one point. The thing is that the textarea content is passed via post parameter, so if the ajax refreshing is taking place within the iFrame it somehow has to know where to get the data from. Saving a temporary db value is too much I think. Could be done with sessions though. JS saves the TA content via ajax into a session variable with the field name and page id as the key, and the iFrame retrieves that session value within. But I don't how performant that is. Perhaps you had something different in mind?

Edit - Some other things to consider with the iFrame approach: Since the iFrame doesn't really know if content has changed until it has fetched the new data, there would have to be a constant fetching within. How to partially surpass it: another session var, which will be set to changed: true from the inputfield ajax, then the iFrame ajax fetches that value, refreshes the HTML content and sets the var to changed: false, so no refreshing is taking place until that var is set to true again. I think that's a pretty important UX issue because a constant refresh would mess with the scrolling, so if the user updates the content and it's long enough that they (see the non-sexist neutral they here? ) have to scroll, a refresh would reset the scrolling position, yuck. This is the part where the whole implementation gets a little less elegant ... but nonetheless should be possible.

Also: I'd love to add the js for within the iFrame like in other regular admin/process pages, for now that's not possible, because I die() out the content, see https://github.com/owzim/ProcessTextareaPreview/blob/master/ProcessTextareaPreview.module#L112-L130

Is there another way to prevent the whole admin UI to show up without loosing JS and CSS? Nevermind, I can of course add the script and css links manually.

[owzim]

New version available:

• It now uses an iframe implementation, not as easy as it sounds, because the text area and the iframe somehow need to share the data. At first I went for the session thing (see above), but then realized there would be too many server requests going on. Then I went with cookies, nah 4096 byte limit .. so I now use local storage with a cookie fallback.
• So now the styles are scoped properly, no clashing of rules.
• The refresh interval is now configurable.
• Major code refactoring under the hood and many additions, little optimizations, not so elegant anymore, but whaaateva.
• It now comes with another optional theme Solarized Dark, it's not as pretty as I thought, will look for better default ones
• Key strokes of space and enter are ignored, so no unnecessary refreshes are taking place.
• When updated content is injected (and overflows the browser window), it does not scroll to to the top, but stays at the current position.

Summary how it now works (for those interested):

1. The text area is watched for changes, when it changes, the text is sent to the server, converted via text formatters.
2. a local storage item with a unique key of that field and the respective page is set to true
3. meanwhile within the iframe, JS is polling for that value very frequently (no server requests are taking place here), if it's true the text is injected (and only then to prevent constant flickering), the value is set to false
4. so the iframe is only injecting when changes happen in the text area

Roadmap:

I would love to make the config on a per field basis, but since this module is not an input field but merely hooks into the rendering I am not sure how to, will look into that.

Oh, and it's on the module directory now too: http://modules.processwire.com/modules/process-textarea-preview/

Cheers!

Edited June 11, 2014 by owzim

[netcarver]

Hello Christian,

Just noticed that this module doesn't seem to play nicely with Hanna Code. If I try going into the Hanna Code page when this is installed I end up with a fairly blank page. Disabling your module brings the Hanna Code interface back to life.

[owzim]

@netcarver, I haven't investigated it yet. I know the module is messing with a lot of things, because it is not an own field but just a bunch of hooks. I'll make a separate Inputfield, or fieldtype out of it out of it, this will fix much and makes it also configurable. But I got little time at the moment.

[floriank]

Hey, this module does not work with Hanna Code as a text formatter right? Even though Hanna Code is set as text formatter for my textarea field it’s still outputting [[button]] etc. Parsedown however works.

[johnstephens]

This is just a report: When I have this module installed with FormBuilder, I can't open entries created by the latter module, thus. When I disable ProcessTextareaPreview, the error disappears.

Thanks for creating this beautiful plugin! No emergency here: I just wanted to alert the author. Cheers!

[owzim]

Hey,

I wonder if there is any interest, that this module is developed any further and that I fix the mentioned issues. It seems like, with things like front-end editing and/or ProDrafts it's kind of obsolete.