More changes in Vanilla 2.8 (coming Feb 6) [update: delayed]
Linc
Admin
I previously announced SSO changes coming in 2.8.
What else is new?
Our new Rich Editor will be the new default for new forum installations. You can manually enable it under Plugins after upgrading. I've now enabled it on this forum for a test drive! It brings automatic link previews, improved content embedding, better accessibility, better shortcut key support, and a more intuitive interface (inline menus instead of a menu bar). It includes full native emoji support and drag-and-drop image uploading.
Our new Keystone theme, based on the new Boilerplate theming system, will be the new default for new forum installations. It will be available under Themes for all forums after upgrading. We'll be swapping our existing theme on this site for it not long after release. It brings native responsiveness to Vanilla for the first time. No more separate mobile theme is needed! It works on all devices at all sizes. We've been experimenting with this for a couple years on our cloud service, and it's time to bring the refined results to everyone.
We're also making a number of security improvements for the 2.8 release. I'll be honest: We got a bit overwhelmed by the response to our HackerOne campaign in 2018, so we have a backlog of mid-level issues we want to get out. High-level reports have been released for 2.6 already, but less urgent improvements will only be available in 2.8. We'd love to be able to backport every single report, but it simply requires a higher level of resources than we have today. So, an important upgrade from a security perspective too.
Under the hood, we continue to make improvements to our code for better performance and setting up future features. We continue to prioritize the transition from framework-based integrations to API-based integrations, and we've started deprecating a large number of "helper" functions that were really just slowing down the product. Addon developers will especially notice the deprecation of the c() and val() functions, among many others. We're not going to break compatibility by removing them for quite some time, but please be on notice to start removing them as you work on code. If you need help with suggestions, start a discussion and we'll be happy to answer.
There should be very few compatibility breaks in this release. What that means is whatever breaks we created we hope are very rare edge cases that few developers if any would notice. If you note an addon you created breaks in the upgrade to 2.8 (which we strongly recommend testing not on your live sites), feel free to request assistance making needed changes by posting relevant errors and information on this forum.
Feel free to post general questions here, but ALWAYS start a new discussion for assistance troubleshooting technical issues.
Comments
Awesome!!! so excited!
I love the rich editor's ability to just throw an image inline. Been waiting for such a feature for about a decade in forum software... about time!
I have a few suggestions for the rich editor before it is finalized.
1) Add the bold/italic/etc options at the bottom, as well as in the little javascript popup. It will be easier for new users of 2.8.x forums to understand how to use them and take advantage of this cool new editor :)
2) The emojis are a bit small on display. It would be nice if they were at least 10% larger in the text.
3) Align the posted images to the left instead of the center by default, or allow the user to chose where it goes.
Nonetheless, i found the editor easy to understand on how to use, and a big improvement over what's out there. Serious hat tip to the team for this.
Add the bold/italic/etc options at the bottom
They appear inline when you highlight text (along with the code and link formatting options). It does raise the barrier for discoverability on first use, but it also makes it easier to use the editor in more contexts because there is less "chrome" around it that needs to be always on.
The emojis are a bit small on display.
This is more a theme issue than an editor issue. I pointed out to the main developer of the editor that links weren't underlining on this site, and he rightly pointed out that too is a theming concern. The editor is mostly about how to build a post, not necessarily what it looks like in the end.
Align the posted images to the left instead of the center by default
I think everyone's going to have a different opinion on this one. Center felt safe because of the high variance of widths. But, you can of course change this with theming. Image alignment is likely on the 'to do' list along with alt text and tables. This is v1, not the end of what we want to accomplish.
I understand this. It's just that it's a bit odd to use overall.
The process of starting or stopping a new bold or italic line is backwards in this system. Usually in a word processor, you hit bold and then start typing, then end the bold. But here, you type, select, and then bold. But if you start typing again, the bold can remain on, so you have to type more, select, then turn the bold off.
It can be many more steps than using something like Microsoft Word.
Putting these icons in the editor itself wouldn't crowd things up excessively. It would speed up discovery and make life easier in some instances.
Emoji size being customizable in themes is a good thing. I understand why the decision to make them small was chosen.
The left/right/center for images is indeed subjective. But mind that the left alignment is the standard. Left alignment with a small image like the one i posted looks better since it doesn't float in space. Left alignment looks good in more instances than center alignment does.
Ah! one last thing. I noticed that if you post an image or do a quote, you have to highlight and hit the delete key to get rid of it. What would be helpful in addition to that is a little 'x' in the top right corner to delete the item. This is much more familiar to users of social media sites, etc. A majority of people use social media sites today ( unfortunately ), so catering to them a bit would be helpful.
As the new Rich Editor doesn't support Markdown any more:
Will there still be an additional Markdown editor, too?
Having Markdown support was the main reason for me to switch to Vanilla Forum!
@Atze:
Linc said: "Our new Rich Editor will be the new default for new forum installations. You can manually enable it under Plugins after upgrading."
A new installation will start with the Rich Editor enabled by default but an existing installation will not be changed. All the plugins you have enabled are still enabled and the input formatter is still the same. So in short: no fear, you can still use markdown
You'll have no problem finding forum software that supports markdown. It seems to be all the rage these days.
It's cool that vanilla can work either way. Writing code that's compatible with two different formats is a convoluted affair.
One thing you should consider is that web forums have lost a significant amount of traffic to sites like facebook which have a short learning curve and rich functionality. The new vanilla editor is a push in the right direction and should be quick to learn, easy to master once the design is sorted.
Unless you have a large amount of users who prefer markdown, i'd highly recommend stepping into the future with 2.8. A good user experience out of the box is the only way forum software today can prevent facebook from sucking up all discussion on the web.
As a developer, I love markdown. As a user I don't love it quite as much. There are certainly some great UX points in a markdown editor that we'd like to bring as improvement to rich editor. The way markdown handles inline code and formatting really powerful. Some inline indicators like the `, *, and ** characters that you have in markdown would go a long way towards improving it.
We have an issue open to add those as well some some other keyboard macros (>, #, ##, ###, !> ```) as well to rich editor, although there are other issues that have had higher priority.
Even if we added these though, the base storage format would not be markdown. The structured JSON data format that rich editor uses makes parsing easier & safer and improves the security of the editor. It also makes embedded rich data in a post trivial.
@neptronix I'd recommend opening issues on the `vanilla/vanilla` repo for the `x` on images. It's a good idea! As far as the having inline element in the bottom bar, I would support a PR that that places them there, if it was optional.
@neptronix said: "Unless you have a large amount of users who prefer markdown, i'd highly recommend stepping into the future with 2.8."
I'd be careful with that suggestion. I felt uneasy when the last editor introduced a format called "WYSIWYG" but it made no real difference to markdown or bbcode or whatever you had preferred. But the Rich Editor comes up with a format like that for three simple words:
[{"insert":"Nested "},{"attributes":{"bold":true},"insert":"for"},{"attributes":{"italic":true,"bold":true},"insert":"m"},{"attributes":{"strike":true,"italic":true,"bold":true},"insert":"at"},{"attributes":{"italic":true,"bold":true},"insert":"t"},{"attributes":{"bold":true},"insert":"ing"},{"insert":" failure\n"}]That is what is written to db for: "Nested form
atting failure"a) This is in total contrast to the goal of Vanilla to favor readable code in favor of overly optimized code.
b) Using a proprietary format for storing messages makes porting so much harder, so if you plan to go away from Vanilla one day or simply want that as an option, I would recommend to stay away from the Rich Editor
The origin is
Yikes. I don't see how a format like that is necessary. I wrote a few WYSIWYG editors and actually just used BBcode to store the data so that it was portable. Even used the IMG tag..
Another WYSIWYG editor i cooked up just used CKEditor and the storage format was just just HTML. There was no ability to embed HTML in the post as readable, but i imagine an escape code would have fixed that.
Internal formatting should be similar to how HTML is structured so that parsing and writing it has as few steps as possible. If str_replace / regex can't handle it, it's way too complex already..
I need a nice rich editor for my forum so bad that i'd just deal with the crazy format if it makes it's way to production.
Yes, that's the problem with markdown. Developers of forum software love it for it's simplicity and speed. Developers spend all day typing and formatting code and markdown makes sense.... to them!
Developers should be aware of how "the normies" use their products. Companies like Microsoft, Facebook, and Google have teams for working out the disconnect between developers and joe the average web surfer. Joe the average web surfer knows what's convenient to use and what isn't, but can't vocalize it very well as he lacks the vocabulary to express what he thinks is wrong or could be improved.
As for me, i started out as a UI designer and crossed the line into programming, so i see both sides. I've butted heads with pretty much every forum software development team over including or even allowing for a rich editor and lost the battle every time. Oh boy, did i duke it out with the maintainers of discourse and phpbb.. 🤣
I will follow through and open some issues. Hopefully i am not considered a pain in the Vanilla team's side as well. I love what you guys are doing and only speak out because i think Vanilla is one of the few platforms that has a chance to stand up against the corporate overlords of today's internet.
One size doesn't fit all when it comes to input mode. It's not just developers who like markdown. I run a math forum and the community there is well adapted to markdown. There, losing markdown would be a big detraction. We like to be able to view the source for a post, study how others format their posts, and copy snippets.
I am in favor of a long term solution that supports backward compatibility with a "plain vanilla" mode of text input. Part of this could involve a plugin that provides a checkbox to select plain text input.
@R_J I'd like to note this is not our own proprietary format. It's quill-delta.
If you wish to take your data somewhere else you can always render to HTML first (a simple script to generate these would be sufficient, although we are planning to keep rendered versions cached in the DB in the future once we have a good method to do this for sites with 100m+ comments). At that point it would be no different than a using the `HTML` or `WYSIWYG` formats from a data portability perspective (or any of our other formats that render to HTML).
@charrondev I had no doubt that it is tied to the quill editor and yes, I see the advantages, though I wouldn't count added security to it. The renderer is the weak spot, not the database.
The advantages I see, when used, are those that a document oriented database would bring to a social network. But Vanilla uses MySQL, not MongoDB. Therefore those possible advantages couldn't be used. Storing data in a document format into a SQL database is somewhat strange...
Yes, it is human readable, but compared to HTML, BBCode or MarkDown it falls behind, kindly spoken. That's another reason why I think it doesn't fit to Vanilla.
But the decision is made, the editor is implemented, it is not said that this format will stay forever and the most important thing is the user experience, which already is great - good work!
I'm most excited for Keystone! It's the culmination of years of theming work and best practices. I've wanted a new responsive default them for Vanilla since I made our first responsive themes for cloud clients, and it's amazing to see it come to fruition.
Thanks @all for the info that I will be able to still use the Markdown editor.
Is it possible to see a Keystone demo somewhere?
You would have to setup a test forum by yourself to see it.
Maybe this description still works if you do not want to set up a local copy
I can setup a test forum, but where can I find Vanilla 2.8?
Vanillas sources are on GitHub and you can either try the master branch or one of the 2.8 development branches: https://github.com/vanilla/vanilla/tree/release/2.8.dev.6/build
Oh My God.... finally from the rich editor, Vanilla made Flarum look old with links preview embedded feature.. :)
I test some links, all embedded perfectly just like Facebook OpenGraph.
I think, I will migrate some of my sites to Vanilla