lordi

No matter how good your content is, how accurate your keywords are or how precise your microdata is, inefficient crawling reduces the number of pages Google will read and store from your site.
Search engines need to look at and store as many pages that exist on the internet as possible. There are currently an estimated 4.5 billion web pages active today. That's a lot of work for Google.
It cannot look and store every page, so it needs to decide what to keep and how long it will spend on your site indexing pages.
Right now, Invision Community is not very good at helping Google understand what is important and how to get there quickly. This blog article runs through the changes we've made to improve crawling efficiency dramatically, starting with Invision Community 4.6.8, our November release.

The short version
This entry will get a little technical. The short version is that we remove a lot of pages from Google's view, including user profiles and filters that create faceted pages and remove a lot of redirect links to reduce the crawl depth and reduce the volume of thin content of little value. Instead, we want Google to focus wholly on topics, posts and other key user-generated content.
Let's now take a deep dive into what crawl budget is, the current problem, the solution and finally look at a before and after analysis. Note, I use the terms "Google" and "search engines" interchangeably. I know that there are many wonderful search engines available but most understand what Google is and does.
Crawl depth and budget
In terms of crawl efficiency, there are two metrics to think about: crawl depth and crawl budget. The crawl budget is the number of links Google (and other search engines) will spider per day. The time spent on your site and the number of links examined depend on multiple factors, including site age, site freshness and more. For example, Google may choose to look at fewer than 100 links per day from your site, whereas Twitter may see hundreds of thousands of links indexed per day.
Crawl depth is essentially how many links Google has to follow to index the page. The fewer links to get to a page, is better. Generally speaking, Google will reduce indexing links more than 5 to 6 clicks deep.
The current problem #1: Crawl depth
A community generates a lot of linked content. Many of these links, such as permalinks to specific posts and redirects to scroll to new posts in a topic, are very useful for logged in members but less so to spiders. These links are easy to spot; just look for "&do=getNewComment" or "&do=getLastComment" in the URL. Indeed, even guests would struggle to use these convenience links given the lack of unread tracking until logged in.  Although they offer no clear advantage to guests and search engines, they are prolific, and following the links results in a redirect which increases the crawl depth for content such as topics.
The current problem #2: Crawl budget and faceted content
A single user profile page can have around 150 redirect links to existing content. User profiles are linked from many pages. A single page of a topic will have around 25 links to user profiles. That's potentially 3,750 links Google has to crawl before deciding if any of it should be stored. Even sites with a healthy crawl budget will see a lot of their budget eaten up by links that add nothing new to the search index. These links are also very deep into the site, adding to the overall average crawl depth, which can signal search engines to reduce your crawl budget.
Filters are a valuable tool to sort lists of data in particular ways. For example, when viewing a list of topics, you can filter by the number of replies or when the topic was created. Unfortunately, these filters are a problem for search engines as they create faceted navigation, which creates duplicate pages.

The solution
There is a straightforward solution to solve all of the problems outlined above.  We can ask that Google avoids indexing certain pages. We can help by using a mix of hints and directives to ensure pages without valuable content are ignored and by reducing the number of links to get to the content. We have used "noindex" in the past, but this still eats up the crawl budget as Google has to crawl the page to learn we do not want it stored in the index.
Fortunately, Google has a hint directive called "nofollow", which you can apply in the <a href> code that wraps a link. This sends a strong hint that this link should not be read at all. However, Google may wish to follow it anyway, which means that we need to use a special file that contains firm instructions for Google on what to follow and index.
This file is called robots.txt. We can use this file to write rules to ensure search engines don't waste their valuable time looking at links that do not have valuable content; that create faceted navigational issues and links that lead to a redirect.
Invision Community will now create a dynamic robots.txt file with rules optimised for your community, or you can create custom rules if you prefer.

The new robots.txt generator in Invision Community
Analysis: Before and after
I took a benchmark crawl using a popular SEO site audit tool of my test community with 50 members and around 20,000 posts, most of which were populated from RSS feeds, so they have actual content, including links, etc. There are approximately 5,000 topics visible to guests.
Once I had implemented the "nofollow" changes, removed a lot of the redirect links for guests and added an optimised robots.txt file, I completed another crawl.
Let's compare the data from the before and after.
First up, the raw numbers show a stark difference.

Before our changes, the audit tool crawled 176,175 links, of which nearly 23% were redirect links. After, just 6,389 links were crawled, with only 0.4% being redirection links. This is a dramatic reduction in both crawl budget and crawl depth. Simply by guiding Google away from thin content like profiles, leaderboards, online lists and redirect links, we can ask it to focus on content such as topics and posts.

Note: You may notice a large drop in "Blocked by Robots.txt" in the 'after' crawl despite using a robots.txt for the first time. The calculation here also includes sharer images and other external links which are blocked by those sites robots.txt files. I added nofollow to the external links for the 'after' crawl so they were not fetched and then blocked externally.

As we can see in this before, the crawl depth has a low peak between 5 and 7 levels deep, with a strong peak at 10+.

After, the peak crawl depth is just 3. This will send a strong signal to Google that your site is optimised and worth crawling more often.
Let's look at a crawl visualisation before we made these changes. It's easy to see how most content was found via table filters, which led to a redirect (the red dots), dramatically increasing crawl depth and reducing crawl efficiency.

Compare that with the after, which shows a much more ordered crawl, with all content discoverable as expected without any red dots indicating redirects.

Conclusion
SEO is a multi-faceted discipline. In the past, we have focused on ensuring we send the correct headers, use the correct microdata such as JSON-LD and optimise meta tags. These are all vital parts of ensuring your site is optimised for crawling. However, as we can see in this blog that without focusing on the crawl budget and crawl efficiency, even the most accurately presented content is wasted if it is not discovered and added into the search index.
These simple changes will offer considerable advantages to how Google and other search engines spider your site.
The features and changes outlined in this blog will be available in our November release, which will be Invision Community 4.6.8.

Invision Community has come a long way over the past five years.
We've added many new features and invigorated the front-end user experience to keep it current and in-line with modern interfaces.
One area that has remained largely the same is the Admin Control Panel.
When we released Invision Community 4.0 back in 2014, the Admin Control Panel was updated but has stayed relatively dormant since.
But that's all about to change with the upcoming release of Invision Community 4.5!

The Admin Control Panel in 4.5 has received a substantial update, resulting in a modern color scheme and a clean, minimalistic design.
We felt that a lighter, more open design allowed the content more space and to feel less crowded. 
The dark grays have been replaced with shades of blue and aqua which closely reflects Invision Community's new branding, while other colors have been lightened and saturated.
Along with the new color scheme, the overall layout of the ACP has intentionally been kept similar to the existing version, resulting in a design that feels surprisingly familiar yet refreshingly new at the same time.

We hope you've enjoyed this small sneak peek into Invision Community 4.5 and we look forward to introducing you to some more new features in the upcoming weeks!

The General Data Protection Regulation (GDPR) is a regulation (EU 2016/679) that is intended to strengthen and unify data protection for EU residents from 25th May 2018.
How can Invision Community help?
While Invision Community enables you to collect and store information, it's important to note that you as the site owner are the data controller. If your site can collect data from EU citizens, then we recommend that you research your responsibilities.
We have introduced several new tools in Invision Community 4.2.7 to help you with compliance, and we'll run through them and the relevant sections of the regulation in this blog.
Individual Rights (More information)
Right to be informed
Invision Community has an area for you to edit your own privacy policy. This is found in the Admin CP > Settings > Terms & Privacy Policy.

 
Guidance on what the policy should contain can be found here.
Right to erasure (More information)
Invision Community allows you to delete a member from the Admin CP. If the member has left posts or comments on your community, you can elect to delete the content, or keep it but remove the author's details thereby making the content anonymous.
Lawful bases for processing (More information)
Consent (More information)
Invision Community now features a setting to not automatically opt in to administrator emails such as those sent by the bulk email system often used for newsletters when registering a new account on your community.
This feature is found in the ACP > Members > Registration Settings

 
Part of the consent regulation is to record when consent was given. The consent to opt-in for administrator emails such as bulk emails sent via the Admin CP is recorded at registration, and each time they change the setting. This record can be found in the member history log when viewing a member in the Admin CP.

If you change the Terms & Conditions, or the Privacy Policy, you can request that members accept these changes when they next log in thus giving their consent for those changes.

Cookies (More information)
Invision Community stores a small amount of data in cookies. These are used to authorize you when you re-visit a community. Other cookies are used to provide a service at the user's request, such as changing a theme or using Commerce's cart.
We have added additional features for Invision Community 4.2.7 to permit acknolwedgement that cookies will be set, and a brief page outlining the types of cookies that are set.
Invision Community has a feature that shows a small message to new visitors to the community. This is found in the Admin CP > Terms & Privacy Policy page.

 
We have pre-configured a cookie acknowledgement message using the short-tags {cookies}.
This will display as follows:

 
This links to a new page showing brief information about the types of cookies that Invision Community stores.

 
Although at the time of writing this blog entry, the regulation states that there is no exact information that you need to show on the cookie page, you can edit it to add more detail if you wish.
Summary
We hope these new tools available with Invision Community 4.2.7 make it easier for you to seek compliance with GDPR if you choose to do so.
It's worth pointing out that we are awesome at making community software and know a huge amount about making communities successful, but we are not experts in EU regulation. We offer this blog entry as a way to assist you in seeking compliance but you must do your own research and are responsible for your own community.
Invision Community 4.2.7 is currently in beta testing. We're aiming to release it early next week.
We hope this is a good starting point for you!

This entry is about our IPS Community Suite 4.2 release.
We are happy to introduce the next major feature that will be available in IPS Community Suite 4.2 - Clubs.
Clubs are a brand new way of supporting sub-communities within your site. Many people have requested social group functionality in the past and Clubs are our implementation of this concept. Let's take a look at a few screenshots, and then go over what they are capable of doing.

The Club directory

A Club homepage

Club member listing

Example of content within a club (topics, in this case)
There's a lot to digest there! Let's go over the basic functionality.
 
Club Types
Four types of club are available:
Public clubs
Clubs that anyone can see and participate in without joining. Open club
Clubs that anyone can see and join. Closed club
Clubs that anyone can see in the directory, but joining must be approved by a Club Leader or Club Moderator. Non-club-members who view the club will only see the member list - not the recent activity or content areas. Private club
Clubs that do not show in public, and users must be invited by a Club Leader or Club Moderator As the site admin, you can of course configure which club types can be created and by whom. You could, for example, allow members to create public and open clubs, but allow a "VIP" group to also create Closed and Private clubs.

Admin configuration option for Club creations
 
Club Users
Each club has three levels of user:
Leader
A leader has all of the permissions of a moderator, and can add other moderators. They can also add content areas (see below). The club owner is automatically a leader. Moderators
Moderators, as the name implies, have the ability to moderate content posted within the club. As the site administrator, you can define which moderator tools can be used. You could, for example, prevent any content being deleted from clubs, but allow it to be hidden. Moderators can also remove members from a club. Users
Anyone else that joins the club.
Defining the moderator permissions available to club moderators
Your site administrator and moderators, with the appropriate permissions, are able to moderator content in any Club regardless of whether they are a member of it. 
Clubs can be created by any user who has permission. As you would expect, this is controlled by our regular permission settings.
For closed clubs, there's an approval process. Users can request to join and the request must be approved by a leader. Leaders get a notification when a user requests to join; the user gets a notification when their request is approved or denied.

Approving and declining join requests
 
Club Content
Club Leaders can add a variety of content areas to their club - forums, calendars, blogs and so on. It's important to note that these content areas are fully functional just as if they existed as a top-level admin created area. They will appear in search results, activity streams, users can follow them, embed links to them, and so on. If a user has permission to see a forum (for example) within a club it will behave exactly like other forums they see - and the same for all other kinds of content.
Each content area a leader adds can have a custom title, and will appear in the club navigation. This means, for example, that you can have multiple forums within a club, and give each a different name.

Adding content areas to a club
 
Club Custom Fields
Clubs also support custom fields. Custom fields are defined by the site administrator and can be filled in by Club Owners. The values they enter are shown (along with the club description) on the club homepage.

Custom fields in a club
On the Club Directory page, users can filter by the custom club fields.

Filtering clubs
 
Club Locations
Clubs have built-in support for Google Maps, allowing users to specify a physical location for their club. Let's say you run a community for car enthusiasts; each club might be tied to a particular region's meetup. The Club Owner specifies the location when setting up the club, and clubs are then shown on map on the directory page:

Club locations
And within a club, the location is shown too:

 
Club Display
We offer two ways to display club headers within the club - the standard way, shown in the screenshots you've seen up to this point, but we also have a sidebar option. This is something the admin sets globally for the site, rather than per-club. This is useful where your site design doesn't facilitate another horizontal banner taking up valuable screen real-estate; moving the club banner to the sidebar alleviates this pressure on vertical space.

Sidebar club style
Using Clubs in Other Ways
There's a lot of scope for using clubs beyond allowing users to create their own groups. You do not even have to call them "clubs" if that does not suit your use case. For example, on a company intranet you could rename Clubs to "Departments", and create a private group for each of your main roles. This would allow each department to have its own community, with its own forums, gallery, file sharing and so on, private and separate from other departments.
Similarly, they'd also work well in situations where you as the site admin want to create entire micro-communities. Take for example a video game publisher. Using Clubs, they could create a micro-community for each of their games, complete with forums, galleries and so forth, and then set the Clubs directory as their overall community homepage. Immediately, they have a setup that hasn't until now been possible out-of-the-box with IPS Community Suite.
 
We expect our clients will come up with some really innovative uses for the new Club functionality, and we can't wait to see what you do. We'd love to hear your feedback - let us know what you think in the comments.

Version 4.1.19 is now available in the client area!
This release focuses on bug fixes and performance along with some new key features.
Ability for members to lock and unlock their own content
We've added a new group level option to allow members to lock and unlock their own content. This is disabled by default.

Messenger Quota Display
To help diagnose issues your members may find, we now display their personal message quota in the ACP.

Default view for Activity Stream
When creating a new activity stream, you can specify either expanded or condensed as the default view. This is especially handy for streams you wish to share with other members.

Other key changes include:
Performance and speed improvements. A new moderator setting to restrict users from ignoring moderators. A new group setting to hide a group from filters in search. When moving content moderators are now prompted for where you want to be redirected after the action. An email is now sent when an account is locked for too many bad login attempts. Check out the Release Notes for a full list of changes.

Version 4.1.18 is now available in the client area!
Two large changes include Two Factor Authentication:
And changes to make Google less jumpy about password inputs:
Some smaller changes include:
Pinterest share link has been added Images embedded in the editor can now have an alternative title set for accessibility The Approval Queue page now has a "Hide" button to hide content (rather than only being able to approve / delete) Disabling Profile Photo uploads will now also disable importing from a URL The Admin CP will now indicate whether or not a member is connected to a social network The Admin CP will now display more information for a user who has been banned imgur embedded is now supported Check out the Release Notes for a full list of changes.

We are releasing a patch for IP.Board 3.4.x and IP.Nexus 1.5.x to address two potential security issues brought to our attention.

It has been brought to our attention that an open redirect exists within IP.Nexus which might allow a user to redirect other users to a remote site of their choosing through IP.Nexus. Additionally, an issue has been brought to our attention where-by sensitive user data may be exposed in certain circumstances.


To apply the patch
Simply download the attached zip and upload the files to your server. This single zip file includes the patch files for both IP.Board as well as IP.Nexus.
 
patch-34x-05252016.zip
 
If you are an IPS Community in the Cloud client running IP.Board 3.4 or above, no further action is necessary as we have already automatically patched your account. If you are using a version older than IP.Board 3.4, you should contact support to upgrade.

If you install or upgrade to IP.Board 3.4.9 after the date and time of this post, no further action is necessary as we have already updated the main download zips.