Matt F

Yeah, what @Matt F said 😄

Pinging @Esther E but I'm pretty sure the answer is yes. The vast majority of lang strings overlap with v4, and the way the language/translation system works hasn't changed much so I'd assume it should just use your existing translations.

Hmm, these all work for me. Could your editor permission settings be restricting external embeds?

Yeah, so there are a few reasons From our perspective, source mode is kinda like giving up on using the editor. Yeah it enables you to do anything, but that also was the number 1 cause of the editor ending up in a broken state and needing to go in and edit HTML to fix it (or file a bug report/support ticket). We want to offer tools that just work, so that you and everyday users alike can simply use the editor's features without needing to give up and edit the source HTML We would like to implement modern features including realtime collaboration and AI. I don't want to get off track delving into the details on that but raw HTML editing doesn't play nicely with those features... Selection management and collision reconciliation become major concerns. Not only does tiptap not natively support it, neither did Ckeditor5. It's just a complicated thing to do the way editors work today because the HTML isn't the source of truth for the editor state. So it's not like we went in and decided to remove it, but rather it would have taken too much time writing loads of code to halfway emulate the way editors used to work. (Yes, I'm aware of the general HTML support ck5 plugin but from our experience it didn't work smoothly because it didn't properly distinguish between block and inline nodes. It also caused performance problems when you have a lot of levels of nesting)

This decision was made after attempting to utilize CKEditor5, but there were a couple critical limitations It would have cost a ridiculous fortune to use on distributed software because they changed their license structure from cke4. This is especially important when you consider the v4 pricing model assumed the cost was $0. Furthermore, despite the cost it came with very little support and assistance, whereas with Tiptap on the other hand we get direct access to their development team who have been very helpful The demos on their site may look really pretty and work in a very snappy manner, but what they don’t show you is, just like most editors today, it requires manually bundling their source code such that extending it would be impossible on the front end. We also found it didn’t play nice with js bundlers and weren’t able to get the bundle size down to an acceptable level. This ties into what I was saying about it being a custom bundled JS app in that CKEditor5 doesn’t really have the custom button/plugin marketplace CKEditor4 had. The short explanation is that they required extension of classes which only exist inside nested dependency modules to create plugins, so an externally loaded plugin wouldn’t really be able to extend the class. In CKEditor4, there was a global CKEDITOR variable which devs used to add toolbar buttons and do dev things. With tiptap we are able to deliver extensibility and robustness. I’m not in agreement on this. Unlike blogs or news publishing, on a forum-based community, the majority of content comes from users who really don’t need or want hyper control over the exact post layout and HTML structure. More advanced things like v4 source mode are generally only something you want admins doing, but the stance we’ve come to is that feels very much like giving up on using the editor to achieve things the right way. In 2024, you shouldn’t need raw HTML in a finished CMS application…. it isn’t effectively managing your content if that’s the case. You are correct that certain content structures are not going to be supported out of the box. That being said, We are going to be implementing table support in an early point release as it is such a commonly requested item There are a lot of features and quirks to consider with tables. We found CKEditor5’s solution had a lot of CSS and bloat which made it tricky to setup and have a very clunky feel in our software. If I were to sum up our perspective on Invision Communtiy 5, we want to make it really easy to use really powerful, modern tools. This requires simplifying some areas and changing how others work, including the editor. Tiptap was chosen after weeks comparing and rigorously testing available options and it stood out as the best option to achieve our goal.

They will be stored as HTML that has had some light processing done (for things like dynamic file urls and the like). Since it is the same storage system as version 4, there isn’t any conversion needed for 5.

What do you mean by tracking banners? If you’re talking about a script of some sort to track whether something’s been displayed, that’s honestly better off as a global listener.. via a theme hook or custom HTML block or something. If you’re talking about a section of actual content, I’m 99% sure it’s possible via editor extensions.

HTML source editing in areas designed for the new editor would be a really tough one and honestly not something we're likely to do. These examples… ToC, kbd element, adding text anchors, etc… are all achievable with editor extensions, and you wouldn't even need to create a react component (which would require an entire extra react root and bulky js bundle). We're probably going to start getting dev guides out on this topic soon. We understand that creating an app is more complicated up front than just writing the HTML, but if it's to execute repeated actions you'll definitely save time and minimize risk of error in the long run.

Yes, that's expected. The short story is HLJS, the highlighting engine, has what are called nested language scopes which are disabled in the editor for optimal performance. You can add more by creating an editor extension… or I should say you will be able to. When trying to setup an example I found a bug in my code 🤫. Custom LanguagesTo create a custom language Create a highlighter or copy a highligher function from the highlight.js repository to get started. The function you want is the one that takes an hljs object Create a javascript <script> tag or file. We haven’t gone in all the details yet about how to extend the editor system, but essentially the code would look like this if I copy the “Intel x86 Assembly” highlighter (after I fix my bug) // This will add your highlighting syntax logic globally so that, after saving, posts will be highlighted with your custom language. document.addEventListener('ipsCodehighlightingLoaded', () => { ips.setString('editor_code--asm', 'ASM'); // This is how you control what it's called ips.ui.codehighlighting.registerLanguage('asm', function(hljs) { return { name: 'Intel x86 Assembly', case_insensitive: true, keywords: { $pattern: '[.%]?' + hljs.IDENT_RE, keyword: 'lock rep repe repz repne repnz xaquire xrelease bnd nobnd ', // truncated for brevity built_in: "" // truncated for brevity }, contains: [ hljs.COMMENT( ';', '$', { relevance: 0 } ), // Truncated for brevity ] }; }); }, {once: true}); // This adds the language to the editor. Ideally this would go in a separate file so it's only loaded when the editor is loaded document.addEventListener('ips:editorBeforeInit', () => { ips.ui.editorv5.registerExtension("assembly_code_lang", { onBeforeCreate: ({editor}) => { editor.options.allowedLanguages = editor.options.allowedLanguages || []; editor.options.allowedLanguages.push('asm') // asm is the name provided above document.dispatchEvent(new CustomEvent('ips:codeHighlightingLangRegistered')); // This tells the editor to add the lang to the dropdown } }); }, {once: true}) Using an Existing HLJS LanguageFor most cases though, a much easier approach is to just whitelist a known language. So, basically, you can add any of the languages in that list I linked to with an editor extension like this ips.setString('editor_code--x86asm', 'x86 ASM'); // This is how you control what it's called ips.ui.editorv5.registerExtension("assembly_code_lang", { onBeforeCreate: ({editor}) => { editor.options.allowedLanguages = editor.options.allowedLanguages || []; editor.options.allowedLanguages.push('x86asm') // x86asm is the name provided inside the file in hljs document.dispatchEvent(new CustomEvent('ips:codeHighlightingLangRegistered')); // This tells the editor to add the lang to the dropdown } });This will use the existing highlighter which is included out of the box, and is loaded ad-hoc. We may add an ACP interface to add languages that are “known” but not available in the editor.

Yes, it should be fixed now

Well, Ehren is really the expert, but I'd look into a container query instead of a media query. E.g. .ipsRichText { container-type: inline-size; container-name: i-rich-text-root; } @container i-rich-text-root (max-width:767px) { .ipsRichTextBox, .tiptap .ipsRichTextBox__nodeview-wrap > [data-node-view-wrapper] { width: 100%; display: block; margin-inline: 0; } }In theory, what that should do is force the box to behave as a full width box whenever the post content container is under 768 pixels wide (if you’re applying custom CSS, obviously you could do 980 or whatever breakpoint suits the situation). A strict min-width in px might also work, but then you’d still be risking a narrow strip of content to the right of the box.

It actually is managed completely by js and a json index for searchability. The only exception being the custom emoticons which have to be loaded from the DB/cache, but it's still the JS generating and managing it. The reason it's actually slow is because the browser takes a while to render thousands of images all at once in the current grid view (yeah, emojis and fa icons are technically characters but it's still an image at the end of the day). I've done very thorough timing and profiling locally to be certain, but one bit of evidence is the : menu for emojis loading almost instantly even though it uses the same underlying code, limited to 20 elements. Furthermore, if I add an additional step on my developer site to hide all icons in the toolbar drop-down except the first 20 before adding the HTML to the document, it also appears just about instantly despite loading all the same data. Nevertheless, like Matt said we are working on making that more snappy and instant.

Yeah, it sounds simple enough but it's a really hard thing to pull off without breaking the layout.

The short answer is it’s 20% half unfinished ☺️. You currently have to exit the page editor, then you can choose individual titles on each page and configure the indent level of the Table of Contents entry. Screen Recording 2024-08-09 at 8.50.56 AM.mp4We plan on auto-generating the default ToC so it’s a bit more obvious that it works, as well as adding more helpful descriptions. There are also a few bugs where the contents don’t work when, for example, the content is on a different page that we’ll be sure to sort. (Also looks like it doesn’t work straight out of the page editor anymore)

Sure can! Extensions define any number of their own acp-managed permissions. They also can define a ‘root’ permission which toggles the entire extension. Here, it'd look like ips.ui.editorv5.registerExtension('undoRedoButtons', { ... restrictions: [""] // "" is the root restriction }); ips.setString("ipsCustomExtension__undoRedoButtons__", "Can use undo and redo buttons?");

Yeah, it’s really easy to extend if that’s something you cannot live without. Here’s a sneak preview of the extension API, it’s largely based on tiptap’s API: I can add undo/redo buttons in under 20 lines of code 😉 🤫 ips.ui.editorv5.registerExtension('undoRedoButtons', { addButtons() { return { redo: { locations: ["format"], isAvailable: editor => editor.can().redo(), command: ({commands}) => commands.redo(), html: '<span><i class="fa-solid fa-redo"></i></span>' }, undo: { locations: ["format"], isAvailable: editor => editor.can().undo(), command: ({commands}) => commands.redo(), html: "<span><i class='fa-solid fa-undo'></i></span>" } } } });