LukasGr.

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. 

Our recent release of Invision Community 4.2 was the most well-received version ever! The feedback we received on new features like Clubs, Reactions, and Promotes was better than we could have hoped and we really enjoyed seeing all the creative uses as people implemented them on their own communities.
We have been hard at work on version 4.3 with a goal of improving on all the great new features. It is well under way and we are happy to able to start announcing what's new over the next few weeks.
Invision Community 4.3 will not only contain new features but also have a core focus on refinement from 4.2's new features. You will see many improvements to Clubs, new integration options, large application improvements, new promotional features, and more changes large and small.

 
You can expect to see news posts about new features and changes very soon with a release date in early 2018. Follow our news section or subscribe to our newsletter to receive updates.

This entry is about our IPS Community Suite 4.2 release.
Improving your SEO can be a complex undertaking with many different approaches but there are things that everyone knows are good practice and also more modern approaches to SEO that have changed since we first started developing IPS Community Suite. So it was time for a review and update.
Unfortunately no pretty screenshots on this one as this is all behind the scenes stuff but still quite useful to know . Also, some of this may sound a bit technical and dry but feel free to search some of these technologies if you are curious.
Move from HTML structured data to JSON-LD and enhance our existing markup with sensible additions. Calendar, blog, forum and pages (articles) data marked up for rich snippets. General review of our schema.org markup and enhance where appropriate. Use sitelinks search and other sensible markup such as the website and logo markup. Allow administrators to specify social profile links in the AdminCP which we then show links to in the footer and also make available in schema.org markup. Fix many duplicate page title issues. Review and ensure nofollow/noindex tags are used in appropriate areas. Add item tags as HTML meta tags Adding <link rel="next" value="next page url"> helps search engines know next/previous page.  
Nothing like a bulleted list of items to get you excited! But really these should be welcome improvements to all.
 

Occasionally you'll want to style a specific element on a specific page of your community - maybe you want to change how topic titles are shown inside a topic, or do something specific to the styles used in activity streams, without also altering other screens where the same elements are used.
Your first instinct might be to open the template editor and add some custom classnames so you can style them. This would certainly work, but the downside is your template is now customized, so any future IPS4 updates would leave the template out of date. Not ideal by any means.
Instead, you can use some helpful attributes that IPS4 adds to the body element, and then build a CSS selector around them. There's four attributes, and they always reference the current page the user is on:
data-pageApp - The application key (e.g. core, forums, cms etc.) data-pageModule - The current module with the application (e.g. pages) data-pageController - The current controller within the module (e.g. topic, page etc.) data-pageLocation - Either admin or front. So let's say we want to change how the .ipsPageHeader element looks within topic view. Our selector would look like this:
body[data-pageapp="forums"][data-pagemodule="forums"][data-pagecontroller="topic"] .ipsPageHeader { ...your styles } If you don't want to be that specific, you can just use the attributes you need. For example, if you want to change all .ipsPageHeader styles in the Forums app, you'd do:
body[data-pageapp="forums"] .ipsPageHeader { ...your styles } Tip: If you don't know the correct app/module/controller for the page you're on, you can find out by visiting the page and then viewing the page source. You'll see these attributes in the body tag near the top.
And as always, be sure you add your CSS to custom.css to keep your upgrades easy  
This theme tip is taken from our guides section.