Matt Finger

Sure does!

So the "Insert image from URL" button has been removed in 5, and there is a global setting which can prevent this behavior. And, yes, the "embed external content" restriction also prevents external image URIs from being converted to images.

These are on our list but will likely not make it in the initial Community 5 release. Tables sound simple enough, but when you factor everything that goes into delivering a powerful table system - background color, border color, border width, what type of content can go in a cell, what to do about overflow, actions applying to the entire row/column etc - and make it not only powerful but easy to use and reliable, the dev time really adds up. 🤔 😉

You currently have to manually click the embed button in the link menu, but this only applies to the new custom iframes. For the predefined embed types, e.g. other topics, youtube, X, og embeds, it will automatically convert to an iframe.

We recently announced the new Invision Community 5 editor which adds many new exciting features such as semantically correct header tags, custom boxes and more. As the new editor is a leap forward in technology, some legacy features had to be left behind. We received a lot of messages about these changes, and have created new tools based on that feedback to ensure you still have the tools you need. The new features are based around restricting some high level editor functionality for specific member groups and enabling an easy way to add custom embeds. Permission Levels Invision Community 5 puts a lot of new tools in the editor, including header tags, boxes and positioning tools. These are useful features, but perhaps you do not want your members changing the semantic structure of the page by adding H1 tags. Or maybe you don't want them being able to add custom boxes with colors. Based on this feedback, we have introduced a permission levels system. At the heart of the system lies three editor permission levels: Minimal, Standard and Advanced. Specific editor features are assigned to one or more levels. For example, you may only want header tags and content boxes to be for the 'advanced' permission level which only administrators can use. These permission levels are configurable via the Admin Control Panel. When is Each Restriction Level Used? Now that we have set up the permission levels, we need to apply them to member groups. We do this by simplying heading over to the Member Groups section of the Admin Control Panel. In the "Content" section of that form, there are two new options: Default Editor Restriction Level: This is the restriction level the group uses by default, for example in Forum Topics and Blog Posts. Editor Restriction Level for Comments: This is the level used for Comments (including Topic Replies) throughout the Community. When a member has multiple groups, they will use the most permissible editor setting out of all groups. Custom Embeds In response to news that the ability to toggle into 'source mode' and directly edit the underlying structure of the editor document was not implemented because editor technology has moved on, many people told us they used that feature to add custom iframes from specific services they use. We understood the need for custom embeds, and we've added the option to create iframe elements with any whitelisted URL from a link. CleanShot 2024-06-20 at 15.49.43.mp4 Additionally, iframes created this way have configurable height and width so you can resize to your liking This feature has two editor permissions: "Can Embed External Content," and "Can Convert Links to iframes". Adding iframes into a post can potentially be a security issue, so strong controls are needed to ensure there isn't abuse of this system. The editor will only allow links to be converted to iframes if the domain has been whitelisted. The whitelist exists in the new tab, Admin Control Panel > System > Posting & Editor > Embeds. The feature can also be entirely disabled from here. That wraps up this round of changes based on your comments. We hope that you enjoy this update to our Invision Community 5 editor and we always appreciate your feedback. View full blog entry

I concur. Again, if this can be reproduced let us know so hopefully we can sort it out but otherwise unfortunately there isn't anything we can do.

Have you tried pasting the same URL as the users experiencing the issue, ideally using a test account that has the same groups/permissions? We do some very light processing on pasted URLs to automatically convert them into links or, when applicable, trigger an embed or attachment upload. If a JS error is thrown, or the embed validation somehow returns an empty embed it could cause this, though unfortunately without being able to reproduce there isn't much we can do. It's also possible a third party IC App or CKEditor Plugin could be interfering.

That will be possible without source mode using editor content boxes and the new page builder, stay tuned as we are wrapping that up soon; it'd take some custom CSS to get the button and heading exactly the same, but nothing crazy. There will also be custom HTML blocks still so you can use custom HTML in those areas for cases where an editor plugin is overkill. No, but thanks to the theme magic of relative colors, you shouldn't need to. It will use the same background as the wrapping container.

Yes, there is a clear formatting button, but more importantly the content is stored according to a predefined schema - this means that there will never be random styles or lines that are unexpected, even after pasting. Though you cannot have "whatever wherever however in the source", this becomes a big advantage for everyday users since the entire content state is achievable through the UI.

Of course!

Not to contradict Marc, but there will be a global Table of Contents widget for which you can apply anchors to headings and box titles (stay tuned for more page builder updates 🙂) Yes, in fact in a few minutes I was able to create a plugin for KBD elements We're still getting docs together so please be patient but the development of supported buttons and content types is much more streamlined than in cke4.

The issue with a region above and below block nodes is everything would be very spaced out, there isn't really much room between the top of the editor's content and the toolbar. You could say "space it out more", but then you'll either end up with really spaced content or an editor that isn't a wysiwyg. The arrows on the other hand, I'll admit that new users might not immediately recognize what they're for, but when they are in a situation needing a new line it becomes obvious. Also, you can reposition the buttons on your own site with CSS to create these invisible regions if you really want, but we just found it more clunky than arrows in most cases.

You assume correctly Pretty much every common modern language is supported in IC5, almost 40 of them in total, though inline code doesn't support language highlighting. The spoilers will likely be auto-updated in the background after upgrade, however users won't know the difference as they are styled to look identical to expandable boxes. Also, the editor will recognize a spoiler and convert it to an expandable box when you open and edit content. On large sites with millions of posts, a bulk conversion during upgrade would just take way too long.

The short answer is no, but the full answer is yes (in theory) but you'll have to manually build them and then roll into an IPS Application to make sure the content type is supported on the back end. We'll address extending the editor in depth in a future blog so stay tuned if that's your thing!

I can say supporting multiple editor frameworks is not something we're likely to consider. Editors today are not copy/paste bundles, and there is a lot of stuff we built on top of the core frameworks. Thousands of lines of code which use the Tiptap and Prosemirror APIs would need to be translated, then all the edge cases would need to be sorted out. After migrating from CKEditor4 to CKEditor5, then from CKEditor5 to Tiptap, I can definitively say from experience that is a lot of work, and there are always differences in how features are actually implemented. And that's not even covering extensions which would be a pain to make compatible. This is why sticking to one editor is the way to go to provide you and all our customers top notch features. We won't lose days, or potentially even weeks, going back and forth to double implement and test features as they come out, and can guarantee things will "work". As a side note, I actually do remember Lexical from when we initially compared editors. We didn't find it to be a great option because it's very new: they are still only on version 0.15.0. Also, not too long before Lexical came out, Facebook first created Draft.js, then abandoned it when it was only a couple years old before version 1 ever came out. In fact, I think a lot of the docs that are now available for Lexical didn't even exist 6 months back.

Yes, we'll do a separate blog post, probably in the Developer Blog, but we created an editor plugin system with the ability to add and position new toolbar buttons.

We're discussing this internally still but there should be a way to restrict buttons by user and editor location in the final release That would be managed by the theme's CSS. We ended up keeping the background color the same once because a slightly darker/lighter color tended to look off in at least a few box color and dark/light mode combinations Probably not, but only because markdown code itself is not technically supported, rather we've included markdown style shortcuts. For example, if I pasted in "**some bold text**", it won't get converted to bold, it's only going to be converted after being typed out Yes! It uses color-mix and other CSS tricks to consistently adapt to the different theme colors.

Invision Community 5 has a brand new editing experience powered by a lightweight, fast React text editor built for mobile and modern browsers. The venerable CKEditor v4 at the core of our current editor is starting to show its age, so we wanted a clean slate with Invision Community v5 with an editor that was optimized for mobile use, easily extensible and had a feature set that would take us into the next era of Invision Community and beyond. The obvious choice was to consider the latest version of CKEditor, but it didn't fit our needs as it wasn't easily extensible, external plug-ins would no longer be possible, and its large footprint would affect page speed scores and be painful to use with a mobile connection. After a long search, we settled on Tiptap as the base for our editor. Written in React, loaded in chunks when needed for optimal performance and with many APIs and extensibility options, it was the perfect fit. Aside from the technical improvements, the editor offers new tools and a great base for writing our own plugins. I'll walk you through the main features throughout this blog. If you want a more technical deep dive, then please see my development blog. The Toolbar The toolbar has been redesigned to put the most commonly used styles first, with the least used styles and functions into an ellipses menu. The new paragraph menu contains the header styles, as well as the code block. The plus menu adds lists, boxes and quotes. The benefit of this new compact menu is that it displays just the same on mobile. Currently, there are different editor styles for desktops, tablets and mobiles with some style buttons removed to save space. With Invision Community 5, this is no longer the case. Even the smallest display gets all the functionality. mobile-toolbar.mp4 Emojis & Icons Emojis have become a great way to embellish writing and express emotion. The new emoji picker has been modernized with larger emojis and tooltips to showcase the emoji shortcodes. The Icons tab, new for Invision Community 5, allows you to add Font Awesome Icons directly to your content. Lastly, both the emoji selector and the shortcode suggestion dropdown support arrow-key navigation, so you don't have to move your hands from the keyboard to the mouse. Content Boxes The feature I'm personally most excited about is boxes. The concept started as an abstraction of spoilers because sometimes you just want "a box" - a section that stands out from the rest of the content, something we do manually in our documentation and guides on this site. Each box has a tile and the following options: Expandable - You can mark a box as "expandable" which is functionally the same as a spoiler. One improvement is that expandable boxes use native HTML details and summary elements instead of plain Javascript animated divs. Colors - You can optionally keep it grey on grey like spoilers, but I think that's so boring! The colors automatically adjust to the theme colors, so it will look great in dark and light mode. Float (left/right/none) - You can make the box align to the left or right of other content just like you can for images Width - When the box is floated, you can set the width to big, medium or small. Boxes.mp4 Link Expansion Invision Community has long expanded some links, such as YouTube, offering more context or even a mini-player where appropriate. With Invision Community 5, we've added support for embedding dynamic link previews using site metadata. This is a preview of a topic on our forum. For those unaware, the Open Graph (OG) Protocol is essentially a way webpages can specify a title, image, and description to be dynamically embedded on another platform. This is the underlying technology when you see the link preview in Meta, X, Slack, or iMessage. Code Blocks and Inline Code The new editor adds inline, syntax-highlighted code blocks and inline code. Both formats can be applied via the toolbar, or optionally, you can wrap text in a single backtick (`) to convert it to an inline code block or triple backticks (```) to convert it to a code block. The code blocks also support numerous languages for syntax highlighting, including a new custom highlighter for the Invision HTML Template Syntax (Invision Community theme creators and application developers, you're welcome!) Semantic Headings and Relative Sizes Invision Community 5 adds a block selector with headings 1 through 6 in the new editor. It's possibly the most common request I hear so that people can use consistent styling rather than just big bold text in a paragraph tag. Semantic headings are also ideal for SEO and accessibility. In addition to the block selector, you can create headings with the corresponding markdown shortcut. Consecutive pound signs (#) at the start of a line followed by a space (the number of pounds corresponds to the "level" of the heading). For example ### creates a Heading 3 (<h3/>) creates the heading for you. Using clear header tags means screen readers and search engines can better understand your content as using absolute font sizes, such as 16px, can make it unclear what type of element is actually being used. Is it a heading or just a paragraph with large bold text? Furthermore, you may want different sizes depending on the content and device type. Mobile devices may benefit from a large base font size. So we added percent-based font sizes which change the font size based on whatever the default would be for that block. text-menus.mp4 Further UX Improvements The new editor in Invision Community 5 has several tangible improvements, including a mobile-first design. In the current editor, some functionality was hidden behind modals and double clicks, which are either not obvious on mobile devices or not possible at all. The new editor no longer relies on modals and instead uses buttons and dropdown menus that work perfectly with mobile and other touch-based devices. New Line Arrows For block content, such as boxes, images and quotes, we've added the ability to create a new line before or after the block with the click of a button. This was an issue of frustration for mobile and touch devices where it was not always clear where the cursor was and a finger is a much less accurate aiming device! Sticky Toolbar Anyone who has authored a long piece of content knows the pain of scrolling up and down to get the toolbar in view. To make writing longer content less stressful, we've made the toolbar sticky so that it will always be fixed at the top of the editor after scrolling down. sticky-toolbar.mp4 Markdown Style Shortcuts One common request is to support markdown in the editor. While we opted not to include full markdown support, the new editor recognizes many markdown-style formatting shortcuts. markdown.mp4 Colors A common challenge with rich text editors on sites with multiple themes is colors often need to consistently look right across all themes. This is even more important with Invision Community 5, as it has a native dark mode feature. For this reason, we opted to offer a reduced set of color options that all adapt dynamically to the theme. I mentioned this about box colors above, but this is also true of the font color. The difference in shade is slight, but it's very noticeable without it. Toggling between light and dark mode will never produce unreadable text. colors.mp4 We can't wait for you to try the new editor; it has already been very popular with our small testing group. Which feature are you most looking forward to trying? View full blog entry

My oh my, how exciting

If you are referring to the classic and custom emojis, yes they are still supported in the editor We didn't include them in the Icon Creator however as those images can get quite large and it can make the SVG too large after embedding them.

No plans for a size option because the generated icons are in fact dimensionless SVGs, meaning they are rendered at whatever size is specified in your community theme's CSS.

Thanks for reporting this issue, we believe it should be resolved now, let us know if you are still having issues.