Lisownik

If you've been around Invision Community for a while, you'll know our frontend default theme hasn't significantly evolved since the early days of 4.0. Indeed, the last significant refresh came with 4.2.
With the upcoming release of 4.5, we wanted to revisit the default theme and give it a facelift for 2020, as well as make incremental improvements to the underlying codebase as a stepping stone to a bigger re-engineering in a future version. Keep an eye out for our next blog for more on the facelift.
In this entry, I want to go over some of the design and code-level changes we've implemented that will be of particular interest to third-party theme designers, or those building a custom theme for their community.
IE11 Support
Until now, we've supported IE11 as a 'B' browser - meaning we didn't aim for perfect support (especially visually), but did aim to make all functionality work, and we fixed IE11-specific issues if possible.
As of 4.5, we no longer support IE11 in any way and Invision Community will not work well in that browser. By removing support for IE11, we are able to make use of newer CSS technologies which significantly eases development for us and third-party designers. I'll discuss some of those below.
Combined theme settings
We've combined a number of existing theme settings into one new setting. We've found that settings like poll_bar, step_background, rating_hover and so on are nearly always set to the same color - typically the site's main brand color. These settings have therefore been replaced with one new brand_color setting, which is used throughout the CSS in places where this primary color would be needed. This will simplify the early stages of theme development and make it easier to match branding in Invision Community.

Front end colors
Removing hardcoded colors
While our theme settings have allowed community owners to change most colors, there were still many hardcoded in our CSS framework. These were typically neutral colors used for things like 'close' links, semi-transparent backgrounds and so on, but it was enough to make creating a dark theme an unrealistic prospect without an awful lot of effort (and kudos to those designers who have offered dark themes up until now!).
In 4.5, we've removed hardcoded colors from our framework, and instead rely on colors already defined by theme settings. You can now, finally, create a dark theme just by editing the built-in theme settings.
Type scale & {fontsize} tag
While we've had fixed type-size classes (e.g. ipsType_normal) for a long time, in practice many elements had their own font sizes set. This leads to inconsistency and poor visual rhythm too. Another side effect is it was also tough to globally change the font size (such as for branding purposes, or to create a theme for visually-impaired users).
To solve these problems, we first created a type scale; that is, a fixed number of sizes to choose from. A product the size of Invision Community does have need for a flexibility, so we settled on the following scale:
x_small: 12; small: 13; medium: 14; base: 16; large: 18; x_large: 20; 2x_large: 24; 3x_large: 30; 4x_large: 36.
All of these values are editable as theme settings, so each theme can adjust the type scale used. Our default CSS in 4.5 has been fully updated to put all type on this scale.
To actually make use of these settings, we have added a new {fontsize} tag which accepts either a scale key, or a specific pixel size (for those occasional situations where a specific size is absolutely needed, e.g. icons).
Why couldn't we just use {theme="x_small"}, or even CSS variables? To solve the problem of globally scaling text, we have also added a percentage-based scale setting that will save you from having to create your own type scale. The {fontsize} tag automatically applies the global scale to any values passed into it. Want text in your theme to be twice as big as default? Simply set the global type scale to 200% and the entire theme will reflect the change immediately. 

The new font size options
Spacing scale
The lack of a consistent spacing scale has led to some arbitrary values being used in any given situation, which again has had a negative impact on the visual harmony of our design. We've therefore implemented a 4px spacing scale (using CSS variables rather than theme settings this time) and applied across almost all padding/margin values. In time, we anticipate fully switching all measurement values to the scale.
New CSS class families
We have added a range of new spacing classes for padding and margins, allowing far more control over how these are applied, especially on different device sizes. Previously, ipsPad (15px) was simply halved on small screens - with no 'opt-out' short of adding specific CSS. We've felt this has been imprecise for some time, especially since mobile devices typically have larger screens in 2020 and don't need to be so tightly-spaced.
ipsPad_all now replaces the existing ipsPad, and does not halve itself on small screens. Instead, there's a new responsive naming convention that allows you to apply specific padding on specific device sizes:
ipsPad_all:double md:ipsPad_all sm:ipsPad_all:half
In this arbitrary example, desktop size (the default) get double padding, medium (tablets) get regular padding and small (phones) get half padding.
We've added similar classes for top, bottom, left and right padding, as well as horizontal, vertical and none (to removing all padding) shortcuts.
For margins, the old ipsSpacer_* classes have been replaced with a new ipsMargin family that work exactly the same as the padding classes above, with the same range of flexibility.
The old ipsPad/ipsSpacer classes will continue working as they did before for backwards compatibility, but should be considered deprecated from 4.5 onwards.
We've also added a whole range of new ipsFlex classes, also with responsive controls (making it easy to have horizontal layouts on desktop and vertical layouts on mobile, for example), as well as a new ipsGap utility that automatically adds spacing between elements, without requiring manual :first-child/:last-child exclusions.
CSS variables & calc()
In 4.5, thanks to IE11 support ending, we're finally making use of CSS variables and calc() to make CSS more maintainable and easier to customize. A lot of repeating or often-customized styles - such as form field styles, message colors, card styles, border radii etc. - are now created as CSS variables, allowing theme designers to easily change styling in one place. Instead of magic numbers, we either stick to our spacing scale, or use calc() to avoid hardcoded numbers.
The future
The work we've done so far is just a 'first-pass'. We'll be pressing forward with modernization throughout the 4.5.* series and beyond with a view to reducing our footprint, improving our ability to maintain our CSS and, of course, making theming easier for our customers.

We want to ensure that converting from your existing community platform to ours is as seamless as possible.
While we do have a migration service available where we take care of everything for you, we do also offer a DIY option.
We took some time to overhaul the conversion process for those opting to convert using our free tools.
Ready to convert?
So you've just purchased your first copy of Invision Community, and you're ready to convert your existing site over from another software package. Great! We're glad you've made the decision to take your community to the next level!
You've already checked out our Migrations page, confirmed the software you wish to convert from is supported, and you're confident in your ability to work through the process. You install the Converters package and you're ready to go. 
Lets get started!
We have overhauled the converters to simplify the process. Beginning with 4.4, you will take the following steps to convert from another software package:
Rather than choose the application you wish to convert first, you will now choose what software you are converting from, which is a much more logical start to a conversion. Next, you will supply the database details for your source database (the database you wish to convert into your new Invision Community). Then, you will see a list of all applications that can be converted for the software package you are converting from. If any applications cannot be converted (perhaps because you were not previously using the corresponding application in your source software), a message will be shown indicating there is nothing to convert. If any steps require additional configuration, you will be able to specify those details here. And finally, when you submit that form - that's it! You're done, and you can sit back and let the conversion process on its own. Each step for each application will be completed automatically, and the conversion will be finalized automatically at the end. A progress bar will be shown, along with a textual indicator that outlines exactly what is being converted. What does it look like?
conversion.mp4 Here's a quick video to illustrate the new conversion process.
The system even remembers where you were at and automatically picks back up where you left off. Closing your browser, losing internet connectivity, or some other unforeseen issue won't stop you dead in your tracks and force you to start all over again.
We hope that these updates make it even easier to switch from another community platform.
 

It's been said that the best place to hide a dead body is on page 2 of Google.
While we can't promise to get you to page 1 for a generic search term, we have taken some time for Invision Community 4.4 to do an SEO sweep.
Moz.com defines SEO as "a marketing discipline focused on growing visibility in organic (non-paid) search engine results. SEO encompasses both the technical and creative elements required to improve rankings, drive traffic, and increase awareness in search engines."
We have the technical skills and were fortunate enough to have Jono Alderson of Yoast lend his time, knowledge and vast experience to improve our SEO.
This blog article gets a little technical. It's completely fine to leave at this point with the comfort of knowing that Google will be a little happier on your site with Invision Community 4.4.
The majority of the changes are designed to send stronger signals to Google and friends over which content to slurp and which to look at a bit later.
Still here? Good. Let us roll up our sleeves and open the hood.

 
Pagination
The most visible change is that we've taken pagination out of query strings and placed it in the path.
For example, the current pagination system looks a little like:
yoursite.com/community/forums/123-forum/?page=3
Which is fine but it gets a little confusing when you add in a bunch of sort filters like so:
yoursite.com/community/forums/123-forum/?sort=asc&field=topic&page=3
A better approach would be to make a clear signal to both Google and humans that pagination is a separate thing.
Invision Community 4.4 does this:
yoursite.com/community/forums/123-forum/page/3/?sort=asc&field=topic
Not only is this good for search engines, but it's also good for the humans too as it is more readable and no longer confused with filter parameters.

Of course, we ensure that the old style pagination is redirected (via a 301 header) to the new pagination URL automatically so nothing breaks.
Canonical Tags
These tags are a way of telling search engines that a specific URL is the 'master copy' of a page. This helps prevent duplicate content from being indexed.
Without it, you are leaving it up to the search engine to choose which is the master copy of the page.
For example:
yoursite.com/community/forums/123-forum/ and yoursite.com/community/forums/123-forum/?sort=desc&field=time may show the same content but have different URLs.
By setting the canonical tag to point to yoursite.com/community/forums/123-forum/ regardless of filters sends a strong signal to the search engines that this is the page you want to be spidered.
Invision Community sets these tags in many places, but we audited these in 4.4 and found a few areas where they were missing.
For example, viewing a member's profile doesn't always set a canonical tag which may confuse search engines when you click on "View Activity" and get a list of content items.
Soft 404s
When an application or website wants to tell the visitor that the page they are looking for doesn't exist, it sends a 404 header code along with a page that says something "We could not find that item" or "No rows available".
If a search engine spiders a page that looks like a 404 page, but it doesn't have the 404 header code, it logs it as a "soft 404".
Given the short amount of time Google has on your site to discover new content, you don't want it to hit many soft 404s.
Invision Community 4.4 omits containers (such as forums, blogs, etc.) that have no content (such as a new forum without any topics yet) from the sitemap, and also adds a 'noindex, follow' meta tag into the HTML source.
Google will periodically check to see if the status of the page has changed and happily slurp away when content has been added.
Other changes
Although the changes listed here don't deserve their own section in this article, they are no less important.
We have audited the new JSON-LD markup added to Invision Community 4.3 to help search engines better understand the relationship between pages.
The "truncate" method that is used to display a snippet of text in areas such as the activity stream now only sends the first 500 characters to the javascript method to reduce page loads and page 'noise'.
The profile view in Invision Community contains a mix of information pertinent to the member and content they've authored.
We've ensured that the content areas are using a specific URL, with appropriate canonical tags. This will help reduce confusion for search engines.
If you made it this far, then well done. It's time to slam the hood closed and mop our collective brows.
These changes will certainly help Google and friends spider your site a little more efficiently and have a clearer idea about what pages and data you want to be indexed which can only improve your ranking.