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.
 
I prefer storing server-side. At least it's browser-independent then, plus, what if someone was using the browser of a shared computer/public workstation?
 
I prefer storing server-side. At least it's browser-independent then, plus, what if someone was using the browser of a shared computer/public workstation?
I'm not sure the private mode is working in this situation but you can still set an expiration delay (see the setTTL function of the previous mentioned script). Now I think today the risk is higher than someone scans the wifi datas than to inspect the browser storage memory, so unless you use an encrypted vpn...
 
I'm not sure the private mode is working in this situation but you can still set an expiration delay (see the setTTL function of the previous mentioned script). Now I think today the risk is higher than someone scans the wifi datas than to inspect the browser storage memory, so unless you use an encrypted vpn...


A shared computer doesn't have to imply that it's connected via wireless.

Visiting a website without a VPN doesn't mean that the connection cannot be secure (an increasing number of websites offer HTTPS).

Making the storage expire defeats the purpose of saving drafts. Besides, what would be the expiration value to make it more secure? Private mode? It just uses a separate storage from the non-private mode, but data in local storage would still reside unencrypted.

Really, I don't see any good reason for not using server-side storage if xF is able to provide it. The argument that it would require more queries is moot compared to all the other functionality the software already offers server-side.
 
Just vitriol again, probably AlexT.

For so many posts to arise as a result of a new feature using server side database storage instead of local storage in an application where the other 99.9% of the application runs in server side storage is just ridiculous.

I'm sure there's people here capable of making it into a locally stored solution and bypassing the database if they feel that is a requirement. For the most part, there isn't any huge benefit.

Mike's point about it storing more than just the message is relevant too. Sounds to me like multiple pieces of content can be stored per draft so it seems like server storage makes much more sense here.
 
Another argument (beside the aforementioned incompatibility and security issues) for server-side: What if I switch computers/browsers? Locally stored data is only, well, stored locally. It is of no use when you are a flexible user who wants to take advantage of multiple computers/devices.
 
A shared computer doesn't have to imply that it's connected via wireless.

Visiting a website without a VPN doesn't mean that the connection cannot be secure (an increasing number of websites offer HTTPS).

Making the storage expire defeats the purpose of saving drafts. Besides, what would be the expiration value to make it more secure? Private mode? It just uses a separate storage from the non-private mode, but data in local storage would still reside unencrypted.

Really, I don't see any good reason for not using server-side storage if xF is able to provide it. The argument that it would require more queries is moot compared to all the other functionality the software already offers server-side.
What I didn't understand in your previous argument to use on public areas is how the datas could be compromised. That's why I thought you were talking about wifi secure problems. For the delay, I have no idea. For the private mode, I mean I'm not sure it's using a specific area and it can be erased when going back to the normal mode. For the the queries, it's just that the autosave function can be often refreshed. If I don't make a mistake the first shoutbox on vBulletin was using a database solution and was quite intensive for the server. I don't know how is working the Luke Shoutbox, but this time nobody complaining about the server resource. So if there's a way to avoid to use too much queries and this option can be configured, I see no problem with it. All I said is that since a post is only few ko, until now I had no problem with the local storage solution.

Just vitriol again, probably AlexT.
Something to say Chris? Yes I've made some critics but since some problems with Redactors that have been confirmed by the developers of Redactor themselves, I think they should be mentioned and talked in public. If you've got a better source, feel free to share. I can see an official reply because I wasn't aware the css can be linked to a template, but I still can't see any reply on the specific points I've raised. So please keep the "vitriol" bottle on the shelf. And if your "again" refers to the earthquake and the bath, that was just irony.
 
For the the queries, it's just that the autosave function can be often refreshed. If I don't make a mistake the first shoutbox on vBulletin was using a database solution and was quite intensive for the server.


I see. That shoutbox was rather "dumb" I believe and it ran queries on a defined schedule, no matter whether changes occurred or not.

A better solution would be to use Javascript to monitor the state of the editor form and detect when changes occur (when its state is "dirtied"). Only when changes to the form take place, trigger an event, which will then allow for the option to autosave the content (combined with a minimum time interval).

Check out this Drupal plugin which does this: http://drupal.org/project/autosave
 
20 pages to talk about an editor and auto-saving??

This editor looks way better than the current one, good job. Personally, I couldn't give a rats where the drafts are saved as long as they a) work and b) work well.
 
Mike, would it be possible to use the new editor for creating page from the forum, without going through the ACP?
 
I think a full version of the editor in the Pages system in the ACP would be useful. Would be good for people who wanted to quickly produce nice looking content. I might look at doing that, myself. :)
 
Add-ons already exist that do that, Lee, so I imagine that actually they'd still work.

I'm just guessing here, but I imagine the way the rich text editor is loaded on the page and set up hasn't changed much, if at all, so if someone used the default methods of putting the editor in an Admin CP page then that will probably still work.

Just a heads up :)
 
Thanks for the swift reply.
That's too bad. The redactor table function is awesome and I have thousands of tables on my site.
 
I'd prefer a fully functional editor, but refactor can be instantiated post load over a post. I'd prefer that. (y).
 
Top Bottom