XF 1.2 A New Editor and Much Much More

I've never hidden my frustrations with XF 1.1's editor (which is based on TinyMCE). In 1.2, we have entirely removed the existing editor and replaced it with a new one based on Redactor:
ss-2013-05-17_12-21-49.webp


So obviously this looks quite a bit different--and I know plenty of people didn't like the 1.1 editor look--but the functionality is there. So what advantages do we have? Well there are various ones:
  • Much lighter code and faster to load. Redactor depends on jQuery and benefits from that.
  • When pasting, most formatting is removed (though some is kept). However, if you're pasting from one XenForo editor to another (or within the same one), all formatting is maintained.
  • White space is maintained for code tags when pasting from Webkit. This was an annoyance for a number of people here, myself included. :)
  • The overlays are now consistent with overlays elsewhere in XF.
  • Generally, from my perspective, the code is much more adaptable to our needs.
  • A bunch of other things I'm going to detail below...
For the most part, the editor simply shouldn't get in your way so in a sense, you shouldn't actually see much different for the average post.

How about some other bigger changes?

Pasting images
If you use Chrome or Firefox and have an image in your clipboard, you can simply paste it into the editor. It will automatically be uploaded as an attachment if possible. If the upload is successful, this works exactly like uploading an image and then clicking the "full image" button.

Note that in Chrome, the image data must be in your clipboard (such as from pressing print screen). In Firefox, you can either have image data or you can copy a file that's an image and paste that.

Drag and drop uploading
Provided your browser supports it, you can now drag files into the editor to upload them:
ss-2013-05-17_12-37-47.webp


@User tagging
While not directly related to the editor change, this is probably the best time to mention it. You can use @Mike style syntax to tag users in a post:
ss-2013-05-17_12-39-42.webp

Tagged users will receive an alert when they're tagged.

You can obviously turn off tag alerts, but as an admin, you can also limit the maximum users that can be tagged per message as a permission. (So you could disable it for registered members and only allow premium members to tag, for example.)

Alternative smilie inserting approach
The smilie dropdown really didn't work well with a lot of smilies. Clicking the :) button will now do this:
ss-2013-05-17_12-42-10.webp

This is now making a call to get the smilies and lays them out with a template. This opens up the possibility for more organization options (though nothing has changed as of this message).

Auto save drafts
While you are typing a message, every X seconds (currently 60), a draft of your message will be saved. If you reload the page later, your message will be automatically re-shown. Drafts will be automatically pruned over time.
Each draft is associated with a particular piece of content, such as a thread, forum, or conversations. A draft reply that you start working on in thread 1 will not be shown to thread 2 and so forth.

Display if messages have been posted since you started your message
Tied into the auto-saving, when you're writing a reply to a thread, we will check to see if any new messages and display a note if there are. You can then display those new posts without reloading the page.




Oh yeah, one more thing on the editor, it's fully responsive:
ss-2013-05-17_12-49-20.webp

That should be a hint... :)



So, when are we going to see this all? Well, we're hoping to have 1.2 running here on XenForo.com in early June. The initial beta release will follow, based on how well the time on 1.2 goes. The final release of 1.2 would be wholly dependent on how the beta process goes.
 
How long are drafts saved for (i.e when are they pruned)?

For instance are they saved for the duration of the visit or a set amount of hours/days?
 
I believe they are stored in the database so I imagine there is a new Cron Entry that does the pruning.

If that is the case, then you will be able to configure the Cron Entry to run as often (or as infrequently) as you like.
 
how about AUTOMATIC IMAGE RESIZING?

Much needed IMHO. Too many users complain that they can't upload their 3000px x 2000px 5MB images, and are not equipped (or are too ignorant--we have those also) to do so. I would hope the editor had it built in but likely not. So many offer uploading and cropping (even look at Gravatar), and this would be the only forum software I know of that would do it IF it were a new feature.

Even my personal preference: if I have to resize before uploading, I don't even bother anymore.
 
@mike

You said that pasted text will have some formatting stripped. Does this include text colouring so that text doesnt become invisible in dark themes?

Just the ability to turn off colored text would be helpful--clueless members don't "get it" that their posts disappear in differently colored themes.
 
A question about the tagging feature I only saw partially addressed--will tagged users show up in the alert system? We use that in one forum to get the attention of others on the staff when needed.
 
I believe they are stored in the database so I imagine there is a new Cron Entry that does the pruning.

If that is the case, then you will be able to configure the Cron Entry to run as often (or as infrequently) as you like.

Seems like this would be a good use case for HTML5 Local Storage. No server-side DB or cron schedules required, easy to implement. I've used this on a couple of projects and it's pretty magical :)
 
Admittedly that would work if you have a browser that supports it.

But equally I don't see any benefit of doing it that way over storing it in the database.
 
Seems like this would be a good use case for HTML5 Local Storage. No server-side DB or cron schedules required, easy to implement. I've used this on a couple of projects and it's pretty magical :)

You are also at the whims of user storage. I remember being able to set a limit on the size of storage that websites would get. If I set it low enough, the drafts feature could be crippled.
 
Admittedly that would work if you have a browser that supports it.

But equally I don't see any benefit of doing it that way over storing it in the database.
It works on everything except IE7 and less. ;)


Plenty of benefits: no network traffic or server requests, no server-side logic or storage required, instantly reloads when you return to resume, work is still saved if your network has dropped (one potential reason why you may have needed a restore point to begin with), etc. A few dashes of JS and you're all sorted out.
 
You are also at the whims of user storage. I remember being able to set a limit on the size of storage that websites would get. If I set it low enough, the drafts feature could be crippled.

That's fairly edge case, and you could show a friendly warning if they've disabled or crippled their local settings for whatever reason.
 
Of course, but I wasn't aware that carrying message drafts across multiple devices and browsers was the goal here. I assumed it was much more basic (browser crashed, network dropped, etc). :)
 
Of course, but I wasn't aware that carrying message drafts across multiple devices and browsers was the goal here. I assumed it was much more basic (browser crashed, network dropped, etc). :)
And we would want it to store a draft regardless of which browser/device a person was using.
 
There are various additional options that come with storing it on the server (as it can store many more things that just the message and restoring that on reload would be a lot simpler with basic PHP/HTML changes rather than more extensive JS work).

Will attachments work in the drafts too? Or will they be removed via cronjob (like it's happening in xf <= 1.2)
The code is there to allow it, but it's not reloading the previous attachments right now. They would still be removed via cronjob though.
 
As TrevC said, avoiding to use the database to prevent unnecessary requests is better. Last years browsers have improved, so unless you have dropped your tablets while you were typing a novel in your bath, or you're writing your last words during an earthquake but don't have the time to press "post reply", or even worse, you're using an old version of IE, using the database is really not necessary. There's a cross browser javascript solution called "jStorage" that is very light. I've implemented in the addon QuoteME. It seems to work fine. Recent browsers storage capacity is 5 Mo, so it's enough. The last two years I've been using the default tinymce javascript solution to avoid to loose text content. I had no problem and my posts were not short.
 
Back
Top Bottom