Mike G.

25 tags. Or maybe a few more, depending on your setup.
As of now, the upgrader will give you a choice to either delete all global tags OR to convert the top 25 tags (by usage) to the new system. 
If you have node-specific tags (for example, for a single forum), you can choose to drop them or convert them. 

Dude, it's already done.
(No, it's not, but if I say it's done then I just make myself more awesome.)

It would be nice if tag pages could be indexable for Google and Co. Or if we had the option to choose whether they are indexable or not.

1) The top three items are from the normal "Featured Content". Oh, actually, we haven't spoken about that much have we. So we merged "featured" and "Our picks" into one thing. The old "feature" didn't really do much apart from allow you to filter in a widget and show a featured block above the content. This new page is much simplified.

You can still feature replies and show the post at the top of the topic as you can now. I should probably do a blog on all the other stuff we did but haven't spoken about. 🫠

2) Right now, all tags but I think it would be nice to have a toggle in the AdminCP form to determine this.
3) Yeah, nice idea. We'd need to be careful with Pages collisions.
3) Um. We can add a bunch of hook points ads can use on that page.
Absolutely. It offers another way to categorise content across all apps within the suite which was the primary point - we wanted a way to bring all that content into one place and have it all look universal.

It will require some thought and it works best with fewer tags, not more. If you have 100+ tags then it's not as effective. Ideally you want broad tags rather than narrow tags.
It uses the standard autocomplete form widget which will offer a search box if there's more than N items (can't recall offhand what that is)
I think we will need to add some bulk tag management in some form. Right @Esther E.? 😅
It still lives in another branch. I'll be updating the alpha site soon.

I expected some improvements, but I was cautiously optimistic about how much of an improvement it could be.
This massively exceeds my expectations and it's that bridge that will really help unify everything - which has been my biggest challenge to figure out. 
Thank you. 
P.S. Even more impressive is how the team is able to not talk about it in advance.

Me, having used the alpha V5 site for a while, upon seeing the topic be about tags...

Me, after having read Matt's post...

This sounds really cool - a fantastic way to revitalise both the tagging system and content discovery across the platform. In my community, I did try to let users tag things themselves, but they often didn't bother and it was usually left to mods/staff - so I am not mourning the lack of open tags going forward...
But this new cross-functional tagging system, coupled with the Featured Content page, sounds like it will be a godsend for my community. Oftentimes community members will post news in the forum before our 'official news staff' get round to writing about it, so being able to tag the forum post as 'news' and guaranteeing it will sit in the same "news" space as our 'official' news articles is something I've been dreaming about!
The only piece of the puzzle missing for me in that regard is how well this feature will pair with the CMS/Pages "Copy to Database" system, which my 'official news team' uses a lot (both in terms of avoiding duplicate records appearing in the tag page, making sure linked Page/Topics are unified in search results, and ensuring Topic OPs are kept visible when converted while still prioritising any Page content as the 'canonical content').
I had a couple questions regarding the tag pages and featured content section:
What determines the posts that appear at the very top of the Featured Content page (the top three items)? Is it the most recent 'Featured' posts across any/all tags? Can we decide which tags can be included on the Featured Content page, or is it automated? Regarding the URL, are we able to set alternative FURLs for certain tag pages (for example, I might want the news tag page to be our site's actual news homepage, so it would be better to have the URL for this as www.site.com/news rather than www.site.com/tags/news)? I hate to ask this but needs must... what are the opportunities for ad placements on the Featured Content/tags page? Will there be ad blocks we can use for the post grid, or will be only be able to place ads above/below certain sections/areas? Thanks so much for another amazing feature update. Really surprised me with this one. 🙂
BTW, it looks like I'll be setting a calendar alert for the 21st June then... 😉

If anyone thought the alpha folks were keeping their lips shut about this I can state unequivocally we have not.
IPS kept this way close to the vest and none of us in the preview even knew this was what the tags changes were going to be, we just knew that tags were going to "change". This is not in the alpha yet, nor was it even hinted at.
I can state with some vague authority that this, treating tags as pseudo-content items to up discoverability and presentation of content has to be one of the best ideas I've seen in the CMS/Forums/Community space in years.
If you were waiting for something to differentiate V5 from just being V4 re-engineered, this is it.

Thanks for the communication. Every bit helps as we inch closer to a large upgrade. 

As we find ourselves with our toes over the precipice of June; signalling the half way point of the year, I thought it's a good time for an update.

Apologies southern hemisphere.
Invision Community 5 has been in alpha testing for a while, and a small group have found a good number of bugs, and offered their thoughts and suggestions, some of which we've implemented. During this time we've wrapped up the new editor, a boat load of UI improvements and more.
We are now ready for the next stage, which is to give our alpha testers their own Cloud v5 to test with. This opens up testing for the Admin CP, and all areas without using developer mode. v5 has a lot of changes to how CSS, JS and resources are managed. They are now built when we build the apps, and should never need rebuilding. We also store compiled templates now, so lots of slow eval() calls are no longer needed. In brief testing locally, it has made the entire platform super-fast.
We are choosing to use a Cloud v5 to test with, rather than a traditional download for two reasons. The first is that using our hosting platform means we don't have to chase down issues with PHP, MySQL and unix versions which can be time consuming in the early stages. The second is that we're still writing the new build code, so we can't actually produce a versioned zip just yet. 😂
But fear not, downloadable versions will be coming at some point.
We're aiming to have this alpha demo system ready next week, so if you want to help alpha test, drop a comment below. I want to keep the first round (1-2 weeks) fairly small or it becomes overwhelming sifting through the feedback and bugs but please do register your interest.
In terms of functionality, we're wrapping up the tagging changes; I'd expect a blog on that next week. The final parts of the Pages app are coming together. We even tested an upgrade of this site to v5 to see how the Pages built pages looked, and much to all of our relief, it looks great with just a few CSS classes needing updating.
It's been a long journey - and a little longer than we'd first hoped but we're getting closer to betas when the fun really starts.
We're really proud of v5 and we hope you like what we've created.
 

This issue was resolved in our latest release of the platform. Please upgrade to resolve this, and if you see any further issues, please let us know.

This issue was resolved in our latest release of the platform. Please upgrade to resolve this, and if you see any further issues, please let us know.

The recommended versions in the latest releases are aligned with the minimum requirements for v5

I think it's worth waiting until you can use it. Then get feedback from your members. I'm sure it actually works better than you imagine and that it's quite intuitive.
If you have a reason to use source code beyond fixing CKEditor issues, please let us know and please be as specific as you can which will really help, for example "Embed other sites" is less helpful than "I have a separate website, and I want to bring blog articles into my posts at around 600px high with a scrollbar".

Conversation is going around in circles a bit now people. We're happy to hear the reasons people are using source mode in the first place, as it does give us opportunity to see things that may be easily solvable without people having to resort to such measures to achieve the same thing. However the back and forth debate between people on whether or not something is useful is a little futile. What is pointless to one, may not be pointless to another. There is a place for these discussions, and its probably not within a topic showing the new editor.
 

It's really not, to be honest. Seriously, this weird "unmarked white space that exists but doesn't really unless you click it" idea is a nonsense - both in usability terms and in WYSIWYG standards. If your community members can't discern what a 'Title' field is, they're definitely not going to figure out whatever esoteric suggestion this is. 🙂
And I dare say that, if you know that your community mostly consists of people who are unable to operate forums, a small change to the post editor is really not going to move the needle for you one way or the other. I also don't know why you would decline to offer email support to people asking for help, but that is probably doing more harm to your cause than a blue arrow button ever could.
Agreed. It's a pretty bizarre argument; "these contextual buttons that add lines above and below a quote box are simply too complicated for the common user! What they really need is a Source button to click on so they can dig into the HTML code, scroll to the line they need on their tiny mobile screen and add extra p tags and div containers!" 😂

I'd argue that a large number of community owners/administrators know their user base, and have a pretty good idea of how new features and changes would be received. Most owners would be looking at this from a perspective of "how well will this do on my site?" and not "how good is this for me personally?"

Whaaaaaat Matt F coming in with the clutch MVP post of the thread!? That's awesome news, thanks for sharing/teasing!
Respectfully, I do not think your suggestion would really solve anything and in fact would make UX worse. Having extra space above/below the box area that is clickable-to-enable-text-input but is otherwise redundant will be super confusing to users, and would make the post editor not WYSIWYG compliant. Users need to see that what they're typing in the editor (and especially how it is presented in the editor) will be 100% accurate to how the post will appear on publish.
I would recommend waiting for V5 to come out and trying out the icon. While every user's experience will of course be different and there will likely be room for improvement in the UI, in my view I really do not think any user (no matter their level of experience) will miss these two clear icons sitting in the box area:

If a user is so inexperienced that you think they will not know what those buttons do, I will imagine the first thing said user would do is experiment and click those buttons to see what function they served. And there, problem solved.
My only suggestion regarding this topic is that, perhaps the arrow buttons should be permanently visible on the box in the post editor (at present in the V5 alpha those blue icons only appear if you hover your mouse over the box - and that's a scenario where I do believe that inexperienced users may have difficulty, as they may not think to hover over the box in order to reveal a solution they're looking for).

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.

I haven't received an answer to my earlier post in this thread, so I wanted to bring attention to it. Personally, I don't need to embed things per se, just to be able to give classes or id to HTML elements so that I can easily style them however I want. 
I also like to use an external code editor to edit the HTML so that I can easily for example do a "find and replace", then bring back the HTML code into my editor in Pages (all the time) or, more rarely, in the forum. 
Basically to me HTML source is a huge deal for Pages, not a huge deal for the forum if I can find other ways to style span elements to reach my goals. 

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.

Yup, a must-have feature. I implemented it myself in the current CKE, and I hope IC5 will allow doing it too. Or, even better, it will finally include it for all IC5 users 

Yes. Custom emojis are still available. But only for you, no one else. 

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

This isn't 100% related to the first message, but also not enough to warrant a new topic, imo.
The homepage canonical is set to the url without the forward slash at the end, which looks to be the case for all Invision Community homepages. I don't believe it influences indexability, but thought it was worth sharing.