Reputation from Rikki - Page 30 - Invision Community

Rikki got a reaction from Sonya* for a blog entry, Theme Tip: Dynamic(ish) forum feeds inside Pages databases April 10, 2020

Recently, we had a post in our pre-sales forum that asked how to achieve a few different things with Pages. One of the questions asked was if it was possible to show topics from a particular forum in each database record. While Pages can create a topic for each record for you, there's no way to associate an entire forum with a record.
In my reply, I indicate that you'd need to have a forum ID stored with each record in a custom field, and then use PHP to interact with our API to pull the topic list.
As it turns out, however, there's an easier way that I discovered after some experimentation. In hindsight it's obvious, but I want to share it here because it could open up some other interesting possibilities with some creative uses.
Setting up blocks
The first thing we need to do is create our blocks. We're going to create a block for each of our forums. You can set whatever parameters you want here, but the important thing is that they're named consistently using the forum ID. So, for my forum ID 2, I've named the block forum_2. This will allow us to include our blocks later.

Creating one of the blocks we'll need

Adding the field
Next we'll need to create a field in our Pages database that will be used to set the forum ID that is going to show in each record. For simplicity, I'm creating a Number field and I'll enter the forum ID manually, but if you wanted to go further, you could create a Select Box field, with the key being each forum and the value being the name. This would give you a friendlier input from which to select the forum for each record.
Here, though, I've just created the Number field, and named it Forum ID.

Setting up the database field

Using the field formatter to show the correct block
Finally, we'll use the Field Formatting options to show the correct block based on the forum ID entered for each record. On the Display Options tab, I'm going to hide the field from the listing template, but show it on the display template. I've selected Custom as the format, then entered this format:
{{if $formValue}} {block="forum_{$formValue}"} {{endif}} That's it - that's all you need for this to work. It's very simple. All we're doing is passing the $formValue of the field (which is the raw value) into the {block} tag as a variable, so that the block that is rendered depends on this value. As long as a block exists with the correct key, it'll be shown in the display view:

End result, with the correct block pulled in based on the ID we provided to the record

Going further
So, given that we know we can use variables in block names to pull in different content (providing the block has been created ahead of time), what other possibilities are there? For starters, we aren't just restricted to using field formatters. Instead, we could use blocks directly in the database templates, using some of the data available there.
Here's one idea - if you have just a few staff members posting records, you could create a block for each staff member that lists their recent posts, status updates, etc. In your database template, you could include the correct block by doing this:
{block="content_for_{$record->author()->member_id}"}
I hope this relatively simple approach gives you some ideas for more creative ways to use blocks. If you have any suggestions for other ways to use this approach, please let us know in the comments!

Rikki got a reaction from MySimS3k® for a blog entry, Theme Tip: Using custom template bits April 7, 2019

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!

Rikki got a reaction from WorthlessJ for a blog entry, Theme Tip: Styling specific elements on specific pages October 21, 2018

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.

Rikki got a reaction from Cemmos for a blog entry, Theme Tip: Using custom template bits January 13, 2018

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!

Rikki got a reaction from RaZor Edge for a blog entry, Theme Tip: Styling specific elements on specific pages January 10, 2017

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.

Rikki got a reaction from Noni for a blog entry, Theme Tip: Dynamic(ish) forum feeds inside Pages databases August 9, 2016

Recently, we had a post in our pre-sales forum that asked how to achieve a few different things with Pages. One of the questions asked was if it was possible to show topics from a particular forum in each database record. While Pages can create a topic for each record for you, there's no way to associate an entire forum with a record.
In my reply, I indicate that you'd need to have a forum ID stored with each record in a custom field, and then use PHP to interact with our API to pull the topic list.
As it turns out, however, there's an easier way that I discovered after some experimentation. In hindsight it's obvious, but I want to share it here because it could open up some other interesting possibilities with some creative uses.
Setting up blocks
The first thing we need to do is create our blocks. We're going to create a block for each of our forums. You can set whatever parameters you want here, but the important thing is that they're named consistently using the forum ID. So, for my forum ID 2, I've named the block forum_2. This will allow us to include our blocks later.

Creating one of the blocks we'll need

Adding the field
Next we'll need to create a field in our Pages database that will be used to set the forum ID that is going to show in each record. For simplicity, I'm creating a Number field and I'll enter the forum ID manually, but if you wanted to go further, you could create a Select Box field, with the key being each forum and the value being the name. This would give you a friendlier input from which to select the forum for each record.
Here, though, I've just created the Number field, and named it Forum ID.

Setting up the database field

Using the field formatter to show the correct block
Finally, we'll use the Field Formatting options to show the correct block based on the forum ID entered for each record. On the Display Options tab, I'm going to hide the field from the listing template, but show it on the display template. I've selected Custom as the format, then entered this format:
{{if $formValue}} {block="forum_{$formValue}"} {{endif}} That's it - that's all you need for this to work. It's very simple. All we're doing is passing the $formValue of the field (which is the raw value) into the {block} tag as a variable, so that the block that is rendered depends on this value. As long as a block exists with the correct key, it'll be shown in the display view:

End result, with the correct block pulled in based on the ID we provided to the record

Going further
So, given that we know we can use variables in block names to pull in different content (providing the block has been created ahead of time), what other possibilities are there? For starters, we aren't just restricted to using field formatters. Instead, we could use blocks directly in the database templates, using some of the data available there.
Here's one idea - if you have just a few staff members posting records, you could create a block for each staff member that lists their recent posts, status updates, etc. In your database template, you could include the correct block by doing this:
{block="content_for_{$record->author()->member_id}"}
I hope this relatively simple approach gives you some ideas for more creative ways to use blocks. If you have any suggestions for other ways to use this approach, please let us know in the comments!

Rikki got a reaction from Phillip for a blog entry, Theme Tip: Dynamic(ish) forum feeds inside Pages databases July 3, 2016

Recently, we had a post in our pre-sales forum that asked how to achieve a few different things with Pages. One of the questions asked was if it was possible to show topics from a particular forum in each database record. While Pages can create a topic for each record for you, there's no way to associate an entire forum with a record.
In my reply, I indicate that you'd need to have a forum ID stored with each record in a custom field, and then use PHP to interact with our API to pull the topic list.
As it turns out, however, there's an easier way that I discovered after some experimentation. In hindsight it's obvious, but I want to share it here because it could open up some other interesting possibilities with some creative uses.
Setting up blocks
The first thing we need to do is create our blocks. We're going to create a block for each of our forums. You can set whatever parameters you want here, but the important thing is that they're named consistently using the forum ID. So, for my forum ID 2, I've named the block forum_2. This will allow us to include our blocks later.

Creating one of the blocks we'll need

Adding the field
Next we'll need to create a field in our Pages database that will be used to set the forum ID that is going to show in each record. For simplicity, I'm creating a Number field and I'll enter the forum ID manually, but if you wanted to go further, you could create a Select Box field, with the key being each forum and the value being the name. This would give you a friendlier input from which to select the forum for each record.
Here, though, I've just created the Number field, and named it Forum ID.

Setting up the database field

Using the field formatter to show the correct block
Finally, we'll use the Field Formatting options to show the correct block based on the forum ID entered for each record. On the Display Options tab, I'm going to hide the field from the listing template, but show it on the display template. I've selected Custom as the format, then entered this format:
{{if $formValue}} {block="forum_{$formValue}"} {{endif}} That's it - that's all you need for this to work. It's very simple. All we're doing is passing the $formValue of the field (which is the raw value) into the {block} tag as a variable, so that the block that is rendered depends on this value. As long as a block exists with the correct key, it'll be shown in the display view:

End result, with the correct block pulled in based on the ID we provided to the record

Going further
So, given that we know we can use variables in block names to pull in different content (providing the block has been created ahead of time), what other possibilities are there? For starters, we aren't just restricted to using field formatters. Instead, we could use blocks directly in the database templates, using some of the data available there.
Here's one idea - if you have just a few staff members posting records, you could create a block for each staff member that lists their recent posts, status updates, etc. In your database template, you could include the correct block by doing this:
{block="content_for_{$record->author()->member_id}"}
I hope this relatively simple approach gives you some ideas for more creative ways to use blocks. If you have any suggestions for other ways to use this approach, please let us know in the comments!

Rikki got a reaction from Luis_angel for a blog entry, Theme Tip: Dynamic(ish) forum feeds inside Pages databases July 2, 2016

Recently, we had a post in our pre-sales forum that asked how to achieve a few different things with Pages. One of the questions asked was if it was possible to show topics from a particular forum in each database record. While Pages can create a topic for each record for you, there's no way to associate an entire forum with a record.
In my reply, I indicate that you'd need to have a forum ID stored with each record in a custom field, and then use PHP to interact with our API to pull the topic list.
As it turns out, however, there's an easier way that I discovered after some experimentation. In hindsight it's obvious, but I want to share it here because it could open up some other interesting possibilities with some creative uses.
Setting up blocks
The first thing we need to do is create our blocks. We're going to create a block for each of our forums. You can set whatever parameters you want here, but the important thing is that they're named consistently using the forum ID. So, for my forum ID 2, I've named the block forum_2. This will allow us to include our blocks later.

Creating one of the blocks we'll need

Adding the field
Next we'll need to create a field in our Pages database that will be used to set the forum ID that is going to show in each record. For simplicity, I'm creating a Number field and I'll enter the forum ID manually, but if you wanted to go further, you could create a Select Box field, with the key being each forum and the value being the name. This would give you a friendlier input from which to select the forum for each record.
Here, though, I've just created the Number field, and named it Forum ID.

Setting up the database field

Using the field formatter to show the correct block
Finally, we'll use the Field Formatting options to show the correct block based on the forum ID entered for each record. On the Display Options tab, I'm going to hide the field from the listing template, but show it on the display template. I've selected Custom as the format, then entered this format:
{{if $formValue}} {block="forum_{$formValue}"} {{endif}} That's it - that's all you need for this to work. It's very simple. All we're doing is passing the $formValue of the field (which is the raw value) into the {block} tag as a variable, so that the block that is rendered depends on this value. As long as a block exists with the correct key, it'll be shown in the display view:

End result, with the correct block pulled in based on the ID we provided to the record

Going further
So, given that we know we can use variables in block names to pull in different content (providing the block has been created ahead of time), what other possibilities are there? For starters, we aren't just restricted to using field formatters. Instead, we could use blocks directly in the database templates, using some of the data available there.
Here's one idea - if you have just a few staff members posting records, you could create a block for each staff member that lists their recent posts, status updates, etc. In your database template, you could include the correct block by doing this:
{block="content_for_{$record->author()->member_id}"}
I hope this relatively simple approach gives you some ideas for more creative ways to use blocks. If you have any suggestions for other ways to use this approach, please let us know in the comments!

Rikki got a reaction from ipbfuck for a blog entry, Theme Tip: Dynamic(ish) forum feeds inside Pages databases May 14, 2016

Recently, we had a post in our pre-sales forum that asked how to achieve a few different things with Pages. One of the questions asked was if it was possible to show topics from a particular forum in each database record. While Pages can create a topic for each record for you, there's no way to associate an entire forum with a record.
In my reply, I indicate that you'd need to have a forum ID stored with each record in a custom field, and then use PHP to interact with our API to pull the topic list.
As it turns out, however, there's an easier way that I discovered after some experimentation. In hindsight it's obvious, but I want to share it here because it could open up some other interesting possibilities with some creative uses.
Setting up blocks
The first thing we need to do is create our blocks. We're going to create a block for each of our forums. You can set whatever parameters you want here, but the important thing is that they're named consistently using the forum ID. So, for my forum ID 2, I've named the block forum_2. This will allow us to include our blocks later.

Creating one of the blocks we'll need

Adding the field
Next we'll need to create a field in our Pages database that will be used to set the forum ID that is going to show in each record. For simplicity, I'm creating a Number field and I'll enter the forum ID manually, but if you wanted to go further, you could create a Select Box field, with the key being each forum and the value being the name. This would give you a friendlier input from which to select the forum for each record.
Here, though, I've just created the Number field, and named it Forum ID.

Setting up the database field

Using the field formatter to show the correct block
Finally, we'll use the Field Formatting options to show the correct block based on the forum ID entered for each record. On the Display Options tab, I'm going to hide the field from the listing template, but show it on the display template. I've selected Custom as the format, then entered this format:
{{if $formValue}} {block="forum_{$formValue}"} {{endif}} That's it - that's all you need for this to work. It's very simple. All we're doing is passing the $formValue of the field (which is the raw value) into the {block} tag as a variable, so that the block that is rendered depends on this value. As long as a block exists with the correct key, it'll be shown in the display view:

End result, with the correct block pulled in based on the ID we provided to the record

Going further
So, given that we know we can use variables in block names to pull in different content (providing the block has been created ahead of time), what other possibilities are there? For starters, we aren't just restricted to using field formatters. Instead, we could use blocks directly in the database templates, using some of the data available there.
Here's one idea - if you have just a few staff members posting records, you could create a block for each staff member that lists their recent posts, status updates, etc. In your database template, you could include the correct block by doing this:
{block="content_for_{$record->author()->member_id}"}
I hope this relatively simple approach gives you some ideas for more creative ways to use blocks. If you have any suggestions for other ways to use this approach, please let us know in the comments!

Rikki got a reaction from Matt for a blog entry, Theme Tip: Dynamic(ish) forum feeds inside Pages databases May 11, 2016

Recently, we had a post in our pre-sales forum that asked how to achieve a few different things with Pages. One of the questions asked was if it was possible to show topics from a particular forum in each database record. While Pages can create a topic for each record for you, there's no way to associate an entire forum with a record.
In my reply, I indicate that you'd need to have a forum ID stored with each record in a custom field, and then use PHP to interact with our API to pull the topic list.
As it turns out, however, there's an easier way that I discovered after some experimentation. In hindsight it's obvious, but I want to share it here because it could open up some other interesting possibilities with some creative uses.
Setting up blocks
The first thing we need to do is create our blocks. We're going to create a block for each of our forums. You can set whatever parameters you want here, but the important thing is that they're named consistently using the forum ID. So, for my forum ID 2, I've named the block forum_2. This will allow us to include our blocks later.

Creating one of the blocks we'll need

Adding the field
Next we'll need to create a field in our Pages database that will be used to set the forum ID that is going to show in each record. For simplicity, I'm creating a Number field and I'll enter the forum ID manually, but if you wanted to go further, you could create a Select Box field, with the key being each forum and the value being the name. This would give you a friendlier input from which to select the forum for each record.
Here, though, I've just created the Number field, and named it Forum ID.

Setting up the database field

Using the field formatter to show the correct block
Finally, we'll use the Field Formatting options to show the correct block based on the forum ID entered for each record. On the Display Options tab, I'm going to hide the field from the listing template, but show it on the display template. I've selected Custom as the format, then entered this format:
{{if $formValue}} {block="forum_{$formValue}"} {{endif}} That's it - that's all you need for this to work. It's very simple. All we're doing is passing the $formValue of the field (which is the raw value) into the {block} tag as a variable, so that the block that is rendered depends on this value. As long as a block exists with the correct key, it'll be shown in the display view:

End result, with the correct block pulled in based on the ID we provided to the record

Going further
So, given that we know we can use variables in block names to pull in different content (providing the block has been created ahead of time), what other possibilities are there? For starters, we aren't just restricted to using field formatters. Instead, we could use blocks directly in the database templates, using some of the data available there.
Here's one idea - if you have just a few staff members posting records, you could create a block for each staff member that lists their recent posts, status updates, etc. In your database template, you could include the correct block by doing this:
{block="content_for_{$record->author()->member_id}"}
I hope this relatively simple approach gives you some ideas for more creative ways to use blocks. If you have any suggestions for other ways to use this approach, please let us know in the comments!

Rikki got a reaction from amir_christ for a blog entry, Theme Tip: Using custom template bits May 11, 2016

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!

Rikki got a reaction from amir_christ for a blog entry, Theme Tip: Dynamic(ish) forum feeds inside Pages databases May 11, 2016

Recently, we had a post in our pre-sales forum that asked how to achieve a few different things with Pages. One of the questions asked was if it was possible to show topics from a particular forum in each database record. While Pages can create a topic for each record for you, there's no way to associate an entire forum with a record.
In my reply, I indicate that you'd need to have a forum ID stored with each record in a custom field, and then use PHP to interact with our API to pull the topic list.
As it turns out, however, there's an easier way that I discovered after some experimentation. In hindsight it's obvious, but I want to share it here because it could open up some other interesting possibilities with some creative uses.
Setting up blocks
The first thing we need to do is create our blocks. We're going to create a block for each of our forums. You can set whatever parameters you want here, but the important thing is that they're named consistently using the forum ID. So, for my forum ID 2, I've named the block forum_2. This will allow us to include our blocks later.

Creating one of the blocks we'll need

Adding the field
Next we'll need to create a field in our Pages database that will be used to set the forum ID that is going to show in each record. For simplicity, I'm creating a Number field and I'll enter the forum ID manually, but if you wanted to go further, you could create a Select Box field, with the key being each forum and the value being the name. This would give you a friendlier input from which to select the forum for each record.
Here, though, I've just created the Number field, and named it Forum ID.

Setting up the database field

Using the field formatter to show the correct block
Finally, we'll use the Field Formatting options to show the correct block based on the forum ID entered for each record. On the Display Options tab, I'm going to hide the field from the listing template, but show it on the display template. I've selected Custom as the format, then entered this format:
{{if $formValue}} {block="forum_{$formValue}"} {{endif}} That's it - that's all you need for this to work. It's very simple. All we're doing is passing the $formValue of the field (which is the raw value) into the {block} tag as a variable, so that the block that is rendered depends on this value. As long as a block exists with the correct key, it'll be shown in the display view:

End result, with the correct block pulled in based on the ID we provided to the record

Going further
So, given that we know we can use variables in block names to pull in different content (providing the block has been created ahead of time), what other possibilities are there? For starters, we aren't just restricted to using field formatters. Instead, we could use blocks directly in the database templates, using some of the data available there.
Here's one idea - if you have just a few staff members posting records, you could create a block for each staff member that lists their recent posts, status updates, etc. In your database template, you could include the correct block by doing this:
{block="content_for_{$record->author()->member_id}"}
I hope this relatively simple approach gives you some ideas for more creative ways to use blocks. If you have any suggestions for other ways to use this approach, please let us know in the comments!

Rikki got a reaction from opentype for a blog entry, Theme Tip: Dynamic(ish) forum feeds inside Pages databases May 10, 2016

Recently, we had a post in our pre-sales forum that asked how to achieve a few different things with Pages. One of the questions asked was if it was possible to show topics from a particular forum in each database record. While Pages can create a topic for each record for you, there's no way to associate an entire forum with a record.
In my reply, I indicate that you'd need to have a forum ID stored with each record in a custom field, and then use PHP to interact with our API to pull the topic list.
As it turns out, however, there's an easier way that I discovered after some experimentation. In hindsight it's obvious, but I want to share it here because it could open up some other interesting possibilities with some creative uses.
Setting up blocks
The first thing we need to do is create our blocks. We're going to create a block for each of our forums. You can set whatever parameters you want here, but the important thing is that they're named consistently using the forum ID. So, for my forum ID 2, I've named the block forum_2. This will allow us to include our blocks later.

Creating one of the blocks we'll need

Adding the field
Next we'll need to create a field in our Pages database that will be used to set the forum ID that is going to show in each record. For simplicity, I'm creating a Number field and I'll enter the forum ID manually, but if you wanted to go further, you could create a Select Box field, with the key being each forum and the value being the name. This would give you a friendlier input from which to select the forum for each record.
Here, though, I've just created the Number field, and named it Forum ID.

Setting up the database field

Using the field formatter to show the correct block
Finally, we'll use the Field Formatting options to show the correct block based on the forum ID entered for each record. On the Display Options tab, I'm going to hide the field from the listing template, but show it on the display template. I've selected Custom as the format, then entered this format:
{{if $formValue}} {block="forum_{$formValue}"} {{endif}} That's it - that's all you need for this to work. It's very simple. All we're doing is passing the $formValue of the field (which is the raw value) into the {block} tag as a variable, so that the block that is rendered depends on this value. As long as a block exists with the correct key, it'll be shown in the display view:

End result, with the correct block pulled in based on the ID we provided to the record

Going further
So, given that we know we can use variables in block names to pull in different content (providing the block has been created ahead of time), what other possibilities are there? For starters, we aren't just restricted to using field formatters. Instead, we could use blocks directly in the database templates, using some of the data available there.
Here's one idea - if you have just a few staff members posting records, you could create a block for each staff member that lists their recent posts, status updates, etc. In your database template, you could include the correct block by doing this:
{block="content_for_{$record->author()->member_id}"}
I hope this relatively simple approach gives you some ideas for more creative ways to use blocks. If you have any suggestions for other ways to use this approach, please let us know in the comments!

Rikki got a reaction from InsideEdge for a blog entry, Theme Tip: Dynamic(ish) forum feeds inside Pages databases May 10, 2016

Recently, we had a post in our pre-sales forum that asked how to achieve a few different things with Pages. One of the questions asked was if it was possible to show topics from a particular forum in each database record. While Pages can create a topic for each record for you, there's no way to associate an entire forum with a record.
In my reply, I indicate that you'd need to have a forum ID stored with each record in a custom field, and then use PHP to interact with our API to pull the topic list.
As it turns out, however, there's an easier way that I discovered after some experimentation. In hindsight it's obvious, but I want to share it here because it could open up some other interesting possibilities with some creative uses.
Setting up blocks
The first thing we need to do is create our blocks. We're going to create a block for each of our forums. You can set whatever parameters you want here, but the important thing is that they're named consistently using the forum ID. So, for my forum ID 2, I've named the block forum_2. This will allow us to include our blocks later.

Creating one of the blocks we'll need

Adding the field
Next we'll need to create a field in our Pages database that will be used to set the forum ID that is going to show in each record. For simplicity, I'm creating a Number field and I'll enter the forum ID manually, but if you wanted to go further, you could create a Select Box field, with the key being each forum and the value being the name. This would give you a friendlier input from which to select the forum for each record.
Here, though, I've just created the Number field, and named it Forum ID.

Setting up the database field

Using the field formatter to show the correct block
Finally, we'll use the Field Formatting options to show the correct block based on the forum ID entered for each record. On the Display Options tab, I'm going to hide the field from the listing template, but show it on the display template. I've selected Custom as the format, then entered this format:
{{if $formValue}} {block="forum_{$formValue}"} {{endif}} That's it - that's all you need for this to work. It's very simple. All we're doing is passing the $formValue of the field (which is the raw value) into the {block} tag as a variable, so that the block that is rendered depends on this value. As long as a block exists with the correct key, it'll be shown in the display view:

End result, with the correct block pulled in based on the ID we provided to the record

Going further
So, given that we know we can use variables in block names to pull in different content (providing the block has been created ahead of time), what other possibilities are there? For starters, we aren't just restricted to using field formatters. Instead, we could use blocks directly in the database templates, using some of the data available there.
Here's one idea - if you have just a few staff members posting records, you could create a block for each staff member that lists their recent posts, status updates, etc. In your database template, you could include the correct block by doing this:
{block="content_for_{$record->author()->member_id}"}
I hope this relatively simple approach gives you some ideas for more creative ways to use blocks. If you have any suggestions for other ways to use this approach, please let us know in the comments!

Rikki got a reaction from sobrenome for a blog entry, Theme Tip: Dynamic(ish) forum feeds inside Pages databases May 9, 2016

Recently, we had a post in our pre-sales forum that asked how to achieve a few different things with Pages. One of the questions asked was if it was possible to show topics from a particular forum in each database record. While Pages can create a topic for each record for you, there's no way to associate an entire forum with a record.
In my reply, I indicate that you'd need to have a forum ID stored with each record in a custom field, and then use PHP to interact with our API to pull the topic list.
As it turns out, however, there's an easier way that I discovered after some experimentation. In hindsight it's obvious, but I want to share it here because it could open up some other interesting possibilities with some creative uses.
Setting up blocks
The first thing we need to do is create our blocks. We're going to create a block for each of our forums. You can set whatever parameters you want here, but the important thing is that they're named consistently using the forum ID. So, for my forum ID 2, I've named the block forum_2. This will allow us to include our blocks later.

Creating one of the blocks we'll need

Adding the field
Next we'll need to create a field in our Pages database that will be used to set the forum ID that is going to show in each record. For simplicity, I'm creating a Number field and I'll enter the forum ID manually, but if you wanted to go further, you could create a Select Box field, with the key being each forum and the value being the name. This would give you a friendlier input from which to select the forum for each record.
Here, though, I've just created the Number field, and named it Forum ID.

Setting up the database field

Using the field formatter to show the correct block
Finally, we'll use the Field Formatting options to show the correct block based on the forum ID entered for each record. On the Display Options tab, I'm going to hide the field from the listing template, but show it on the display template. I've selected Custom as the format, then entered this format:
{{if $formValue}} {block="forum_{$formValue}"} {{endif}} That's it - that's all you need for this to work. It's very simple. All we're doing is passing the $formValue of the field (which is the raw value) into the {block} tag as a variable, so that the block that is rendered depends on this value. As long as a block exists with the correct key, it'll be shown in the display view:

End result, with the correct block pulled in based on the ID we provided to the record

Going further
So, given that we know we can use variables in block names to pull in different content (providing the block has been created ahead of time), what other possibilities are there? For starters, we aren't just restricted to using field formatters. Instead, we could use blocks directly in the database templates, using some of the data available there.
Here's one idea - if you have just a few staff members posting records, you could create a block for each staff member that lists their recent posts, status updates, etc. In your database template, you could include the correct block by doing this:
{block="content_for_{$record->author()->member_id}"}
I hope this relatively simple approach gives you some ideas for more creative ways to use blocks. If you have any suggestions for other ways to use this approach, please let us know in the comments!

Rikki got a reaction from Hisashi for a blog entry, Theme Tip: Dynamic(ish) forum feeds inside Pages databases May 9, 2016

Recently, we had a post in our pre-sales forum that asked how to achieve a few different things with Pages. One of the questions asked was if it was possible to show topics from a particular forum in each database record. While Pages can create a topic for each record for you, there's no way to associate an entire forum with a record.
In my reply, I indicate that you'd need to have a forum ID stored with each record in a custom field, and then use PHP to interact with our API to pull the topic list.
As it turns out, however, there's an easier way that I discovered after some experimentation. In hindsight it's obvious, but I want to share it here because it could open up some other interesting possibilities with some creative uses.
Setting up blocks
The first thing we need to do is create our blocks. We're going to create a block for each of our forums. You can set whatever parameters you want here, but the important thing is that they're named consistently using the forum ID. So, for my forum ID 2, I've named the block forum_2. This will allow us to include our blocks later.

Creating one of the blocks we'll need

Adding the field
Next we'll need to create a field in our Pages database that will be used to set the forum ID that is going to show in each record. For simplicity, I'm creating a Number field and I'll enter the forum ID manually, but if you wanted to go further, you could create a Select Box field, with the key being each forum and the value being the name. This would give you a friendlier input from which to select the forum for each record.
Here, though, I've just created the Number field, and named it Forum ID.

Setting up the database field

Using the field formatter to show the correct block
Finally, we'll use the Field Formatting options to show the correct block based on the forum ID entered for each record. On the Display Options tab, I'm going to hide the field from the listing template, but show it on the display template. I've selected Custom as the format, then entered this format:
{{if $formValue}} {block="forum_{$formValue}"} {{endif}} That's it - that's all you need for this to work. It's very simple. All we're doing is passing the $formValue of the field (which is the raw value) into the {block} tag as a variable, so that the block that is rendered depends on this value. As long as a block exists with the correct key, it'll be shown in the display view:

End result, with the correct block pulled in based on the ID we provided to the record

Going further
So, given that we know we can use variables in block names to pull in different content (providing the block has been created ahead of time), what other possibilities are there? For starters, we aren't just restricted to using field formatters. Instead, we could use blocks directly in the database templates, using some of the data available there.
Here's one idea - if you have just a few staff members posting records, you could create a block for each staff member that lists their recent posts, status updates, etc. In your database template, you could include the correct block by doing this:
{block="content_for_{$record->author()->member_id}"}
I hope this relatively simple approach gives you some ideas for more creative ways to use blocks. If you have any suggestions for other ways to use this approach, please let us know in the comments!

Rikki got a reaction from Izaya Orihara for a blog entry, Theme Tip: Dynamic(ish) forum feeds inside Pages databases May 9, 2016

Recently, we had a post in our pre-sales forum that asked how to achieve a few different things with Pages. One of the questions asked was if it was possible to show topics from a particular forum in each database record. While Pages can create a topic for each record for you, there's no way to associate an entire forum with a record.
In my reply, I indicate that you'd need to have a forum ID stored with each record in a custom field, and then use PHP to interact with our API to pull the topic list.
As it turns out, however, there's an easier way that I discovered after some experimentation. In hindsight it's obvious, but I want to share it here because it could open up some other interesting possibilities with some creative uses.
Setting up blocks
The first thing we need to do is create our blocks. We're going to create a block for each of our forums. You can set whatever parameters you want here, but the important thing is that they're named consistently using the forum ID. So, for my forum ID 2, I've named the block forum_2. This will allow us to include our blocks later.

Creating one of the blocks we'll need

Adding the field
Next we'll need to create a field in our Pages database that will be used to set the forum ID that is going to show in each record. For simplicity, I'm creating a Number field and I'll enter the forum ID manually, but if you wanted to go further, you could create a Select Box field, with the key being each forum and the value being the name. This would give you a friendlier input from which to select the forum for each record.
Here, though, I've just created the Number field, and named it Forum ID.

Setting up the database field

Using the field formatter to show the correct block
Finally, we'll use the Field Formatting options to show the correct block based on the forum ID entered for each record. On the Display Options tab, I'm going to hide the field from the listing template, but show it on the display template. I've selected Custom as the format, then entered this format:
{{if $formValue}} {block="forum_{$formValue}"} {{endif}} That's it - that's all you need for this to work. It's very simple. All we're doing is passing the $formValue of the field (which is the raw value) into the {block} tag as a variable, so that the block that is rendered depends on this value. As long as a block exists with the correct key, it'll be shown in the display view:

End result, with the correct block pulled in based on the ID we provided to the record

Going further
So, given that we know we can use variables in block names to pull in different content (providing the block has been created ahead of time), what other possibilities are there? For starters, we aren't just restricted to using field formatters. Instead, we could use blocks directly in the database templates, using some of the data available there.
Here's one idea - if you have just a few staff members posting records, you could create a block for each staff member that lists their recent posts, status updates, etc. In your database template, you could include the correct block by doing this:
{block="content_for_{$record->author()->member_id}"}
I hope this relatively simple approach gives you some ideas for more creative ways to use blocks. If you have any suggestions for other ways to use this approach, please let us know in the comments!

Rikki got a reaction from Meddysong for a blog entry, Theme Tip: Dynamic(ish) forum feeds inside Pages databases May 9, 2016

Recently, we had a post in our pre-sales forum that asked how to achieve a few different things with Pages. One of the questions asked was if it was possible to show topics from a particular forum in each database record. While Pages can create a topic for each record for you, there's no way to associate an entire forum with a record.
In my reply, I indicate that you'd need to have a forum ID stored with each record in a custom field, and then use PHP to interact with our API to pull the topic list.
As it turns out, however, there's an easier way that I discovered after some experimentation. In hindsight it's obvious, but I want to share it here because it could open up some other interesting possibilities with some creative uses.
Setting up blocks
The first thing we need to do is create our blocks. We're going to create a block for each of our forums. You can set whatever parameters you want here, but the important thing is that they're named consistently using the forum ID. So, for my forum ID 2, I've named the block forum_2. This will allow us to include our blocks later.

Creating one of the blocks we'll need

Adding the field
Next we'll need to create a field in our Pages database that will be used to set the forum ID that is going to show in each record. For simplicity, I'm creating a Number field and I'll enter the forum ID manually, but if you wanted to go further, you could create a Select Box field, with the key being each forum and the value being the name. This would give you a friendlier input from which to select the forum for each record.
Here, though, I've just created the Number field, and named it Forum ID.

Setting up the database field

Using the field formatter to show the correct block
Finally, we'll use the Field Formatting options to show the correct block based on the forum ID entered for each record. On the Display Options tab, I'm going to hide the field from the listing template, but show it on the display template. I've selected Custom as the format, then entered this format:
{{if $formValue}} {block="forum_{$formValue}"} {{endif}} That's it - that's all you need for this to work. It's very simple. All we're doing is passing the $formValue of the field (which is the raw value) into the {block} tag as a variable, so that the block that is rendered depends on this value. As long as a block exists with the correct key, it'll be shown in the display view:

End result, with the correct block pulled in based on the ID we provided to the record

Going further
So, given that we know we can use variables in block names to pull in different content (providing the block has been created ahead of time), what other possibilities are there? For starters, we aren't just restricted to using field formatters. Instead, we could use blocks directly in the database templates, using some of the data available there.
Here's one idea - if you have just a few staff members posting records, you could create a block for each staff member that lists their recent posts, status updates, etc. In your database template, you could include the correct block by doing this:
{block="content_for_{$record->author()->member_id}"}
I hope this relatively simple approach gives you some ideas for more creative ways to use blocks. If you have any suggestions for other ways to use this approach, please let us know in the comments!

Rikki got a reaction from chilihead for a blog entry, Theme Tip: Dynamic(ish) forum feeds inside Pages databases May 9, 2016

Recently, we had a post in our pre-sales forum that asked how to achieve a few different things with Pages. One of the questions asked was if it was possible to show topics from a particular forum in each database record. While Pages can create a topic for each record for you, there's no way to associate an entire forum with a record.
In my reply, I indicate that you'd need to have a forum ID stored with each record in a custom field, and then use PHP to interact with our API to pull the topic list.
As it turns out, however, there's an easier way that I discovered after some experimentation. In hindsight it's obvious, but I want to share it here because it could open up some other interesting possibilities with some creative uses.
Setting up blocks
The first thing we need to do is create our blocks. We're going to create a block for each of our forums. You can set whatever parameters you want here, but the important thing is that they're named consistently using the forum ID. So, for my forum ID 2, I've named the block forum_2. This will allow us to include our blocks later.

Creating one of the blocks we'll need

Adding the field
Next we'll need to create a field in our Pages database that will be used to set the forum ID that is going to show in each record. For simplicity, I'm creating a Number field and I'll enter the forum ID manually, but if you wanted to go further, you could create a Select Box field, with the key being each forum and the value being the name. This would give you a friendlier input from which to select the forum for each record.
Here, though, I've just created the Number field, and named it Forum ID.

Setting up the database field

Using the field formatter to show the correct block
Finally, we'll use the Field Formatting options to show the correct block based on the forum ID entered for each record. On the Display Options tab, I'm going to hide the field from the listing template, but show it on the display template. I've selected Custom as the format, then entered this format:
{{if $formValue}} {block="forum_{$formValue}"} {{endif}} That's it - that's all you need for this to work. It's very simple. All we're doing is passing the $formValue of the field (which is the raw value) into the {block} tag as a variable, so that the block that is rendered depends on this value. As long as a block exists with the correct key, it'll be shown in the display view:

End result, with the correct block pulled in based on the ID we provided to the record

Going further
So, given that we know we can use variables in block names to pull in different content (providing the block has been created ahead of time), what other possibilities are there? For starters, we aren't just restricted to using field formatters. Instead, we could use blocks directly in the database templates, using some of the data available there.
Here's one idea - if you have just a few staff members posting records, you could create a block for each staff member that lists their recent posts, status updates, etc. In your database template, you could include the correct block by doing this:
{block="content_for_{$record->author()->member_id}"}
I hope this relatively simple approach gives you some ideas for more creative ways to use blocks. If you have any suggestions for other ways to use this approach, please let us know in the comments!

Rikki got a reaction from -FP for a blog entry, Theme Tip: Dynamic(ish) forum feeds inside Pages databases May 9, 2016

Recently, we had a post in our pre-sales forum that asked how to achieve a few different things with Pages. One of the questions asked was if it was possible to show topics from a particular forum in each database record. While Pages can create a topic for each record for you, there's no way to associate an entire forum with a record.
In my reply, I indicate that you'd need to have a forum ID stored with each record in a custom field, and then use PHP to interact with our API to pull the topic list.
As it turns out, however, there's an easier way that I discovered after some experimentation. In hindsight it's obvious, but I want to share it here because it could open up some other interesting possibilities with some creative uses.
Setting up blocks
The first thing we need to do is create our blocks. We're going to create a block for each of our forums. You can set whatever parameters you want here, but the important thing is that they're named consistently using the forum ID. So, for my forum ID 2, I've named the block forum_2. This will allow us to include our blocks later.

Creating one of the blocks we'll need

Adding the field
Next we'll need to create a field in our Pages database that will be used to set the forum ID that is going to show in each record. For simplicity, I'm creating a Number field and I'll enter the forum ID manually, but if you wanted to go further, you could create a Select Box field, with the key being each forum and the value being the name. This would give you a friendlier input from which to select the forum for each record.
Here, though, I've just created the Number field, and named it Forum ID.

Setting up the database field

Using the field formatter to show the correct block
Finally, we'll use the Field Formatting options to show the correct block based on the forum ID entered for each record. On the Display Options tab, I'm going to hide the field from the listing template, but show it on the display template. I've selected Custom as the format, then entered this format:
{{if $formValue}} {block="forum_{$formValue}"} {{endif}} That's it - that's all you need for this to work. It's very simple. All we're doing is passing the $formValue of the field (which is the raw value) into the {block} tag as a variable, so that the block that is rendered depends on this value. As long as a block exists with the correct key, it'll be shown in the display view:

End result, with the correct block pulled in based on the ID we provided to the record

Going further
So, given that we know we can use variables in block names to pull in different content (providing the block has been created ahead of time), what other possibilities are there? For starters, we aren't just restricted to using field formatters. Instead, we could use blocks directly in the database templates, using some of the data available there.
Here's one idea - if you have just a few staff members posting records, you could create a block for each staff member that lists their recent posts, status updates, etc. In your database template, you could include the correct block by doing this:
{block="content_for_{$record->author()->member_id}"}
I hope this relatively simple approach gives you some ideas for more creative ways to use blocks. If you have any suggestions for other ways to use this approach, please let us know in the comments!

Rikki got a reaction from BN_IT_Support for a blog entry, Theme Tip: Dynamic(ish) forum feeds inside Pages databases May 9, 2016

Recently, we had a post in our pre-sales forum that asked how to achieve a few different things with Pages. One of the questions asked was if it was possible to show topics from a particular forum in each database record. While Pages can create a topic for each record for you, there's no way to associate an entire forum with a record.
In my reply, I indicate that you'd need to have a forum ID stored with each record in a custom field, and then use PHP to interact with our API to pull the topic list.
As it turns out, however, there's an easier way that I discovered after some experimentation. In hindsight it's obvious, but I want to share it here because it could open up some other interesting possibilities with some creative uses.
Setting up blocks
The first thing we need to do is create our blocks. We're going to create a block for each of our forums. You can set whatever parameters you want here, but the important thing is that they're named consistently using the forum ID. So, for my forum ID 2, I've named the block forum_2. This will allow us to include our blocks later.

Creating one of the blocks we'll need

Adding the field
Next we'll need to create a field in our Pages database that will be used to set the forum ID that is going to show in each record. For simplicity, I'm creating a Number field and I'll enter the forum ID manually, but if you wanted to go further, you could create a Select Box field, with the key being each forum and the value being the name. This would give you a friendlier input from which to select the forum for each record.
Here, though, I've just created the Number field, and named it Forum ID.

Setting up the database field

Using the field formatter to show the correct block
Finally, we'll use the Field Formatting options to show the correct block based on the forum ID entered for each record. On the Display Options tab, I'm going to hide the field from the listing template, but show it on the display template. I've selected Custom as the format, then entered this format:
{{if $formValue}} {block="forum_{$formValue}"} {{endif}} That's it - that's all you need for this to work. It's very simple. All we're doing is passing the $formValue of the field (which is the raw value) into the {block} tag as a variable, so that the block that is rendered depends on this value. As long as a block exists with the correct key, it'll be shown in the display view:

End result, with the correct block pulled in based on the ID we provided to the record

Going further
So, given that we know we can use variables in block names to pull in different content (providing the block has been created ahead of time), what other possibilities are there? For starters, we aren't just restricted to using field formatters. Instead, we could use blocks directly in the database templates, using some of the data available there.
Here's one idea - if you have just a few staff members posting records, you could create a block for each staff member that lists their recent posts, status updates, etc. In your database template, you could include the correct block by doing this:
{block="content_for_{$record->author()->member_id}"}
I hope this relatively simple approach gives you some ideas for more creative ways to use blocks. If you have any suggestions for other ways to use this approach, please let us know in the comments!

Rikki got a reaction from LukasGr. for a blog entry, Theme Tip: Styling specific elements on specific pages May 7, 2016

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.

Rikki got a reaction from ipbfuck for a blog entry, Theme Tip: Styling specific elements on specific pages May 4, 2016

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.

Rikki got a reaction from IBTheme for a blog entry, Streamlining our website and community May 4, 2016

Many of the regular visitors to our community won't have failed to notice the new look we launched last week. Now that the dust has settled, I thought it was a good time to explain why we've made the change.
Streamlined access to everything we offer
Ever since IPS was founded in 2002, our community has been distinct from our website. The community is also where we kept all kinds of resources, from guides to the Marketplace. For those customers who know us well and enjoy hanging out in our community (and we have many who have been with us since that day in 2002!), this is no problem. Unfortunately, the downside is many new and potential customers didn't see everything we have to offer: all the wonderful addons our contributors offer, additional support resources, plentiful advice from other community administrators, and more.
In addition, we've always used the default theme that our software ships with, but with our self-service demo system now being the primary way new customers get to try out our software, this has become less important.
So, we took the decision to move some parts of the community to the website for more exposure and easier discovery by new visitors. We made some tweaks to our navigation so that finding these areas is easier than before. And, of course, we've brought the website header over to the community, giving it a fresher look and more consistent navigation, wherever you happen to be on our website.
Of course, all of our website is built in IPS4, as you would expect. Whereas before our website existed on a separate installation, as part of the update we merged our community and website together. This means you can sign in from anywhere, see your notifications and so on.
This is just the first step we've taken on improving what we offer and how we offer it. We have many plans in progress. You may have seen the theme tip we posted this week, which is the first in a series of regular tips we'll be sharing to help you get the most out of the IPS Community Suite. We'll also be highlighting some of the incredible work our customers do, whether it's a unique use of our software, or something in our Marketplace that adds a great feature.
Stay tuned!

Rikki got a reaction from Teascu Dorin for a blog entry, Theme Tip: Styling specific elements on specific pages May 4, 2016

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.

Rikki got a reaction from Flitterkill for a blog entry, Theme Tip: Styling specific elements on specific pages May 4, 2016

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.

Rikki got a reaction from sobrenome for a blog entry, Theme Tip: Using custom template bits May 4, 2016

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!

Rikki got a reaction from tAPir for a blog entry, Theme Tip: Styling specific elements on specific pages May 3, 2016

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.

Rikki got a reaction from Mr.Jake for a blog entry, Theme Tip: Styling specific elements on specific pages May 3, 2016

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.

Rikki got a reaction from Meddysong for a blog entry, Theme Tip: Styling specific elements on specific pages May 2, 2016

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.

Rikki got a reaction from sobrenome for a blog entry, Theme Tip: Styling specific elements on specific pages May 2, 2016

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.

Rikki got a reaction from zelgadis for a blog entry, Theme Tip: Styling specific elements on specific pages May 2, 2016

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.

Rikki got a reaction from Daddy for a blog entry, Theme Tip: Styling specific elements on specific pages May 2, 2016

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.

Rikki got a reaction from LiquidFractal for a blog entry, Theme Tip: Styling specific elements on specific pages May 2, 2016

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.

Rikki got a reaction from Ticaga for a blog entry, Support for PHP 5.4 ending soon May 2, 2016

For our self-hosted customers, we wanted to give you advanced notice that support for PHP 5.4 in the IPS Community Suite will be ending soon. IPS Community Suite 4.1.11 will be the last release to support this version of PHP.
PHP 5.4 was released in 2012 and reached 'end of life' in September 2015, and so we will be requiring at least PHP 5.5 from IPS Community Suite 4.1.12 onwards. We do recommend PHP 5.6 or greater as 5.5 is approaching end of life as well.
If you currently use PHP 5.4, please contact your host and ask them to upgrade to a supported version as soon as possible.
If you would rather not have to worry about server-level issues like this, consider switching to one of our Community in the Cloud plans. They include all of our suite apps and we take care of all of the server management for you, leaving you to focus on running your community. If you are currently self-hosting, we can transfer your community to a cloud plan for free, in most cases. Contact our sales team for more information.

Rikki got a reaction from Adlago for a blog entry, Theme Tip: Styling specific elements on specific pages May 2, 2016

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.

Rikki got a reaction from Hunter Lyons for a blog entry, Theme Tip: Styling specific elements on specific pages May 2, 2016

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.

Rikki got a reaction from Ahmad E. for a blog entry, Theme Tip: Styling specific elements on specific pages May 2, 2016

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.

Rikki got a reaction from AndyF for a blog entry, Theme Tip: Styling specific elements on specific pages May 1, 2016

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.

Rikki got a reaction from Hunter Lyons for a blog entry, Theme Tip: Using custom template bits April 29, 2016

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!

Rikki got a reaction from Poojitha for a blog entry, Support for PHP 5.4 ending soon April 29, 2016

For our self-hosted customers, we wanted to give you advanced notice that support for PHP 5.4 in the IPS Community Suite will be ending soon. IPS Community Suite 4.1.11 will be the last release to support this version of PHP.
PHP 5.4 was released in 2012 and reached 'end of life' in September 2015, and so we will be requiring at least PHP 5.5 from IPS Community Suite 4.1.12 onwards. We do recommend PHP 5.6 or greater as 5.5 is approaching end of life as well.
If you currently use PHP 5.4, please contact your host and ask them to upgrade to a supported version as soon as possible.
If you would rather not have to worry about server-level issues like this, consider switching to one of our Community in the Cloud plans. They include all of our suite apps and we take care of all of the server management for you, leaving you to focus on running your community. If you are currently self-hosting, we can transfer your community to a cloud plan for free, in most cases. Contact our sales team for more information.

Rikki got a reaction from Meddysong for a blog entry, Theme Tip: Using custom template bits April 29, 2016

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!

Rikki got a reaction from Shariq Ansari for a blog entry, Theme Tip: Using custom template bits April 27, 2016

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!

Rikki got a reaction from -FP for a blog entry, Theme Tip: Using custom template bits April 27, 2016

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!

Rikki got a reaction from Veilon for a blog entry, Theme Tip: Using custom template bits April 27, 2016

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!

Rikki got a reaction from SlimTall for a blog entry, Theme Tip: Using custom template bits April 26, 2016

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!

Rikki got a reaction from kgrahim for a blog entry, Theme Tip: Using custom template bits April 26, 2016

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!

Rikki got a reaction from LiquidFractal for a blog entry, Theme Tip: Using custom template bits April 26, 2016

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!

Rikki got a reaction from linkmat for a blog entry, Theme Tip: Using custom template bits April 25, 2016

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!

Rikki got a reaction from Marcher Technologies for a blog entry, Theme Tip: Using custom template bits April 25, 2016

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!

Rikki got a reaction from Zen Geek for a blog entry, Theme Tip: Using custom template bits April 25, 2016

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!

Rikki got a reaction from Stephane for a blog entry, Theme Tip: Using custom template bits April 25, 2016

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!

Rikki got a reaction from Marcher Technologies for a blog entry, Support for PHP 5.4 ending soon April 14, 2016

For our self-hosted customers, we wanted to give you advanced notice that support for PHP 5.4 in the IPS Community Suite will be ending soon. IPS Community Suite 4.1.11 will be the last release to support this version of PHP.
PHP 5.4 was released in 2012 and reached 'end of life' in September 2015, and so we will be requiring at least PHP 5.5 from IPS Community Suite 4.1.12 onwards. We do recommend PHP 5.6 or greater as 5.5 is approaching end of life as well.
If you currently use PHP 5.4, please contact your host and ask them to upgrade to a supported version as soon as possible.
If you would rather not have to worry about server-level issues like this, consider switching to one of our Community in the Cloud plans. They include all of our suite apps and we take care of all of the server management for you, leaving you to focus on running your community. If you are currently self-hosting, we can transfer your community to a cloud plan for free, in most cases. Contact our sales team for more information.

Rikki got a reaction from Dennis_87 for a blog entry, Support for PHP 5.4 ending soon April 13, 2016

For our self-hosted customers, we wanted to give you advanced notice that support for PHP 5.4 in the IPS Community Suite will be ending soon. IPS Community Suite 4.1.11 will be the last release to support this version of PHP.
PHP 5.4 was released in 2012 and reached 'end of life' in September 2015, and so we will be requiring at least PHP 5.5 from IPS Community Suite 4.1.12 onwards. We do recommend PHP 5.6 or greater as 5.5 is approaching end of life as well.
If you currently use PHP 5.4, please contact your host and ask them to upgrade to a supported version as soon as possible.
If you would rather not have to worry about server-level issues like this, consider switching to one of our Community in the Cloud plans. They include all of our suite apps and we take care of all of the server management for you, leaving you to focus on running your community. If you are currently self-hosting, we can transfer your community to a cloud plan for free, in most cases. Contact our sales team for more information.

Rikki got a reaction from Haku2 for a blog entry, Support for PHP 5.4 ending soon April 12, 2016

For our self-hosted customers, we wanted to give you advanced notice that support for PHP 5.4 in the IPS Community Suite will be ending soon. IPS Community Suite 4.1.11 will be the last release to support this version of PHP.
PHP 5.4 was released in 2012 and reached 'end of life' in September 2015, and so we will be requiring at least PHP 5.5 from IPS Community Suite 4.1.12 onwards. We do recommend PHP 5.6 or greater as 5.5 is approaching end of life as well.
If you currently use PHP 5.4, please contact your host and ask them to upgrade to a supported version as soon as possible.
If you would rather not have to worry about server-level issues like this, consider switching to one of our Community in the Cloud plans. They include all of our suite apps and we take care of all of the server management for you, leaving you to focus on running your community. If you are currently self-hosting, we can transfer your community to a cloud plan for free, in most cases. Contact our sales team for more information.

Rikki got a reaction from Daniel F for a blog entry, Support for PHP 5.4 ending soon April 12, 2016

For our self-hosted customers, we wanted to give you advanced notice that support for PHP 5.4 in the IPS Community Suite will be ending soon. IPS Community Suite 4.1.11 will be the last release to support this version of PHP.
PHP 5.4 was released in 2012 and reached 'end of life' in September 2015, and so we will be requiring at least PHP 5.5 from IPS Community Suite 4.1.12 onwards. We do recommend PHP 5.6 or greater as 5.5 is approaching end of life as well.
If you currently use PHP 5.4, please contact your host and ask them to upgrade to a supported version as soon as possible.
If you would rather not have to worry about server-level issues like this, consider switching to one of our Community in the Cloud plans. They include all of our suite apps and we take care of all of the server management for you, leaving you to focus on running your community. If you are currently self-hosting, we can transfer your community to a cloud plan for free, in most cases. Contact our sales team for more information.

Rikki got a reaction from Ilya Hoilik for a blog entry, Support for PHP 5.4 ending soon April 12, 2016

For our self-hosted customers, we wanted to give you advanced notice that support for PHP 5.4 in the IPS Community Suite will be ending soon. IPS Community Suite 4.1.11 will be the last release to support this version of PHP.
PHP 5.4 was released in 2012 and reached 'end of life' in September 2015, and so we will be requiring at least PHP 5.5 from IPS Community Suite 4.1.12 onwards. We do recommend PHP 5.6 or greater as 5.5 is approaching end of life as well.
If you currently use PHP 5.4, please contact your host and ask them to upgrade to a supported version as soon as possible.
If you would rather not have to worry about server-level issues like this, consider switching to one of our Community in the Cloud plans. They include all of our suite apps and we take care of all of the server management for you, leaving you to focus on running your community. If you are currently self-hosting, we can transfer your community to a cloud plan for free, in most cases. Contact our sales team for more information.

Rikki got a reaction from AndyF for a blog entry, Support for PHP 5.4 ending soon April 11, 2016

For our self-hosted customers, we wanted to give you advanced notice that support for PHP 5.4 in the IPS Community Suite will be ending soon. IPS Community Suite 4.1.11 will be the last release to support this version of PHP.
PHP 5.4 was released in 2012 and reached 'end of life' in September 2015, and so we will be requiring at least PHP 5.5 from IPS Community Suite 4.1.12 onwards. We do recommend PHP 5.6 or greater as 5.5 is approaching end of life as well.
If you currently use PHP 5.4, please contact your host and ask them to upgrade to a supported version as soon as possible.
If you would rather not have to worry about server-level issues like this, consider switching to one of our Community in the Cloud plans. They include all of our suite apps and we take care of all of the server management for you, leaving you to focus on running your community. If you are currently self-hosting, we can transfer your community to a cloud plan for free, in most cases. Contact our sales team for more information.

Rikki got a reaction from Hunter Lyons for a blog entry, Streamlining our website and community April 4, 2016

Many of the regular visitors to our community won't have failed to notice the new look we launched last week. Now that the dust has settled, I thought it was a good time to explain why we've made the change.
Streamlined access to everything we offer
Ever since IPS was founded in 2002, our community has been distinct from our website. The community is also where we kept all kinds of resources, from guides to the Marketplace. For those customers who know us well and enjoy hanging out in our community (and we have many who have been with us since that day in 2002!), this is no problem. Unfortunately, the downside is many new and potential customers didn't see everything we have to offer: all the wonderful addons our contributors offer, additional support resources, plentiful advice from other community administrators, and more.
In addition, we've always used the default theme that our software ships with, but with our self-service demo system now being the primary way new customers get to try out our software, this has become less important.
So, we took the decision to move some parts of the community to the website for more exposure and easier discovery by new visitors. We made some tweaks to our navigation so that finding these areas is easier than before. And, of course, we've brought the website header over to the community, giving it a fresher look and more consistent navigation, wherever you happen to be on our website.
Of course, all of our website is built in IPS4, as you would expect. Whereas before our website existed on a separate installation, as part of the update we merged our community and website together. This means you can sign in from anywhere, see your notifications and so on.
This is just the first step we've taken on improving what we offer and how we offer it. We have many plans in progress. You may have seen the theme tip we posted this week, which is the first in a series of regular tips we'll be sharing to help you get the most out of the IPS Community Suite. We'll also be highlighting some of the incredible work our customers do, whether it's a unique use of our software, or something in our Marketplace that adds a great feature.
Stay tuned!

Rikki got a reaction from karld for a blog entry, Streamlining our website and community March 28, 2016

Many of the regular visitors to our community won't have failed to notice the new look we launched last week. Now that the dust has settled, I thought it was a good time to explain why we've made the change.
Streamlined access to everything we offer
Ever since IPS was founded in 2002, our community has been distinct from our website. The community is also where we kept all kinds of resources, from guides to the Marketplace. For those customers who know us well and enjoy hanging out in our community (and we have many who have been with us since that day in 2002!), this is no problem. Unfortunately, the downside is many new and potential customers didn't see everything we have to offer: all the wonderful addons our contributors offer, additional support resources, plentiful advice from other community administrators, and more.
In addition, we've always used the default theme that our software ships with, but with our self-service demo system now being the primary way new customers get to try out our software, this has become less important.
So, we took the decision to move some parts of the community to the website for more exposure and easier discovery by new visitors. We made some tweaks to our navigation so that finding these areas is easier than before. And, of course, we've brought the website header over to the community, giving it a fresher look and more consistent navigation, wherever you happen to be on our website.
Of course, all of our website is built in IPS4, as you would expect. Whereas before our website existed on a separate installation, as part of the update we merged our community and website together. This means you can sign in from anywhere, see your notifications and so on.
This is just the first step we've taken on improving what we offer and how we offer it. We have many plans in progress. You may have seen the theme tip we posted this week, which is the first in a series of regular tips we'll be sharing to help you get the most out of the IPS Community Suite. We'll also be highlighting some of the incredible work our customers do, whether it's a unique use of our software, or something in our Marketplace that adds a great feature.
Stay tuned!

Rikki got a reaction from SuJay for a blog entry, Streamlining our website and community March 27, 2016

Many of the regular visitors to our community won't have failed to notice the new look we launched last week. Now that the dust has settled, I thought it was a good time to explain why we've made the change.
Streamlined access to everything we offer
Ever since IPS was founded in 2002, our community has been distinct from our website. The community is also where we kept all kinds of resources, from guides to the Marketplace. For those customers who know us well and enjoy hanging out in our community (and we have many who have been with us since that day in 2002!), this is no problem. Unfortunately, the downside is many new and potential customers didn't see everything we have to offer: all the wonderful addons our contributors offer, additional support resources, plentiful advice from other community administrators, and more.
In addition, we've always used the default theme that our software ships with, but with our self-service demo system now being the primary way new customers get to try out our software, this has become less important.
So, we took the decision to move some parts of the community to the website for more exposure and easier discovery by new visitors. We made some tweaks to our navigation so that finding these areas is easier than before. And, of course, we've brought the website header over to the community, giving it a fresher look and more consistent navigation, wherever you happen to be on our website.
Of course, all of our website is built in IPS4, as you would expect. Whereas before our website existed on a separate installation, as part of the update we merged our community and website together. This means you can sign in from anywhere, see your notifications and so on.
This is just the first step we've taken on improving what we offer and how we offer it. We have many plans in progress. You may have seen the theme tip we posted this week, which is the first in a series of regular tips we'll be sharing to help you get the most out of the IPS Community Suite. We'll also be highlighting some of the incredible work our customers do, whether it's a unique use of our software, or something in our Marketplace that adds a great feature.
Stay tuned!

Rikki got a reaction from media for a blog entry, Streamlining our website and community March 21, 2016

Many of the regular visitors to our community won't have failed to notice the new look we launched last week. Now that the dust has settled, I thought it was a good time to explain why we've made the change.
Streamlined access to everything we offer
Ever since IPS was founded in 2002, our community has been distinct from our website. The community is also where we kept all kinds of resources, from guides to the Marketplace. For those customers who know us well and enjoy hanging out in our community (and we have many who have been with us since that day in 2002!), this is no problem. Unfortunately, the downside is many new and potential customers didn't see everything we have to offer: all the wonderful addons our contributors offer, additional support resources, plentiful advice from other community administrators, and more.
In addition, we've always used the default theme that our software ships with, but with our self-service demo system now being the primary way new customers get to try out our software, this has become less important.
So, we took the decision to move some parts of the community to the website for more exposure and easier discovery by new visitors. We made some tweaks to our navigation so that finding these areas is easier than before. And, of course, we've brought the website header over to the community, giving it a fresher look and more consistent navigation, wherever you happen to be on our website.
Of course, all of our website is built in IPS4, as you would expect. Whereas before our website existed on a separate installation, as part of the update we merged our community and website together. This means you can sign in from anywhere, see your notifications and so on.
This is just the first step we've taken on improving what we offer and how we offer it. We have many plans in progress. You may have seen the theme tip we posted this week, which is the first in a series of regular tips we'll be sharing to help you get the most out of the IPS Community Suite. We'll also be highlighting some of the incredible work our customers do, whether it's a unique use of our software, or something in our Marketplace that adds a great feature.
Stay tuned!

Rikki got a reaction from wrap10 for a blog entry, Streamlining our website and community March 18, 2016

Many of the regular visitors to our community won't have failed to notice the new look we launched last week. Now that the dust has settled, I thought it was a good time to explain why we've made the change.
Streamlined access to everything we offer
Ever since IPS was founded in 2002, our community has been distinct from our website. The community is also where we kept all kinds of resources, from guides to the Marketplace. For those customers who know us well and enjoy hanging out in our community (and we have many who have been with us since that day in 2002!), this is no problem. Unfortunately, the downside is many new and potential customers didn't see everything we have to offer: all the wonderful addons our contributors offer, additional support resources, plentiful advice from other community administrators, and more.
In addition, we've always used the default theme that our software ships with, but with our self-service demo system now being the primary way new customers get to try out our software, this has become less important.
So, we took the decision to move some parts of the community to the website for more exposure and easier discovery by new visitors. We made some tweaks to our navigation so that finding these areas is easier than before. And, of course, we've brought the website header over to the community, giving it a fresher look and more consistent navigation, wherever you happen to be on our website.
Of course, all of our website is built in IPS4, as you would expect. Whereas before our website existed on a separate installation, as part of the update we merged our community and website together. This means you can sign in from anywhere, see your notifications and so on.
This is just the first step we've taken on improving what we offer and how we offer it. We have many plans in progress. You may have seen the theme tip we posted this week, which is the first in a series of regular tips we'll be sharing to help you get the most out of the IPS Community Suite. We'll also be highlighting some of the incredible work our customers do, whether it's a unique use of our software, or something in our Marketplace that adds a great feature.
Stay tuned!

Rikki got a reaction from The Old Man for a blog entry, Streamlining our website and community March 18, 2016

Many of the regular visitors to our community won't have failed to notice the new look we launched last week. Now that the dust has settled, I thought it was a good time to explain why we've made the change.
Streamlined access to everything we offer
Ever since IPS was founded in 2002, our community has been distinct from our website. The community is also where we kept all kinds of resources, from guides to the Marketplace. For those customers who know us well and enjoy hanging out in our community (and we have many who have been with us since that day in 2002!), this is no problem. Unfortunately, the downside is many new and potential customers didn't see everything we have to offer: all the wonderful addons our contributors offer, additional support resources, plentiful advice from other community administrators, and more.
In addition, we've always used the default theme that our software ships with, but with our self-service demo system now being the primary way new customers get to try out our software, this has become less important.
So, we took the decision to move some parts of the community to the website for more exposure and easier discovery by new visitors. We made some tweaks to our navigation so that finding these areas is easier than before. And, of course, we've brought the website header over to the community, giving it a fresher look and more consistent navigation, wherever you happen to be on our website.
Of course, all of our website is built in IPS4, as you would expect. Whereas before our website existed on a separate installation, as part of the update we merged our community and website together. This means you can sign in from anywhere, see your notifications and so on.
This is just the first step we've taken on improving what we offer and how we offer it. We have many plans in progress. You may have seen the theme tip we posted this week, which is the first in a series of regular tips we'll be sharing to help you get the most out of the IPS Community Suite. We'll also be highlighting some of the incredible work our customers do, whether it's a unique use of our software, or something in our Marketplace that adds a great feature.
Stay tuned!

Rikki got a reaction from Matt C. for a blog entry, Streamlining our website and community March 17, 2016

Many of the regular visitors to our community won't have failed to notice the new look we launched last week. Now that the dust has settled, I thought it was a good time to explain why we've made the change.
Streamlined access to everything we offer
Ever since IPS was founded in 2002, our community has been distinct from our website. The community is also where we kept all kinds of resources, from guides to the Marketplace. For those customers who know us well and enjoy hanging out in our community (and we have many who have been with us since that day in 2002!), this is no problem. Unfortunately, the downside is many new and potential customers didn't see everything we have to offer: all the wonderful addons our contributors offer, additional support resources, plentiful advice from other community administrators, and more.
In addition, we've always used the default theme that our software ships with, but with our self-service demo system now being the primary way new customers get to try out our software, this has become less important.
So, we took the decision to move some parts of the community to the website for more exposure and easier discovery by new visitors. We made some tweaks to our navigation so that finding these areas is easier than before. And, of course, we've brought the website header over to the community, giving it a fresher look and more consistent navigation, wherever you happen to be on our website.
Of course, all of our website is built in IPS4, as you would expect. Whereas before our website existed on a separate installation, as part of the update we merged our community and website together. This means you can sign in from anywhere, see your notifications and so on.
This is just the first step we've taken on improving what we offer and how we offer it. We have many plans in progress. You may have seen the theme tip we posted this week, which is the first in a series of regular tips we'll be sharing to help you get the most out of the IPS Community Suite. We'll also be highlighting some of the incredible work our customers do, whether it's a unique use of our software, or something in our Marketplace that adds a great feature.
Stay tuned!

Rikki got a reaction from Robiss767 for a blog entry, Streamlining our website and community March 16, 2016

Many of the regular visitors to our community won't have failed to notice the new look we launched last week. Now that the dust has settled, I thought it was a good time to explain why we've made the change.
Streamlined access to everything we offer
Ever since IPS was founded in 2002, our community has been distinct from our website. The community is also where we kept all kinds of resources, from guides to the Marketplace. For those customers who know us well and enjoy hanging out in our community (and we have many who have been with us since that day in 2002!), this is no problem. Unfortunately, the downside is many new and potential customers didn't see everything we have to offer: all the wonderful addons our contributors offer, additional support resources, plentiful advice from other community administrators, and more.
In addition, we've always used the default theme that our software ships with, but with our self-service demo system now being the primary way new customers get to try out our software, this has become less important.
So, we took the decision to move some parts of the community to the website for more exposure and easier discovery by new visitors. We made some tweaks to our navigation so that finding these areas is easier than before. And, of course, we've brought the website header over to the community, giving it a fresher look and more consistent navigation, wherever you happen to be on our website.
Of course, all of our website is built in IPS4, as you would expect. Whereas before our website existed on a separate installation, as part of the update we merged our community and website together. This means you can sign in from anywhere, see your notifications and so on.
This is just the first step we've taken on improving what we offer and how we offer it. We have many plans in progress. You may have seen the theme tip we posted this week, which is the first in a series of regular tips we'll be sharing to help you get the most out of the IPS Community Suite. We'll also be highlighting some of the incredible work our customers do, whether it's a unique use of our software, or something in our Marketplace that adds a great feature.
Stay tuned!

Rikki got a reaction from Meddysong for a blog entry, Streamlining our website and community March 16, 2016

Many of the regular visitors to our community won't have failed to notice the new look we launched last week. Now that the dust has settled, I thought it was a good time to explain why we've made the change.
Streamlined access to everything we offer
Ever since IPS was founded in 2002, our community has been distinct from our website. The community is also where we kept all kinds of resources, from guides to the Marketplace. For those customers who know us well and enjoy hanging out in our community (and we have many who have been with us since that day in 2002!), this is no problem. Unfortunately, the downside is many new and potential customers didn't see everything we have to offer: all the wonderful addons our contributors offer, additional support resources, plentiful advice from other community administrators, and more.
In addition, we've always used the default theme that our software ships with, but with our self-service demo system now being the primary way new customers get to try out our software, this has become less important.
So, we took the decision to move some parts of the community to the website for more exposure and easier discovery by new visitors. We made some tweaks to our navigation so that finding these areas is easier than before. And, of course, we've brought the website header over to the community, giving it a fresher look and more consistent navigation, wherever you happen to be on our website.
Of course, all of our website is built in IPS4, as you would expect. Whereas before our website existed on a separate installation, as part of the update we merged our community and website together. This means you can sign in from anywhere, see your notifications and so on.
This is just the first step we've taken on improving what we offer and how we offer it. We have many plans in progress. You may have seen the theme tip we posted this week, which is the first in a series of regular tips we'll be sharing to help you get the most out of the IPS Community Suite. We'll also be highlighting some of the incredible work our customers do, whether it's a unique use of our software, or something in our Marketplace that adds a great feature.
Stay tuned!

Rikki got a reaction from shahed for a blog entry, Streamlining our website and community March 16, 2016

Many of the regular visitors to our community won't have failed to notice the new look we launched last week. Now that the dust has settled, I thought it was a good time to explain why we've made the change.
Streamlined access to everything we offer
Ever since IPS was founded in 2002, our community has been distinct from our website. The community is also where we kept all kinds of resources, from guides to the Marketplace. For those customers who know us well and enjoy hanging out in our community (and we have many who have been with us since that day in 2002!), this is no problem. Unfortunately, the downside is many new and potential customers didn't see everything we have to offer: all the wonderful addons our contributors offer, additional support resources, plentiful advice from other community administrators, and more.
In addition, we've always used the default theme that our software ships with, but with our self-service demo system now being the primary way new customers get to try out our software, this has become less important.
So, we took the decision to move some parts of the community to the website for more exposure and easier discovery by new visitors. We made some tweaks to our navigation so that finding these areas is easier than before. And, of course, we've brought the website header over to the community, giving it a fresher look and more consistent navigation, wherever you happen to be on our website.
Of course, all of our website is built in IPS4, as you would expect. Whereas before our website existed on a separate installation, as part of the update we merged our community and website together. This means you can sign in from anywhere, see your notifications and so on.
This is just the first step we've taken on improving what we offer and how we offer it. We have many plans in progress. You may have seen the theme tip we posted this week, which is the first in a series of regular tips we'll be sharing to help you get the most out of the IPS Community Suite. We'll also be highlighting some of the incredible work our customers do, whether it's a unique use of our software, or something in our Marketplace that adds a great feature.
Stay tuned!

Rikki got a reaction from Izaya Orihara for a blog entry, Streamlining our website and community March 16, 2016

Many of the regular visitors to our community won't have failed to notice the new look we launched last week. Now that the dust has settled, I thought it was a good time to explain why we've made the change.
Streamlined access to everything we offer
Ever since IPS was founded in 2002, our community has been distinct from our website. The community is also where we kept all kinds of resources, from guides to the Marketplace. For those customers who know us well and enjoy hanging out in our community (and we have many who have been with us since that day in 2002!), this is no problem. Unfortunately, the downside is many new and potential customers didn't see everything we have to offer: all the wonderful addons our contributors offer, additional support resources, plentiful advice from other community administrators, and more.
In addition, we've always used the default theme that our software ships with, but with our self-service demo system now being the primary way new customers get to try out our software, this has become less important.
So, we took the decision to move some parts of the community to the website for more exposure and easier discovery by new visitors. We made some tweaks to our navigation so that finding these areas is easier than before. And, of course, we've brought the website header over to the community, giving it a fresher look and more consistent navigation, wherever you happen to be on our website.
Of course, all of our website is built in IPS4, as you would expect. Whereas before our website existed on a separate installation, as part of the update we merged our community and website together. This means you can sign in from anywhere, see your notifications and so on.
This is just the first step we've taken on improving what we offer and how we offer it. We have many plans in progress. You may have seen the theme tip we posted this week, which is the first in a series of regular tips we'll be sharing to help you get the most out of the IPS Community Suite. We'll also be highlighting some of the incredible work our customers do, whether it's a unique use of our software, or something in our Marketplace that adds a great feature.
Stay tuned!

Rikki got a reaction from Simon Woods for a blog entry, Streamlining our website and community March 16, 2016

Many of the regular visitors to our community won't have failed to notice the new look we launched last week. Now that the dust has settled, I thought it was a good time to explain why we've made the change.
Streamlined access to everything we offer
Ever since IPS was founded in 2002, our community has been distinct from our website. The community is also where we kept all kinds of resources, from guides to the Marketplace. For those customers who know us well and enjoy hanging out in our community (and we have many who have been with us since that day in 2002!), this is no problem. Unfortunately, the downside is many new and potential customers didn't see everything we have to offer: all the wonderful addons our contributors offer, additional support resources, plentiful advice from other community administrators, and more.
In addition, we've always used the default theme that our software ships with, but with our self-service demo system now being the primary way new customers get to try out our software, this has become less important.
So, we took the decision to move some parts of the community to the website for more exposure and easier discovery by new visitors. We made some tweaks to our navigation so that finding these areas is easier than before. And, of course, we've brought the website header over to the community, giving it a fresher look and more consistent navigation, wherever you happen to be on our website.
Of course, all of our website is built in IPS4, as you would expect. Whereas before our website existed on a separate installation, as part of the update we merged our community and website together. This means you can sign in from anywhere, see your notifications and so on.
This is just the first step we've taken on improving what we offer and how we offer it. We have many plans in progress. You may have seen the theme tip we posted this week, which is the first in a series of regular tips we'll be sharing to help you get the most out of the IPS Community Suite. We'll also be highlighting some of the incredible work our customers do, whether it's a unique use of our software, or something in our Marketplace that adds a great feature.
Stay tuned!

Rikki got a reaction from chilihead for a blog entry, Streamlining our website and community March 16, 2016

Many of the regular visitors to our community won't have failed to notice the new look we launched last week. Now that the dust has settled, I thought it was a good time to explain why we've made the change.
Streamlined access to everything we offer
Ever since IPS was founded in 2002, our community has been distinct from our website. The community is also where we kept all kinds of resources, from guides to the Marketplace. For those customers who know us well and enjoy hanging out in our community (and we have many who have been with us since that day in 2002!), this is no problem. Unfortunately, the downside is many new and potential customers didn't see everything we have to offer: all the wonderful addons our contributors offer, additional support resources, plentiful advice from other community administrators, and more.
In addition, we've always used the default theme that our software ships with, but with our self-service demo system now being the primary way new customers get to try out our software, this has become less important.
So, we took the decision to move some parts of the community to the website for more exposure and easier discovery by new visitors. We made some tweaks to our navigation so that finding these areas is easier than before. And, of course, we've brought the website header over to the community, giving it a fresher look and more consistent navigation, wherever you happen to be on our website.
Of course, all of our website is built in IPS4, as you would expect. Whereas before our website existed on a separate installation, as part of the update we merged our community and website together. This means you can sign in from anywhere, see your notifications and so on.
This is just the first step we've taken on improving what we offer and how we offer it. We have many plans in progress. You may have seen the theme tip we posted this week, which is the first in a series of regular tips we'll be sharing to help you get the most out of the IPS Community Suite. We'll also be highlighting some of the incredible work our customers do, whether it's a unique use of our software, or something in our Marketplace that adds a great feature.
Stay tuned!

Rikki got a reaction from Michael.J for a blog entry, Streamlining our website and community March 15, 2016

Many of the regular visitors to our community won't have failed to notice the new look we launched last week. Now that the dust has settled, I thought it was a good time to explain why we've made the change.
Streamlined access to everything we offer
Ever since IPS was founded in 2002, our community has been distinct from our website. The community is also where we kept all kinds of resources, from guides to the Marketplace. For those customers who know us well and enjoy hanging out in our community (and we have many who have been with us since that day in 2002!), this is no problem. Unfortunately, the downside is many new and potential customers didn't see everything we have to offer: all the wonderful addons our contributors offer, additional support resources, plentiful advice from other community administrators, and more.
In addition, we've always used the default theme that our software ships with, but with our self-service demo system now being the primary way new customers get to try out our software, this has become less important.
So, we took the decision to move some parts of the community to the website for more exposure and easier discovery by new visitors. We made some tweaks to our navigation so that finding these areas is easier than before. And, of course, we've brought the website header over to the community, giving it a fresher look and more consistent navigation, wherever you happen to be on our website.
Of course, all of our website is built in IPS4, as you would expect. Whereas before our website existed on a separate installation, as part of the update we merged our community and website together. This means you can sign in from anywhere, see your notifications and so on.
This is just the first step we've taken on improving what we offer and how we offer it. We have many plans in progress. You may have seen the theme tip we posted this week, which is the first in a series of regular tips we'll be sharing to help you get the most out of the IPS Community Suite. We'll also be highlighting some of the incredible work our customers do, whether it's a unique use of our software, or something in our Marketplace that adds a great feature.
Stay tuned!

Rikki got a reaction from Adlago for a blog entry, Streamlining our website and community March 15, 2016

Many of the regular visitors to our community won't have failed to notice the new look we launched last week. Now that the dust has settled, I thought it was a good time to explain why we've made the change.
Streamlined access to everything we offer
Ever since IPS was founded in 2002, our community has been distinct from our website. The community is also where we kept all kinds of resources, from guides to the Marketplace. For those customers who know us well and enjoy hanging out in our community (and we have many who have been with us since that day in 2002!), this is no problem. Unfortunately, the downside is many new and potential customers didn't see everything we have to offer: all the wonderful addons our contributors offer, additional support resources, plentiful advice from other community administrators, and more.
In addition, we've always used the default theme that our software ships with, but with our self-service demo system now being the primary way new customers get to try out our software, this has become less important.
So, we took the decision to move some parts of the community to the website for more exposure and easier discovery by new visitors. We made some tweaks to our navigation so that finding these areas is easier than before. And, of course, we've brought the website header over to the community, giving it a fresher look and more consistent navigation, wherever you happen to be on our website.
Of course, all of our website is built in IPS4, as you would expect. Whereas before our website existed on a separate installation, as part of the update we merged our community and website together. This means you can sign in from anywhere, see your notifications and so on.
This is just the first step we've taken on improving what we offer and how we offer it. We have many plans in progress. You may have seen the theme tip we posted this week, which is the first in a series of regular tips we'll be sharing to help you get the most out of the IPS Community Suite. We'll also be highlighting some of the incredible work our customers do, whether it's a unique use of our software, or something in our Marketplace that adds a great feature.
Stay tuned!

Rikki got a reaction from AndyF for a blog entry, Streamlining our website and community March 15, 2016

Many of the regular visitors to our community won't have failed to notice the new look we launched last week. Now that the dust has settled, I thought it was a good time to explain why we've made the change.
Streamlined access to everything we offer
Ever since IPS was founded in 2002, our community has been distinct from our website. The community is also where we kept all kinds of resources, from guides to the Marketplace. For those customers who know us well and enjoy hanging out in our community (and we have many who have been with us since that day in 2002!), this is no problem. Unfortunately, the downside is many new and potential customers didn't see everything we have to offer: all the wonderful addons our contributors offer, additional support resources, plentiful advice from other community administrators, and more.
In addition, we've always used the default theme that our software ships with, but with our self-service demo system now being the primary way new customers get to try out our software, this has become less important.
So, we took the decision to move some parts of the community to the website for more exposure and easier discovery by new visitors. We made some tweaks to our navigation so that finding these areas is easier than before. And, of course, we've brought the website header over to the community, giving it a fresher look and more consistent navigation, wherever you happen to be on our website.
Of course, all of our website is built in IPS4, as you would expect. Whereas before our website existed on a separate installation, as part of the update we merged our community and website together. This means you can sign in from anywhere, see your notifications and so on.
This is just the first step we've taken on improving what we offer and how we offer it. We have many plans in progress. You may have seen the theme tip we posted this week, which is the first in a series of regular tips we'll be sharing to help you get the most out of the IPS Community Suite. We'll also be highlighting some of the incredible work our customers do, whether it's a unique use of our software, or something in our Marketplace that adds a great feature.
Stay tuned!

Rikki got a reaction from Martin A. for a blog entry, Streamlining our website and community March 15, 2016

Many of the regular visitors to our community won't have failed to notice the new look we launched last week. Now that the dust has settled, I thought it was a good time to explain why we've made the change.
Streamlined access to everything we offer
Ever since IPS was founded in 2002, our community has been distinct from our website. The community is also where we kept all kinds of resources, from guides to the Marketplace. For those customers who know us well and enjoy hanging out in our community (and we have many who have been with us since that day in 2002!), this is no problem. Unfortunately, the downside is many new and potential customers didn't see everything we have to offer: all the wonderful addons our contributors offer, additional support resources, plentiful advice from other community administrators, and more.
In addition, we've always used the default theme that our software ships with, but with our self-service demo system now being the primary way new customers get to try out our software, this has become less important.
So, we took the decision to move some parts of the community to the website for more exposure and easier discovery by new visitors. We made some tweaks to our navigation so that finding these areas is easier than before. And, of course, we've brought the website header over to the community, giving it a fresher look and more consistent navigation, wherever you happen to be on our website.
Of course, all of our website is built in IPS4, as you would expect. Whereas before our website existed on a separate installation, as part of the update we merged our community and website together. This means you can sign in from anywhere, see your notifications and so on.
This is just the first step we've taken on improving what we offer and how we offer it. We have many plans in progress. You may have seen the theme tip we posted this week, which is the first in a series of regular tips we'll be sharing to help you get the most out of the IPS Community Suite. We'll also be highlighting some of the incredible work our customers do, whether it's a unique use of our software, or something in our Marketplace that adds a great feature.
Stay tuned!

Rikki got a reaction from Ioannis D for a blog entry, Streamlining our website and community March 15, 2016

Many of the regular visitors to our community won't have failed to notice the new look we launched last week. Now that the dust has settled, I thought it was a good time to explain why we've made the change.
Streamlined access to everything we offer
Ever since IPS was founded in 2002, our community has been distinct from our website. The community is also where we kept all kinds of resources, from guides to the Marketplace. For those customers who know us well and enjoy hanging out in our community (and we have many who have been with us since that day in 2002!), this is no problem. Unfortunately, the downside is many new and potential customers didn't see everything we have to offer: all the wonderful addons our contributors offer, additional support resources, plentiful advice from other community administrators, and more.
In addition, we've always used the default theme that our software ships with, but with our self-service demo system now being the primary way new customers get to try out our software, this has become less important.
So, we took the decision to move some parts of the community to the website for more exposure and easier discovery by new visitors. We made some tweaks to our navigation so that finding these areas is easier than before. And, of course, we've brought the website header over to the community, giving it a fresher look and more consistent navigation, wherever you happen to be on our website.
Of course, all of our website is built in IPS4, as you would expect. Whereas before our website existed on a separate installation, as part of the update we merged our community and website together. This means you can sign in from anywhere, see your notifications and so on.
This is just the first step we've taken on improving what we offer and how we offer it. We have many plans in progress. You may have seen the theme tip we posted this week, which is the first in a series of regular tips we'll be sharing to help you get the most out of the IPS Community Suite. We'll also be highlighting some of the incredible work our customers do, whether it's a unique use of our software, or something in our Marketplace that adds a great feature.
Stay tuned!

Rikki got a reaction from -RAW- for a blog entry, Streamlining our website and community March 15, 2016

Many of the regular visitors to our community won't have failed to notice the new look we launched last week. Now that the dust has settled, I thought it was a good time to explain why we've made the change.
Streamlined access to everything we offer
Ever since IPS was founded in 2002, our community has been distinct from our website. The community is also where we kept all kinds of resources, from guides to the Marketplace. For those customers who know us well and enjoy hanging out in our community (and we have many who have been with us since that day in 2002!), this is no problem. Unfortunately, the downside is many new and potential customers didn't see everything we have to offer: all the wonderful addons our contributors offer, additional support resources, plentiful advice from other community administrators, and more.
In addition, we've always used the default theme that our software ships with, but with our self-service demo system now being the primary way new customers get to try out our software, this has become less important.
So, we took the decision to move some parts of the community to the website for more exposure and easier discovery by new visitors. We made some tweaks to our navigation so that finding these areas is easier than before. And, of course, we've brought the website header over to the community, giving it a fresher look and more consistent navigation, wherever you happen to be on our website.
Of course, all of our website is built in IPS4, as you would expect. Whereas before our website existed on a separate installation, as part of the update we merged our community and website together. This means you can sign in from anywhere, see your notifications and so on.
This is just the first step we've taken on improving what we offer and how we offer it. We have many plans in progress. You may have seen the theme tip we posted this week, which is the first in a series of regular tips we'll be sharing to help you get the most out of the IPS Community Suite. We'll also be highlighting some of the incredible work our customers do, whether it's a unique use of our software, or something in our Marketplace that adds a great feature.
Stay tuned!

Rikki got a reaction from Hatsu for a blog entry, Streamlining our website and community March 15, 2016

Many of the regular visitors to our community won't have failed to notice the new look we launched last week. Now that the dust has settled, I thought it was a good time to explain why we've made the change.
Streamlined access to everything we offer
Ever since IPS was founded in 2002, our community has been distinct from our website. The community is also where we kept all kinds of resources, from guides to the Marketplace. For those customers who know us well and enjoy hanging out in our community (and we have many who have been with us since that day in 2002!), this is no problem. Unfortunately, the downside is many new and potential customers didn't see everything we have to offer: all the wonderful addons our contributors offer, additional support resources, plentiful advice from other community administrators, and more.
In addition, we've always used the default theme that our software ships with, but with our self-service demo system now being the primary way new customers get to try out our software, this has become less important.
So, we took the decision to move some parts of the community to the website for more exposure and easier discovery by new visitors. We made some tweaks to our navigation so that finding these areas is easier than before. And, of course, we've brought the website header over to the community, giving it a fresher look and more consistent navigation, wherever you happen to be on our website.
Of course, all of our website is built in IPS4, as you would expect. Whereas before our website existed on a separate installation, as part of the update we merged our community and website together. This means you can sign in from anywhere, see your notifications and so on.
This is just the first step we've taken on improving what we offer and how we offer it. We have many plans in progress. You may have seen the theme tip we posted this week, which is the first in a series of regular tips we'll be sharing to help you get the most out of the IPS Community Suite. We'll also be highlighting some of the incredible work our customers do, whether it's a unique use of our software, or something in our Marketplace that adds a great feature.
Stay tuned!

Invision Community 5: Assign topics to moderators

Invision Community 4: Pages databases in Clubs

Invision Community 5: Live Topic Improvements

Invision Community 5: New Live Community Features

Rikki

Posts

Joined

Last visited

Days Won

Reputation Activity

More