Shariq Ansari

A topic is more than a collection of posts; it's a living entity that ebbs and flows over time.
Evergreen topics can see month-long gaps between posts and longer topics spanning numerous pages can end up hard to navigate through to find useful content.
With this in mind, we've added numerous improvements to the topic view to bring context and summaries key areas within the topic.

Topic view updates
Topic Activity
The first thing you likely spotted in the above screenshot is the new sidebar. This acts much like a summary of activity within the topic. It very quickly lets you know how old the topic is and how long it has been since the last reply. This context is essential if you are unwittingly replying to an older topic.
Most topics are driven by a handful of key members. The topic activity section shows you who have been most active, which may influence which posters you give greater authority to.
Likewise, popular days lets you dig into the 'meat' of the topic which may have evolved quickly over several days.
More often than not, a single post attracts more reactions if it is particularly helpful or insightful, and this is shown too.
Finally, a mini gallery of all upload images allows you to review media that has been attached to posts.

The topic activity summary under the first post
This activity bar can be shown either as a sidebar or underneath the first post in a topic. If you enable it for mobile devices, then it will show under the first post automatically.

The topic activity summary on mobile
As with many new features in Invision Community, you have several controls in the Admin CP to fine-tune this to your communities needs.

AdminCP settings
Other improvements
The eagle-eyed among you will have spotted a few other changes to the topic view.
The first is the badge underneath the user's photo. The shield icon notes that this poster is part of the moderation team. Of course, this badge can be hidden for communities that do not like to draw attention to all their moderators.

You will also notice that when the topic starter makes a reply to a topic, they get an "author" badge as their reply may carry more authority.
When you scroll down a topic, it's not often apparent that there has been a significant time gap between replies. For some topical topics (see what I did there) this may alter the context of the conversation.
We have added a little identifier between posts when a period of time has passed between posts.

These changes add a little context to the topic to give you more insight into how the replies direct the conversation.
The new topic activity summary gives you an at-a-glance overview of key moments and posters to help you navigate longer topics.
We hope that you and your members enjoy these new features coming to Invision Community 4.5!

It's easy to think that email is a relic from the past; from simpler times long before social media and the rise of phone apps.
And it's reasonable to think that way. Your phone constantly pings at you, and your laptop OS constantly pings at you, so why bother with email?
Because it's still a hugely powerful medium to get and retain attention.
In 2017, over 269 billion emails were sent and received per day. Of those, 3,360,250,000 are opened, read, and a link clicked.
Email is still very much a critical tool in your quest for retention.
Invision Community knows this. We have options to notify members of replies by email, weekly or monthly digests by email and members can opt-in for bulk emails sent from your community team.
Given how important email is, it was only fair that we invested in some love for our email system for 4.4.
Email Statistics
Just above, I mention that 269 billion emails are sent, and 3.4 billion are opened, read and clicked.
How many emails are sent from your Invision Community daily?
(No cheating and checking with SendGrid)
You probably have no idea as we didn't record email statistics.
As of Invision Community 4.4 we do!

Chart showing the number of emails sent daily
We now track emails sent, and the number of link clicks inside those emails.
Email Advertisements
Email notifications are a powerful way to get your members to revisit your community. The member welcomes these emails as it means they have new replies to topics they are interested in reading.

While you have your member's attention, you have an opportunity to show them a banner-style advertisement.


The new email advertisement form
When creating a new email advert, you can choose to limit the advert to specific areas such as topics, blogs, etc. - and even which forums to limit by.


Subliminal messages
This is a new way to reach your audience with your promotions.
Unfollow without logging in
Despite spending most of this blog entry shouting the virtues of email, it's inevitable that one or two members may wish to stop receiving notification emails.
In previous versions, the unfollow link would have taken you to a login page if you were signed out. For members that haven't been back in a while, this may cause some annoyance if they do not recall their login details.
Invision Community 4.4 allows non-logged in members to unfollow the item they received an email about or all followed items without the need to log in.

You no longer need to log in to unfollow items
Respecting your member's inbox is vital to keep on good terms with them and to keep them engaged in your community.
We'd love to know which of these features you're most keen to try in 4.4. Please drop a comment below and let us know!

Ever since its first release, the REST API built into the Invision Community software has proven to be a very powerful and well-received feature.
We love seeing what our clients and modification authors are able to do with the level of integration afforded to them through this capability, and so it is only natural that we have looked to expand the functionality in our upcoming 4.4 release.
Poll Support
Beginning with 4.4, you will now be able to create and update polls for both topics and blog entries through the REST API. Of course, modification authors can use this new endpoint.
Warn Reasons
You will also now be able to manage warn reasons through the REST API. This includes fetching a list of reasons, as well as fetching an individual reason, creating warn reasons, updating existing warn reasons, and deleting warn reasons.
Event Venues
Event venues can now be listed and individual venues fetched through the REST API, and you can now add, update and delete event venues through the REST API.
Member Notifications
You can now retrieve a list of notifications for a specific member through the REST API, useful if you were to attempt to recreate the notifications menu on a third party website (for example).
Warning Users
The REST API will now expose the warnings a user has received through a new endpoint. Additionally, you can fetch individual warnings, issue new warnings, undo and/or delete issued warnings, and acknowledge warnings through the REST API. If you are building a site wrapper around your community, you can leverage this functionality to ensure that users are unable to post elsewhere on your site if they have unacknowledged warnings within the community (and also to provide them with a way to acknowledge those warnings right on your site).

The REST API Reference
Node permissions
Beginning with 4.4, you will now be able to set the permissions for a node when adding or updating it through the REST API (for example, you can now adjust the permissions for a forum or a downloads category through the REST API). Many clients noticed that while they could create new nodes through the API, the nodes would be unusable until an administrator manually went in and specified the permissions, so this change can eliminate this extra step in many situations.
Event filtering
You will now also be able to filter the events you pull through the Calendar REST API endpoints by start and end date (e.g. so you can show events within a specific time frame, such as the current week), and you can now also specify to sort the events returned by the event start date or the event end date.
Clubs
And finally, for those who leverage clubs on their communities, we have built in full REST API support for clubs. You can list all clubs, return a specific club, create new clubs, update existing clubs, and delete clubs through the REST API. Further, you can list all members in a club, add a specific member to a specific club, remove a member from a club, fetch the content types available for use within a club (i.e. so you can determine which applications are installed and have club support on a given site), fetch the nodes (displayed as tabs/sections within a club) created within a club, and delete nodes from a club. Important behind the scenes steps, such as generating invoices for members requesting to join paid clubs, are all handled automatically for you when using the REST API.
We believe these changes will help clients better integrate with our software and open up new possibilities with their websites.
Would you like us to add any other endpoints? Let us know in the comments below!

The best way to convert guests into members is to make the onboarding process as simple as possible.
Over the years, we've added special log in methods for Facebook, Google, LinkedIn and Microsoft. We've carefully hand coded these integrations to allow guests to sign up with just a few clicks using services they're already a member of.
These services used to use proprietary methods to link with other websites, but a new standard has emerged.
OAuth
You may not know it, but you're probably familiar with OAuth already. If you have enabled the ability for users of your community to sign in with their Facebook, Twitter, Google, LinkedIn or Microsoft account, you may have noticed that the process for setting up each of these is quite similar. This is because they all use the OAuth protocol.
In Invision Community 4.3, we are introducing several exciting new features:
In addition to all of the existing social networks above, which retain their "easy setup" status, we have also added Wordpress. Users on your community can now sign in with any Wordpress site you control (you will need to install a Wordpress plugin to enable OAuth capabilities). As well as those "easy setup" options, we have also added the ability for you to allow users on your site to sign in with any OAuth 2.0 based provider. This means, for example, if your community is based in a location where other social networks are popular, if they use OAuth, you can set those up too. While the setup is a little bit more complicated, this doesn't require any custom programming - you'll just need to find out a few more pieces of information from the provider (an example is provided below). Invision Community itself can now also serve as an OAuth 2.0 server so you can set up other sites to be able to facilitate logins using credentials from your community. This works in conjunction with our REST API, allowing you to make API calls as an authenticated member, which will return just the information that user has access to. With the ability for Invision Community to serve as both an OAuth server and client, this now provides standard integration for multiple Invision Communities together, which will now replace the old IPS Connect feature. We have also taken this opportunity to make a few other minor tweaks to login, registration and account management features, especially for communities which rely heavily on non-standard login methods (more details below).  
Setting Up a Custom OAuth Provider
For this example, I'm going to use vk.com, which is a popular social network in Europe. While Invision Community doesn't provide this as one of the "easy setup" options, it is based on OAuth 2.0 so we can use the new functionality in Invision Community 4.3 to set it up.
In older versions, the list of login handlers in the AdminCP had all of the providers listed with enable/disable toggles - because now you can add as many custom handlers as you like in 4.3, it's now a list where you can add/delete options:

Login Handlers List
When clicking the "Create New" button, you'll see all of the different handlers Invision Community supports. Since vk.com isn't in the list, but is still OAuth 2.0-based, I'll choose the "Other OAuth 2.0" option:
 
Choosing a Login Handler
You'll now need to use the documentation provided by the site you want to integrate with to fill out this form. While no custom programming is required, the documentation is usually quite technical in nature - but you only need a few key pieces of information. We anticipate that for some of the more popular options, guides will be provided to help you find the information you need.
I have created an application in vk.com's developer center and so I will copy and paste my credentials into the form:

Inputting vk.com credentials
I then need to find the endpoints from vk.com's documentation and input those too.

Inputting vk.com endpoints
Next I need to find the endpoint where I can access the user's information within their API and the parameters they are returned by. The only required piece of information is an ID, but you can also provide the parameters for accessing the display name, email address and profile photo. If display name/email address isn't available/provided, the user will be asked for this the first time they sign in. vk.com's API doesn't provide access to the email, but I can use the screen name as the display name, and they do provide access to the photo:


Inputting vk.com User Information Endpoint and response parameters
Finally, provide a logo and a color for the sign in button and some final settings:

Inputting vk.com Logo and Button Color
And now vk.com login is set up. A button will now show up on the front end which I can use to sign in. I didn't provide a way to access the email address, so on the first sign in, the user will be prompted to provide that, but the screen name and profile photo from vk.com will be used:

Signing in with vk.com
 
Using Invision Community as an OAuth Server
You can also set up Invision Community itself to be an OAuth Server. This may be useful for two main reasons:
If you want to integrate two communities together, or integrate with something else which supports adding custom OAuth clients. If you are a developer and want to use the REST API using OAuth for authentication rather than an API Key. You can either make requests as an authenticated user (by obtaining an access token) or using Client Credentials. The screenshots below show the full capabilities which are quite technical and mostly aimed at developers. If you will just use this feature to link two communities, don't be concerned if it looks too complicated, an easy-to-follow guide will be available to achieve that.
You will set up the clients from the AdminCP:


Setting up an OAuth Client
When creating the OAuth Client, you can control which scopes are available, and which endpoints of the REST API they provide access to:

Defining OAuth Client Scopes
The login process is then the standard OAuth flow, and users have the ability to view authorisations in the account settings:

Authenticating an OAuth Client
The REST API has new and updated endpoints to be aware of the authenticated user:

A new REST API endpoint which returns details of the currently authenticated user

An updated REST API endpoint which, when called using OAuth authentication, will only return data the authenticated user has access to
 
Other Login System Tweaks
Users can now choose if they want to change their local display name or email address if it is changed by an external login method (or the administrator can choose this behaviour). If there is an issue with this (for example, it wants to change the email to one that is already taken), or profile photo syncing, this is now better communicated to the user. You can now control per-login-handler if new registrations are allowed using it. This addresses some confusion from previous versions as to if the "Allow New Registrations" setting applies to accounts being created by social network logins. The Standard login handler can be disabled if you rely totally on an alternate login method. To allow this to happen:  All areas where a user is prompted to re-enter their password (some areas of the account settings) now allow reauthentication using any login handler. You can disable local registration but still allow accounts to be created by other login handlers, or redirect users to an external URL to register an account. You can also disable or redirect to an external URL for changing email address / password or the Forgot Password tool. You can now create multiple instances of the external MySQL database and LDAP login methods which have also had some other minor tweaks: The external MySQL database handler now has PHP's password_hash() function as an available option for password encryption type, and defining a custom encryption method is now much easier, done entirely in the AdminCP without needing to modify PHP files. You can now choose if changes to the local display name / email address / password is synced back to the external database / LDAP database. You can optionally show these handlers in the Account Settings pages like other login handlers to allow users with an existing account to link their accounts. You can define a Forgot Password URL for the external database which the user will be redirected to if they try to use the Forgot Password tool and that is how their account is authenticated. 

Version 4.1.17 is in the final stages of development and will be released soon!
Check out the release notes for the full list of what's new and our preview articles for details on some of the most interesting changes:
Better Analytics Integration Tag Quick Edit Default Warning Notes Custom RSS Feeds Word and Link Filters Leaderboard Moderation Improvements Security and Privacy Embeds and Integration We hope you enjoy all these new additions coming in 4.1.17 and be sure to read the release notes for many smaller changes. The big feature in 4.1.17 is the new Leaderboard which we really think will enhance your community.
If you like using pre-release beta versions, the public beta of 4.1.17 will be available in the client area on 28 November. We support betas on live installs with some exceptions so give it a try if you like to be first to try the new features!

I'm pleased to announce we're finally ready to open our new Developers area. The aim of this project has been to improve our existing developer documentation by building a central place to contain it, as well as update and expand the content available.
As of today, we have the regular documentation and REST API documentation ready to use. Over the coming weeks and months, we'll be expanding what's available further, going into more detail about the tools available within the framework. We've also started work on comprehensive Getting Started guides, that will walk you through simple developer projects from start to finish - these will be available soon, once they're complete.
If there's a particular aspect of IPS4 development that you don't feel is adequately catered for right now, please let us know! This will help us direct our efforts to the most useful places.
Enjoy!

Our Pages CMS is one of our most popular applications as we are continuing to improve it based on feedback. New in 4.1.13 includes:
Designer’s Mode HTML Editing
This update allows you to edit your HTML mode pages inside the designer's mode file system. Any edits you make, once saved in your text editor are instantly available which makes it much faster to build HTML pages with Pages.

 
Database Template Improvements
We listened to a lot of feedback about templating within the AdminCP for Pages and one common request was for a way to delete a group of database templates and to rename those groups. When you import databases, the template group names are created unique but you may want to change this to something more memorable. You will see here that the dialog also shows you which databases this template is used.

 
Page titles when using databases
Currently, when you add a database to a page, the page title is replaced with the database name. This may not always be desirable, and you may want the page title to remain in all database URLs (such as record view). There is now an option for this per database.

Relational Field Improvements
Now when you create a relational link between databases, you can opt to show which records link to the relational record. To give you an example, say you had a database for actors, and a database for movies, and you created a link on the actors record to show which movies they star in; now when viewing the movie, it will show you a list of the actors.

 
More Filterable Fields
We added both "Date" and "YesNo" field types to be filterable when viewing a list of records. When you use the Date type, you can select a date range for listing articles.

We also added the ability to use any custom field set as filterable to be used when creating a database feed widget.

 
Unique Fields
Another popular request was to allow a way to force unique entries for custom fields. This means that when enabled, only one record per database can have the same value. This is enabled when creating or editing a field.

 
Other improvements
You can now quickly delete an entire media folder via the AdminCP.

You can now quickly see which databases are used on which pages via the AdminCP page list.

 
And we added a way to programatically fetch a custom field value via the $record object. Currently, you need to use something like $record->field_12 which works well until you import that database to another installation. The fields are renumbered so this syntax no longer works. We made it possible to use the field key like so $record->field_{my_key_name_here}. Not only does this solve the issue when importing databases, it is also much more readable and easier to remember!

Last week we introduced you to a couple of key new improvements in IPS Community Suite 4.1.12, the new post preview and enhanced activity streams and search. However, this is a packed release, so I wanted to quickly review what else you can expect to find when it is released this week.
Mentions
4.0 introduced mentions, and since then a frequently-requested feature is the ability to ignore notifications triggered by particular members. In 4.1.12, we enhanced the Ignore Users functionality to also allow you to block mention notifications. They will still be able to mention you in posts, but you will no longer be notified about it.

Ratings
As of 4.1.12, ratings will now display half-stars in order to be more accurate. Users will still rate whole stars out of 5 (or 10 if configured so), but the aggregated ratings displayed alongside content will be more fine-grained.
Custom date formatting
We have used built-in, automatic locale formats for dates since 4.0, but it became increasingly clear that this did not offer the flexibility that some community administrators desired. As a result, 4.1.12 re-introduces the ability to provide custom formats for dates.
Bug fixes
Amongst the handful of new features, there's over 400 other bug fixes and improvements that contribute towards the overall stability of the IPS Community Suite, as we start working towards the next major release, IPS Community Suite 4.2 which will be available later this year. Further fixes for stability in the 4.1 line will come before 4.2 is available.
 
Please check our release notes to read more about other smaller changes and fixes in 4.1.12.

We are currently beta testing our next release, 4.1.12, which contains hundreds of bug fixes, dozens of improvements, as well as a handful of new features. I wanted to introduce one of those new features: post preview.
Long-time users of our software will know that a post preview function was a standard feature, but we took the decision to not include it in the initial IPS4 release. It had a couple of drawbacks:
it only applied to certain pages, such as topic view - other WYSIWYG editors simply didn't get a preview the workflow wasn't very good for modern web apps, requiring a round-trip to the server and a full page refresh When IPS4 was released, we felt that the built-in rendering of the editor was a sufficient preview of how the end result would appear. However, while analyzing ongoing customer and user feedback for IPS4 in its first year of release, we have seen that a preview still has a use. There are some circumstances when a true WYSIWYG experience is just not possible such as using more advanced formatting (like LaTeX) or when admins create certain custom editor plugins.
As a result, we rethought post preview. We wanted to ensure that all editors could be previewed, and that it didn't have a clunky workflow. In addition, since IPS4 uses a responsive theme, we wanted to give users the opportunity to preview how their post would look on different devices.
Here's the result, and what will be available in 4.1.12:

Post preview in IPS Community Suite 4.1.12
The preview is shown by clicking a new button on the toolbar (meaning it can be moved, removed, etc. just like the other default buttons). When the preview loads, the toolbar allows the user to resize it to different device sizes. If they are on desktop, they can also view it at tablet at phone sizes; on a tablet, it can also be viewed at phone size.
So now we not only show a true preview of what content will look like when posted, but we also allow you to preview how it will look on other devices. Of course that preview is just a best-guess since different devices have different window sizes but it does give you an idea.
We hope this reimagining of an old feature for a more modern web will please end-users and make posting content a more accurate process. Stay tuned for more updates on what's included in 4.1.12!
Version 4.1.12 is currently in beta testing and should be released in the next two weeks.

We frequently encourage people to use custom CSS files when designing their themes. The reason for this is simple: it makes upgrading your site much easier because IPS4 can apply any changes to its own CSS files, and will leave your custom CSS files untouched. If instead you made edits to IPS4's CSS directly, it wouldn't be able to upgrade them automatically, which means more work for you, and a potentially broken UI on each upgrade.
Something that's not quite as common, but that we still strongly suggest, is using custom template bits as much as possible. The most common template you'd edit is globalTemplate, perhaps to include some extra resources in the <head>, a custom header, and maybe some footer pieces. The usual approach would be to simply add all of that custom HTML directly into globalTemplate, but my recommendation is that you instead create each piece as a custom template bit, and then include it.
With templates, it's not quite as much of a clear-cut benefit as with CSS; you'll still need to modify the original template in order to include your custom pieces of course. But there's still good reasons for doing so; it keeps your template as clean as possible, meaning if in a later upgrade you have to revert it to get the latest changes, reapplying your custom pieces is easy - you just add the template includes back in.
We've been taking this approach with all custom themes we've created since IPS4's release (dozens by my last count). We try and keep the naming convention consistent too. All custom templates are named _customABC.phtml and exist in the /front/global/ group in the core application. This puts them in an easy-to-find location, and because of the underscore prefix, they're shown at the top of the directory.

Example custom template bits in a custom theme
Using them is simple:
{template="_customHeader" group="global" app="core"}  
I hope this approach helps you keep your templates clean and more manageable! If you have any tips for working with your templates, please share them in the comments!

We are wrapping up testing in preparation of version 4.1.10 release. This is a follow up to 4.1.9 which introduced a lot of great enhancements.
Changes in 4.1.10 include:
Instant notifications are now dismissible. The sidebar has been added back to the Activity Stream pages. You can now sort by most downloaded in Downloads app.  The ModeratorCP and AdminCP IP Address Tools now allow you to track the IP addresses used to vote in polls. A new setting has been added to disable the RSS feed for activity streams. A new setting has been added to specify the minimum display name length. Adds a new "can unban" moderator permission separate to the "can edit profiles" permission being used previously. IP addresses now show in reports. There is now a constant-level setting to disable the ACP IP address check in case of being locked out of the ACP. Several improvements to Commerce to make some features clearer: the Shipping Rates configuration pages now indicate to the admin if a potential mistake has been made, the front-end indicates to admins if no support departments have been set up, and the renewal settings wording has been clarified. And of course countless bugs fixed and performance enhancements. View our full release notes for more details.
If you are an existing IPS client and enjoy testing pre-release software, a beta release of 4.1.10 is available. We always appreciate help testing upcoming releases.
We are already well into development on 4.1.11 which include some larger feature changes and additions.

HTML Logic is our name for the additional tags available in IPS4's templates that allow runtime logic to be executed. It comprises if/then/else statements as well as loops and more.
Since HTML Logic has access to all of the underlying PHP framework in IPS4, it's very powerful and a lot can be achieved with it. One common use is to limit certain content within a template to particular member groups. Let's see how that might be done.
 
Showing or hiding content only to guests
We'll first look at a simpler idea: showing or hiding content specifically to guests (i.e. anyone who isn't logged in). Within IPS4, the \IPS\Member::loggedIn() object contains information about the current user. Guests always have a member_id of NULL (i.e. no value), so we can simply check that value in our logic tag:
{{if \IPS\Member::loggedIn()->member_id === NULL}} This content *only* shows to guests, since they have a NULL member_id. {{endif}} {{if \IPS\Member::loggedIn()->member_id}} This content *only* shows to logged-in users since their member_id is a number, which will equal true. {{endif}}  
Showing content only to specific groups
Let's go a bit further and this time show content to specific (primary) member groups. First, you need to get the IDs for the group(s) you want to deal with. You can find this by editing the group in the AdminCP, and making a note of the id parameter in the URL. On my installation, the Administrator group is ID 4 so we'll use that in our example.
Once again, we're using the \IPS\Member::loggedIn() object, but this time we're using the member_group_id property.
{{if \IPS\Member::loggedIn()->member_group_id === 4}} This content only shows to members in the "Administrators" group (ID 4 in our example) {{endif}}  
Working with multiple groups at once
Following the code above, you could simply repeat the check against \IPS\Member::loggedIn()->member_group_id several times, for each ID you want to allow. However, since our templates allow arbitrary PHP expressions to be used, there's a neater way: use an array of member group IDs you want to allow, and check against that using PHP's in_array function. Here's an example where we only show content to group IDs 2, 4 and 6:
{{if in_array( \IPS\Member::loggedIn()->member_group_id, array( 2, 4, 6 ) )}} This content only shows to members in groups with the ID 2, 4 or 6. {{endif}}  
Have a request for a theme tip? Let us know in the comments and we'll try and help out in a future tip!