In 2024, a secure WYSIWYG Editor has become a complex intricate thing.

Copy/paste bundle files have largely been phased out in favor of complicated NPM repos and build tools. What was more or less just "HTML Manipulation" has evolved to abstract content models with dynamic rules on how to actually render the content to HTML. Then, for kicks, throw in the requirement that this editor needs to work in non-standard cases like the drag and drop page builder and live topics. The solution for Invision Community 5 is a new, custom, state of the art Editor built using ReactJS and Tiptap.

In this article, I'll cover high level advantages, technical highlights and what's possible with 3rd party extensions. 

If you want to know more about the editor functionality, then see my other blog here.

This story begins after we switched to CKEditor5 over a year ago. It is a decent product, but it had several serious limitations in a distributed platform like Community. We compared just about every editor currently on the market, and even considered building an editor completely from scratch, and ultimately landed on creating a custom editor using ReactJS and Tiptap.

A lightweight package

The v5 editor bundle size is small, coming to about 2mb in total (and it's split into separate chunks loaded ad-hoc, each one cached in the browser, so in practice much less data actually "loads"). After optimizing and tweaking CKEditor5, the smallest we could get it was over 50mb; now some build tool experts could probably wrangle that cke package to a smaller size, but I doubt it'd come anywhere close to Tiptap with all the features we added.

It's also worth noting that, during operation, Tiptap had by far the lowest impact on browser memory consumption, and stubborn memory leaks never came up with this architecture. Part of this comes from taking advantage of ReactJS's stateful nature, but I think the most significant thing is that Tiptap doesn't have loose logic hanging around.

How a modern WYSIWYG works (the short version)

As I previously alluded to, editors today don't directly manipulate HTML at all. Instead, they store a Content Model according to a Schema.

Different platforms may use different terms, but the content schema consists of the following Entities

• Nodes - Actual containers to put content in. Think blockquotes, headings or lists. Nodes are then stored in the document in a tree
• Text and Inline Nodes - Text is, well, text. It is exclusively just a string of characters; one way to think of it is, if it can go in a text message, it's text. Inline nodes, on the other hand, are not true "characters" but displayed inline with characters. Think custom emoticons and mentions.
• Marks - Styles and/or data that is applied over a range of text. Marks are similar to Nodes except that marks can overlap. For example, it if text is italic and bold, it makes no difference if it's bold inside italic or vise versa. Moreover, it it most accurate to simply say that text is just both italic and bold; this data is stored in Marks. In old editors, like CKEditor4, this was often just thrown into a "style" attribute which led to all sorts of issues and overhead processing. (These are not what CKEditor calls "marks" FYI, they call this concept "text attributes", in case anyone has existing CKE knowledge)

All the above entities rely on Converters to generate them from HTML and then reconvert back into HTML. When the editor starts, it uses those converts to convert the initial data into the Content Model. Then, any change is made to the Content Model directly, which is continuously being converted back into HTML for the user to see.

Security and Consistency

The Schema and architecture add a layer of complexity but provide much better security, consistency and reliability because it only allows whitelisted content structures. For example, if I inserted something with the attribute style="color:white; transform: rotate(45deg)", the transform and color will be stripped out unless there's an existing converter to convert it to a Mark.

Another example good example is simple bold styling: I can define several converters to parse the bold Mark: one for <b> tags, one for <strong> and one for style="font-weight: bold", and have them all convert back into a <strong> tag.

Lastly, this gives us the assurance that, for any style, there is a user interface to manipulate and manage it. For this reason, source editing was removed because you won't ever need to fall back to source editing.

I could go on for hours (seriously, don't get me started) but that's more than enough context to understand the rest of this article.

Extending the Editor in Invision

Another limitation of CKEditor5 in a distributed platform, where individual admins may want to customize, is that all Plugins have to be present at build not at runtime. This would pretty much mean no extending the editor, just rearranging the toolbar and flipping certain builtin features on and off.

Fortunately, in Tiptap we were able to extend their internal node, mark and extension APIs. We'll have a more complete dev guide, but essentially all nodes, marks and extensions, which I'll just call "extensions" collectively, are rolled into the existing app system. There are 2 reasons we did this instead of just "buttons" like Invision 4, where you can just upload the CKEditor4 plugin zip file:

1. It relies on using PHP to parse JavaScript to get things like the button title and stuff. If you create a valid plugin but define things in a slightly different way than expected, such as adding the name to the wrong line in the file, the plugin upload fails.
2. Plugins/extensions are not buttons. Many CKE plugins have multiple buttons and many have none. This make management difficult because sometimes there isn't a button to remove and you have to reset all plugins, or you want to remove just one and 5 others disappear with it. Also, mostly all plugins add a new type of content; this type of content needs to be whitelisted

Now, you may be thinking, "like the editor itself, won't the server side HTML Parser will strip any content that is not whitelisted"? Well, the answer is yes and we added a new AdminCP Dev Center tool to create Parser Whitelist Rules inside Invision Community Apps (again more on all this later). With the coupling of the Parser Whitelist and Editor Extensions, admins can rest assured that their editors will just "work" when you install Extensions.

If you want to prematurely prepare to create Invision Community 5 Editor Extensions, have a look at Tiptap's Dev API Documentation, specifically the methods Node.create(), Mark.create() and Extension.create(). We've added wrappers for those three methods, in addition to an interface to add and position buttons in the toolbar.

Please let me know if you have any questions!

As part of our commitment to encourage 3rd party development and extension, we have given our Developer Center a much needed makeover. A picture is worth a thousand words, but how about a video?

Highlights

• The Developer Center now has its own dedicated tab in the ACP.
• What were previously tabs are now displayed on individual screens, making for a far less cluttered UI.
• You can easily switch from one application to another using the main menu or the button at the top right of the screen.
• We've implemented UI for some JSON files that previously had to be manually created; specifically acpsearch.json and furl.json
• We've replaced the "Support" button at the top of the ACP with a more helpful "Quick Links" dropdown menu. While this is not specific to developers, with easy access to things like the Task Manager and clearing caches, it's very handy for troubleshooting!

Application Landing Page

When you open the Developer Center for a particular application, the landing page is designed to help you quickly access common functions, and to help you find any potential issues within your code.

The Application Scanner currently checks for:

• Missing Admin CP Language Strings
• Missing Front-End Language Strings
• Missing EditorLocations extensions
• Missing FileStorage extensions
• Missing FrontNavigation extensions
• Missing FURLs
• Missing Email Templates

Language strings are grouped so that can you easily see where the missing strings were detected.

We will continue to expand the scanners over the course of the next few months.

Thoughts?

What do you think? Are there any other useful features you'd like to see added to the Dev Center? What kind of scans can we implement on the landing page?

One of the areas we have reviewed in Commerce is the way that we handle custom items. Previously, many of our features were limited to Commerce Products. Even items such as Subscriptions and Download Files were not fully integrated. In Invision Community 5, we have looked at ways to improve the overall experience.

Icons and Images

A small, but important change: displaying the item icon when an image is not available. In previous versions, if no image was available, the checkout and client area displayed a standard "box" icon for all items. In IC5, we now show the icon defined in your Item extension.

Product Details

Line item details are displayed on the checkout screens, as well as on the Invoice. However, this functionality was restricted to custom package fields, which are only available for Commerce Products. This logic has been moved to a new extension method, detailsForDisplay.

Coupons

A very popular request is to create coupons for specific items that are not Commerce Products. Previously, coupons could either be applied to the entire purchase or to specific packages. We have added the following methods to the Item extensions to allow you to integrate your items with the coupon form.

• couponFormElements
  Returns an array of elements that will be shown on the coupon form. If no elements are returned, your item will not be listed.
• saveCouponForm
  Process the values of the fields defined in your couponFormElements method. This method returns an array of data that will be stored with the coupon.
• isCouponValid
  Check if the coupon is valid for this item.

New default coupon form:

Autopay

When Commerce generates renewal invoices, we attempt to take a payment if a user has a card on file. We have moved this functionality to \IPS\nexus\Gateway::autopay(). Your gateway must also have the SUPPORTS_AUTOPAY constant set to true in order for this to work.

With the new logic, when a renewal invoice is generated, the task will loop through all available methods. If autopay is supported, it will attempt to take payment using that payment method.

We've tried to include the most popular requests that we've seen for custom items and payments. What do you think? Have we missed anything? What are some of the requests you've received for custom item integration?

As we get closer to our first release, we'll be discussing how to update your custom applications to be compatible with IPS v5. We know this can seem like a daunting task, especially since not all changes will be immediately obvious, so we'll be walking through this step by step.

Updating Source Classes

• Classnames should no longer start with an underscore.
• All our source classes are now strictly typed, so any of your classes that extend pretty much anything (Content Items, Nodes, Active Record) will need to be updated with the correct method signatures and property types.
• Almost all Content interfaces have been converted to traits (e.g. \IPS\Content\Pinnable, \IPS\Content\Lockable). Your content classes should have use statements instead of implements, and if you are overloading any trait methods, verify that it is properly declared.
  The following interfaces have not been moved to traits:
  \IPS\Content\Embeddable
  \IPS\Content\Filter
  \IPS\Node\Permissions
• \IPS\Content\Searchable has been removed entirely and replaced with a SearchContent extension.
• Recommended: We no longer use FQN in our code. This is not required for v5 compatibility, but a recommendation for best practice.

A few examples of the changes to the code base, showing strictly typed function signatures and using traits versus interfaces

Updating Extensions

• All extensions now have an abstract class that should be extended. Most of these can be found under \IPS\Extensions. The abstract class is typically the same name as the extension type (e.g. EditorLocations extend EditorLocationsAbstract). Verify that your extensions use the correct abstract class and that all your method signatures and properties are declared correctly.
• Remove deprecated extensions. See this blog entry for a complete list.
• Convert your CreateMenu extensions to a UserMenu extension.
• Convert your MemberSync extensions to a Listener.

Replacing Code Hooks

The following is a general list of the most common types of code hooks. Obviously, we cannot predict, nor support, all possibilities, but we have tried to cover the basics here.

• Hooks on content classes should be replaced with Listeners or UI Extensions.
• Hooks on the Dispatcher (e.g. for loading JS/CSS) should be converted to Loader Extensions.
• Hooks on commerce items should be replaced with Listeners.
• Hooks that add functionality (e.g. Commerce gateways, Login handlers) should be moved to the appropriate extensions.

Replacing Theme Hooks

As with code hooks, below is a list of common uses for theme hooks.

• Theme hooks that add to the user dropdown menu should be moved to a UserMenu extension.
• Theme hooks that add classes or attributes should be moved to UI Extensions.
• Theme hooks that insert HTML should be moved to template hooks.

Please let us know in the comments if there is anything that we may have missed, or if something is unclear. We would like to make this transition as smooth as possible.

Theming has been a core component of Invision Community since its inception, and this continues with Invision Community 5, but in a very different way.

If you haven't already seen Ehren's blog on the new Theme Editor, please do take the time to watch it. The all-new theme editor reduces the complexity of theming by taking complex concepts like HSL CSS variables into a pretty slick UI that almost any Invision Community owner can use to personalise or brand match to any existing properties.

Ehren will talk more on the technology behind the theme editor in another developer blog soon, but the short version is that the CSS framework has been completely rewritten from scratch with a new approach to how CSS classes interact with page elements.

Of course, if you're reading this, you'll want to know what tools you have for more advanced theming in v5.

Custom templates and template hooks
Invision Community 5 merges the concepts of custom templates and template hooks into a single feature. In the past, you could edit templates directly and create theme hooks. With Invision Community 5, these features are replaced with the new custom template system.

You can create new templates, which you can use in other custom templates via the short tag: {customtemplate='key'}. 

You can also hook into specific areas with a custom template allowing you to insert code before the opening tag, after the opening tag, before the closing tag or after the closing tag.

For example, if you wanted to add something custom before the reply editor when viewing a topic, you would target that area like so:

The result, when viewed on the front end, is as follows:

These hookable areas are defined by a special tag that we add to the core templates. We would expect a lot of requests through the beta release and will likely create a request form so we can process them. We will try and accommodate as many areas as possible.

While direct template editing is no longer possible in Invision Community v5, the new custom template and hook system allows you to add new functionality, while the new CSS framework makes it easier to target and change elements without the need to edit templates.

We also added a suite of new development tools to enable you to target menus, data attributes and other areas where developers commonly had to edit templates before.

The good news is that now custom templates are not built on top of our 'master' template engine; they are virtually upgrade-proof and do not require manual merging.

Theme Designer Mode
Those who create themes for others have some extra tooling to enable them to build truly custom themes.

Even though the theme editor has space for custom CSS, there is always a need for CSS that your customers cannot edit, and Invision Community 5 has a special area for that once Theme Designer Mode has been enabled.

You also can add any ad-hoc javascript for when you want to hide elements or provide custom interactions.

As direct CSS editing and direct template editing are no longer possible with Invision Community 5, there is no need for a 'sync' tool to copy from the filesystem.

Conclusion
The new front-end theme editor is now the primary way to manage themes. This is where you upload logos and toggle settings.

As you can see, theming may look different in Invision Community v5. Still, the new custom templates, theme designer tools and UI extensions provide a lot of functionality that means you can do nearly everything you did in v4, but often in an easier way.

I'm sure you'll have many questions, so please add them below, and we'll do our best to answer them for you.

We've been dropping hints about various development features that haven't yet made their appearance in our previous blog entries. Now that hooks are no longer a possibility, we've expanded our Extensions system to allow developers to integrate with other areas within the framework.

This blog entry will give an overview of our new Extensions. We are working on updating our developer documentation to include these changes.

AccountSettings

Allows you to add tabs to the Account Settings page. This extension contains two methods:

• getTab
  Returns the key for the tab (or null to hide)
• getContent
  The tab content

Loader

This extension was created primarily to allow you to load Javascript and CSS files in areas outside of your application, but has since been expanded to include other functionality. It is essentially an extension on the Dispatcher.

Available methods:

• css
  Returns an array of CSS files to load
• js
  Returns an array of JS files to load
• checkForRedirect
  Redirect users to another location. This is especially useful for custom applications that would have previously bypassed an existing controller.
• customError
  Show a custom error message to the user instead of the standard IPS error messages.

SearchContent

This is used to allow your application's content to the Search Index. Previously, the framework relied on the ContentRouter extension for this, and the use of the \IPS\Content\Searchable interface. The interface has been removed, and searchable classes are determined by the new extension.

The SearchContent extension contains one required method, supportedClasses. You can also use this extension to override our default search logic for your content.

Other New Extensions

• LoginHandler
  Allows you to create additional Login methods
• UIComment/UIItem/UINode/UIReview
  UI Extensions, described here, here, and here
• UserMenu
  Allows you to add content to various menus. Additional information can be found here.

New Commerce Extensions

The following new extensions have been added to Commerce:

• Gateway
  Allows you to create new payment gateways
• LicenseKey
  Allows you to add new methods for generating and managing license keys
• Payout
  Allows you to create gateways for payouts

Deprecated Extensions

The following Extensions are no longer supported and have been removed:

• BBCode
• ContentModeratorPermissions (use ModeratorPermissions instead)
• CreateMenu (replaced by UserMenu)
• IncomingEmail
• MemberForm

Reminder: Send us your Feedback

Send us your questions or use-cases by submitting a topic here. Please note that this is a private forum; you will not see topics posted by others, so you are free to share code samples if necessary. We will review your questions, and then aggregate them into an FAQ. The deadline for your question to be considered for the FAQ is October 15. After that you may still submit questions in the Contributor forum, where we will do our best to respond.

By now you might be getting a little tired of hearing about our UI Extensions, but we still have a few more features to talk about. We showed you how to add CSS and data attributes to content. We discussed how to add form fields and menu items. In this final entry on this tool, we'll talk about working with Nodes.

ACP Tools

Nodes are different than the Items and Comments, as they are typically managed in the ACP and not on the front-end. Therefore, we needed additional extension methods to allow developers to handle custom actions.

Let's take a look at Nodes in the ACP.

There are a few areas where developers may need to insert custom logic. The UINode extension includes the following methods:

• rowButtons
  Returns an array of action buttons that will be added to the control strip on the right. This method functions identically to the Model::getButtons() method.
• rowHtml
  Inserts custom HTML to the left of the control strip.
• rowBadge
  If a badge should be displayed, return an array with the CSS class and language string. Note that anything defined in the base class get__badge() method will take precedence over your extension.

  No Entry

It is important to note that not all Node classes support the form-related methods. We have of course added support for all content containers, such as Forums and Calendars. We will consider including support for other classes upon request, however, nodes that handle infrastructure (e.g. Theme, Lang) will not be supported.

We have also locked down some system-level classes (not all) where any extension is potentially destructive. Classes such as Application and Module cannot be extended.

OK, so what CAN I still do? AMA (well, almost anything).

We still have a few more tools to show you, but at this point we'd like to hear from you. We know there is still a lot of uncertainty around how to migrate your modifications from v4 to v5, and we're here to assist with that. Send us your questions or use-cases by submitting a topic here. Please note that this is a private forum; you will not see topics posted by others, so you are free to share code samples if necessary. We will review your questions, and then aggregate them into an FAQ. The deadline for your question to be considered for the FAQ is September 1. After that you may still submit questions in the Contributor forum, where we will do our best to respond.

In our  previous blog entry, we described the UI Extension and its overall capabilities. Today, we'll talk about how to use this new tool to extend content forms and menus.

Form Fields

A popular modification request is to add fields to a Content Item, such as a Topic. All UI extension classes contain the following methods:

• formElements
  Returns an array of form elements that will be added to the form.

Note: Unlike other UI Extension methods, the first parameter of this method can be NULL, if you are creating a new item.

• formPostSave
  Allows you to process the fields that were added in the formElements method. Note that this method is triggered after the form is saved.

Note: This method has the same function as the ContentListener method onCreateOrEdit, but we've added support for it here as well to avoid the creation of multiple classes, and to keep related code in the same place.

Element Placement

By default, all new form elements will be inserted at the end of the form. However, there are times that you may want to insert your fields into specific positions within the form. You can use the new FormAbstract::setPosition() method to specify where the element should be inserted.

Let's look at an example.

public function formElements( ?BaseItem $item, ?Model $container ): array
{
	return [
		'my_new_field' => new Text( 'my_new_field', $item ? $item->new_field : null, true )
	];
}

The above will append a Text field called "my_new_field" at the end of the Topic form.

public function formElements( ?BaseItem $item, ?Model $container ): array
{
	$field = new Text( 'my_new_field', null, true );
	return [
		'my_new_field' => $field->setPosition( Topic::$formLangPrefix . 'tags', Topic::$formLangPrefix . 'mainTab' )
	];
}

By using setPosition, I've placed the new field after the "tags" field, on the main tab in the form.

Extending Content Menus

In this blog entry, we introduced our new approach to building menus. With UI extensions, you can add your own items to Item and Comment menus using the following methods:

• UIItem::menuItems
• UIComment::menuItems

We will discuss nodes and their menus in a future blog entry.

Extending Item Badges

Similarly, you can use the UI Extension to add badges to the item header. The UIItem::badges() method returns an array of badges and/or icons to be appended to the badge display.

This concludes our discussion of UI Extension features related to Items and Comments. In our next blog entry, we'll discuss Nodes and what additional methods are available.

Only a little over a week into our development tools announcements, and there is already lots of buzz about our new UI Extensions. The UI Extensions handle a variety of functionality, and we will discuss them all in detail, over the course of multiple blog entries. For today, we'll start with an introduction and an overview of some of the basic usage.

Features and Functionality

UI Extensions are extensions to a single content class - Nodes, Items, Comments, or Reviews. With a UI Extension, you can:

• Add custom CSS classes and data attributes
• Add options to content menus
• Add badges to content item headers
• Add fields to content forms
• ACP-related functionality (for nodes)

And a couple of other small things that we'll cover here.

Setup

The Application Developer Center has 4 new options in the Extensions tab:

• UIComment
• UIItem
• UINode
• UIReview

To add a UI extension, simply create a class under the appropriate extension type.

Note: We are working on improving this process, however, those changes will likely be introduced at a later date.

The default extension file will be generated in the appropriate directory within your application's extensions folder. All UI Extensions are abstracted, so if you omit a method from your class, or if new methods are introduced later on, your extension will not throw an error.

All UI Extension methods receive the object as the first parameter.

UI Extensions for... UI

The idea for UI Extensions was born when we were reviewing the most common third-party development hooks. With the removal of theme hooks, we needed a way for developers to add custom CSS and attributes to areas such as topic rows, the author panel, among others. Even with the theme hooks in v4, the way to accomplish this was less than ideal. Adding a CSS class typically required at least 2 hooks per template - one to determine the correct class (usually based on custom logic) and one to insert the class as a variable. It was tedious and finicky at best.

All UI Extensions include the following methods:

• css
  Returns an array of CSS classes that will be applied to the object
• dataAttributes
  Returns an array of data attributes (as "key=value", "key=value") that will be applied to the object

To insert those values into the appropriate location, our templates now contain the following syntax:

{$object->ui( 'css' )}

and

{$object->ui( 'dataAttributes' )}

Let's examine the Content::ui() method (identical to Model::ui().)

public function ui( string $method, ?array $payload=array(), bool $returnAsArray=false, string $separator = " " ) : array|string

The ui method accepts 4 arguments: the method name, an optional payload (determined based on the method being called), the option to return as an array (vs a string), and an optional separator (when data is returned as a string). The defaults for this method were set for the simplest, shortest syntax within the templates, as seen above. You may also see syntax like this:

foreach( $this->ui( 'menuItems', array(), TRUE ) as $key => $link )
{
	$links[$key] = $link;
}

As you can see, in this case the ui method will return the results as an array.

Class-Specific Methods

Some of our extensions include methods that are applicable only to objects of that type.

• UIItem::sidebar()
  Returns HTML that will be included in the contextual sidebar when viewing the item
• UIComment::authorPanel()
  Returns HTML to be inserted into the author panel of a post

Note: All methods in the UIComment extension are also available in UIReview.

We hope this entry gave you a glimpse into what will be available with this new tool, and a better understanding of the direction we are taking with our toolkit. We will discuss the other features of this tool in upcoming blog entries.

Action and Moderation Menus can be one of the most tedious development tasks, while also being critical to user experience.

For example, we may add support for pinning/unpinning content, then we need to remember to include the ability to pin/unpin that content in all the HTML templates. 3rd party developers add screens inside their applications, and then they need to add a link to the User Menu to make that accessible.

With Invision Community 4, this would require a template hook targeting fairly complex classes and children that was susceptible to structural changes to templates between versions.

In Invision Community 5, we have made significant changes to menu creation in order to streamline the process, and also to allow 3rd party developers better accessibility.

New Helper Classes

Menus are now built using helper classes, rather than relying on lengthy HTML templates. A menu is created by initializing a new Menu object.

$menu = new Menu( 'AccountMenu' );

We can then add elements to the menu.

$menu->addTitleField( 'menu_content' );
$menu->add( new Link( $member->url(), 'menu_profile', icon:'fa-solid fa-user' ) );
$menu->addSeparator();
$menu->add( new Link( Url::internal( "app=core&module=system&controller=markread", "front", "mark_site_as_read" )->csrf()->addRef( Request::i()->url() ), 'mark_site_read', dataAttributes: [
			'data-action' => 'markSiteRead',
			'data-controller' => 'core.front.core.markRead'
		], icon: 'fa-solid fa-eye' ) );

The most common menu element is the Link. This will generate the appropriate <li> element within the menu. You can define the URL, CSS class (default is ipsMenu_item), data attributes, icon, title, among other properties.

Titles and Separators are added using the Menu::addTitleField() and Menu::addSeparator() methods respectively.

You can also insert custom HTML into the menu using the Menu::addHtml() method.

In your HTML template, you would then simply display the menu object as a string.

{{if $menu->hasContent()}}
{$menu|raw}
{{endif}}

The menu templates will include the link that opens the menu, as well as the menu itself.

You'll notice that the above contains a call to the hasContent() method. This method will check if the menu object has any elements inside; if a user does not have permission to any of the elements, nothing will be displayed.

Content Menus

Almost all content items and comments (and reviews) require some kind of menu for moderation. Previously, this meant creating large chunks of redundant HTML code throughout the codebase. We've implemented \IPS\Content\Item::menu() and \IPS\Content\Comment::menu() to build these menus in a central location. The new methods include checks for whether a feature is in use and whether the user has permission to perform this action.

Example:

if( IPS::classUsesTrait( $this, 'IPS\Content\Pinnable' ) AND $this->canPin( $member ) )
{
	$links['pin'] = new ContentMenuLink( $this->url()->csrf()->setQueryString( array( 'do' => 'moderate', 'action' => 'pin' ) ), 'pin'  );
}

Now, the HTML template simply contains:

{$entry->menu()|raw}

(Note: Yes, these content menus can be extended using... you guessed it. UI Extensions.)

Other Menus

We have also migrated the following menus to the new structure:

• User Menu
• Mobile Menu
• Create Menu

Badges

Another area with redundant HTML was our content badges. For example, pinned topics will display an icon on both the topic list and the topic header. We have created helper classes for badges and badge icons to centralize this logic. Within the new Item::badges() method, we build an array of icons that will be shown.

if( IPS::classUsesTrait( $this, Featurable::class ) AND $this->isFeatured() )
{
	$return['featured'] = new Icon( Badge::BADGE_POSITIVE, 'fa-solid fa-star', Member::loggedIn()->language()->addToStack( 'featured' ) );
}

The above generates a badge icon with the badge type ipsBadge--positive (constants have been declared for all common types, but any class can be used), the star icon, and the "featured" language string as the tooltip.

In our template HTML, we now have

<div class='ipsBadges'>
	{{foreach $entry->badges() as $badge}}{$badge|raw}{{endforeach}}
</div>

UserMenu Extension

Now that we've moved the menus into the codebase and out of the templates, we needed a way to allow 3rd party developers to insert their own menu items. We've introduced a new extension called UserMenu.

The UserMenu extension contains the following methods:

• accountMenu
  This method allows you to add menu elements to the user menu. The method includes a parameter to allow you to add elements in one of 3 places within the menu: content, settings, or logout.
• mobileMenu
  Allows you to add elements to the mobile navigation menu. All elements are inserted before the "sign out" option.
• createMenu
  Replaces the CreateMenu extension, which has been deprecated.
• accountSettingsLinks
  Allows you to add links to the inner sidebar in the Account Settings overview tab (under the link for Notification Settings).

Note: No, this does not add tabs to the Account Settings page, but fear not, that's coming. (Not in the UI Extension.)

• userNav
  This method will insert HTML in the user bar, to the left of the Create Menu.
• mobileNav
  Similar to the userNav method, but inserts HTML into the mobile navigation header.

What do you think of our changes to the Menus? Let us know in the comments below.