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!