Esther E.

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.

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.

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.

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.
 

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.

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.

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.

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.

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.

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.

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.

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.
 

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.

I'm very excited to be posting my first blog entry for IPS, and thrilled that this is what I get to post.
When we started planning the new development tools for v5, we looked at existing resources - from the marketplace, from some contributors, and from our own managed clients - and asked, what is it that developers find themselves doing the most often? Matt’s previous blog entry gave a brief summary of some of those functions. Today’s blog entry is going to focus on one of our powerful new tools, Listeners.
One common reason for a code hook was to execute custom code when a specific action occurs. For example, when a topic is created, or when a new reply is posted. Listeners allow you to execute your code at key points in the workflow, without the worry of finding exactly the right hook location.
Here is an excerpt from the BlogComment listener in our Cloud application:

 
Creating Listeners
Let’s start with the application’s Developer Center.

We’ve added a new tab for Listeners. This tab lists all your existing listeners, as well as the class on which it is listening.
You’ll notice that each listener can only observe a single class. While this may seem slightly tedious, the idea here was that as a developer, you should be conscious of what class you are working with. It also eliminates the need to check what type of object is being passed preventing accidents and unintended consequences when missing class checks.
When you add a listener, there are several listener types available. We will discuss each one in detail.

 
Content Listener
This listener is fired on an Item or Comment (or Review) class. When adding a Content Listener, you must specify the class you are observing. When you hit Save, there is a validation check in place to ensure that the class exists, and that it is a valid class for the selected listener type.
Content Listeners have the following methods available. All methods are included in the default listener file that is generated.
onLoad
Triggered when an object is loaded (in Content::constructFromData) NOTE: Be careful! This event could be fired at unexpected times. If you’re executing code here, you may want to check the dispatcher instance to verify that your code is running where you expect.
onBeforeCreateOrEdit
Fired when a form is submitted, before it is saved. This is the equivalent of Item::processBeforeCreate and Item::processBeforeEdit. This method includes a parameter to indicate whether this is a create or edit. onCreateOrEdit
Fired after a form is saved. This is the equivalent of Item::processAfterCreate and Item::processAfterEdit. This method includes a parameter to indicate whether this is a create or edit. onDelete
Fired after an object is deleted. onStatusChange
Fired when any moderation action occurs. For example, when an item is pinned/unpinned, locked/unlocked. The moderation action is passed as a parameter so that your code can take that into account. onMerge
Triggered AFTER an item is merged. onItemView
Triggered when an item is viewed and the view count is incremented.  
Invoice Listener
An Invoice listener is fired only on the \IPS\nexus\Invoice class. This listener does not require you to specify a class to extend.
The Invoice listener includes a single method, onStatusChange. This is fired when the invoice is saved and the status changes (pending/paid/expired/canceled).
 
Member Listener
The Member listener will be familiar to many of you. We have taken the MemberSync extension and moved it in its entirety to a listener, as it was a better fit for this structure. All the previous methods that were available are still available here. We have also added the following new methods:
onJoinClub
Fired when a member joins a club. If approval is required, this is fired after they are approved. onLeaveClub
Fired when a member leaves or is removed from a club. onEventRsvp
Fired when a member responds to an event. The response is included as a parameter to this method.  
Commerce Package Listener
The Commerce Package listener is fired on any implementation of \IPS\nexus\Invoice\Item. You must specify the class that you are observing.
The methods are the same as those that are available in an item extension.
onCancel onChange onDelete onExpireWarning onExpire onInvoiceCancel onPaid onPurchaseGenerated onReactivate onRenew onTransfer onUnpaid  
Some Technical Notes
All listener files will be generated in a “listeners” directory within your application. Your application’s data directory will include a listeners.json file that defines all your listeners. The json file is automatically generated when you add/remove a listener. All listener methods are optional. The default class that is generated will include all available methods, but they do not have to be present in your file. All listener methods are return type void. If a listener method fails, an exception will be thrown when IN_DEV is enabled. In production, the exception will be logged with a reference to the listener class and the event on which the exception occurred.  
Firing Events
Your code can fire any existing event using the Event::fire method.
Example:
Event::fire( 'onBeforeCreateOrEdit', $comment, array( $values ) ); The Event::fire method is called statically and accepts an event name, the object on which the event will be fired, and an array of additional parameters (varies according to the event that you are triggering).
This concludes our introduction to Listeners. We do intend to implement additional listener types and events based on your feedback and as the need arises.

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.
 

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.
 

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.
 

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.
 

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.
 

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.
 

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.
 
 

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.

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.
 
 

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.
 
 

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

I'm very excited to be posting my first blog entry for IPS, and thrilled that this is what I get to post.
When we started planning the new development tools for v5, we looked at existing resources - from the marketplace, from some contributors, and from our own managed clients - and asked, what is it that developers find themselves doing the most often? Matt’s previous blog entry gave a brief summary of some of those functions. Today’s blog entry is going to focus on one of our powerful new tools, Listeners.
One common reason for a code hook was to execute custom code when a specific action occurs. For example, when a topic is created, or when a new reply is posted. Listeners allow you to execute your code at key points in the workflow, without the worry of finding exactly the right hook location.
Here is an excerpt from the BlogComment listener in our Cloud application:

 
Creating Listeners
Let’s start with the application’s Developer Center.

We’ve added a new tab for Listeners. This tab lists all your existing listeners, as well as the class on which it is listening.
You’ll notice that each listener can only observe a single class. While this may seem slightly tedious, the idea here was that as a developer, you should be conscious of what class you are working with. It also eliminates the need to check what type of object is being passed preventing accidents and unintended consequences when missing class checks.
When you add a listener, there are several listener types available. We will discuss each one in detail.

 
Content Listener
This listener is fired on an Item or Comment (or Review) class. When adding a Content Listener, you must specify the class you are observing. When you hit Save, there is a validation check in place to ensure that the class exists, and that it is a valid class for the selected listener type.
Content Listeners have the following methods available. All methods are included in the default listener file that is generated.
onLoad
Triggered when an object is loaded (in Content::constructFromData) NOTE: Be careful! This event could be fired at unexpected times. If you’re executing code here, you may want to check the dispatcher instance to verify that your code is running where you expect.
onBeforeCreateOrEdit
Fired when a form is submitted, before it is saved. This is the equivalent of Item::processBeforeCreate and Item::processBeforeEdit. This method includes a parameter to indicate whether this is a create or edit. onCreateOrEdit
Fired after a form is saved. This is the equivalent of Item::processAfterCreate and Item::processAfterEdit. This method includes a parameter to indicate whether this is a create or edit. onDelete
Fired after an object is deleted. onStatusChange
Fired when any moderation action occurs. For example, when an item is pinned/unpinned, locked/unlocked. The moderation action is passed as a parameter so that your code can take that into account. onMerge
Triggered AFTER an item is merged. onItemView
Triggered when an item is viewed and the view count is incremented.  
Invoice Listener
An Invoice listener is fired only on the \IPS\nexus\Invoice class. This listener does not require you to specify a class to extend.
The Invoice listener includes a single method, onStatusChange. This is fired when the invoice is saved and the status changes (pending/paid/expired/canceled).
 
Member Listener
The Member listener will be familiar to many of you. We have taken the MemberSync extension and moved it in its entirety to a listener, as it was a better fit for this structure. All the previous methods that were available are still available here. We have also added the following new methods:
onJoinClub
Fired when a member joins a club. If approval is required, this is fired after they are approved. onLeaveClub
Fired when a member leaves or is removed from a club. onEventRsvp
Fired when a member responds to an event. The response is included as a parameter to this method.  
Commerce Package Listener
The Commerce Package listener is fired on any implementation of \IPS\nexus\Invoice\Item. You must specify the class that you are observing.
The methods are the same as those that are available in an item extension.
onCancel onChange onDelete onExpireWarning onExpire onInvoiceCancel onPaid onPurchaseGenerated onReactivate onRenew onTransfer onUnpaid  
Some Technical Notes
All listener files will be generated in a “listeners” directory within your application. Your application’s data directory will include a listeners.json file that defines all your listeners. The json file is automatically generated when you add/remove a listener. All listener methods are optional. The default class that is generated will include all available methods, but they do not have to be present in your file. All listener methods are return type void. If a listener method fails, an exception will be thrown when IN_DEV is enabled. In production, the exception will be logged with a reference to the listener class and the event on which the exception occurred.  
Firing Events
Your code can fire any existing event using the Event::fire method.
Example:
Event::fire( 'onBeforeCreateOrEdit', $comment, array( $values ) ); The Event::fire method is called statically and accepts an event name, the object on which the event will be fired, and an array of additional parameters (varies according to the event that you are triggering).
This concludes our introduction to Listeners. We do intend to implement additional listener types and events based on your feedback and as the need arises.

I'm very excited to be posting my first blog entry for IPS, and thrilled that this is what I get to post.
When we started planning the new development tools for v5, we looked at existing resources - from the marketplace, from some contributors, and from our own managed clients - and asked, what is it that developers find themselves doing the most often? Matt’s previous blog entry gave a brief summary of some of those functions. Today’s blog entry is going to focus on one of our powerful new tools, Listeners.
One common reason for a code hook was to execute custom code when a specific action occurs. For example, when a topic is created, or when a new reply is posted. Listeners allow you to execute your code at key points in the workflow, without the worry of finding exactly the right hook location.
Here is an excerpt from the BlogComment listener in our Cloud application:

 
Creating Listeners
Let’s start with the application’s Developer Center.

We’ve added a new tab for Listeners. This tab lists all your existing listeners, as well as the class on which it is listening.
You’ll notice that each listener can only observe a single class. While this may seem slightly tedious, the idea here was that as a developer, you should be conscious of what class you are working with. It also eliminates the need to check what type of object is being passed preventing accidents and unintended consequences when missing class checks.
When you add a listener, there are several listener types available. We will discuss each one in detail.

 
Content Listener
This listener is fired on an Item or Comment (or Review) class. When adding a Content Listener, you must specify the class you are observing. When you hit Save, there is a validation check in place to ensure that the class exists, and that it is a valid class for the selected listener type.
Content Listeners have the following methods available. All methods are included in the default listener file that is generated.
onLoad
Triggered when an object is loaded (in Content::constructFromData) NOTE: Be careful! This event could be fired at unexpected times. If you’re executing code here, you may want to check the dispatcher instance to verify that your code is running where you expect.
onBeforeCreateOrEdit
Fired when a form is submitted, before it is saved. This is the equivalent of Item::processBeforeCreate and Item::processBeforeEdit. This method includes a parameter to indicate whether this is a create or edit. onCreateOrEdit
Fired after a form is saved. This is the equivalent of Item::processAfterCreate and Item::processAfterEdit. This method includes a parameter to indicate whether this is a create or edit. onDelete
Fired after an object is deleted. onStatusChange
Fired when any moderation action occurs. For example, when an item is pinned/unpinned, locked/unlocked. The moderation action is passed as a parameter so that your code can take that into account. onMerge
Triggered AFTER an item is merged. onItemView
Triggered when an item is viewed and the view count is incremented.  
Invoice Listener
An Invoice listener is fired only on the \IPS\nexus\Invoice class. This listener does not require you to specify a class to extend.
The Invoice listener includes a single method, onStatusChange. This is fired when the invoice is saved and the status changes (pending/paid/expired/canceled).
 
Member Listener
The Member listener will be familiar to many of you. We have taken the MemberSync extension and moved it in its entirety to a listener, as it was a better fit for this structure. All the previous methods that were available are still available here. We have also added the following new methods:
onJoinClub
Fired when a member joins a club. If approval is required, this is fired after they are approved. onLeaveClub
Fired when a member leaves or is removed from a club. onEventRsvp
Fired when a member responds to an event. The response is included as a parameter to this method.  
Commerce Package Listener
The Commerce Package listener is fired on any implementation of \IPS\nexus\Invoice\Item. You must specify the class that you are observing.
The methods are the same as those that are available in an item extension.
onCancel onChange onDelete onExpireWarning onExpire onInvoiceCancel onPaid onPurchaseGenerated onReactivate onRenew onTransfer onUnpaid  
Some Technical Notes
All listener files will be generated in a “listeners” directory within your application. Your application’s data directory will include a listeners.json file that defines all your listeners. The json file is automatically generated when you add/remove a listener. All listener methods are optional. The default class that is generated will include all available methods, but they do not have to be present in your file. All listener methods are return type void. If a listener method fails, an exception will be thrown when IN_DEV is enabled. In production, the exception will be logged with a reference to the listener class and the event on which the exception occurred.  
Firing Events
Your code can fire any existing event using the Event::fire method.
Example:
Event::fire( 'onBeforeCreateOrEdit', $comment, array( $values ) ); The Event::fire method is called statically and accepts an event name, the object on which the event will be fired, and an array of additional parameters (varies according to the event that you are triggering).
This concludes our introduction to Listeners. We do intend to implement additional listener types and events based on your feedback and as the need arises.

I'm very excited to be posting my first blog entry for IPS, and thrilled that this is what I get to post.
When we started planning the new development tools for v5, we looked at existing resources - from the marketplace, from some contributors, and from our own managed clients - and asked, what is it that developers find themselves doing the most often? Matt’s previous blog entry gave a brief summary of some of those functions. Today’s blog entry is going to focus on one of our powerful new tools, Listeners.
One common reason for a code hook was to execute custom code when a specific action occurs. For example, when a topic is created, or when a new reply is posted. Listeners allow you to execute your code at key points in the workflow, without the worry of finding exactly the right hook location.
Here is an excerpt from the BlogComment listener in our Cloud application:

 
Creating Listeners
Let’s start with the application’s Developer Center.

We’ve added a new tab for Listeners. This tab lists all your existing listeners, as well as the class on which it is listening.
You’ll notice that each listener can only observe a single class. While this may seem slightly tedious, the idea here was that as a developer, you should be conscious of what class you are working with. It also eliminates the need to check what type of object is being passed preventing accidents and unintended consequences when missing class checks.
When you add a listener, there are several listener types available. We will discuss each one in detail.

 
Content Listener
This listener is fired on an Item or Comment (or Review) class. When adding a Content Listener, you must specify the class you are observing. When you hit Save, there is a validation check in place to ensure that the class exists, and that it is a valid class for the selected listener type.
Content Listeners have the following methods available. All methods are included in the default listener file that is generated.
onLoad
Triggered when an object is loaded (in Content::constructFromData) NOTE: Be careful! This event could be fired at unexpected times. If you’re executing code here, you may want to check the dispatcher instance to verify that your code is running where you expect.
onBeforeCreateOrEdit
Fired when a form is submitted, before it is saved. This is the equivalent of Item::processBeforeCreate and Item::processBeforeEdit. This method includes a parameter to indicate whether this is a create or edit. onCreateOrEdit
Fired after a form is saved. This is the equivalent of Item::processAfterCreate and Item::processAfterEdit. This method includes a parameter to indicate whether this is a create or edit. onDelete
Fired after an object is deleted. onStatusChange
Fired when any moderation action occurs. For example, when an item is pinned/unpinned, locked/unlocked. The moderation action is passed as a parameter so that your code can take that into account. onMerge
Triggered AFTER an item is merged. onItemView
Triggered when an item is viewed and the view count is incremented.  
Invoice Listener
An Invoice listener is fired only on the \IPS\nexus\Invoice class. This listener does not require you to specify a class to extend.
The Invoice listener includes a single method, onStatusChange. This is fired when the invoice is saved and the status changes (pending/paid/expired/canceled).
 
Member Listener
The Member listener will be familiar to many of you. We have taken the MemberSync extension and moved it in its entirety to a listener, as it was a better fit for this structure. All the previous methods that were available are still available here. We have also added the following new methods:
onJoinClub
Fired when a member joins a club. If approval is required, this is fired after they are approved. onLeaveClub
Fired when a member leaves or is removed from a club. onEventRsvp
Fired when a member responds to an event. The response is included as a parameter to this method.  
Commerce Package Listener
The Commerce Package listener is fired on any implementation of \IPS\nexus\Invoice\Item. You must specify the class that you are observing.
The methods are the same as those that are available in an item extension.
onCancel onChange onDelete onExpireWarning onExpire onInvoiceCancel onPaid onPurchaseGenerated onReactivate onRenew onTransfer onUnpaid  
Some Technical Notes
All listener files will be generated in a “listeners” directory within your application. Your application’s data directory will include a listeners.json file that defines all your listeners. The json file is automatically generated when you add/remove a listener. All listener methods are optional. The default class that is generated will include all available methods, but they do not have to be present in your file. All listener methods are return type void. If a listener method fails, an exception will be thrown when IN_DEV is enabled. In production, the exception will be logged with a reference to the listener class and the event on which the exception occurred.  
Firing Events
Your code can fire any existing event using the Event::fire method.
Example:
Event::fire( 'onBeforeCreateOrEdit', $comment, array( $values ) ); The Event::fire method is called statically and accepts an event name, the object on which the event will be fired, and an array of additional parameters (varies according to the event that you are triggering).
This concludes our introduction to Listeners. We do intend to implement additional listener types and events based on your feedback and as the need arises.

I'm very excited to be posting my first blog entry for IPS, and thrilled that this is what I get to post.
When we started planning the new development tools for v5, we looked at existing resources - from the marketplace, from some contributors, and from our own managed clients - and asked, what is it that developers find themselves doing the most often? Matt’s previous blog entry gave a brief summary of some of those functions. Today’s blog entry is going to focus on one of our powerful new tools, Listeners.
One common reason for a code hook was to execute custom code when a specific action occurs. For example, when a topic is created, or when a new reply is posted. Listeners allow you to execute your code at key points in the workflow, without the worry of finding exactly the right hook location.
Here is an excerpt from the BlogComment listener in our Cloud application:

 
Creating Listeners
Let’s start with the application’s Developer Center.

We’ve added a new tab for Listeners. This tab lists all your existing listeners, as well as the class on which it is listening.
You’ll notice that each listener can only observe a single class. While this may seem slightly tedious, the idea here was that as a developer, you should be conscious of what class you are working with. It also eliminates the need to check what type of object is being passed preventing accidents and unintended consequences when missing class checks.
When you add a listener, there are several listener types available. We will discuss each one in detail.

 
Content Listener
This listener is fired on an Item or Comment (or Review) class. When adding a Content Listener, you must specify the class you are observing. When you hit Save, there is a validation check in place to ensure that the class exists, and that it is a valid class for the selected listener type.
Content Listeners have the following methods available. All methods are included in the default listener file that is generated.
onLoad
Triggered when an object is loaded (in Content::constructFromData) NOTE: Be careful! This event could be fired at unexpected times. If you’re executing code here, you may want to check the dispatcher instance to verify that your code is running where you expect.
onBeforeCreateOrEdit
Fired when a form is submitted, before it is saved. This is the equivalent of Item::processBeforeCreate and Item::processBeforeEdit. This method includes a parameter to indicate whether this is a create or edit. onCreateOrEdit
Fired after a form is saved. This is the equivalent of Item::processAfterCreate and Item::processAfterEdit. This method includes a parameter to indicate whether this is a create or edit. onDelete
Fired after an object is deleted. onStatusChange
Fired when any moderation action occurs. For example, when an item is pinned/unpinned, locked/unlocked. The moderation action is passed as a parameter so that your code can take that into account. onMerge
Triggered AFTER an item is merged. onItemView
Triggered when an item is viewed and the view count is incremented.  
Invoice Listener
An Invoice listener is fired only on the \IPS\nexus\Invoice class. This listener does not require you to specify a class to extend.
The Invoice listener includes a single method, onStatusChange. This is fired when the invoice is saved and the status changes (pending/paid/expired/canceled).
 
Member Listener
The Member listener will be familiar to many of you. We have taken the MemberSync extension and moved it in its entirety to a listener, as it was a better fit for this structure. All the previous methods that were available are still available here. We have also added the following new methods:
onJoinClub
Fired when a member joins a club. If approval is required, this is fired after they are approved. onLeaveClub
Fired when a member leaves or is removed from a club. onEventRsvp
Fired when a member responds to an event. The response is included as a parameter to this method.  
Commerce Package Listener
The Commerce Package listener is fired on any implementation of \IPS\nexus\Invoice\Item. You must specify the class that you are observing.
The methods are the same as those that are available in an item extension.
onCancel onChange onDelete onExpireWarning onExpire onInvoiceCancel onPaid onPurchaseGenerated onReactivate onRenew onTransfer onUnpaid  
Some Technical Notes
All listener files will be generated in a “listeners” directory within your application. Your application’s data directory will include a listeners.json file that defines all your listeners. The json file is automatically generated when you add/remove a listener. All listener methods are optional. The default class that is generated will include all available methods, but they do not have to be present in your file. All listener methods are return type void. If a listener method fails, an exception will be thrown when IN_DEV is enabled. In production, the exception will be logged with a reference to the listener class and the event on which the exception occurred.  
Firing Events
Your code can fire any existing event using the Event::fire method.
Example:
Event::fire( 'onBeforeCreateOrEdit', $comment, array( $values ) ); The Event::fire method is called statically and accepts an event name, the object on which the event will be fired, and an array of additional parameters (varies according to the event that you are triggering).
This concludes our introduction to Listeners. We do intend to implement additional listener types and events based on your feedback and as the need arises.

I'm very excited to be posting my first blog entry for IPS, and thrilled that this is what I get to post.
When we started planning the new development tools for v5, we looked at existing resources - from the marketplace, from some contributors, and from our own managed clients - and asked, what is it that developers find themselves doing the most often? Matt’s previous blog entry gave a brief summary of some of those functions. Today’s blog entry is going to focus on one of our powerful new tools, Listeners.
One common reason for a code hook was to execute custom code when a specific action occurs. For example, when a topic is created, or when a new reply is posted. Listeners allow you to execute your code at key points in the workflow, without the worry of finding exactly the right hook location.
Here is an excerpt from the BlogComment listener in our Cloud application:

 
Creating Listeners
Let’s start with the application’s Developer Center.

We’ve added a new tab for Listeners. This tab lists all your existing listeners, as well as the class on which it is listening.
You’ll notice that each listener can only observe a single class. While this may seem slightly tedious, the idea here was that as a developer, you should be conscious of what class you are working with. It also eliminates the need to check what type of object is being passed preventing accidents and unintended consequences when missing class checks.
When you add a listener, there are several listener types available. We will discuss each one in detail.

 
Content Listener
This listener is fired on an Item or Comment (or Review) class. When adding a Content Listener, you must specify the class you are observing. When you hit Save, there is a validation check in place to ensure that the class exists, and that it is a valid class for the selected listener type.
Content Listeners have the following methods available. All methods are included in the default listener file that is generated.
onLoad
Triggered when an object is loaded (in Content::constructFromData) NOTE: Be careful! This event could be fired at unexpected times. If you’re executing code here, you may want to check the dispatcher instance to verify that your code is running where you expect.
onBeforeCreateOrEdit
Fired when a form is submitted, before it is saved. This is the equivalent of Item::processBeforeCreate and Item::processBeforeEdit. This method includes a parameter to indicate whether this is a create or edit. onCreateOrEdit
Fired after a form is saved. This is the equivalent of Item::processAfterCreate and Item::processAfterEdit. This method includes a parameter to indicate whether this is a create or edit. onDelete
Fired after an object is deleted. onStatusChange
Fired when any moderation action occurs. For example, when an item is pinned/unpinned, locked/unlocked. The moderation action is passed as a parameter so that your code can take that into account. onMerge
Triggered AFTER an item is merged. onItemView
Triggered when an item is viewed and the view count is incremented.  
Invoice Listener
An Invoice listener is fired only on the \IPS\nexus\Invoice class. This listener does not require you to specify a class to extend.
The Invoice listener includes a single method, onStatusChange. This is fired when the invoice is saved and the status changes (pending/paid/expired/canceled).
 
Member Listener
The Member listener will be familiar to many of you. We have taken the MemberSync extension and moved it in its entirety to a listener, as it was a better fit for this structure. All the previous methods that were available are still available here. We have also added the following new methods:
onJoinClub
Fired when a member joins a club. If approval is required, this is fired after they are approved. onLeaveClub
Fired when a member leaves or is removed from a club. onEventRsvp
Fired when a member responds to an event. The response is included as a parameter to this method.  
Commerce Package Listener
The Commerce Package listener is fired on any implementation of \IPS\nexus\Invoice\Item. You must specify the class that you are observing.
The methods are the same as those that are available in an item extension.
onCancel onChange onDelete onExpireWarning onExpire onInvoiceCancel onPaid onPurchaseGenerated onReactivate onRenew onTransfer onUnpaid  
Some Technical Notes
All listener files will be generated in a “listeners” directory within your application. Your application’s data directory will include a listeners.json file that defines all your listeners. The json file is automatically generated when you add/remove a listener. All listener methods are optional. The default class that is generated will include all available methods, but they do not have to be present in your file. All listener methods are return type void. If a listener method fails, an exception will be thrown when IN_DEV is enabled. In production, the exception will be logged with a reference to the listener class and the event on which the exception occurred.  
Firing Events
Your code can fire any existing event using the Event::fire method.
Example:
Event::fire( 'onBeforeCreateOrEdit', $comment, array( $values ) ); The Event::fire method is called statically and accepts an event name, the object on which the event will be fired, and an array of additional parameters (varies according to the event that you are triggering).
This concludes our introduction to Listeners. We do intend to implement additional listener types and events based on your feedback and as the need arises.

I'm very excited to be posting my first blog entry for IPS, and thrilled that this is what I get to post.
When we started planning the new development tools for v5, we looked at existing resources - from the marketplace, from some contributors, and from our own managed clients - and asked, what is it that developers find themselves doing the most often? Matt’s previous blog entry gave a brief summary of some of those functions. Today’s blog entry is going to focus on one of our powerful new tools, Listeners.
One common reason for a code hook was to execute custom code when a specific action occurs. For example, when a topic is created, or when a new reply is posted. Listeners allow you to execute your code at key points in the workflow, without the worry of finding exactly the right hook location.
Here is an excerpt from the BlogComment listener in our Cloud application:

 
Creating Listeners
Let’s start with the application’s Developer Center.

We’ve added a new tab for Listeners. This tab lists all your existing listeners, as well as the class on which it is listening.
You’ll notice that each listener can only observe a single class. While this may seem slightly tedious, the idea here was that as a developer, you should be conscious of what class you are working with. It also eliminates the need to check what type of object is being passed preventing accidents and unintended consequences when missing class checks.
When you add a listener, there are several listener types available. We will discuss each one in detail.

 
Content Listener
This listener is fired on an Item or Comment (or Review) class. When adding a Content Listener, you must specify the class you are observing. When you hit Save, there is a validation check in place to ensure that the class exists, and that it is a valid class for the selected listener type.
Content Listeners have the following methods available. All methods are included in the default listener file that is generated.
onLoad
Triggered when an object is loaded (in Content::constructFromData) NOTE: Be careful! This event could be fired at unexpected times. If you’re executing code here, you may want to check the dispatcher instance to verify that your code is running where you expect.
onBeforeCreateOrEdit
Fired when a form is submitted, before it is saved. This is the equivalent of Item::processBeforeCreate and Item::processBeforeEdit. This method includes a parameter to indicate whether this is a create or edit. onCreateOrEdit
Fired after a form is saved. This is the equivalent of Item::processAfterCreate and Item::processAfterEdit. This method includes a parameter to indicate whether this is a create or edit. onDelete
Fired after an object is deleted. onStatusChange
Fired when any moderation action occurs. For example, when an item is pinned/unpinned, locked/unlocked. The moderation action is passed as a parameter so that your code can take that into account. onMerge
Triggered AFTER an item is merged. onItemView
Triggered when an item is viewed and the view count is incremented.  
Invoice Listener
An Invoice listener is fired only on the \IPS\nexus\Invoice class. This listener does not require you to specify a class to extend.
The Invoice listener includes a single method, onStatusChange. This is fired when the invoice is saved and the status changes (pending/paid/expired/canceled).
 
Member Listener
The Member listener will be familiar to many of you. We have taken the MemberSync extension and moved it in its entirety to a listener, as it was a better fit for this structure. All the previous methods that were available are still available here. We have also added the following new methods:
onJoinClub
Fired when a member joins a club. If approval is required, this is fired after they are approved. onLeaveClub
Fired when a member leaves or is removed from a club. onEventRsvp
Fired when a member responds to an event. The response is included as a parameter to this method.  
Commerce Package Listener
The Commerce Package listener is fired on any implementation of \IPS\nexus\Invoice\Item. You must specify the class that you are observing.
The methods are the same as those that are available in an item extension.
onCancel onChange onDelete onExpireWarning onExpire onInvoiceCancel onPaid onPurchaseGenerated onReactivate onRenew onTransfer onUnpaid  
Some Technical Notes
All listener files will be generated in a “listeners” directory within your application. Your application’s data directory will include a listeners.json file that defines all your listeners. The json file is automatically generated when you add/remove a listener. All listener methods are optional. The default class that is generated will include all available methods, but they do not have to be present in your file. All listener methods are return type void. If a listener method fails, an exception will be thrown when IN_DEV is enabled. In production, the exception will be logged with a reference to the listener class and the event on which the exception occurred.  
Firing Events
Your code can fire any existing event using the Event::fire method.
Example:
Event::fire( 'onBeforeCreateOrEdit', $comment, array( $values ) ); The Event::fire method is called statically and accepts an event name, the object on which the event will be fired, and an array of additional parameters (varies according to the event that you are triggering).
This concludes our introduction to Listeners. We do intend to implement additional listener types and events based on your feedback and as the need arises.

I'm very excited to be posting my first blog entry for IPS, and thrilled that this is what I get to post.
When we started planning the new development tools for v5, we looked at existing resources - from the marketplace, from some contributors, and from our own managed clients - and asked, what is it that developers find themselves doing the most often? Matt’s previous blog entry gave a brief summary of some of those functions. Today’s blog entry is going to focus on one of our powerful new tools, Listeners.
One common reason for a code hook was to execute custom code when a specific action occurs. For example, when a topic is created, or when a new reply is posted. Listeners allow you to execute your code at key points in the workflow, without the worry of finding exactly the right hook location.
Here is an excerpt from the BlogComment listener in our Cloud application:

 
Creating Listeners
Let’s start with the application’s Developer Center.

We’ve added a new tab for Listeners. This tab lists all your existing listeners, as well as the class on which it is listening.
You’ll notice that each listener can only observe a single class. While this may seem slightly tedious, the idea here was that as a developer, you should be conscious of what class you are working with. It also eliminates the need to check what type of object is being passed preventing accidents and unintended consequences when missing class checks.
When you add a listener, there are several listener types available. We will discuss each one in detail.

 
Content Listener
This listener is fired on an Item or Comment (or Review) class. When adding a Content Listener, you must specify the class you are observing. When you hit Save, there is a validation check in place to ensure that the class exists, and that it is a valid class for the selected listener type.
Content Listeners have the following methods available. All methods are included in the default listener file that is generated.
onLoad
Triggered when an object is loaded (in Content::constructFromData) NOTE: Be careful! This event could be fired at unexpected times. If you’re executing code here, you may want to check the dispatcher instance to verify that your code is running where you expect.
onBeforeCreateOrEdit
Fired when a form is submitted, before it is saved. This is the equivalent of Item::processBeforeCreate and Item::processBeforeEdit. This method includes a parameter to indicate whether this is a create or edit. onCreateOrEdit
Fired after a form is saved. This is the equivalent of Item::processAfterCreate and Item::processAfterEdit. This method includes a parameter to indicate whether this is a create or edit. onDelete
Fired after an object is deleted. onStatusChange
Fired when any moderation action occurs. For example, when an item is pinned/unpinned, locked/unlocked. The moderation action is passed as a parameter so that your code can take that into account. onMerge
Triggered AFTER an item is merged. onItemView
Triggered when an item is viewed and the view count is incremented.  
Invoice Listener
An Invoice listener is fired only on the \IPS\nexus\Invoice class. This listener does not require you to specify a class to extend.
The Invoice listener includes a single method, onStatusChange. This is fired when the invoice is saved and the status changes (pending/paid/expired/canceled).
 
Member Listener
The Member listener will be familiar to many of you. We have taken the MemberSync extension and moved it in its entirety to a listener, as it was a better fit for this structure. All the previous methods that were available are still available here. We have also added the following new methods:
onJoinClub
Fired when a member joins a club. If approval is required, this is fired after they are approved. onLeaveClub
Fired when a member leaves or is removed from a club. onEventRsvp
Fired when a member responds to an event. The response is included as a parameter to this method.  
Commerce Package Listener
The Commerce Package listener is fired on any implementation of \IPS\nexus\Invoice\Item. You must specify the class that you are observing.
The methods are the same as those that are available in an item extension.
onCancel onChange onDelete onExpireWarning onExpire onInvoiceCancel onPaid onPurchaseGenerated onReactivate onRenew onTransfer onUnpaid  
Some Technical Notes
All listener files will be generated in a “listeners” directory within your application. Your application’s data directory will include a listeners.json file that defines all your listeners. The json file is automatically generated when you add/remove a listener. All listener methods are optional. The default class that is generated will include all available methods, but they do not have to be present in your file. All listener methods are return type void. If a listener method fails, an exception will be thrown when IN_DEV is enabled. In production, the exception will be logged with a reference to the listener class and the event on which the exception occurred.  
Firing Events
Your code can fire any existing event using the Event::fire method.
Example:
Event::fire( 'onBeforeCreateOrEdit', $comment, array( $values ) ); The Event::fire method is called statically and accepts an event name, the object on which the event will be fired, and an array of additional parameters (varies according to the event that you are triggering).
This concludes our introduction to Listeners. We do intend to implement additional listener types and events based on your feedback and as the need arises.

I'm very excited to be posting my first blog entry for IPS, and thrilled that this is what I get to post.
When we started planning the new development tools for v5, we looked at existing resources - from the marketplace, from some contributors, and from our own managed clients - and asked, what is it that developers find themselves doing the most often? Matt’s previous blog entry gave a brief summary of some of those functions. Today’s blog entry is going to focus on one of our powerful new tools, Listeners.
One common reason for a code hook was to execute custom code when a specific action occurs. For example, when a topic is created, or when a new reply is posted. Listeners allow you to execute your code at key points in the workflow, without the worry of finding exactly the right hook location.
Here is an excerpt from the BlogComment listener in our Cloud application:

 
Creating Listeners
Let’s start with the application’s Developer Center.

We’ve added a new tab for Listeners. This tab lists all your existing listeners, as well as the class on which it is listening.
You’ll notice that each listener can only observe a single class. While this may seem slightly tedious, the idea here was that as a developer, you should be conscious of what class you are working with. It also eliminates the need to check what type of object is being passed preventing accidents and unintended consequences when missing class checks.
When you add a listener, there are several listener types available. We will discuss each one in detail.

 
Content Listener
This listener is fired on an Item or Comment (or Review) class. When adding a Content Listener, you must specify the class you are observing. When you hit Save, there is a validation check in place to ensure that the class exists, and that it is a valid class for the selected listener type.
Content Listeners have the following methods available. All methods are included in the default listener file that is generated.
onLoad
Triggered when an object is loaded (in Content::constructFromData) NOTE: Be careful! This event could be fired at unexpected times. If you’re executing code here, you may want to check the dispatcher instance to verify that your code is running where you expect.
onBeforeCreateOrEdit
Fired when a form is submitted, before it is saved. This is the equivalent of Item::processBeforeCreate and Item::processBeforeEdit. This method includes a parameter to indicate whether this is a create or edit. onCreateOrEdit
Fired after a form is saved. This is the equivalent of Item::processAfterCreate and Item::processAfterEdit. This method includes a parameter to indicate whether this is a create or edit. onDelete
Fired after an object is deleted. onStatusChange
Fired when any moderation action occurs. For example, when an item is pinned/unpinned, locked/unlocked. The moderation action is passed as a parameter so that your code can take that into account. onMerge
Triggered AFTER an item is merged. onItemView
Triggered when an item is viewed and the view count is incremented.  
Invoice Listener
An Invoice listener is fired only on the \IPS\nexus\Invoice class. This listener does not require you to specify a class to extend.
The Invoice listener includes a single method, onStatusChange. This is fired when the invoice is saved and the status changes (pending/paid/expired/canceled).
 
Member Listener
The Member listener will be familiar to many of you. We have taken the MemberSync extension and moved it in its entirety to a listener, as it was a better fit for this structure. All the previous methods that were available are still available here. We have also added the following new methods:
onJoinClub
Fired when a member joins a club. If approval is required, this is fired after they are approved. onLeaveClub
Fired when a member leaves or is removed from a club. onEventRsvp
Fired when a member responds to an event. The response is included as a parameter to this method.  
Commerce Package Listener
The Commerce Package listener is fired on any implementation of \IPS\nexus\Invoice\Item. You must specify the class that you are observing.
The methods are the same as those that are available in an item extension.
onCancel onChange onDelete onExpireWarning onExpire onInvoiceCancel onPaid onPurchaseGenerated onReactivate onRenew onTransfer onUnpaid  
Some Technical Notes
All listener files will be generated in a “listeners” directory within your application. Your application’s data directory will include a listeners.json file that defines all your listeners. The json file is automatically generated when you add/remove a listener. All listener methods are optional. The default class that is generated will include all available methods, but they do not have to be present in your file. All listener methods are return type void. If a listener method fails, an exception will be thrown when IN_DEV is enabled. In production, the exception will be logged with a reference to the listener class and the event on which the exception occurred.  
Firing Events
Your code can fire any existing event using the Event::fire method.
Example:
Event::fire( 'onBeforeCreateOrEdit', $comment, array( $values ) ); The Event::fire method is called statically and accepts an event name, the object on which the event will be fired, and an array of additional parameters (varies according to the event that you are triggering).
This concludes our introduction to Listeners. We do intend to implement additional listener types and events based on your feedback and as the need arises.