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:

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:

@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:

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:

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:

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.

 

[Hoffi]

The new look is great and fits.

 

[Chris D]

There was nothing wrong with the old look, but this looks great. Well done Kier and Mike.

 

[Mike]

Thank @Kier

 

[Chris D]

Thank you @Kier

 

[Jeremy]

I personally didn't mind the old one, but this now forces users to update it on their sites. Oh we'll, looks good and I don't mind it! Good job, Kier!

 

[tyteen4a03]

I love you @Kier . <3

 

[DSF]

The editor has a wonderfull default style now.

 

[CTXMedia]

The fade-in-on-focus behaviour isn't something I particularly like - presumably it can easily be changed?

 

[Lisa]

Original didn't bother me, 1.2 new version didn't bother me... latest update doesn't bother me. So long as it works, I'm happy

 

[Paul B]

but this now forces users to update it on their sites.

It's using Style Properties so in most cases it won't require any custom styling as it will follow the colour palette.

Of course, it can still be customised should you want to do so.

 

[cclaerhout]

The fade-in/fade-out are nice.

 

[Kier]

The fade-in-on-focus behaviour isn't something I particularly like - presumably it can easily be changed?

It's a very simple change that can be added to extra.css:

.redactor_toolbar .redactor_btn_group ul
{
opacity: 1;
filter: alpha(opacity='100');
}

Will disable the faded-out behaviour completely.

 

[CTXMedia]

It's a very simple change that can be added to extra.css:

.redactor_toolbar .redactor_btn_group ul
{
opacity: 1;
filter: alpha(opacity='100');
}

Will disable the faded-out behaviour completely.

Excellent!! Thanks.

 

[Lee]

Wow, looks like a totally different editor again. Impressed.

Was it just CSS changes that allowed you to style this or were there image edits also?

 

[xf_phantom]

It's a very simple change that can be added to extra.css:

.redactor_toolbar .redactor_btn_group ul
{
opacity: 1;
filter: alpha(opacity='100');
}

Will disable the faded-out behaviour completely.

That's a perfect example for my question which i wanted to ask once 1.2 is public available.

Would it be better to add the css changes to the css direct inside the templates (e.g. in this case editor_ui.css) and to keep the extra.css only for global changes?

 

[Chris D]

It's a good question, @xf_phantom.

For a long time we've been so scared of making template edits, but it seems that with the change conflict resolution and diff/merge functionality that actually it makes more sense now to make CSS changes in the applicable templates. And like you say, just use EXTRA.css for global changes.

 

[Paul B]

If you edit the css template and it is updated with the next release, you will have to do a diff compare and merge.

If it is in EXTRA.css you won't have to do anything.

 

[Chris D]

@Kier

@Clickfinity just made a valid point. The editor fades down, but the smiley chooser doesn't. Perhaps the opacity should apply to the smiley area too, just in case it is left open for any reason and you click away from the editor.

 

[Chris D]

That is of course true regarding EXTRA.css.

But before we never had a choice. Now we do.

If you've got thousands of lines of customisations, like some people have, you might find that only 20% of those customisations apply to the current page. The other 80% is potentially just unnecessary code being processed by the browser.

In this day and age and with the way that browsers cache things, I guess the difference is negligible. But if you're super performance conscious, then directly modifying the specific CSS templates may now be worth the extra effort of doing a diff/merge.

 

[Jeremy]

It's using Style Properties so in most cases it won't require any custom styling as it will follow the colour palette.

Of course, it can still be customised should you want to do so.

That's what I figured, which is why I'm not too worried about people having to customize it / update it.