Rikki

In IPS4, it's easy to add custom icons to your forums, simply by uploading them on the Edit Forum screen in the AdminCP. But if you want to replace all of your forum icons, uploading the same icon for each forum can be a bit tedious.
It's easy to use some custom CSS to replace all of the icons - lets see how.
First, you'll want to upload the image(s) you want to use to the Resources section of your theme so that it can be used in your CSS. To start with, we'll use the same image for both read and unread status, but we'll cover using a different icon for both too.
 
The basics
Here's the basic CSS to replace the icon for all forums with your custom image:
body[data-pageapp="forums"] .cForumRow .ipsItemStatus.ipsItemStatus_large { width: 50px; height: 50px; border-radius: 0; background-color: transparent; background-image: url('{resource="mushroom.png" app="core" location="front"}'); background-size: 50px 50px; } body[data-pageapp="forums"] .cForumRow .ipsItemStatus.ipsItemStatus_large > i { display: none; } What we're doing here is specifically targeting the item status icons in the forums app, using the body[data-pageapp="forums"] selector. Within this style, we're setting the size of the icon - I've chosen 50px here which is about right in most cases, although you can change this if desired. Next we reset the border radius and background color so the icon looks right. And finally, we set the background image to our icon by using the {resource} tag and the background size to the same dimensions we just set the element to.
The next style hides the FontAwesome icon that IPS4 inserts by default, so that our icon can be seen.
 
Using a different 'read' icon
By default, your icon will be faded out for 'read' icons, but it's easy to use a completely different icon if you wish. Simply add:
body[data-pageapp="forums"] .cForumRow .ipsItemStatus.ipsItemStatus_large.ipsItemStatus_read { background-image: url('{resource="mushroom_faded.png" app="core" location="front"}'); } All we're doing here is using a more specific selector with .ipsItemStatus_read so that only the 'read' state is targeted. In the style, we specify the background image - we don't need to set and reset the other rules again because the styles we wrote in the first step are inherited.
 
Using different icons for redirect or Q&A forums
If you want to add icons specifically for redirect or Q&A forums, you can do that by targeting unique classes that are added to the icons for those kinds of forums. Those classes are .cForumIcon_redirect and .cForumIcon_answers, respectively. So, to use a custom icon for a Q&A forum, you would add another style like so:
body[data-pageapp="forums"] .cForumRow .cForumIcon_answers.ipsItemStatus.ipsItemStatus_large { background-image: url('{resource="question.png" app="core" location="front"}'); } Notice we've added .cForumIcon_answers to our selector.

An enterprise customer recently asked us how to have a different feed block for each of their forums. Their goal was to have each forum show a 'popular topics' block containing topics only from that particular forum. Unfortunately this isn't possible using the standard block manager right now, since each view is treated as one configuration. That means that any blocks added to forum view will show for all forums.
However, as usual in IPS4, some of the more advanced power under the hood does allow you to achieve the same goal - in this case, by using HTML Logic. This technique uses a similar idea to the one I outlined in the Dynamic-ish Forum Feeds blog in May.
 
Creating conditional blocks
The way we would implement this functionality is by creating a custom block that is simply a wrapper for other blocks. This wrapper block will contain HTML Logic that determines which feed block to show, based on some information about the current page.
The first step would be to create standard feed blocks for each of the forums to which this should apply. In our example we're creating 'popular topics' blocks, but it could be anything you wish - the principle will remain the same. Another idea would be to create a 'Topics from other forums' block for each of your forums, whereby in the block configuration, you set it to include topics from all forums except the one in which it will be displayed - a good way of cross-promoting your topics.
In order to include the blocks later, set the template key of each to be forum_x, where x is the ID of the forum in which you will display the block.
 
Once we've created a block for each forum, the next step is to create our wrapper block, which should be a custom block set to use Manual HTML, with the following code:
{{if request.app == 'forums' && request.module == 'forums'}} {{$id = \IPS\Request::i()->id;}} {block="forum_{$id}"} {{endif}} What's happening here is we're checking the app and module from the page URL are both 'forums', which indicates we're in forum view. We then use the {block} tag to insert the appropriate block based on the ID parameter from the URL.
To use this block, simply save it, then using the Block Manager on the front-end, drag it into the desired location in your forum view.
I hope this quick suggestion gives you some ideas for other ways to create blocks that show contextually depending on what the user is viewing. If you have ideas for interesting ways to use this technique, share them in the comments!

In IPS4, it's easy to add custom icons to your forums, simply by uploading them on the Edit Forum screen in the AdminCP. But if you want to replace all of your forum icons, uploading the same icon for each forum can be a bit tedious.
It's easy to use some custom CSS to replace all of the icons - lets see how.
First, you'll want to upload the image(s) you want to use to the Resources section of your theme so that it can be used in your CSS. To start with, we'll use the same image for both read and unread status, but we'll cover using a different icon for both too.
 
The basics
Here's the basic CSS to replace the icon for all forums with your custom image:
body[data-pageapp="forums"] .cForumRow .ipsItemStatus.ipsItemStatus_large { width: 50px; height: 50px; border-radius: 0; background-color: transparent; background-image: url('{resource="mushroom.png" app="core" location="front"}'); background-size: 50px 50px; } body[data-pageapp="forums"] .cForumRow .ipsItemStatus.ipsItemStatus_large > i { display: none; } What we're doing here is specifically targeting the item status icons in the forums app, using the body[data-pageapp="forums"] selector. Within this style, we're setting the size of the icon - I've chosen 50px here which is about right in most cases, although you can change this if desired. Next we reset the border radius and background color so the icon looks right. And finally, we set the background image to our icon by using the {resource} tag and the background size to the same dimensions we just set the element to.
The next style hides the FontAwesome icon that IPS4 inserts by default, so that our icon can be seen.
 
Using a different 'read' icon
By default, your icon will be faded out for 'read' icons, but it's easy to use a completely different icon if you wish. Simply add:
body[data-pageapp="forums"] .cForumRow .ipsItemStatus.ipsItemStatus_large.ipsItemStatus_read { background-image: url('{resource="mushroom_faded.png" app="core" location="front"}'); } All we're doing here is using a more specific selector with .ipsItemStatus_read so that only the 'read' state is targeted. In the style, we specify the background image - we don't need to set and reset the other rules again because the styles we wrote in the first step are inherited.
 
Using different icons for redirect or Q&A forums
If you want to add icons specifically for redirect or Q&A forums, you can do that by targeting unique classes that are added to the icons for those kinds of forums. Those classes are .cForumIcon_redirect and .cForumIcon_answers, respectively. So, to use a custom icon for a Q&A forum, you would add another style like so:
body[data-pageapp="forums"] .cForumRow .cForumIcon_answers.ipsItemStatus.ipsItemStatus_large { background-image: url('{resource="question.png" app="core" location="front"}'); } Notice we've added .cForumIcon_answers to our selector.

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!

In IPS4, it's easy to add custom icons to your forums, simply by uploading them on the Edit Forum screen in the AdminCP. But if you want to replace all of your forum icons, uploading the same icon for each forum can be a bit tedious.
It's easy to use some custom CSS to replace all of the icons - lets see how.
First, you'll want to upload the image(s) you want to use to the Resources section of your theme so that it can be used in your CSS. To start with, we'll use the same image for both read and unread status, but we'll cover using a different icon for both too.
 
The basics
Here's the basic CSS to replace the icon for all forums with your custom image:
body[data-pageapp="forums"] .cForumRow .ipsItemStatus.ipsItemStatus_large { width: 50px; height: 50px; border-radius: 0; background-color: transparent; background-image: url('{resource="mushroom.png" app="core" location="front"}'); background-size: 50px 50px; } body[data-pageapp="forums"] .cForumRow .ipsItemStatus.ipsItemStatus_large > i { display: none; } What we're doing here is specifically targeting the item status icons in the forums app, using the body[data-pageapp="forums"] selector. Within this style, we're setting the size of the icon - I've chosen 50px here which is about right in most cases, although you can change this if desired. Next we reset the border radius and background color so the icon looks right. And finally, we set the background image to our icon by using the {resource} tag and the background size to the same dimensions we just set the element to.
The next style hides the FontAwesome icon that IPS4 inserts by default, so that our icon can be seen.
 
Using a different 'read' icon
By default, your icon will be faded out for 'read' icons, but it's easy to use a completely different icon if you wish. Simply add:
body[data-pageapp="forums"] .cForumRow .ipsItemStatus.ipsItemStatus_large.ipsItemStatus_read { background-image: url('{resource="mushroom_faded.png" app="core" location="front"}'); } All we're doing here is using a more specific selector with .ipsItemStatus_read so that only the 'read' state is targeted. In the style, we specify the background image - we don't need to set and reset the other rules again because the styles we wrote in the first step are inherited.
 
Using different icons for redirect or Q&A forums
If you want to add icons specifically for redirect or Q&A forums, you can do that by targeting unique classes that are added to the icons for those kinds of forums. Those classes are .cForumIcon_redirect and .cForumIcon_answers, respectively. So, to use a custom icon for a Q&A forum, you would add another style like so:
body[data-pageapp="forums"] .cForumRow .cForumIcon_answers.ipsItemStatus.ipsItemStatus_large { background-image: url('{resource="question.png" app="core" location="front"}'); } Notice we've added .cForumIcon_answers to our selector.

In IPS4, it's easy to add custom icons to your forums, simply by uploading them on the Edit Forum screen in the AdminCP. But if you want to replace all of your forum icons, uploading the same icon for each forum can be a bit tedious.
It's easy to use some custom CSS to replace all of the icons - lets see how.
First, you'll want to upload the image(s) you want to use to the Resources section of your theme so that it can be used in your CSS. To start with, we'll use the same image for both read and unread status, but we'll cover using a different icon for both too.
 
The basics
Here's the basic CSS to replace the icon for all forums with your custom image:
body[data-pageapp="forums"] .cForumRow .ipsItemStatus.ipsItemStatus_large { width: 50px; height: 50px; border-radius: 0; background-color: transparent; background-image: url('{resource="mushroom.png" app="core" location="front"}'); background-size: 50px 50px; } body[data-pageapp="forums"] .cForumRow .ipsItemStatus.ipsItemStatus_large > i { display: none; } What we're doing here is specifically targeting the item status icons in the forums app, using the body[data-pageapp="forums"] selector. Within this style, we're setting the size of the icon - I've chosen 50px here which is about right in most cases, although you can change this if desired. Next we reset the border radius and background color so the icon looks right. And finally, we set the background image to our icon by using the {resource} tag and the background size to the same dimensions we just set the element to.
The next style hides the FontAwesome icon that IPS4 inserts by default, so that our icon can be seen.
 
Using a different 'read' icon
By default, your icon will be faded out for 'read' icons, but it's easy to use a completely different icon if you wish. Simply add:
body[data-pageapp="forums"] .cForumRow .ipsItemStatus.ipsItemStatus_large.ipsItemStatus_read { background-image: url('{resource="mushroom_faded.png" app="core" location="front"}'); } All we're doing here is using a more specific selector with .ipsItemStatus_read so that only the 'read' state is targeted. In the style, we specify the background image - we don't need to set and reset the other rules again because the styles we wrote in the first step are inherited.
 
Using different icons for redirect or Q&A forums
If you want to add icons specifically for redirect or Q&A forums, you can do that by targeting unique classes that are added to the icons for those kinds of forums. Those classes are .cForumIcon_redirect and .cForumIcon_answers, respectively. So, to use a custom icon for a Q&A forum, you would add another style like so:
body[data-pageapp="forums"] .cForumRow .cForumIcon_answers.ipsItemStatus.ipsItemStatus_large { background-image: url('{resource="question.png" app="core" location="front"}'); } Notice we've added .cForumIcon_answers to our selector.

In IPS4, it's easy to add custom icons to your forums, simply by uploading them on the Edit Forum screen in the AdminCP. But if you want to replace all of your forum icons, uploading the same icon for each forum can be a bit tedious.
It's easy to use some custom CSS to replace all of the icons - lets see how.
First, you'll want to upload the image(s) you want to use to the Resources section of your theme so that it can be used in your CSS. To start with, we'll use the same image for both read and unread status, but we'll cover using a different icon for both too.
 
The basics
Here's the basic CSS to replace the icon for all forums with your custom image:
body[data-pageapp="forums"] .cForumRow .ipsItemStatus.ipsItemStatus_large { width: 50px; height: 50px; border-radius: 0; background-color: transparent; background-image: url('{resource="mushroom.png" app="core" location="front"}'); background-size: 50px 50px; } body[data-pageapp="forums"] .cForumRow .ipsItemStatus.ipsItemStatus_large > i { display: none; } What we're doing here is specifically targeting the item status icons in the forums app, using the body[data-pageapp="forums"] selector. Within this style, we're setting the size of the icon - I've chosen 50px here which is about right in most cases, although you can change this if desired. Next we reset the border radius and background color so the icon looks right. And finally, we set the background image to our icon by using the {resource} tag and the background size to the same dimensions we just set the element to.
The next style hides the FontAwesome icon that IPS4 inserts by default, so that our icon can be seen.
 
Using a different 'read' icon
By default, your icon will be faded out for 'read' icons, but it's easy to use a completely different icon if you wish. Simply add:
body[data-pageapp="forums"] .cForumRow .ipsItemStatus.ipsItemStatus_large.ipsItemStatus_read { background-image: url('{resource="mushroom_faded.png" app="core" location="front"}'); } All we're doing here is using a more specific selector with .ipsItemStatus_read so that only the 'read' state is targeted. In the style, we specify the background image - we don't need to set and reset the other rules again because the styles we wrote in the first step are inherited.
 
Using different icons for redirect or Q&A forums
If you want to add icons specifically for redirect or Q&A forums, you can do that by targeting unique classes that are added to the icons for those kinds of forums. Those classes are .cForumIcon_redirect and .cForumIcon_answers, respectively. So, to use a custom icon for a Q&A forum, you would add another style like so:
body[data-pageapp="forums"] .cForumRow .cForumIcon_answers.ipsItemStatus.ipsItemStatus_large { background-image: url('{resource="question.png" app="core" location="front"}'); } Notice we've added .cForumIcon_answers to our selector.

An enterprise customer recently asked us how to have a different feed block for each of their forums. Their goal was to have each forum show a 'popular topics' block containing topics only from that particular forum. Unfortunately this isn't possible using the standard block manager right now, since each view is treated as one configuration. That means that any blocks added to forum view will show for all forums.
However, as usual in IPS4, some of the more advanced power under the hood does allow you to achieve the same goal - in this case, by using HTML Logic. This technique uses a similar idea to the one I outlined in the Dynamic-ish Forum Feeds blog in May.
 
Creating conditional blocks
The way we would implement this functionality is by creating a custom block that is simply a wrapper for other blocks. This wrapper block will contain HTML Logic that determines which feed block to show, based on some information about the current page.
The first step would be to create standard feed blocks for each of the forums to which this should apply. In our example we're creating 'popular topics' blocks, but it could be anything you wish - the principle will remain the same. Another idea would be to create a 'Topics from other forums' block for each of your forums, whereby in the block configuration, you set it to include topics from all forums except the one in which it will be displayed - a good way of cross-promoting your topics.
In order to include the blocks later, set the template key of each to be forum_x, where x is the ID of the forum in which you will display the block.
 
Once we've created a block for each forum, the next step is to create our wrapper block, which should be a custom block set to use Manual HTML, with the following code:
{{if request.app == 'forums' && request.module == 'forums'}} {{$id = \IPS\Request::i()->id;}} {block="forum_{$id}"} {{endif}} What's happening here is we're checking the app and module from the page URL are both 'forums', which indicates we're in forum view. We then use the {block} tag to insert the appropriate block based on the ID parameter from the URL.
To use this block, simply save it, then using the Block Manager on the front-end, drag it into the desired location in your forum view.
I hope this quick suggestion gives you some ideas for other ways to create blocks that show contextually depending on what the user is viewing. If you have ideas for interesting ways to use this technique, share them in the comments!

An enterprise customer recently asked us how to have a different feed block for each of their forums. Their goal was to have each forum show a 'popular topics' block containing topics only from that particular forum. Unfortunately this isn't possible using the standard block manager right now, since each view is treated as one configuration. That means that any blocks added to forum view will show for all forums.
However, as usual in IPS4, some of the more advanced power under the hood does allow you to achieve the same goal - in this case, by using HTML Logic. This technique uses a similar idea to the one I outlined in the Dynamic-ish Forum Feeds blog in May.
 
Creating conditional blocks
The way we would implement this functionality is by creating a custom block that is simply a wrapper for other blocks. This wrapper block will contain HTML Logic that determines which feed block to show, based on some information about the current page.
The first step would be to create standard feed blocks for each of the forums to which this should apply. In our example we're creating 'popular topics' blocks, but it could be anything you wish - the principle will remain the same. Another idea would be to create a 'Topics from other forums' block for each of your forums, whereby in the block configuration, you set it to include topics from all forums except the one in which it will be displayed - a good way of cross-promoting your topics.
In order to include the blocks later, set the template key of each to be forum_x, where x is the ID of the forum in which you will display the block.
 
Once we've created a block for each forum, the next step is to create our wrapper block, which should be a custom block set to use Manual HTML, with the following code:
{{if request.app == 'forums' && request.module == 'forums'}} {{$id = \IPS\Request::i()->id;}} {block="forum_{$id}"} {{endif}} What's happening here is we're checking the app and module from the page URL are both 'forums', which indicates we're in forum view. We then use the {block} tag to insert the appropriate block based on the ID parameter from the URL.
To use this block, simply save it, then using the Block Manager on the front-end, drag it into the desired location in your forum view.
I hope this quick suggestion gives you some ideas for other ways to create blocks that show contextually depending on what the user is viewing. If you have ideas for interesting ways to use this technique, share them in the comments!

An enterprise customer recently asked us how to have a different feed block for each of their forums. Their goal was to have each forum show a 'popular topics' block containing topics only from that particular forum. Unfortunately this isn't possible using the standard block manager right now, since each view is treated as one configuration. That means that any blocks added to forum view will show for all forums.
However, as usual in IPS4, some of the more advanced power under the hood does allow you to achieve the same goal - in this case, by using HTML Logic. This technique uses a similar idea to the one I outlined in the Dynamic-ish Forum Feeds blog in May.
 
Creating conditional blocks
The way we would implement this functionality is by creating a custom block that is simply a wrapper for other blocks. This wrapper block will contain HTML Logic that determines which feed block to show, based on some information about the current page.
The first step would be to create standard feed blocks for each of the forums to which this should apply. In our example we're creating 'popular topics' blocks, but it could be anything you wish - the principle will remain the same. Another idea would be to create a 'Topics from other forums' block for each of your forums, whereby in the block configuration, you set it to include topics from all forums except the one in which it will be displayed - a good way of cross-promoting your topics.
In order to include the blocks later, set the template key of each to be forum_x, where x is the ID of the forum in which you will display the block.
 
Once we've created a block for each forum, the next step is to create our wrapper block, which should be a custom block set to use Manual HTML, with the following code:
{{if request.app == 'forums' && request.module == 'forums'}} {{$id = \IPS\Request::i()->id;}} {block="forum_{$id}"} {{endif}} What's happening here is we're checking the app and module from the page URL are both 'forums', which indicates we're in forum view. We then use the {block} tag to insert the appropriate block based on the ID parameter from the URL.
To use this block, simply save it, then using the Block Manager on the front-end, drag it into the desired location in your forum view.
I hope this quick suggestion gives you some ideas for other ways to create blocks that show contextually depending on what the user is viewing. If you have ideas for interesting ways to use this technique, share them in the comments!

An enterprise customer recently asked us how to have a different feed block for each of their forums. Their goal was to have each forum show a 'popular topics' block containing topics only from that particular forum. Unfortunately this isn't possible using the standard block manager right now, since each view is treated as one configuration. That means that any blocks added to forum view will show for all forums.
However, as usual in IPS4, some of the more advanced power under the hood does allow you to achieve the same goal - in this case, by using HTML Logic. This technique uses a similar idea to the one I outlined in the Dynamic-ish Forum Feeds blog in May.
 
Creating conditional blocks
The way we would implement this functionality is by creating a custom block that is simply a wrapper for other blocks. This wrapper block will contain HTML Logic that determines which feed block to show, based on some information about the current page.
The first step would be to create standard feed blocks for each of the forums to which this should apply. In our example we're creating 'popular topics' blocks, but it could be anything you wish - the principle will remain the same. Another idea would be to create a 'Topics from other forums' block for each of your forums, whereby in the block configuration, you set it to include topics from all forums except the one in which it will be displayed - a good way of cross-promoting your topics.
In order to include the blocks later, set the template key of each to be forum_x, where x is the ID of the forum in which you will display the block.
 
Once we've created a block for each forum, the next step is to create our wrapper block, which should be a custom block set to use Manual HTML, with the following code:
{{if request.app == 'forums' && request.module == 'forums'}} {{$id = \IPS\Request::i()->id;}} {block="forum_{$id}"} {{endif}} What's happening here is we're checking the app and module from the page URL are both 'forums', which indicates we're in forum view. We then use the {block} tag to insert the appropriate block based on the ID parameter from the URL.
To use this block, simply save it, then using the Block Manager on the front-end, drag it into the desired location in your forum view.
I hope this quick suggestion gives you some ideas for other ways to create blocks that show contextually depending on what the user is viewing. If you have ideas for interesting ways to use this technique, share them in the comments!

In IPS4, it's easy to add custom icons to your forums, simply by uploading them on the Edit Forum screen in the AdminCP. But if you want to replace all of your forum icons, uploading the same icon for each forum can be a bit tedious.
It's easy to use some custom CSS to replace all of the icons - lets see how.
First, you'll want to upload the image(s) you want to use to the Resources section of your theme so that it can be used in your CSS. To start with, we'll use the same image for both read and unread status, but we'll cover using a different icon for both too.
 
The basics
Here's the basic CSS to replace the icon for all forums with your custom image:
body[data-pageapp="forums"] .cForumRow .ipsItemStatus.ipsItemStatus_large { width: 50px; height: 50px; border-radius: 0; background-color: transparent; background-image: url('{resource="mushroom.png" app="core" location="front"}'); background-size: 50px 50px; } body[data-pageapp="forums"] .cForumRow .ipsItemStatus.ipsItemStatus_large > i { display: none; } What we're doing here is specifically targeting the item status icons in the forums app, using the body[data-pageapp="forums"] selector. Within this style, we're setting the size of the icon - I've chosen 50px here which is about right in most cases, although you can change this if desired. Next we reset the border radius and background color so the icon looks right. And finally, we set the background image to our icon by using the {resource} tag and the background size to the same dimensions we just set the element to.
The next style hides the FontAwesome icon that IPS4 inserts by default, so that our icon can be seen.
 
Using a different 'read' icon
By default, your icon will be faded out for 'read' icons, but it's easy to use a completely different icon if you wish. Simply add:
body[data-pageapp="forums"] .cForumRow .ipsItemStatus.ipsItemStatus_large.ipsItemStatus_read { background-image: url('{resource="mushroom_faded.png" app="core" location="front"}'); } All we're doing here is using a more specific selector with .ipsItemStatus_read so that only the 'read' state is targeted. In the style, we specify the background image - we don't need to set and reset the other rules again because the styles we wrote in the first step are inherited.
 
Using different icons for redirect or Q&A forums
If you want to add icons specifically for redirect or Q&A forums, you can do that by targeting unique classes that are added to the icons for those kinds of forums. Those classes are .cForumIcon_redirect and .cForumIcon_answers, respectively. So, to use a custom icon for a Q&A forum, you would add another style like so:
body[data-pageapp="forums"] .cForumRow .cForumIcon_answers.ipsItemStatus.ipsItemStatus_large { background-image: url('{resource="question.png" app="core" location="front"}'); } Notice we've added .cForumIcon_answers to our selector.

Blocks are an extremely popular feature in IPS4, used by a huge number of customers to great effect. They range from feeds of topics, to statistics, to custom blocks that can contain anything you wish. They're a great way to add dynamic content to your community theme.
What many people don't know is that blocks you create with Pages can be used anywhere in your theme, not just in the designated block containers (in the header, footer & sidebar).
 
The {block} tag
It's really easy to do so. Here's the tag you'd use:
{block="block_key"} That's it! The block_key is the one you specify when you're creating the block in Pages (if you don't specify one manually, Pages will auto-generate one for you).
 
Where can you use them?
Block tags can be used anywhere that template logic is supported. That includes:
Theme templates Pages page content Other kinds of templates (e.g. database templates) Even within other blocks!  
What can you do with them?
The obvious benefit of blocks is that they are reusable, so in any situation where you need the same content duplicated, it makes sense to put the content in a custom block instead, and simply insert it wherever needed. Then if you need to update the content later, you have one place to do so. Custom menus are a great example of reusing blocks; since blocks have full use of template logic, you can build your menu HTML in a block, use HTML Logic to highlight the correct item, and insert the menu block on each of your pages. We use this approach on our feature tour section menu. Here's a snippet of the menu block HTML for that page:
<nav id='elTourNav'> <div class='container'> <ul class='ipsList_inline'> <li><a href='/features/apps' {{if \IPS\Request::i()->path == 'features/apps'}}class='sSelected'{{endif}}>Our Apps</a></li> <li><a href='/features/engagement' {{if \IPS\Request::i()->path == 'features/engagement'}}class='sSelected'{{endif}}>Engagement</a></li> <!-- ... --> </ul> </div> </nav>  
Blocks are useful beyond that, though. A couple of weeks ago, we showed you how to use HTML Logic to only show content to certain groups. Using blocks is actually an easier way to do this - simply add the content to a custom block, then check the groups who should see it. We use this technique to show a 'welcome to our community' message to guests on our own community. We created our welcome message as a custom Pages block, set it so that only guests have permission to view it, and then added it to our template header. Simple, effective and easy to manage.
That's just two ways you can use blocks - there's many other creative users too! If you've used blocks in an interesting way, share your example in the comments!

An enterprise customer recently asked us how to have a different feed block for each of their forums. Their goal was to have each forum show a 'popular topics' block containing topics only from that particular forum. Unfortunately this isn't possible using the standard block manager right now, since each view is treated as one configuration. That means that any blocks added to forum view will show for all forums.
However, as usual in IPS4, some of the more advanced power under the hood does allow you to achieve the same goal - in this case, by using HTML Logic. This technique uses a similar idea to the one I outlined in the Dynamic-ish Forum Feeds blog in May.
 
Creating conditional blocks
The way we would implement this functionality is by creating a custom block that is simply a wrapper for other blocks. This wrapper block will contain HTML Logic that determines which feed block to show, based on some information about the current page.
The first step would be to create standard feed blocks for each of the forums to which this should apply. In our example we're creating 'popular topics' blocks, but it could be anything you wish - the principle will remain the same. Another idea would be to create a 'Topics from other forums' block for each of your forums, whereby in the block configuration, you set it to include topics from all forums except the one in which it will be displayed - a good way of cross-promoting your topics.
In order to include the blocks later, set the template key of each to be forum_x, where x is the ID of the forum in which you will display the block.
 
Once we've created a block for each forum, the next step is to create our wrapper block, which should be a custom block set to use Manual HTML, with the following code:
{{if request.app == 'forums' && request.module == 'forums'}} {{$id = \IPS\Request::i()->id;}} {block="forum_{$id}"} {{endif}} What's happening here is we're checking the app and module from the page URL are both 'forums', which indicates we're in forum view. We then use the {block} tag to insert the appropriate block based on the ID parameter from the URL.
To use this block, simply save it, then using the Block Manager on the front-end, drag it into the desired location in your forum view.
I hope this quick suggestion gives you some ideas for other ways to create blocks that show contextually depending on what the user is viewing. If you have ideas for interesting ways to use this technique, share them in the comments!

In line with our aim to make incremental improvements in each release, I wanted to go over a few of the small but useful changes to the personal messenger that you'll find in our next release, 4.1.13.
 
Read/unread filtering
The first improvement is that you can now filter the message list by read and unread, making it a little easier to browse through just the messages you're interested in.
 
Search improvements
Next up, the messenger search has been improved in a couple of ways; first, you can now also search the names of both the recipients and the senders, and second, we've added a menu so you can specify which fields in particular you want to search by.
 
Easier moving
Finally, we've added a popular request - the ability to use the mass-move tool inside the messenger. You can now check multiple messages, and the usual mass-action toolbar will appear that will allow you either move them to another folder, or, has been the case in the past, delete them.
 
While these are each small improvements by themselves, we hope the incremental changes in each release add up to a more pleasant experience for users. 

When IPS4 encounters an error (be it a simple 404 Not Found or a more complex configuration issue), the user sees a standard built-in error page. That's fine in many cases, but did you know you can create your own error page using our Pages app?
This is a particularly good approach for communities that use Pages for their website too. If you have built a website theme, the standard error page may not fit with your visual style, so building your own error page allows you to improve it. You might want to show some helpful links to other parts of your website, for example.
 
Creating your error page
The first step is creating your error page in Pages. Note that for this page, you must create a manual page - the Page Builder tool can't be used in this case.
In order to show the error on your page, there's two special tags you should insert in the page content. When your page is shown in response to an error, Pages will swap out these tags for the relevant text. They are:
{error_code}
Replaced with the technical error code for this error. This code identifies the exact piece of code that triggered the error, and can be given to IPS support technicians to help diagnose problems. {error_message}
Replaced with a human-friendly description of the error that occurred.  
Configuring Pages to use the error page
Next, set Pages to display the error page. You do this in the Pages section; click the Advanced Settings button, and select your page from the list. Note that this will replace all error pages across the suite - not just errors triggered by Pages itself!
 
Have a request for a theme tip? Let us know in the comments and we'll try and help out in a future tip! 
 

In line with our aim to make incremental improvements in each release, I wanted to go over a few of the small but useful changes to the personal messenger that you'll find in our next release, 4.1.13.
 
Read/unread filtering
The first improvement is that you can now filter the message list by read and unread, making it a little easier to browse through just the messages you're interested in.
 
Search improvements
Next up, the messenger search has been improved in a couple of ways; first, you can now also search the names of both the recipients and the senders, and second, we've added a menu so you can specify which fields in particular you want to search by.
 
Easier moving
Finally, we've added a popular request - the ability to use the mass-move tool inside the messenger. You can now check multiple messages, and the usual mass-action toolbar will appear that will allow you either move them to another folder, or, has been the case in the past, delete them.
 
While these are each small improvements by themselves, we hope the incremental changes in each release add up to a more pleasant experience for users. 

In line with our aim to make incremental improvements in each release, I wanted to go over a few of the small but useful changes to the personal messenger that you'll find in our next release, 4.1.13.
 
Read/unread filtering
The first improvement is that you can now filter the message list by read and unread, making it a little easier to browse through just the messages you're interested in.
 
Search improvements
Next up, the messenger search has been improved in a couple of ways; first, you can now also search the names of both the recipients and the senders, and second, we've added a menu so you can specify which fields in particular you want to search by.
 
Easier moving
Finally, we've added a popular request - the ability to use the mass-move tool inside the messenger. You can now check multiple messages, and the usual mass-action toolbar will appear that will allow you either move them to another folder, or, has been the case in the past, delete them.
 
While these are each small improvements by themselves, we hope the incremental changes in each release add up to a more pleasant experience for users. 

When IPS4 encounters an error (be it a simple 404 Not Found or a more complex configuration issue), the user sees a standard built-in error page. That's fine in many cases, but did you know you can create your own error page using our Pages app?
This is a particularly good approach for communities that use Pages for their website too. If you have built a website theme, the standard error page may not fit with your visual style, so building your own error page allows you to improve it. You might want to show some helpful links to other parts of your website, for example.
 
Creating your error page
The first step is creating your error page in Pages. Note that for this page, you must create a manual page - the Page Builder tool can't be used in this case.
In order to show the error on your page, there's two special tags you should insert in the page content. When your page is shown in response to an error, Pages will swap out these tags for the relevant text. They are:
{error_code}
Replaced with the technical error code for this error. This code identifies the exact piece of code that triggered the error, and can be given to IPS support technicians to help diagnose problems. {error_message}
Replaced with a human-friendly description of the error that occurred.  
Configuring Pages to use the error page
Next, set Pages to display the error page. You do this in the Pages section; click the Advanced Settings button, and select your page from the list. Note that this will replace all error pages across the suite - not just errors triggered by Pages itself!
 
Have a request for a theme tip? Let us know in the comments and we'll try and help out in a future tip! 
 

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!

An enterprise customer recently asked us how to have a different feed block for each of their forums. Their goal was to have each forum show a 'popular topics' block containing topics only from that particular forum. Unfortunately this isn't possible using the standard block manager right now, since each view is treated as one configuration. That means that any blocks added to forum view will show for all forums.
However, as usual in IPS4, some of the more advanced power under the hood does allow you to achieve the same goal - in this case, by using HTML Logic. This technique uses a similar idea to the one I outlined in the Dynamic-ish Forum Feeds blog in May.
 
Creating conditional blocks
The way we would implement this functionality is by creating a custom block that is simply a wrapper for other blocks. This wrapper block will contain HTML Logic that determines which feed block to show, based on some information about the current page.
The first step would be to create standard feed blocks for each of the forums to which this should apply. In our example we're creating 'popular topics' blocks, but it could be anything you wish - the principle will remain the same. Another idea would be to create a 'Topics from other forums' block for each of your forums, whereby in the block configuration, you set it to include topics from all forums except the one in which it will be displayed - a good way of cross-promoting your topics.
In order to include the blocks later, set the template key of each to be forum_x, where x is the ID of the forum in which you will display the block.
 
Once we've created a block for each forum, the next step is to create our wrapper block, which should be a custom block set to use Manual HTML, with the following code:
{{if request.app == 'forums' && request.module == 'forums'}} {{$id = \IPS\Request::i()->id;}} {block="forum_{$id}"} {{endif}} What's happening here is we're checking the app and module from the page URL are both 'forums', which indicates we're in forum view. We then use the {block} tag to insert the appropriate block based on the ID parameter from the URL.
To use this block, simply save it, then using the Block Manager on the front-end, drag it into the desired location in your forum view.
I hope this quick suggestion gives you some ideas for other ways to create blocks that show contextually depending on what the user is viewing. If you have ideas for interesting ways to use this technique, share them in the comments!

An enterprise customer recently asked us how to have a different feed block for each of their forums. Their goal was to have each forum show a 'popular topics' block containing topics only from that particular forum. Unfortunately this isn't possible using the standard block manager right now, since each view is treated as one configuration. That means that any blocks added to forum view will show for all forums.
However, as usual in IPS4, some of the more advanced power under the hood does allow you to achieve the same goal - in this case, by using HTML Logic. This technique uses a similar idea to the one I outlined in the Dynamic-ish Forum Feeds blog in May.
 
Creating conditional blocks
The way we would implement this functionality is by creating a custom block that is simply a wrapper for other blocks. This wrapper block will contain HTML Logic that determines which feed block to show, based on some information about the current page.
The first step would be to create standard feed blocks for each of the forums to which this should apply. In our example we're creating 'popular topics' blocks, but it could be anything you wish - the principle will remain the same. Another idea would be to create a 'Topics from other forums' block for each of your forums, whereby in the block configuration, you set it to include topics from all forums except the one in which it will be displayed - a good way of cross-promoting your topics.
In order to include the blocks later, set the template key of each to be forum_x, where x is the ID of the forum in which you will display the block.
 
Once we've created a block for each forum, the next step is to create our wrapper block, which should be a custom block set to use Manual HTML, with the following code:
{{if request.app == 'forums' && request.module == 'forums'}} {{$id = \IPS\Request::i()->id;}} {block="forum_{$id}"} {{endif}} What's happening here is we're checking the app and module from the page URL are both 'forums', which indicates we're in forum view. We then use the {block} tag to insert the appropriate block based on the ID parameter from the URL.
To use this block, simply save it, then using the Block Manager on the front-end, drag it into the desired location in your forum view.
I hope this quick suggestion gives you some ideas for other ways to create blocks that show contextually depending on what the user is viewing. If you have ideas for interesting ways to use this technique, share them in the comments!

An enterprise customer recently asked us how to have a different feed block for each of their forums. Their goal was to have each forum show a 'popular topics' block containing topics only from that particular forum. Unfortunately this isn't possible using the standard block manager right now, since each view is treated as one configuration. That means that any blocks added to forum view will show for all forums.
However, as usual in IPS4, some of the more advanced power under the hood does allow you to achieve the same goal - in this case, by using HTML Logic. This technique uses a similar idea to the one I outlined in the Dynamic-ish Forum Feeds blog in May.
 
Creating conditional blocks
The way we would implement this functionality is by creating a custom block that is simply a wrapper for other blocks. This wrapper block will contain HTML Logic that determines which feed block to show, based on some information about the current page.
The first step would be to create standard feed blocks for each of the forums to which this should apply. In our example we're creating 'popular topics' blocks, but it could be anything you wish - the principle will remain the same. Another idea would be to create a 'Topics from other forums' block for each of your forums, whereby in the block configuration, you set it to include topics from all forums except the one in which it will be displayed - a good way of cross-promoting your topics.
In order to include the blocks later, set the template key of each to be forum_x, where x is the ID of the forum in which you will display the block.
 
Once we've created a block for each forum, the next step is to create our wrapper block, which should be a custom block set to use Manual HTML, with the following code:
{{if request.app == 'forums' && request.module == 'forums'}} {{$id = \IPS\Request::i()->id;}} {block="forum_{$id}"} {{endif}} What's happening here is we're checking the app and module from the page URL are both 'forums', which indicates we're in forum view. We then use the {block} tag to insert the appropriate block based on the ID parameter from the URL.
To use this block, simply save it, then using the Block Manager on the front-end, drag it into the desired location in your forum view.
I hope this quick suggestion gives you some ideas for other ways to create blocks that show contextually depending on what the user is viewing. If you have ideas for interesting ways to use this technique, share them in the comments!

An enterprise customer recently asked us how to have a different feed block for each of their forums. Their goal was to have each forum show a 'popular topics' block containing topics only from that particular forum. Unfortunately this isn't possible using the standard block manager right now, since each view is treated as one configuration. That means that any blocks added to forum view will show for all forums.
However, as usual in IPS4, some of the more advanced power under the hood does allow you to achieve the same goal - in this case, by using HTML Logic. This technique uses a similar idea to the one I outlined in the Dynamic-ish Forum Feeds blog in May.
 
Creating conditional blocks
The way we would implement this functionality is by creating a custom block that is simply a wrapper for other blocks. This wrapper block will contain HTML Logic that determines which feed block to show, based on some information about the current page.
The first step would be to create standard feed blocks for each of the forums to which this should apply. In our example we're creating 'popular topics' blocks, but it could be anything you wish - the principle will remain the same. Another idea would be to create a 'Topics from other forums' block for each of your forums, whereby in the block configuration, you set it to include topics from all forums except the one in which it will be displayed - a good way of cross-promoting your topics.
In order to include the blocks later, set the template key of each to be forum_x, where x is the ID of the forum in which you will display the block.
 
Once we've created a block for each forum, the next step is to create our wrapper block, which should be a custom block set to use Manual HTML, with the following code:
{{if request.app == 'forums' && request.module == 'forums'}} {{$id = \IPS\Request::i()->id;}} {block="forum_{$id}"} {{endif}} What's happening here is we're checking the app and module from the page URL are both 'forums', which indicates we're in forum view. We then use the {block} tag to insert the appropriate block based on the ID parameter from the URL.
To use this block, simply save it, then using the Block Manager on the front-end, drag it into the desired location in your forum view.
I hope this quick suggestion gives you some ideas for other ways to create blocks that show contextually depending on what the user is viewing. If you have ideas for interesting ways to use this technique, share them in the comments!

An enterprise customer recently asked us how to have a different feed block for each of their forums. Their goal was to have each forum show a 'popular topics' block containing topics only from that particular forum. Unfortunately this isn't possible using the standard block manager right now, since each view is treated as one configuration. That means that any blocks added to forum view will show for all forums.
However, as usual in IPS4, some of the more advanced power under the hood does allow you to achieve the same goal - in this case, by using HTML Logic. This technique uses a similar idea to the one I outlined in the Dynamic-ish Forum Feeds blog in May.
 
Creating conditional blocks
The way we would implement this functionality is by creating a custom block that is simply a wrapper for other blocks. This wrapper block will contain HTML Logic that determines which feed block to show, based on some information about the current page.
The first step would be to create standard feed blocks for each of the forums to which this should apply. In our example we're creating 'popular topics' blocks, but it could be anything you wish - the principle will remain the same. Another idea would be to create a 'Topics from other forums' block for each of your forums, whereby in the block configuration, you set it to include topics from all forums except the one in which it will be displayed - a good way of cross-promoting your topics.
In order to include the blocks later, set the template key of each to be forum_x, where x is the ID of the forum in which you will display the block.
 
Once we've created a block for each forum, the next step is to create our wrapper block, which should be a custom block set to use Manual HTML, with the following code:
{{if request.app == 'forums' && request.module == 'forums'}} {{$id = \IPS\Request::i()->id;}} {block="forum_{$id}"} {{endif}} What's happening here is we're checking the app and module from the page URL are both 'forums', which indicates we're in forum view. We then use the {block} tag to insert the appropriate block based on the ID parameter from the URL.
To use this block, simply save it, then using the Block Manager on the front-end, drag it into the desired location in your forum view.
I hope this quick suggestion gives you some ideas for other ways to create blocks that show contextually depending on what the user is viewing. If you have ideas for interesting ways to use this technique, share them in the comments!

An enterprise customer recently asked us how to have a different feed block for each of their forums. Their goal was to have each forum show a 'popular topics' block containing topics only from that particular forum. Unfortunately this isn't possible using the standard block manager right now, since each view is treated as one configuration. That means that any blocks added to forum view will show for all forums.
However, as usual in IPS4, some of the more advanced power under the hood does allow you to achieve the same goal - in this case, by using HTML Logic. This technique uses a similar idea to the one I outlined in the Dynamic-ish Forum Feeds blog in May.
 
Creating conditional blocks
The way we would implement this functionality is by creating a custom block that is simply a wrapper for other blocks. This wrapper block will contain HTML Logic that determines which feed block to show, based on some information about the current page.
The first step would be to create standard feed blocks for each of the forums to which this should apply. In our example we're creating 'popular topics' blocks, but it could be anything you wish - the principle will remain the same. Another idea would be to create a 'Topics from other forums' block for each of your forums, whereby in the block configuration, you set it to include topics from all forums except the one in which it will be displayed - a good way of cross-promoting your topics.
In order to include the blocks later, set the template key of each to be forum_x, where x is the ID of the forum in which you will display the block.
 
Once we've created a block for each forum, the next step is to create our wrapper block, which should be a custom block set to use Manual HTML, with the following code:
{{if request.app == 'forums' && request.module == 'forums'}} {{$id = \IPS\Request::i()->id;}} {block="forum_{$id}"} {{endif}} What's happening here is we're checking the app and module from the page URL are both 'forums', which indicates we're in forum view. We then use the {block} tag to insert the appropriate block based on the ID parameter from the URL.
To use this block, simply save it, then using the Block Manager on the front-end, drag it into the desired location in your forum view.
I hope this quick suggestion gives you some ideas for other ways to create blocks that show contextually depending on what the user is viewing. If you have ideas for interesting ways to use this technique, share them in the comments!

An enterprise customer recently asked us how to have a different feed block for each of their forums. Their goal was to have each forum show a 'popular topics' block containing topics only from that particular forum. Unfortunately this isn't possible using the standard block manager right now, since each view is treated as one configuration. That means that any blocks added to forum view will show for all forums.
However, as usual in IPS4, some of the more advanced power under the hood does allow you to achieve the same goal - in this case, by using HTML Logic. This technique uses a similar idea to the one I outlined in the Dynamic-ish Forum Feeds blog in May.
 
Creating conditional blocks
The way we would implement this functionality is by creating a custom block that is simply a wrapper for other blocks. This wrapper block will contain HTML Logic that determines which feed block to show, based on some information about the current page.
The first step would be to create standard feed blocks for each of the forums to which this should apply. In our example we're creating 'popular topics' blocks, but it could be anything you wish - the principle will remain the same. Another idea would be to create a 'Topics from other forums' block for each of your forums, whereby in the block configuration, you set it to include topics from all forums except the one in which it will be displayed - a good way of cross-promoting your topics.
In order to include the blocks later, set the template key of each to be forum_x, where x is the ID of the forum in which you will display the block.
 
Once we've created a block for each forum, the next step is to create our wrapper block, which should be a custom block set to use Manual HTML, with the following code:
{{if request.app == 'forums' && request.module == 'forums'}} {{$id = \IPS\Request::i()->id;}} {block="forum_{$id}"} {{endif}} What's happening here is we're checking the app and module from the page URL are both 'forums', which indicates we're in forum view. We then use the {block} tag to insert the appropriate block based on the ID parameter from the URL.
To use this block, simply save it, then using the Block Manager on the front-end, drag it into the desired location in your forum view.
I hope this quick suggestion gives you some ideas for other ways to create blocks that show contextually depending on what the user is viewing. If you have ideas for interesting ways to use this technique, share them in the comments!

An enterprise customer recently asked us how to have a different feed block for each of their forums. Their goal was to have each forum show a 'popular topics' block containing topics only from that particular forum. Unfortunately this isn't possible using the standard block manager right now, since each view is treated as one configuration. That means that any blocks added to forum view will show for all forums.
However, as usual in IPS4, some of the more advanced power under the hood does allow you to achieve the same goal - in this case, by using HTML Logic. This technique uses a similar idea to the one I outlined in the Dynamic-ish Forum Feeds blog in May.
 
Creating conditional blocks
The way we would implement this functionality is by creating a custom block that is simply a wrapper for other blocks. This wrapper block will contain HTML Logic that determines which feed block to show, based on some information about the current page.
The first step would be to create standard feed blocks for each of the forums to which this should apply. In our example we're creating 'popular topics' blocks, but it could be anything you wish - the principle will remain the same. Another idea would be to create a 'Topics from other forums' block for each of your forums, whereby in the block configuration, you set it to include topics from all forums except the one in which it will be displayed - a good way of cross-promoting your topics.
In order to include the blocks later, set the template key of each to be forum_x, where x is the ID of the forum in which you will display the block.
 
Once we've created a block for each forum, the next step is to create our wrapper block, which should be a custom block set to use Manual HTML, with the following code:
{{if request.app == 'forums' && request.module == 'forums'}} {{$id = \IPS\Request::i()->id;}} {block="forum_{$id}"} {{endif}} What's happening here is we're checking the app and module from the page URL are both 'forums', which indicates we're in forum view. We then use the {block} tag to insert the appropriate block based on the ID parameter from the URL.
To use this block, simply save it, then using the Block Manager on the front-end, drag it into the desired location in your forum view.
I hope this quick suggestion gives you some ideas for other ways to create blocks that show contextually depending on what the user is viewing. If you have ideas for interesting ways to use this technique, share them in the comments!

An enterprise customer recently asked us how to have a different feed block for each of their forums. Their goal was to have each forum show a 'popular topics' block containing topics only from that particular forum. Unfortunately this isn't possible using the standard block manager right now, since each view is treated as one configuration. That means that any blocks added to forum view will show for all forums.
However, as usual in IPS4, some of the more advanced power under the hood does allow you to achieve the same goal - in this case, by using HTML Logic. This technique uses a similar idea to the one I outlined in the Dynamic-ish Forum Feeds blog in May.
 
Creating conditional blocks
The way we would implement this functionality is by creating a custom block that is simply a wrapper for other blocks. This wrapper block will contain HTML Logic that determines which feed block to show, based on some information about the current page.
The first step would be to create standard feed blocks for each of the forums to which this should apply. In our example we're creating 'popular topics' blocks, but it could be anything you wish - the principle will remain the same. Another idea would be to create a 'Topics from other forums' block for each of your forums, whereby in the block configuration, you set it to include topics from all forums except the one in which it will be displayed - a good way of cross-promoting your topics.
In order to include the blocks later, set the template key of each to be forum_x, where x is the ID of the forum in which you will display the block.
 
Once we've created a block for each forum, the next step is to create our wrapper block, which should be a custom block set to use Manual HTML, with the following code:
{{if request.app == 'forums' && request.module == 'forums'}} {{$id = \IPS\Request::i()->id;}} {block="forum_{$id}"} {{endif}} What's happening here is we're checking the app and module from the page URL are both 'forums', which indicates we're in forum view. We then use the {block} tag to insert the appropriate block based on the ID parameter from the URL.
To use this block, simply save it, then using the Block Manager on the front-end, drag it into the desired location in your forum view.
I hope this quick suggestion gives you some ideas for other ways to create blocks that show contextually depending on what the user is viewing. If you have ideas for interesting ways to use this technique, share them in the comments!

An enterprise customer recently asked us how to have a different feed block for each of their forums. Their goal was to have each forum show a 'popular topics' block containing topics only from that particular forum. Unfortunately this isn't possible using the standard block manager right now, since each view is treated as one configuration. That means that any blocks added to forum view will show for all forums.
However, as usual in IPS4, some of the more advanced power under the hood does allow you to achieve the same goal - in this case, by using HTML Logic. This technique uses a similar idea to the one I outlined in the Dynamic-ish Forum Feeds blog in May.
 
Creating conditional blocks
The way we would implement this functionality is by creating a custom block that is simply a wrapper for other blocks. This wrapper block will contain HTML Logic that determines which feed block to show, based on some information about the current page.
The first step would be to create standard feed blocks for each of the forums to which this should apply. In our example we're creating 'popular topics' blocks, but it could be anything you wish - the principle will remain the same. Another idea would be to create a 'Topics from other forums' block for each of your forums, whereby in the block configuration, you set it to include topics from all forums except the one in which it will be displayed - a good way of cross-promoting your topics.
In order to include the blocks later, set the template key of each to be forum_x, where x is the ID of the forum in which you will display the block.
 
Once we've created a block for each forum, the next step is to create our wrapper block, which should be a custom block set to use Manual HTML, with the following code:
{{if request.app == 'forums' && request.module == 'forums'}} {{$id = \IPS\Request::i()->id;}} {block="forum_{$id}"} {{endif}} What's happening here is we're checking the app and module from the page URL are both 'forums', which indicates we're in forum view. We then use the {block} tag to insert the appropriate block based on the ID parameter from the URL.
To use this block, simply save it, then using the Block Manager on the front-end, drag it into the desired location in your forum view.
I hope this quick suggestion gives you some ideas for other ways to create blocks that show contextually depending on what the user is viewing. If you have ideas for interesting ways to use this technique, share them in the comments!

An enterprise customer recently asked us how to have a different feed block for each of their forums. Their goal was to have each forum show a 'popular topics' block containing topics only from that particular forum. Unfortunately this isn't possible using the standard block manager right now, since each view is treated as one configuration. That means that any blocks added to forum view will show for all forums.
However, as usual in IPS4, some of the more advanced power under the hood does allow you to achieve the same goal - in this case, by using HTML Logic. This technique uses a similar idea to the one I outlined in the Dynamic-ish Forum Feeds blog in May.
 
Creating conditional blocks
The way we would implement this functionality is by creating a custom block that is simply a wrapper for other blocks. This wrapper block will contain HTML Logic that determines which feed block to show, based on some information about the current page.
The first step would be to create standard feed blocks for each of the forums to which this should apply. In our example we're creating 'popular topics' blocks, but it could be anything you wish - the principle will remain the same. Another idea would be to create a 'Topics from other forums' block for each of your forums, whereby in the block configuration, you set it to include topics from all forums except the one in which it will be displayed - a good way of cross-promoting your topics.
In order to include the blocks later, set the template key of each to be forum_x, where x is the ID of the forum in which you will display the block.
 
Once we've created a block for each forum, the next step is to create our wrapper block, which should be a custom block set to use Manual HTML, with the following code:
{{if request.app == 'forums' && request.module == 'forums'}} {{$id = \IPS\Request::i()->id;}} {block="forum_{$id}"} {{endif}} What's happening here is we're checking the app and module from the page URL are both 'forums', which indicates we're in forum view. We then use the {block} tag to insert the appropriate block based on the ID parameter from the URL.
To use this block, simply save it, then using the Block Manager on the front-end, drag it into the desired location in your forum view.
I hope this quick suggestion gives you some ideas for other ways to create blocks that show contextually depending on what the user is viewing. If you have ideas for interesting ways to use this technique, share them in the comments!

In line with our aim to make incremental improvements in each release, I wanted to go over a few of the small but useful changes to the personal messenger that you'll find in our next release, 4.1.13.
 
Read/unread filtering
The first improvement is that you can now filter the message list by read and unread, making it a little easier to browse through just the messages you're interested in.
 
Search improvements
Next up, the messenger search has been improved in a couple of ways; first, you can now also search the names of both the recipients and the senders, and second, we've added a menu so you can specify which fields in particular you want to search by.
 
Easier moving
Finally, we've added a popular request - the ability to use the mass-move tool inside the messenger. You can now check multiple messages, and the usual mass-action toolbar will appear that will allow you either move them to another folder, or, has been the case in the past, delete them.
 
While these are each small improvements by themselves, we hope the incremental changes in each release add up to a more pleasant experience for users. 

In IPS4, it's easy to add custom icons to your forums, simply by uploading them on the Edit Forum screen in the AdminCP. But if you want to replace all of your forum icons, uploading the same icon for each forum can be a bit tedious.
It's easy to use some custom CSS to replace all of the icons - lets see how.
First, you'll want to upload the image(s) you want to use to the Resources section of your theme so that it can be used in your CSS. To start with, we'll use the same image for both read and unread status, but we'll cover using a different icon for both too.
 
The basics
Here's the basic CSS to replace the icon for all forums with your custom image:
body[data-pageapp="forums"] .cForumRow .ipsItemStatus.ipsItemStatus_large { width: 50px; height: 50px; border-radius: 0; background-color: transparent; background-image: url('{resource="mushroom.png" app="core" location="front"}'); background-size: 50px 50px; } body[data-pageapp="forums"] .cForumRow .ipsItemStatus.ipsItemStatus_large > i { display: none; } What we're doing here is specifically targeting the item status icons in the forums app, using the body[data-pageapp="forums"] selector. Within this style, we're setting the size of the icon - I've chosen 50px here which is about right in most cases, although you can change this if desired. Next we reset the border radius and background color so the icon looks right. And finally, we set the background image to our icon by using the {resource} tag and the background size to the same dimensions we just set the element to.
The next style hides the FontAwesome icon that IPS4 inserts by default, so that our icon can be seen.
 
Using a different 'read' icon
By default, your icon will be faded out for 'read' icons, but it's easy to use a completely different icon if you wish. Simply add:
body[data-pageapp="forums"] .cForumRow .ipsItemStatus.ipsItemStatus_large.ipsItemStatus_read { background-image: url('{resource="mushroom_faded.png" app="core" location="front"}'); } All we're doing here is using a more specific selector with .ipsItemStatus_read so that only the 'read' state is targeted. In the style, we specify the background image - we don't need to set and reset the other rules again because the styles we wrote in the first step are inherited.
 
Using different icons for redirect or Q&A forums
If you want to add icons specifically for redirect or Q&A forums, you can do that by targeting unique classes that are added to the icons for those kinds of forums. Those classes are .cForumIcon_redirect and .cForumIcon_answers, respectively. So, to use a custom icon for a Q&A forum, you would add another style like so:
body[data-pageapp="forums"] .cForumRow .cForumIcon_answers.ipsItemStatus.ipsItemStatus_large { background-image: url('{resource="question.png" app="core" location="front"}'); } Notice we've added .cForumIcon_answers to our selector.

In line with our aim to make incremental improvements in each release, I wanted to go over a few of the small but useful changes to the personal messenger that you'll find in our next release, 4.1.13.
 
Read/unread filtering
The first improvement is that you can now filter the message list by read and unread, making it a little easier to browse through just the messages you're interested in.
 
Search improvements
Next up, the messenger search has been improved in a couple of ways; first, you can now also search the names of both the recipients and the senders, and second, we've added a menu so you can specify which fields in particular you want to search by.
 
Easier moving
Finally, we've added a popular request - the ability to use the mass-move tool inside the messenger. You can now check multiple messages, and the usual mass-action toolbar will appear that will allow you either move them to another folder, or, has been the case in the past, delete them.
 
While these are each small improvements by themselves, we hope the incremental changes in each release add up to a more pleasant experience for users. 

Blocks are an extremely popular feature in IPS4, used by a huge number of customers to great effect. They range from feeds of topics, to statistics, to custom blocks that can contain anything you wish. They're a great way to add dynamic content to your community theme.
What many people don't know is that blocks you create with Pages can be used anywhere in your theme, not just in the designated block containers (in the header, footer & sidebar).
 
The {block} tag
It's really easy to do so. Here's the tag you'd use:
{block="block_key"} That's it! The block_key is the one you specify when you're creating the block in Pages (if you don't specify one manually, Pages will auto-generate one for you).
 
Where can you use them?
Block tags can be used anywhere that template logic is supported. That includes:
Theme templates Pages page content Other kinds of templates (e.g. database templates) Even within other blocks!  
What can you do with them?
The obvious benefit of blocks is that they are reusable, so in any situation where you need the same content duplicated, it makes sense to put the content in a custom block instead, and simply insert it wherever needed. Then if you need to update the content later, you have one place to do so. Custom menus are a great example of reusing blocks; since blocks have full use of template logic, you can build your menu HTML in a block, use HTML Logic to highlight the correct item, and insert the menu block on each of your pages. We use this approach on our feature tour section menu. Here's a snippet of the menu block HTML for that page:
<nav id='elTourNav'> <div class='container'> <ul class='ipsList_inline'> <li><a href='/features/apps' {{if \IPS\Request::i()->path == 'features/apps'}}class='sSelected'{{endif}}>Our Apps</a></li> <li><a href='/features/engagement' {{if \IPS\Request::i()->path == 'features/engagement'}}class='sSelected'{{endif}}>Engagement</a></li> <!-- ... --> </ul> </div> </nav>  
Blocks are useful beyond that, though. A couple of weeks ago, we showed you how to use HTML Logic to only show content to certain groups. Using blocks is actually an easier way to do this - simply add the content to a custom block, then check the groups who should see it. We use this technique to show a 'welcome to our community' message to guests on our own community. We created our welcome message as a custom Pages block, set it so that only guests have permission to view it, and then added it to our template header. Simple, effective and easy to manage.
That's just two ways you can use blocks - there's many other creative users too! If you've used blocks in an interesting way, share your example in the comments!

In line with our aim to make incremental improvements in each release, I wanted to go over a few of the small but useful changes to the personal messenger that you'll find in our next release, 4.1.13.
 
Read/unread filtering
The first improvement is that you can now filter the message list by read and unread, making it a little easier to browse through just the messages you're interested in.
 
Search improvements
Next up, the messenger search has been improved in a couple of ways; first, you can now also search the names of both the recipients and the senders, and second, we've added a menu so you can specify which fields in particular you want to search by.
 
Easier moving
Finally, we've added a popular request - the ability to use the mass-move tool inside the messenger. You can now check multiple messages, and the usual mass-action toolbar will appear that will allow you either move them to another folder, or, has been the case in the past, delete them.
 
While these are each small improvements by themselves, we hope the incremental changes in each release add up to a more pleasant experience for users. 

In line with our aim to make incremental improvements in each release, I wanted to go over a few of the small but useful changes to the personal messenger that you'll find in our next release, 4.1.13.
 
Read/unread filtering
The first improvement is that you can now filter the message list by read and unread, making it a little easier to browse through just the messages you're interested in.
 
Search improvements
Next up, the messenger search has been improved in a couple of ways; first, you can now also search the names of both the recipients and the senders, and second, we've added a menu so you can specify which fields in particular you want to search by.
 
Easier moving
Finally, we've added a popular request - the ability to use the mass-move tool inside the messenger. You can now check multiple messages, and the usual mass-action toolbar will appear that will allow you either move them to another folder, or, has been the case in the past, delete them.
 
While these are each small improvements by themselves, we hope the incremental changes in each release add up to a more pleasant experience for users. 

In line with our aim to make incremental improvements in each release, I wanted to go over a few of the small but useful changes to the personal messenger that you'll find in our next release, 4.1.13.
 
Read/unread filtering
The first improvement is that you can now filter the message list by read and unread, making it a little easier to browse through just the messages you're interested in.
 
Search improvements
Next up, the messenger search has been improved in a couple of ways; first, you can now also search the names of both the recipients and the senders, and second, we've added a menu so you can specify which fields in particular you want to search by.
 
Easier moving
Finally, we've added a popular request - the ability to use the mass-move tool inside the messenger. You can now check multiple messages, and the usual mass-action toolbar will appear that will allow you either move them to another folder, or, has been the case in the past, delete them.
 
While these are each small improvements by themselves, we hope the incremental changes in each release add up to a more pleasant experience for users. 

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!

In line with our aim to make incremental improvements in each release, I wanted to go over a few of the small but useful changes to the personal messenger that you'll find in our next release, 4.1.13.
 
Read/unread filtering
The first improvement is that you can now filter the message list by read and unread, making it a little easier to browse through just the messages you're interested in.
 
Search improvements
Next up, the messenger search has been improved in a couple of ways; first, you can now also search the names of both the recipients and the senders, and second, we've added a menu so you can specify which fields in particular you want to search by.
 
Easier moving
Finally, we've added a popular request - the ability to use the mass-move tool inside the messenger. You can now check multiple messages, and the usual mass-action toolbar will appear that will allow you either move them to another folder, or, has been the case in the past, delete them.
 
While these are each small improvements by themselves, we hope the incremental changes in each release add up to a more pleasant experience for users. 

In line with our aim to make incremental improvements in each release, I wanted to go over a few of the small but useful changes to the personal messenger that you'll find in our next release, 4.1.13.
 
Read/unread filtering
The first improvement is that you can now filter the message list by read and unread, making it a little easier to browse through just the messages you're interested in.
 
Search improvements
Next up, the messenger search has been improved in a couple of ways; first, you can now also search the names of both the recipients and the senders, and second, we've added a menu so you can specify which fields in particular you want to search by.
 
Easier moving
Finally, we've added a popular request - the ability to use the mass-move tool inside the messenger. You can now check multiple messages, and the usual mass-action toolbar will appear that will allow you either move them to another folder, or, has been the case in the past, delete them.
 
While these are each small improvements by themselves, we hope the incremental changes in each release add up to a more pleasant experience for users. 

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!

In line with our aim to make incremental improvements in each release, I wanted to go over a few of the small but useful changes to the personal messenger that you'll find in our next release, 4.1.13.
 
Read/unread filtering
The first improvement is that you can now filter the message list by read and unread, making it a little easier to browse through just the messages you're interested in.
 
Search improvements
Next up, the messenger search has been improved in a couple of ways; first, you can now also search the names of both the recipients and the senders, and second, we've added a menu so you can specify which fields in particular you want to search by.
 
Easier moving
Finally, we've added a popular request - the ability to use the mass-move tool inside the messenger. You can now check multiple messages, and the usual mass-action toolbar will appear that will allow you either move them to another folder, or, has been the case in the past, delete them.
 
While these are each small improvements by themselves, we hope the incremental changes in each release add up to a more pleasant experience for users. 

In line with our aim to make incremental improvements in each release, I wanted to go over a few of the small but useful changes to the personal messenger that you'll find in our next release, 4.1.13.
 
Read/unread filtering
The first improvement is that you can now filter the message list by read and unread, making it a little easier to browse through just the messages you're interested in.
 
Search improvements
Next up, the messenger search has been improved in a couple of ways; first, you can now also search the names of both the recipients and the senders, and second, we've added a menu so you can specify which fields in particular you want to search by.
 
Easier moving
Finally, we've added a popular request - the ability to use the mass-move tool inside the messenger. You can now check multiple messages, and the usual mass-action toolbar will appear that will allow you either move them to another folder, or, has been the case in the past, delete them.
 
While these are each small improvements by themselves, we hope the incremental changes in each release add up to a more pleasant experience for users. 

In line with our aim to make incremental improvements in each release, I wanted to go over a few of the small but useful changes to the personal messenger that you'll find in our next release, 4.1.13.
 
Read/unread filtering
The first improvement is that you can now filter the message list by read and unread, making it a little easier to browse through just the messages you're interested in.
 
Search improvements
Next up, the messenger search has been improved in a couple of ways; first, you can now also search the names of both the recipients and the senders, and second, we've added a menu so you can specify which fields in particular you want to search by.
 
Easier moving
Finally, we've added a popular request - the ability to use the mass-move tool inside the messenger. You can now check multiple messages, and the usual mass-action toolbar will appear that will allow you either move them to another folder, or, has been the case in the past, delete them.
 
While these are each small improvements by themselves, we hope the incremental changes in each release add up to a more pleasant experience for users. 

In line with our aim to make incremental improvements in each release, I wanted to go over a few of the small but useful changes to the personal messenger that you'll find in our next release, 4.1.13.
 
Read/unread filtering
The first improvement is that you can now filter the message list by read and unread, making it a little easier to browse through just the messages you're interested in.
 
Search improvements
Next up, the messenger search has been improved in a couple of ways; first, you can now also search the names of both the recipients and the senders, and second, we've added a menu so you can specify which fields in particular you want to search by.
 
Easier moving
Finally, we've added a popular request - the ability to use the mass-move tool inside the messenger. You can now check multiple messages, and the usual mass-action toolbar will appear that will allow you either move them to another folder, or, has been the case in the past, delete them.
 
While these are each small improvements by themselves, we hope the incremental changes in each release add up to a more pleasant experience for users. 

In line with our aim to make incremental improvements in each release, I wanted to go over a few of the small but useful changes to the personal messenger that you'll find in our next release, 4.1.13.
 
Read/unread filtering
The first improvement is that you can now filter the message list by read and unread, making it a little easier to browse through just the messages you're interested in.
 
Search improvements
Next up, the messenger search has been improved in a couple of ways; first, you can now also search the names of both the recipients and the senders, and second, we've added a menu so you can specify which fields in particular you want to search by.
 
Easier moving
Finally, we've added a popular request - the ability to use the mass-move tool inside the messenger. You can now check multiple messages, and the usual mass-action toolbar will appear that will allow you either move them to another folder, or, has been the case in the past, delete them.
 
While these are each small improvements by themselves, we hope the incremental changes in each release add up to a more pleasant experience for users. 

In line with our aim to make incremental improvements in each release, I wanted to go over a few of the small but useful changes to the personal messenger that you'll find in our next release, 4.1.13.
 
Read/unread filtering
The first improvement is that you can now filter the message list by read and unread, making it a little easier to browse through just the messages you're interested in.
 
Search improvements
Next up, the messenger search has been improved in a couple of ways; first, you can now also search the names of both the recipients and the senders, and second, we've added a menu so you can specify which fields in particular you want to search by.
 
Easier moving
Finally, we've added a popular request - the ability to use the mass-move tool inside the messenger. You can now check multiple messages, and the usual mass-action toolbar will appear that will allow you either move them to another folder, or, has been the case in the past, delete them.
 
While these are each small improvements by themselves, we hope the incremental changes in each release add up to a more pleasant experience for users. 

In line with our aim to make incremental improvements in each release, I wanted to go over a few of the small but useful changes to the personal messenger that you'll find in our next release, 4.1.13.
 
Read/unread filtering
The first improvement is that you can now filter the message list by read and unread, making it a little easier to browse through just the messages you're interested in.
 
Search improvements
Next up, the messenger search has been improved in a couple of ways; first, you can now also search the names of both the recipients and the senders, and second, we've added a menu so you can specify which fields in particular you want to search by.
 
Easier moving
Finally, we've added a popular request - the ability to use the mass-move tool inside the messenger. You can now check multiple messages, and the usual mass-action toolbar will appear that will allow you either move them to another folder, or, has been the case in the past, delete them.
 
While these are each small improvements by themselves, we hope the incremental changes in each release add up to a more pleasant experience for users. 

In line with our aim to make incremental improvements in each release, I wanted to go over a few of the small but useful changes to the personal messenger that you'll find in our next release, 4.1.13.
 
Read/unread filtering
The first improvement is that you can now filter the message list by read and unread, making it a little easier to browse through just the messages you're interested in.
 
Search improvements
Next up, the messenger search has been improved in a couple of ways; first, you can now also search the names of both the recipients and the senders, and second, we've added a menu so you can specify which fields in particular you want to search by.
 
Easier moving
Finally, we've added a popular request - the ability to use the mass-move tool inside the messenger. You can now check multiple messages, and the usual mass-action toolbar will appear that will allow you either move them to another folder, or, has been the case in the past, delete them.
 
While these are each small improvements by themselves, we hope the incremental changes in each release add up to a more pleasant experience for users. 

In line with our aim to make incremental improvements in each release, I wanted to go over a few of the small but useful changes to the personal messenger that you'll find in our next release, 4.1.13.
 
Read/unread filtering
The first improvement is that you can now filter the message list by read and unread, making it a little easier to browse through just the messages you're interested in.
 
Search improvements
Next up, the messenger search has been improved in a couple of ways; first, you can now also search the names of both the recipients and the senders, and second, we've added a menu so you can specify which fields in particular you want to search by.
 
Easier moving
Finally, we've added a popular request - the ability to use the mass-move tool inside the messenger. You can now check multiple messages, and the usual mass-action toolbar will appear that will allow you either move them to another folder, or, has been the case in the past, delete them.
 
While these are each small improvements by themselves, we hope the incremental changes in each release add up to a more pleasant experience for users. 

In IPS4, it's easy to add custom icons to your forums, simply by uploading them on the Edit Forum screen in the AdminCP. But if you want to replace all of your forum icons, uploading the same icon for each forum can be a bit tedious.
It's easy to use some custom CSS to replace all of the icons - lets see how.
First, you'll want to upload the image(s) you want to use to the Resources section of your theme so that it can be used in your CSS. To start with, we'll use the same image for both read and unread status, but we'll cover using a different icon for both too.
 
The basics
Here's the basic CSS to replace the icon for all forums with your custom image:
body[data-pageapp="forums"] .cForumRow .ipsItemStatus.ipsItemStatus_large { width: 50px; height: 50px; border-radius: 0; background-color: transparent; background-image: url('{resource="mushroom.png" app="core" location="front"}'); background-size: 50px 50px; } body[data-pageapp="forums"] .cForumRow .ipsItemStatus.ipsItemStatus_large > i { display: none; } What we're doing here is specifically targeting the item status icons in the forums app, using the body[data-pageapp="forums"] selector. Within this style, we're setting the size of the icon - I've chosen 50px here which is about right in most cases, although you can change this if desired. Next we reset the border radius and background color so the icon looks right. And finally, we set the background image to our icon by using the {resource} tag and the background size to the same dimensions we just set the element to.
The next style hides the FontAwesome icon that IPS4 inserts by default, so that our icon can be seen.
 
Using a different 'read' icon
By default, your icon will be faded out for 'read' icons, but it's easy to use a completely different icon if you wish. Simply add:
body[data-pageapp="forums"] .cForumRow .ipsItemStatus.ipsItemStatus_large.ipsItemStatus_read { background-image: url('{resource="mushroom_faded.png" app="core" location="front"}'); } All we're doing here is using a more specific selector with .ipsItemStatus_read so that only the 'read' state is targeted. In the style, we specify the background image - we don't need to set and reset the other rules again because the styles we wrote in the first step are inherited.
 
Using different icons for redirect or Q&A forums
If you want to add icons specifically for redirect or Q&A forums, you can do that by targeting unique classes that are added to the icons for those kinds of forums. Those classes are .cForumIcon_redirect and .cForumIcon_answers, respectively. So, to use a custom icon for a Q&A forum, you would add another style like so:
body[data-pageapp="forums"] .cForumRow .cForumIcon_answers.ipsItemStatus.ipsItemStatus_large { background-image: url('{resource="question.png" app="core" location="front"}'); } Notice we've added .cForumIcon_answers to our selector.

In line with our aim to make incremental improvements in each release, I wanted to go over a few of the small but useful changes to the personal messenger that you'll find in our next release, 4.1.13.
 
Read/unread filtering
The first improvement is that you can now filter the message list by read and unread, making it a little easier to browse through just the messages you're interested in.
 
Search improvements
Next up, the messenger search has been improved in a couple of ways; first, you can now also search the names of both the recipients and the senders, and second, we've added a menu so you can specify which fields in particular you want to search by.
 
Easier moving
Finally, we've added a popular request - the ability to use the mass-move tool inside the messenger. You can now check multiple messages, and the usual mass-action toolbar will appear that will allow you either move them to another folder, or, has been the case in the past, delete them.
 
While these are each small improvements by themselves, we hope the incremental changes in each release add up to a more pleasant experience for users. 

In line with our aim to make incremental improvements in each release, I wanted to go over a few of the small but useful changes to the personal messenger that you'll find in our next release, 4.1.13.
 
Read/unread filtering
The first improvement is that you can now filter the message list by read and unread, making it a little easier to browse through just the messages you're interested in.
 
Search improvements
Next up, the messenger search has been improved in a couple of ways; first, you can now also search the names of both the recipients and the senders, and second, we've added a menu so you can specify which fields in particular you want to search by.
 
Easier moving
Finally, we've added a popular request - the ability to use the mass-move tool inside the messenger. You can now check multiple messages, and the usual mass-action toolbar will appear that will allow you either move them to another folder, or, has been the case in the past, delete them.
 
While these are each small improvements by themselves, we hope the incremental changes in each release add up to a more pleasant experience for users. 

In line with our aim to make incremental improvements in each release, I wanted to go over a few of the small but useful changes to the personal messenger that you'll find in our next release, 4.1.13.
 
Read/unread filtering
The first improvement is that you can now filter the message list by read and unread, making it a little easier to browse through just the messages you're interested in.
 
Search improvements
Next up, the messenger search has been improved in a couple of ways; first, you can now also search the names of both the recipients and the senders, and second, we've added a menu so you can specify which fields in particular you want to search by.
 
Easier moving
Finally, we've added a popular request - the ability to use the mass-move tool inside the messenger. You can now check multiple messages, and the usual mass-action toolbar will appear that will allow you either move them to another folder, or, has been the case in the past, delete them.
 
While these are each small improvements by themselves, we hope the incremental changes in each release add up to a more pleasant experience for users. 

In line with our aim to make incremental improvements in each release, I wanted to go over a few of the small but useful changes to the personal messenger that you'll find in our next release, 4.1.13.
 
Read/unread filtering
The first improvement is that you can now filter the message list by read and unread, making it a little easier to browse through just the messages you're interested in.
 
Search improvements
Next up, the messenger search has been improved in a couple of ways; first, you can now also search the names of both the recipients and the senders, and second, we've added a menu so you can specify which fields in particular you want to search by.
 
Easier moving
Finally, we've added a popular request - the ability to use the mass-move tool inside the messenger. You can now check multiple messages, and the usual mass-action toolbar will appear that will allow you either move them to another folder, or, has been the case in the past, delete them.
 
While these are each small improvements by themselves, we hope the incremental changes in each release add up to a more pleasant experience for users. 

In line with our aim to make incremental improvements in each release, I wanted to go over a few of the small but useful changes to the personal messenger that you'll find in our next release, 4.1.13.
 
Read/unread filtering
The first improvement is that you can now filter the message list by read and unread, making it a little easier to browse through just the messages you're interested in.
 
Search improvements
Next up, the messenger search has been improved in a couple of ways; first, you can now also search the names of both the recipients and the senders, and second, we've added a menu so you can specify which fields in particular you want to search by.
 
Easier moving
Finally, we've added a popular request - the ability to use the mass-move tool inside the messenger. You can now check multiple messages, and the usual mass-action toolbar will appear that will allow you either move them to another folder, or, has been the case in the past, delete them.
 
While these are each small improvements by themselves, we hope the incremental changes in each release add up to a more pleasant experience for users. 

In line with our aim to make incremental improvements in each release, I wanted to go over a few of the small but useful changes to the personal messenger that you'll find in our next release, 4.1.13.
 
Read/unread filtering
The first improvement is that you can now filter the message list by read and unread, making it a little easier to browse through just the messages you're interested in.
 
Search improvements
Next up, the messenger search has been improved in a couple of ways; first, you can now also search the names of both the recipients and the senders, and second, we've added a menu so you can specify which fields in particular you want to search by.
 
Easier moving
Finally, we've added a popular request - the ability to use the mass-move tool inside the messenger. You can now check multiple messages, and the usual mass-action toolbar will appear that will allow you either move them to another folder, or, has been the case in the past, delete them.
 
While these are each small improvements by themselves, we hope the incremental changes in each release add up to a more pleasant experience for users. 

In line with our aim to make incremental improvements in each release, I wanted to go over a few of the small but useful changes to the personal messenger that you'll find in our next release, 4.1.13.
 
Read/unread filtering
The first improvement is that you can now filter the message list by read and unread, making it a little easier to browse through just the messages you're interested in.
 
Search improvements
Next up, the messenger search has been improved in a couple of ways; first, you can now also search the names of both the recipients and the senders, and second, we've added a menu so you can specify which fields in particular you want to search by.
 
Easier moving
Finally, we've added a popular request - the ability to use the mass-move tool inside the messenger. You can now check multiple messages, and the usual mass-action toolbar will appear that will allow you either move them to another folder, or, has been the case in the past, delete them.
 
While these are each small improvements by themselves, we hope the incremental changes in each release add up to a more pleasant experience for users. 

In line with our aim to make incremental improvements in each release, I wanted to go over a few of the small but useful changes to the personal messenger that you'll find in our next release, 4.1.13.
 
Read/unread filtering
The first improvement is that you can now filter the message list by read and unread, making it a little easier to browse through just the messages you're interested in.
 
Search improvements
Next up, the messenger search has been improved in a couple of ways; first, you can now also search the names of both the recipients and the senders, and second, we've added a menu so you can specify which fields in particular you want to search by.
 
Easier moving
Finally, we've added a popular request - the ability to use the mass-move tool inside the messenger. You can now check multiple messages, and the usual mass-action toolbar will appear that will allow you either move them to another folder, or, has been the case in the past, delete them.
 
While these are each small improvements by themselves, we hope the incremental changes in each release add up to a more pleasant experience for users. 

In line with our aim to make incremental improvements in each release, I wanted to go over a few of the small but useful changes to the personal messenger that you'll find in our next release, 4.1.13.
 
Read/unread filtering
The first improvement is that you can now filter the message list by read and unread, making it a little easier to browse through just the messages you're interested in.
 
Search improvements
Next up, the messenger search has been improved in a couple of ways; first, you can now also search the names of both the recipients and the senders, and second, we've added a menu so you can specify which fields in particular you want to search by.
 
Easier moving
Finally, we've added a popular request - the ability to use the mass-move tool inside the messenger. You can now check multiple messages, and the usual mass-action toolbar will appear that will allow you either move them to another folder, or, has been the case in the past, delete them.
 
While these are each small improvements by themselves, we hope the incremental changes in each release add up to a more pleasant experience for users. 

In line with our aim to make incremental improvements in each release, I wanted to go over a few of the small but useful changes to the personal messenger that you'll find in our next release, 4.1.13.
 
Read/unread filtering
The first improvement is that you can now filter the message list by read and unread, making it a little easier to browse through just the messages you're interested in.
 
Search improvements
Next up, the messenger search has been improved in a couple of ways; first, you can now also search the names of both the recipients and the senders, and second, we've added a menu so you can specify which fields in particular you want to search by.
 
Easier moving
Finally, we've added a popular request - the ability to use the mass-move tool inside the messenger. You can now check multiple messages, and the usual mass-action toolbar will appear that will allow you either move them to another folder, or, has been the case in the past, delete them.
 
While these are each small improvements by themselves, we hope the incremental changes in each release add up to a more pleasant experience for users. 

In line with our aim to make incremental improvements in each release, I wanted to go over a few of the small but useful changes to the personal messenger that you'll find in our next release, 4.1.13.
 
Read/unread filtering
The first improvement is that you can now filter the message list by read and unread, making it a little easier to browse through just the messages you're interested in.
 
Search improvements
Next up, the messenger search has been improved in a couple of ways; first, you can now also search the names of both the recipients and the senders, and second, we've added a menu so you can specify which fields in particular you want to search by.
 
Easier moving
Finally, we've added a popular request - the ability to use the mass-move tool inside the messenger. You can now check multiple messages, and the usual mass-action toolbar will appear that will allow you either move them to another folder, or, has been the case in the past, delete them.
 
While these are each small improvements by themselves, we hope the incremental changes in each release add up to a more pleasant experience for users. 

In line with our aim to make incremental improvements in each release, I wanted to go over a few of the small but useful changes to the personal messenger that you'll find in our next release, 4.1.13.
 
Read/unread filtering
The first improvement is that you can now filter the message list by read and unread, making it a little easier to browse through just the messages you're interested in.
 
Search improvements
Next up, the messenger search has been improved in a couple of ways; first, you can now also search the names of both the recipients and the senders, and second, we've added a menu so you can specify which fields in particular you want to search by.
 
Easier moving
Finally, we've added a popular request - the ability to use the mass-move tool inside the messenger. You can now check multiple messages, and the usual mass-action toolbar will appear that will allow you either move them to another folder, or, has been the case in the past, delete them.
 
While these are each small improvements by themselves, we hope the incremental changes in each release add up to a more pleasant experience for users. 

In line with our aim to make incremental improvements in each release, I wanted to go over a few of the small but useful changes to the personal messenger that you'll find in our next release, 4.1.13.
 
Read/unread filtering
The first improvement is that you can now filter the message list by read and unread, making it a little easier to browse through just the messages you're interested in.
 
Search improvements
Next up, the messenger search has been improved in a couple of ways; first, you can now also search the names of both the recipients and the senders, and second, we've added a menu so you can specify which fields in particular you want to search by.
 
Easier moving
Finally, we've added a popular request - the ability to use the mass-move tool inside the messenger. You can now check multiple messages, and the usual mass-action toolbar will appear that will allow you either move them to another folder, or, has been the case in the past, delete them.
 
While these are each small improvements by themselves, we hope the incremental changes in each release add up to a more pleasant experience for users. 

In line with our aim to make incremental improvements in each release, I wanted to go over a few of the small but useful changes to the personal messenger that you'll find in our next release, 4.1.13.
 
Read/unread filtering
The first improvement is that you can now filter the message list by read and unread, making it a little easier to browse through just the messages you're interested in.
 
Search improvements
Next up, the messenger search has been improved in a couple of ways; first, you can now also search the names of both the recipients and the senders, and second, we've added a menu so you can specify which fields in particular you want to search by.
 
Easier moving
Finally, we've added a popular request - the ability to use the mass-move tool inside the messenger. You can now check multiple messages, and the usual mass-action toolbar will appear that will allow you either move them to another folder, or, has been the case in the past, delete them.
 
While these are each small improvements by themselves, we hope the incremental changes in each release add up to a more pleasant experience for users. 

In line with our aim to make incremental improvements in each release, I wanted to go over a few of the small but useful changes to the personal messenger that you'll find in our next release, 4.1.13.
 
Read/unread filtering
The first improvement is that you can now filter the message list by read and unread, making it a little easier to browse through just the messages you're interested in.
 
Search improvements
Next up, the messenger search has been improved in a couple of ways; first, you can now also search the names of both the recipients and the senders, and second, we've added a menu so you can specify which fields in particular you want to search by.
 
Easier moving
Finally, we've added a popular request - the ability to use the mass-move tool inside the messenger. You can now check multiple messages, and the usual mass-action toolbar will appear that will allow you either move them to another folder, or, has been the case in the past, delete them.
 
While these are each small improvements by themselves, we hope the incremental changes in each release add up to a more pleasant experience for users. 

In IPS4, it's easy to add custom icons to your forums, simply by uploading them on the Edit Forum screen in the AdminCP. But if you want to replace all of your forum icons, uploading the same icon for each forum can be a bit tedious.
It's easy to use some custom CSS to replace all of the icons - lets see how.
First, you'll want to upload the image(s) you want to use to the Resources section of your theme so that it can be used in your CSS. To start with, we'll use the same image for both read and unread status, but we'll cover using a different icon for both too.
 
The basics
Here's the basic CSS to replace the icon for all forums with your custom image:
body[data-pageapp="forums"] .cForumRow .ipsItemStatus.ipsItemStatus_large { width: 50px; height: 50px; border-radius: 0; background-color: transparent; background-image: url('{resource="mushroom.png" app="core" location="front"}'); background-size: 50px 50px; } body[data-pageapp="forums"] .cForumRow .ipsItemStatus.ipsItemStatus_large > i { display: none; } What we're doing here is specifically targeting the item status icons in the forums app, using the body[data-pageapp="forums"] selector. Within this style, we're setting the size of the icon - I've chosen 50px here which is about right in most cases, although you can change this if desired. Next we reset the border radius and background color so the icon looks right. And finally, we set the background image to our icon by using the {resource} tag and the background size to the same dimensions we just set the element to.
The next style hides the FontAwesome icon that IPS4 inserts by default, so that our icon can be seen.
 
Using a different 'read' icon
By default, your icon will be faded out for 'read' icons, but it's easy to use a completely different icon if you wish. Simply add:
body[data-pageapp="forums"] .cForumRow .ipsItemStatus.ipsItemStatus_large.ipsItemStatus_read { background-image: url('{resource="mushroom_faded.png" app="core" location="front"}'); } All we're doing here is using a more specific selector with .ipsItemStatus_read so that only the 'read' state is targeted. In the style, we specify the background image - we don't need to set and reset the other rules again because the styles we wrote in the first step are inherited.
 
Using different icons for redirect or Q&A forums
If you want to add icons specifically for redirect or Q&A forums, you can do that by targeting unique classes that are added to the icons for those kinds of forums. Those classes are .cForumIcon_redirect and .cForumIcon_answers, respectively. So, to use a custom icon for a Q&A forum, you would add another style like so:
body[data-pageapp="forums"] .cForumRow .cForumIcon_answers.ipsItemStatus.ipsItemStatus_large { background-image: url('{resource="question.png" app="core" location="front"}'); } Notice we've added .cForumIcon_answers to our selector.

In IPS4, it's easy to add custom icons to your forums, simply by uploading them on the Edit Forum screen in the AdminCP. But if you want to replace all of your forum icons, uploading the same icon for each forum can be a bit tedious.
It's easy to use some custom CSS to replace all of the icons - lets see how.
First, you'll want to upload the image(s) you want to use to the Resources section of your theme so that it can be used in your CSS. To start with, we'll use the same image for both read and unread status, but we'll cover using a different icon for both too.
 
The basics
Here's the basic CSS to replace the icon for all forums with your custom image:
body[data-pageapp="forums"] .cForumRow .ipsItemStatus.ipsItemStatus_large { width: 50px; height: 50px; border-radius: 0; background-color: transparent; background-image: url('{resource="mushroom.png" app="core" location="front"}'); background-size: 50px 50px; } body[data-pageapp="forums"] .cForumRow .ipsItemStatus.ipsItemStatus_large > i { display: none; } What we're doing here is specifically targeting the item status icons in the forums app, using the body[data-pageapp="forums"] selector. Within this style, we're setting the size of the icon - I've chosen 50px here which is about right in most cases, although you can change this if desired. Next we reset the border radius and background color so the icon looks right. And finally, we set the background image to our icon by using the {resource} tag and the background size to the same dimensions we just set the element to.
The next style hides the FontAwesome icon that IPS4 inserts by default, so that our icon can be seen.
 
Using a different 'read' icon
By default, your icon will be faded out for 'read' icons, but it's easy to use a completely different icon if you wish. Simply add:
body[data-pageapp="forums"] .cForumRow .ipsItemStatus.ipsItemStatus_large.ipsItemStatus_read { background-image: url('{resource="mushroom_faded.png" app="core" location="front"}'); } All we're doing here is using a more specific selector with .ipsItemStatus_read so that only the 'read' state is targeted. In the style, we specify the background image - we don't need to set and reset the other rules again because the styles we wrote in the first step are inherited.
 
Using different icons for redirect or Q&A forums
If you want to add icons specifically for redirect or Q&A forums, you can do that by targeting unique classes that are added to the icons for those kinds of forums. Those classes are .cForumIcon_redirect and .cForumIcon_answers, respectively. So, to use a custom icon for a Q&A forum, you would add another style like so:
body[data-pageapp="forums"] .cForumRow .cForumIcon_answers.ipsItemStatus.ipsItemStatus_large { background-image: url('{resource="question.png" app="core" location="front"}'); } Notice we've added .cForumIcon_answers to our selector.

In IPS4, it's easy to add custom icons to your forums, simply by uploading them on the Edit Forum screen in the AdminCP. But if you want to replace all of your forum icons, uploading the same icon for each forum can be a bit tedious.
It's easy to use some custom CSS to replace all of the icons - lets see how.
First, you'll want to upload the image(s) you want to use to the Resources section of your theme so that it can be used in your CSS. To start with, we'll use the same image for both read and unread status, but we'll cover using a different icon for both too.
 
The basics
Here's the basic CSS to replace the icon for all forums with your custom image:
body[data-pageapp="forums"] .cForumRow .ipsItemStatus.ipsItemStatus_large { width: 50px; height: 50px; border-radius: 0; background-color: transparent; background-image: url('{resource="mushroom.png" app="core" location="front"}'); background-size: 50px 50px; } body[data-pageapp="forums"] .cForumRow .ipsItemStatus.ipsItemStatus_large > i { display: none; } What we're doing here is specifically targeting the item status icons in the forums app, using the body[data-pageapp="forums"] selector. Within this style, we're setting the size of the icon - I've chosen 50px here which is about right in most cases, although you can change this if desired. Next we reset the border radius and background color so the icon looks right. And finally, we set the background image to our icon by using the {resource} tag and the background size to the same dimensions we just set the element to.
The next style hides the FontAwesome icon that IPS4 inserts by default, so that our icon can be seen.
 
Using a different 'read' icon
By default, your icon will be faded out for 'read' icons, but it's easy to use a completely different icon if you wish. Simply add:
body[data-pageapp="forums"] .cForumRow .ipsItemStatus.ipsItemStatus_large.ipsItemStatus_read { background-image: url('{resource="mushroom_faded.png" app="core" location="front"}'); } All we're doing here is using a more specific selector with .ipsItemStatus_read so that only the 'read' state is targeted. In the style, we specify the background image - we don't need to set and reset the other rules again because the styles we wrote in the first step are inherited.
 
Using different icons for redirect or Q&A forums
If you want to add icons specifically for redirect or Q&A forums, you can do that by targeting unique classes that are added to the icons for those kinds of forums. Those classes are .cForumIcon_redirect and .cForumIcon_answers, respectively. So, to use a custom icon for a Q&A forum, you would add another style like so:
body[data-pageapp="forums"] .cForumRow .cForumIcon_answers.ipsItemStatus.ipsItemStatus_large { background-image: url('{resource="question.png" app="core" location="front"}'); } Notice we've added .cForumIcon_answers to our selector.

In IPS4, it's easy to add custom icons to your forums, simply by uploading them on the Edit Forum screen in the AdminCP. But if you want to replace all of your forum icons, uploading the same icon for each forum can be a bit tedious.
It's easy to use some custom CSS to replace all of the icons - lets see how.
First, you'll want to upload the image(s) you want to use to the Resources section of your theme so that it can be used in your CSS. To start with, we'll use the same image for both read and unread status, but we'll cover using a different icon for both too.
 
The basics
Here's the basic CSS to replace the icon for all forums with your custom image:
body[data-pageapp="forums"] .cForumRow .ipsItemStatus.ipsItemStatus_large { width: 50px; height: 50px; border-radius: 0; background-color: transparent; background-image: url('{resource="mushroom.png" app="core" location="front"}'); background-size: 50px 50px; } body[data-pageapp="forums"] .cForumRow .ipsItemStatus.ipsItemStatus_large > i { display: none; } What we're doing here is specifically targeting the item status icons in the forums app, using the body[data-pageapp="forums"] selector. Within this style, we're setting the size of the icon - I've chosen 50px here which is about right in most cases, although you can change this if desired. Next we reset the border radius and background color so the icon looks right. And finally, we set the background image to our icon by using the {resource} tag and the background size to the same dimensions we just set the element to.
The next style hides the FontAwesome icon that IPS4 inserts by default, so that our icon can be seen.
 
Using a different 'read' icon
By default, your icon will be faded out for 'read' icons, but it's easy to use a completely different icon if you wish. Simply add:
body[data-pageapp="forums"] .cForumRow .ipsItemStatus.ipsItemStatus_large.ipsItemStatus_read { background-image: url('{resource="mushroom_faded.png" app="core" location="front"}'); } All we're doing here is using a more specific selector with .ipsItemStatus_read so that only the 'read' state is targeted. In the style, we specify the background image - we don't need to set and reset the other rules again because the styles we wrote in the first step are inherited.
 
Using different icons for redirect or Q&A forums
If you want to add icons specifically for redirect or Q&A forums, you can do that by targeting unique classes that are added to the icons for those kinds of forums. Those classes are .cForumIcon_redirect and .cForumIcon_answers, respectively. So, to use a custom icon for a Q&A forum, you would add another style like so:
body[data-pageapp="forums"] .cForumRow .cForumIcon_answers.ipsItemStatus.ipsItemStatus_large { background-image: url('{resource="question.png" app="core" location="front"}'); } Notice we've added .cForumIcon_answers to our selector.

In IPS4, it's easy to add custom icons to your forums, simply by uploading them on the Edit Forum screen in the AdminCP. But if you want to replace all of your forum icons, uploading the same icon for each forum can be a bit tedious.
It's easy to use some custom CSS to replace all of the icons - lets see how.
First, you'll want to upload the image(s) you want to use to the Resources section of your theme so that it can be used in your CSS. To start with, we'll use the same image for both read and unread status, but we'll cover using a different icon for both too.
 
The basics
Here's the basic CSS to replace the icon for all forums with your custom image:
body[data-pageapp="forums"] .cForumRow .ipsItemStatus.ipsItemStatus_large { width: 50px; height: 50px; border-radius: 0; background-color: transparent; background-image: url('{resource="mushroom.png" app="core" location="front"}'); background-size: 50px 50px; } body[data-pageapp="forums"] .cForumRow .ipsItemStatus.ipsItemStatus_large > i { display: none; } What we're doing here is specifically targeting the item status icons in the forums app, using the body[data-pageapp="forums"] selector. Within this style, we're setting the size of the icon - I've chosen 50px here which is about right in most cases, although you can change this if desired. Next we reset the border radius and background color so the icon looks right. And finally, we set the background image to our icon by using the {resource} tag and the background size to the same dimensions we just set the element to.
The next style hides the FontAwesome icon that IPS4 inserts by default, so that our icon can be seen.
 
Using a different 'read' icon
By default, your icon will be faded out for 'read' icons, but it's easy to use a completely different icon if you wish. Simply add:
body[data-pageapp="forums"] .cForumRow .ipsItemStatus.ipsItemStatus_large.ipsItemStatus_read { background-image: url('{resource="mushroom_faded.png" app="core" location="front"}'); } All we're doing here is using a more specific selector with .ipsItemStatus_read so that only the 'read' state is targeted. In the style, we specify the background image - we don't need to set and reset the other rules again because the styles we wrote in the first step are inherited.
 
Using different icons for redirect or Q&A forums
If you want to add icons specifically for redirect or Q&A forums, you can do that by targeting unique classes that are added to the icons for those kinds of forums. Those classes are .cForumIcon_redirect and .cForumIcon_answers, respectively. So, to use a custom icon for a Q&A forum, you would add another style like so:
body[data-pageapp="forums"] .cForumRow .cForumIcon_answers.ipsItemStatus.ipsItemStatus_large { background-image: url('{resource="question.png" app="core" location="front"}'); } Notice we've added .cForumIcon_answers to our selector.

In IPS4, it's easy to add custom icons to your forums, simply by uploading them on the Edit Forum screen in the AdminCP. But if you want to replace all of your forum icons, uploading the same icon for each forum can be a bit tedious.
It's easy to use some custom CSS to replace all of the icons - lets see how.
First, you'll want to upload the image(s) you want to use to the Resources section of your theme so that it can be used in your CSS. To start with, we'll use the same image for both read and unread status, but we'll cover using a different icon for both too.
 
The basics
Here's the basic CSS to replace the icon for all forums with your custom image:
body[data-pageapp="forums"] .cForumRow .ipsItemStatus.ipsItemStatus_large { width: 50px; height: 50px; border-radius: 0; background-color: transparent; background-image: url('{resource="mushroom.png" app="core" location="front"}'); background-size: 50px 50px; } body[data-pageapp="forums"] .cForumRow .ipsItemStatus.ipsItemStatus_large > i { display: none; } What we're doing here is specifically targeting the item status icons in the forums app, using the body[data-pageapp="forums"] selector. Within this style, we're setting the size of the icon - I've chosen 50px here which is about right in most cases, although you can change this if desired. Next we reset the border radius and background color so the icon looks right. And finally, we set the background image to our icon by using the {resource} tag and the background size to the same dimensions we just set the element to.
The next style hides the FontAwesome icon that IPS4 inserts by default, so that our icon can be seen.
 
Using a different 'read' icon
By default, your icon will be faded out for 'read' icons, but it's easy to use a completely different icon if you wish. Simply add:
body[data-pageapp="forums"] .cForumRow .ipsItemStatus.ipsItemStatus_large.ipsItemStatus_read { background-image: url('{resource="mushroom_faded.png" app="core" location="front"}'); } All we're doing here is using a more specific selector with .ipsItemStatus_read so that only the 'read' state is targeted. In the style, we specify the background image - we don't need to set and reset the other rules again because the styles we wrote in the first step are inherited.
 
Using different icons for redirect or Q&A forums
If you want to add icons specifically for redirect or Q&A forums, you can do that by targeting unique classes that are added to the icons for those kinds of forums. Those classes are .cForumIcon_redirect and .cForumIcon_answers, respectively. So, to use a custom icon for a Q&A forum, you would add another style like so:
body[data-pageapp="forums"] .cForumRow .cForumIcon_answers.ipsItemStatus.ipsItemStatus_large { background-image: url('{resource="question.png" app="core" location="front"}'); } Notice we've added .cForumIcon_answers to our selector.

In IPS4, it's easy to add custom icons to your forums, simply by uploading them on the Edit Forum screen in the AdminCP. But if you want to replace all of your forum icons, uploading the same icon for each forum can be a bit tedious.
It's easy to use some custom CSS to replace all of the icons - lets see how.
First, you'll want to upload the image(s) you want to use to the Resources section of your theme so that it can be used in your CSS. To start with, we'll use the same image for both read and unread status, but we'll cover using a different icon for both too.
 
The basics
Here's the basic CSS to replace the icon for all forums with your custom image:
body[data-pageapp="forums"] .cForumRow .ipsItemStatus.ipsItemStatus_large { width: 50px; height: 50px; border-radius: 0; background-color: transparent; background-image: url('{resource="mushroom.png" app="core" location="front"}'); background-size: 50px 50px; } body[data-pageapp="forums"] .cForumRow .ipsItemStatus.ipsItemStatus_large > i { display: none; } What we're doing here is specifically targeting the item status icons in the forums app, using the body[data-pageapp="forums"] selector. Within this style, we're setting the size of the icon - I've chosen 50px here which is about right in most cases, although you can change this if desired. Next we reset the border radius and background color so the icon looks right. And finally, we set the background image to our icon by using the {resource} tag and the background size to the same dimensions we just set the element to.
The next style hides the FontAwesome icon that IPS4 inserts by default, so that our icon can be seen.
 
Using a different 'read' icon
By default, your icon will be faded out for 'read' icons, but it's easy to use a completely different icon if you wish. Simply add:
body[data-pageapp="forums"] .cForumRow .ipsItemStatus.ipsItemStatus_large.ipsItemStatus_read { background-image: url('{resource="mushroom_faded.png" app="core" location="front"}'); } All we're doing here is using a more specific selector with .ipsItemStatus_read so that only the 'read' state is targeted. In the style, we specify the background image - we don't need to set and reset the other rules again because the styles we wrote in the first step are inherited.
 
Using different icons for redirect or Q&A forums
If you want to add icons specifically for redirect or Q&A forums, you can do that by targeting unique classes that are added to the icons for those kinds of forums. Those classes are .cForumIcon_redirect and .cForumIcon_answers, respectively. So, to use a custom icon for a Q&A forum, you would add another style like so:
body[data-pageapp="forums"] .cForumRow .cForumIcon_answers.ipsItemStatus.ipsItemStatus_large { background-image: url('{resource="question.png" app="core" location="front"}'); } Notice we've added .cForumIcon_answers to our selector.

In IPS4, it's easy to add custom icons to your forums, simply by uploading them on the Edit Forum screen in the AdminCP. But if you want to replace all of your forum icons, uploading the same icon for each forum can be a bit tedious.
It's easy to use some custom CSS to replace all of the icons - lets see how.
First, you'll want to upload the image(s) you want to use to the Resources section of your theme so that it can be used in your CSS. To start with, we'll use the same image for both read and unread status, but we'll cover using a different icon for both too.
 
The basics
Here's the basic CSS to replace the icon for all forums with your custom image:
body[data-pageapp="forums"] .cForumRow .ipsItemStatus.ipsItemStatus_large { width: 50px; height: 50px; border-radius: 0; background-color: transparent; background-image: url('{resource="mushroom.png" app="core" location="front"}'); background-size: 50px 50px; } body[data-pageapp="forums"] .cForumRow .ipsItemStatus.ipsItemStatus_large > i { display: none; } What we're doing here is specifically targeting the item status icons in the forums app, using the body[data-pageapp="forums"] selector. Within this style, we're setting the size of the icon - I've chosen 50px here which is about right in most cases, although you can change this if desired. Next we reset the border radius and background color so the icon looks right. And finally, we set the background image to our icon by using the {resource} tag and the background size to the same dimensions we just set the element to.
The next style hides the FontAwesome icon that IPS4 inserts by default, so that our icon can be seen.
 
Using a different 'read' icon
By default, your icon will be faded out for 'read' icons, but it's easy to use a completely different icon if you wish. Simply add:
body[data-pageapp="forums"] .cForumRow .ipsItemStatus.ipsItemStatus_large.ipsItemStatus_read { background-image: url('{resource="mushroom_faded.png" app="core" location="front"}'); } All we're doing here is using a more specific selector with .ipsItemStatus_read so that only the 'read' state is targeted. In the style, we specify the background image - we don't need to set and reset the other rules again because the styles we wrote in the first step are inherited.
 
Using different icons for redirect or Q&A forums
If you want to add icons specifically for redirect or Q&A forums, you can do that by targeting unique classes that are added to the icons for those kinds of forums. Those classes are .cForumIcon_redirect and .cForumIcon_answers, respectively. So, to use a custom icon for a Q&A forum, you would add another style like so:
body[data-pageapp="forums"] .cForumRow .cForumIcon_answers.ipsItemStatus.ipsItemStatus_large { background-image: url('{resource="question.png" app="core" location="front"}'); } Notice we've added .cForumIcon_answers to our selector.

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!

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!

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!

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!

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!

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!

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!

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!

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!

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!

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!

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!

Blocks are an extremely popular feature in IPS4, used by a huge number of customers to great effect. They range from feeds of topics, to statistics, to custom blocks that can contain anything you wish. They're a great way to add dynamic content to your community theme.
What many people don't know is that blocks you create with Pages can be used anywhere in your theme, not just in the designated block containers (in the header, footer & sidebar).
 
The {block} tag
It's really easy to do so. Here's the tag you'd use:
{block="block_key"} That's it! The block_key is the one you specify when you're creating the block in Pages (if you don't specify one manually, Pages will auto-generate one for you).
 
Where can you use them?
Block tags can be used anywhere that template logic is supported. That includes:
Theme templates Pages page content Other kinds of templates (e.g. database templates) Even within other blocks!  
What can you do with them?
The obvious benefit of blocks is that they are reusable, so in any situation where you need the same content duplicated, it makes sense to put the content in a custom block instead, and simply insert it wherever needed. Then if you need to update the content later, you have one place to do so. Custom menus are a great example of reusing blocks; since blocks have full use of template logic, you can build your menu HTML in a block, use HTML Logic to highlight the correct item, and insert the menu block on each of your pages. We use this approach on our feature tour section menu. Here's a snippet of the menu block HTML for that page:
<nav id='elTourNav'> <div class='container'> <ul class='ipsList_inline'> <li><a href='/features/apps' {{if \IPS\Request::i()->path == 'features/apps'}}class='sSelected'{{endif}}>Our Apps</a></li> <li><a href='/features/engagement' {{if \IPS\Request::i()->path == 'features/engagement'}}class='sSelected'{{endif}}>Engagement</a></li> <!-- ... --> </ul> </div> </nav>  
Blocks are useful beyond that, though. A couple of weeks ago, we showed you how to use HTML Logic to only show content to certain groups. Using blocks is actually an easier way to do this - simply add the content to a custom block, then check the groups who should see it. We use this technique to show a 'welcome to our community' message to guests on our own community. We created our welcome message as a custom Pages block, set it so that only guests have permission to view it, and then added it to our template header. Simple, effective and easy to manage.
That's just two ways you can use blocks - there's many other creative users too! If you've used blocks in an interesting way, share your example in the comments!

Blocks are an extremely popular feature in IPS4, used by a huge number of customers to great effect. They range from feeds of topics, to statistics, to custom blocks that can contain anything you wish. They're a great way to add dynamic content to your community theme.
What many people don't know is that blocks you create with Pages can be used anywhere in your theme, not just in the designated block containers (in the header, footer & sidebar).
 
The {block} tag
It's really easy to do so. Here's the tag you'd use:
{block="block_key"} That's it! The block_key is the one you specify when you're creating the block in Pages (if you don't specify one manually, Pages will auto-generate one for you).
 
Where can you use them?
Block tags can be used anywhere that template logic is supported. That includes:
Theme templates Pages page content Other kinds of templates (e.g. database templates) Even within other blocks!  
What can you do with them?
The obvious benefit of blocks is that they are reusable, so in any situation where you need the same content duplicated, it makes sense to put the content in a custom block instead, and simply insert it wherever needed. Then if you need to update the content later, you have one place to do so. Custom menus are a great example of reusing blocks; since blocks have full use of template logic, you can build your menu HTML in a block, use HTML Logic to highlight the correct item, and insert the menu block on each of your pages. We use this approach on our feature tour section menu. Here's a snippet of the menu block HTML for that page:
<nav id='elTourNav'> <div class='container'> <ul class='ipsList_inline'> <li><a href='/features/apps' {{if \IPS\Request::i()->path == 'features/apps'}}class='sSelected'{{endif}}>Our Apps</a></li> <li><a href='/features/engagement' {{if \IPS\Request::i()->path == 'features/engagement'}}class='sSelected'{{endif}}>Engagement</a></li> <!-- ... --> </ul> </div> </nav>  
Blocks are useful beyond that, though. A couple of weeks ago, we showed you how to use HTML Logic to only show content to certain groups. Using blocks is actually an easier way to do this - simply add the content to a custom block, then check the groups who should see it. We use this technique to show a 'welcome to our community' message to guests on our own community. We created our welcome message as a custom Pages block, set it so that only guests have permission to view it, and then added it to our template header. Simple, effective and easy to manage.
That's just two ways you can use blocks - there's many other creative users too! If you've used blocks in an interesting way, share your example in the comments!

When IPS4 encounters an error (be it a simple 404 Not Found or a more complex configuration issue), the user sees a standard built-in error page. That's fine in many cases, but did you know you can create your own error page using our Pages app?
This is a particularly good approach for communities that use Pages for their website too. If you have built a website theme, the standard error page may not fit with your visual style, so building your own error page allows you to improve it. You might want to show some helpful links to other parts of your website, for example.
 
Creating your error page
The first step is creating your error page in Pages. Note that for this page, you must create a manual page - the Page Builder tool can't be used in this case.
In order to show the error on your page, there's two special tags you should insert in the page content. When your page is shown in response to an error, Pages will swap out these tags for the relevant text. They are:
{error_code}
Replaced with the technical error code for this error. This code identifies the exact piece of code that triggered the error, and can be given to IPS support technicians to help diagnose problems. {error_message}
Replaced with a human-friendly description of the error that occurred.  
Configuring Pages to use the error page
Next, set Pages to display the error page. You do this in the Pages section; click the Advanced Settings button, and select your page from the list. Note that this will replace all error pages across the suite - not just errors triggered by Pages itself!
 
Have a request for a theme tip? Let us know in the comments and we'll try and help out in a future tip! 
 

When IPS4 encounters an error (be it a simple 404 Not Found or a more complex configuration issue), the user sees a standard built-in error page. That's fine in many cases, but did you know you can create your own error page using our Pages app?
This is a particularly good approach for communities that use Pages for their website too. If you have built a website theme, the standard error page may not fit with your visual style, so building your own error page allows you to improve it. You might want to show some helpful links to other parts of your website, for example.
 
Creating your error page
The first step is creating your error page in Pages. Note that for this page, you must create a manual page - the Page Builder tool can't be used in this case.
In order to show the error on your page, there's two special tags you should insert in the page content. When your page is shown in response to an error, Pages will swap out these tags for the relevant text. They are:
{error_code}
Replaced with the technical error code for this error. This code identifies the exact piece of code that triggered the error, and can be given to IPS support technicians to help diagnose problems. {error_message}
Replaced with a human-friendly description of the error that occurred.  
Configuring Pages to use the error page
Next, set Pages to display the error page. You do this in the Pages section; click the Advanced Settings button, and select your page from the list. Note that this will replace all error pages across the suite - not just errors triggered by Pages itself!
 
Have a request for a theme tip? Let us know in the comments and we'll try and help out in a future tip! 
 

Blocks are an extremely popular feature in IPS4, used by a huge number of customers to great effect. They range from feeds of topics, to statistics, to custom blocks that can contain anything you wish. They're a great way to add dynamic content to your community theme.
What many people don't know is that blocks you create with Pages can be used anywhere in your theme, not just in the designated block containers (in the header, footer & sidebar).
 
The {block} tag
It's really easy to do so. Here's the tag you'd use:
{block="block_key"} That's it! The block_key is the one you specify when you're creating the block in Pages (if you don't specify one manually, Pages will auto-generate one for you).
 
Where can you use them?
Block tags can be used anywhere that template logic is supported. That includes:
Theme templates Pages page content Other kinds of templates (e.g. database templates) Even within other blocks!  
What can you do with them?
The obvious benefit of blocks is that they are reusable, so in any situation where you need the same content duplicated, it makes sense to put the content in a custom block instead, and simply insert it wherever needed. Then if you need to update the content later, you have one place to do so. Custom menus are a great example of reusing blocks; since blocks have full use of template logic, you can build your menu HTML in a block, use HTML Logic to highlight the correct item, and insert the menu block on each of your pages. We use this approach on our feature tour section menu. Here's a snippet of the menu block HTML for that page:
<nav id='elTourNav'> <div class='container'> <ul class='ipsList_inline'> <li><a href='/features/apps' {{if \IPS\Request::i()->path == 'features/apps'}}class='sSelected'{{endif}}>Our Apps</a></li> <li><a href='/features/engagement' {{if \IPS\Request::i()->path == 'features/engagement'}}class='sSelected'{{endif}}>Engagement</a></li> <!-- ... --> </ul> </div> </nav>  
Blocks are useful beyond that, though. A couple of weeks ago, we showed you how to use HTML Logic to only show content to certain groups. Using blocks is actually an easier way to do this - simply add the content to a custom block, then check the groups who should see it. We use this technique to show a 'welcome to our community' message to guests on our own community. We created our welcome message as a custom Pages block, set it so that only guests have permission to view it, and then added it to our template header. Simple, effective and easy to manage.
That's just two ways you can use blocks - there's many other creative users too! If you've used blocks in an interesting way, share your example in the comments!

Blocks are an extremely popular feature in IPS4, used by a huge number of customers to great effect. They range from feeds of topics, to statistics, to custom blocks that can contain anything you wish. They're a great way to add dynamic content to your community theme.
What many people don't know is that blocks you create with Pages can be used anywhere in your theme, not just in the designated block containers (in the header, footer & sidebar).
 
The {block} tag
It's really easy to do so. Here's the tag you'd use:
{block="block_key"} That's it! The block_key is the one you specify when you're creating the block in Pages (if you don't specify one manually, Pages will auto-generate one for you).
 
Where can you use them?
Block tags can be used anywhere that template logic is supported. That includes:
Theme templates Pages page content Other kinds of templates (e.g. database templates) Even within other blocks!  
What can you do with them?
The obvious benefit of blocks is that they are reusable, so in any situation where you need the same content duplicated, it makes sense to put the content in a custom block instead, and simply insert it wherever needed. Then if you need to update the content later, you have one place to do so. Custom menus are a great example of reusing blocks; since blocks have full use of template logic, you can build your menu HTML in a block, use HTML Logic to highlight the correct item, and insert the menu block on each of your pages. We use this approach on our feature tour section menu. Here's a snippet of the menu block HTML for that page:
<nav id='elTourNav'> <div class='container'> <ul class='ipsList_inline'> <li><a href='/features/apps' {{if \IPS\Request::i()->path == 'features/apps'}}class='sSelected'{{endif}}>Our Apps</a></li> <li><a href='/features/engagement' {{if \IPS\Request::i()->path == 'features/engagement'}}class='sSelected'{{endif}}>Engagement</a></li> <!-- ... --> </ul> </div> </nav>  
Blocks are useful beyond that, though. A couple of weeks ago, we showed you how to use HTML Logic to only show content to certain groups. Using blocks is actually an easier way to do this - simply add the content to a custom block, then check the groups who should see it. We use this technique to show a 'welcome to our community' message to guests on our own community. We created our welcome message as a custom Pages block, set it so that only guests have permission to view it, and then added it to our template header. Simple, effective and easy to manage.
That's just two ways you can use blocks - there's many other creative users too! If you've used blocks in an interesting way, share your example in the comments!

Blocks are an extremely popular feature in IPS4, used by a huge number of customers to great effect. They range from feeds of topics, to statistics, to custom blocks that can contain anything you wish. They're a great way to add dynamic content to your community theme.
What many people don't know is that blocks you create with Pages can be used anywhere in your theme, not just in the designated block containers (in the header, footer & sidebar).
 
The {block} tag
It's really easy to do so. Here's the tag you'd use:
{block="block_key"} That's it! The block_key is the one you specify when you're creating the block in Pages (if you don't specify one manually, Pages will auto-generate one for you).
 
Where can you use them?
Block tags can be used anywhere that template logic is supported. That includes:
Theme templates Pages page content Other kinds of templates (e.g. database templates) Even within other blocks!  
What can you do with them?
The obvious benefit of blocks is that they are reusable, so in any situation where you need the same content duplicated, it makes sense to put the content in a custom block instead, and simply insert it wherever needed. Then if you need to update the content later, you have one place to do so. Custom menus are a great example of reusing blocks; since blocks have full use of template logic, you can build your menu HTML in a block, use HTML Logic to highlight the correct item, and insert the menu block on each of your pages. We use this approach on our feature tour section menu. Here's a snippet of the menu block HTML for that page:
<nav id='elTourNav'> <div class='container'> <ul class='ipsList_inline'> <li><a href='/features/apps' {{if \IPS\Request::i()->path == 'features/apps'}}class='sSelected'{{endif}}>Our Apps</a></li> <li><a href='/features/engagement' {{if \IPS\Request::i()->path == 'features/engagement'}}class='sSelected'{{endif}}>Engagement</a></li> <!-- ... --> </ul> </div> </nav>  
Blocks are useful beyond that, though. A couple of weeks ago, we showed you how to use HTML Logic to only show content to certain groups. Using blocks is actually an easier way to do this - simply add the content to a custom block, then check the groups who should see it. We use this technique to show a 'welcome to our community' message to guests on our own community. We created our welcome message as a custom Pages block, set it so that only guests have permission to view it, and then added it to our template header. Simple, effective and easy to manage.
That's just two ways you can use blocks - there's many other creative users too! If you've used blocks in an interesting way, share your example in the comments!

Blocks are an extremely popular feature in IPS4, used by a huge number of customers to great effect. They range from feeds of topics, to statistics, to custom blocks that can contain anything you wish. They're a great way to add dynamic content to your community theme.
What many people don't know is that blocks you create with Pages can be used anywhere in your theme, not just in the designated block containers (in the header, footer & sidebar).
 
The {block} tag
It's really easy to do so. Here's the tag you'd use:
{block="block_key"} That's it! The block_key is the one you specify when you're creating the block in Pages (if you don't specify one manually, Pages will auto-generate one for you).
 
Where can you use them?
Block tags can be used anywhere that template logic is supported. That includes:
Theme templates Pages page content Other kinds of templates (e.g. database templates) Even within other blocks!  
What can you do with them?
The obvious benefit of blocks is that they are reusable, so in any situation where you need the same content duplicated, it makes sense to put the content in a custom block instead, and simply insert it wherever needed. Then if you need to update the content later, you have one place to do so. Custom menus are a great example of reusing blocks; since blocks have full use of template logic, you can build your menu HTML in a block, use HTML Logic to highlight the correct item, and insert the menu block on each of your pages. We use this approach on our feature tour section menu. Here's a snippet of the menu block HTML for that page:
<nav id='elTourNav'> <div class='container'> <ul class='ipsList_inline'> <li><a href='/features/apps' {{if \IPS\Request::i()->path == 'features/apps'}}class='sSelected'{{endif}}>Our Apps</a></li> <li><a href='/features/engagement' {{if \IPS\Request::i()->path == 'features/engagement'}}class='sSelected'{{endif}}>Engagement</a></li> <!-- ... --> </ul> </div> </nav>  
Blocks are useful beyond that, though. A couple of weeks ago, we showed you how to use HTML Logic to only show content to certain groups. Using blocks is actually an easier way to do this - simply add the content to a custom block, then check the groups who should see it. We use this technique to show a 'welcome to our community' message to guests on our own community. We created our welcome message as a custom Pages block, set it so that only guests have permission to view it, and then added it to our template header. Simple, effective and easy to manage.
That's just two ways you can use blocks - there's many other creative users too! If you've used blocks in an interesting way, share your example in the comments!

Blocks are an extremely popular feature in IPS4, used by a huge number of customers to great effect. They range from feeds of topics, to statistics, to custom blocks that can contain anything you wish. They're a great way to add dynamic content to your community theme.
What many people don't know is that blocks you create with Pages can be used anywhere in your theme, not just in the designated block containers (in the header, footer & sidebar).
 
The {block} tag
It's really easy to do so. Here's the tag you'd use:
{block="block_key"} That's it! The block_key is the one you specify when you're creating the block in Pages (if you don't specify one manually, Pages will auto-generate one for you).
 
Where can you use them?
Block tags can be used anywhere that template logic is supported. That includes:
Theme templates Pages page content Other kinds of templates (e.g. database templates) Even within other blocks!  
What can you do with them?
The obvious benefit of blocks is that they are reusable, so in any situation where you need the same content duplicated, it makes sense to put the content in a custom block instead, and simply insert it wherever needed. Then if you need to update the content later, you have one place to do so. Custom menus are a great example of reusing blocks; since blocks have full use of template logic, you can build your menu HTML in a block, use HTML Logic to highlight the correct item, and insert the menu block on each of your pages. We use this approach on our feature tour section menu. Here's a snippet of the menu block HTML for that page:
<nav id='elTourNav'> <div class='container'> <ul class='ipsList_inline'> <li><a href='/features/apps' {{if \IPS\Request::i()->path == 'features/apps'}}class='sSelected'{{endif}}>Our Apps</a></li> <li><a href='/features/engagement' {{if \IPS\Request::i()->path == 'features/engagement'}}class='sSelected'{{endif}}>Engagement</a></li> <!-- ... --> </ul> </div> </nav>  
Blocks are useful beyond that, though. A couple of weeks ago, we showed you how to use HTML Logic to only show content to certain groups. Using blocks is actually an easier way to do this - simply add the content to a custom block, then check the groups who should see it. We use this technique to show a 'welcome to our community' message to guests on our own community. We created our welcome message as a custom Pages block, set it so that only guests have permission to view it, and then added it to our template header. Simple, effective and easy to manage.
That's just two ways you can use blocks - there's many other creative users too! If you've used blocks in an interesting way, share your example in the comments!

When IPS4 encounters an error (be it a simple 404 Not Found or a more complex configuration issue), the user sees a standard built-in error page. That's fine in many cases, but did you know you can create your own error page using our Pages app?
This is a particularly good approach for communities that use Pages for their website too. If you have built a website theme, the standard error page may not fit with your visual style, so building your own error page allows you to improve it. You might want to show some helpful links to other parts of your website, for example.
 
Creating your error page
The first step is creating your error page in Pages. Note that for this page, you must create a manual page - the Page Builder tool can't be used in this case.
In order to show the error on your page, there's two special tags you should insert in the page content. When your page is shown in response to an error, Pages will swap out these tags for the relevant text. They are:
{error_code}
Replaced with the technical error code for this error. This code identifies the exact piece of code that triggered the error, and can be given to IPS support technicians to help diagnose problems. {error_message}
Replaced with a human-friendly description of the error that occurred.  
Configuring Pages to use the error page
Next, set Pages to display the error page. You do this in the Pages section; click the Advanced Settings button, and select your page from the list. Note that this will replace all error pages across the suite - not just errors triggered by Pages itself!
 
Have a request for a theme tip? Let us know in the comments and we'll try and help out in a future tip! 
 

When IPS4 encounters an error (be it a simple 404 Not Found or a more complex configuration issue), the user sees a standard built-in error page. That's fine in many cases, but did you know you can create your own error page using our Pages app?
This is a particularly good approach for communities that use Pages for their website too. If you have built a website theme, the standard error page may not fit with your visual style, so building your own error page allows you to improve it. You might want to show some helpful links to other parts of your website, for example.
 
Creating your error page
The first step is creating your error page in Pages. Note that for this page, you must create a manual page - the Page Builder tool can't be used in this case.
In order to show the error on your page, there's two special tags you should insert in the page content. When your page is shown in response to an error, Pages will swap out these tags for the relevant text. They are:
{error_code}
Replaced with the technical error code for this error. This code identifies the exact piece of code that triggered the error, and can be given to IPS support technicians to help diagnose problems. {error_message}
Replaced with a human-friendly description of the error that occurred.  
Configuring Pages to use the error page
Next, set Pages to display the error page. You do this in the Pages section; click the Advanced Settings button, and select your page from the list. Note that this will replace all error pages across the suite - not just errors triggered by Pages itself!
 
Have a request for a theme tip? Let us know in the comments and we'll try and help out in a future tip! 
 

When IPS4 encounters an error (be it a simple 404 Not Found or a more complex configuration issue), the user sees a standard built-in error page. That's fine in many cases, but did you know you can create your own error page using our Pages app?
This is a particularly good approach for communities that use Pages for their website too. If you have built a website theme, the standard error page may not fit with your visual style, so building your own error page allows you to improve it. You might want to show some helpful links to other parts of your website, for example.
 
Creating your error page
The first step is creating your error page in Pages. Note that for this page, you must create a manual page - the Page Builder tool can't be used in this case.
In order to show the error on your page, there's two special tags you should insert in the page content. When your page is shown in response to an error, Pages will swap out these tags for the relevant text. They are:
{error_code}
Replaced with the technical error code for this error. This code identifies the exact piece of code that triggered the error, and can be given to IPS support technicians to help diagnose problems. {error_message}
Replaced with a human-friendly description of the error that occurred.  
Configuring Pages to use the error page
Next, set Pages to display the error page. You do this in the Pages section; click the Advanced Settings button, and select your page from the list. Note that this will replace all error pages across the suite - not just errors triggered by Pages itself!
 
Have a request for a theme tip? Let us know in the comments and we'll try and help out in a future tip! 
 

When IPS4 encounters an error (be it a simple 404 Not Found or a more complex configuration issue), the user sees a standard built-in error page. That's fine in many cases, but did you know you can create your own error page using our Pages app?
This is a particularly good approach for communities that use Pages for their website too. If you have built a website theme, the standard error page may not fit with your visual style, so building your own error page allows you to improve it. You might want to show some helpful links to other parts of your website, for example.
 
Creating your error page
The first step is creating your error page in Pages. Note that for this page, you must create a manual page - the Page Builder tool can't be used in this case.
In order to show the error on your page, there's two special tags you should insert in the page content. When your page is shown in response to an error, Pages will swap out these tags for the relevant text. They are:
{error_code}
Replaced with the technical error code for this error. This code identifies the exact piece of code that triggered the error, and can be given to IPS support technicians to help diagnose problems. {error_message}
Replaced with a human-friendly description of the error that occurred.  
Configuring Pages to use the error page
Next, set Pages to display the error page. You do this in the Pages section; click the Advanced Settings button, and select your page from the list. Note that this will replace all error pages across the suite - not just errors triggered by Pages itself!
 
Have a request for a theme tip? Let us know in the comments and we'll try and help out in a future tip! 
 

When IPS4 encounters an error (be it a simple 404 Not Found or a more complex configuration issue), the user sees a standard built-in error page. That's fine in many cases, but did you know you can create your own error page using our Pages app?
This is a particularly good approach for communities that use Pages for their website too. If you have built a website theme, the standard error page may not fit with your visual style, so building your own error page allows you to improve it. You might want to show some helpful links to other parts of your website, for example.
 
Creating your error page
The first step is creating your error page in Pages. Note that for this page, you must create a manual page - the Page Builder tool can't be used in this case.
In order to show the error on your page, there's two special tags you should insert in the page content. When your page is shown in response to an error, Pages will swap out these tags for the relevant text. They are:
{error_code}
Replaced with the technical error code for this error. This code identifies the exact piece of code that triggered the error, and can be given to IPS support technicians to help diagnose problems. {error_message}
Replaced with a human-friendly description of the error that occurred.  
Configuring Pages to use the error page
Next, set Pages to display the error page. You do this in the Pages section; click the Advanced Settings button, and select your page from the list. Note that this will replace all error pages across the suite - not just errors triggered by Pages itself!
 
Have a request for a theme tip? Let us know in the comments and we'll try and help out in a future tip! 
 

When IPS4 encounters an error (be it a simple 404 Not Found or a more complex configuration issue), the user sees a standard built-in error page. That's fine in many cases, but did you know you can create your own error page using our Pages app?
This is a particularly good approach for communities that use Pages for their website too. If you have built a website theme, the standard error page may not fit with your visual style, so building your own error page allows you to improve it. You might want to show some helpful links to other parts of your website, for example.
 
Creating your error page
The first step is creating your error page in Pages. Note that for this page, you must create a manual page - the Page Builder tool can't be used in this case.
In order to show the error on your page, there's two special tags you should insert in the page content. When your page is shown in response to an error, Pages will swap out these tags for the relevant text. They are:
{error_code}
Replaced with the technical error code for this error. This code identifies the exact piece of code that triggered the error, and can be given to IPS support technicians to help diagnose problems. {error_message}
Replaced with a human-friendly description of the error that occurred.  
Configuring Pages to use the error page
Next, set Pages to display the error page. You do this in the Pages section; click the Advanced Settings button, and select your page from the list. Note that this will replace all error pages across the suite - not just errors triggered by Pages itself!
 
Have a request for a theme tip? Let us know in the comments and we'll try and help out in a future tip! 
 

When IPS4 encounters an error (be it a simple 404 Not Found or a more complex configuration issue), the user sees a standard built-in error page. That's fine in many cases, but did you know you can create your own error page using our Pages app?
This is a particularly good approach for communities that use Pages for their website too. If you have built a website theme, the standard error page may not fit with your visual style, so building your own error page allows you to improve it. You might want to show some helpful links to other parts of your website, for example.
 
Creating your error page
The first step is creating your error page in Pages. Note that for this page, you must create a manual page - the Page Builder tool can't be used in this case.
In order to show the error on your page, there's two special tags you should insert in the page content. When your page is shown in response to an error, Pages will swap out these tags for the relevant text. They are:
{error_code}
Replaced with the technical error code for this error. This code identifies the exact piece of code that triggered the error, and can be given to IPS support technicians to help diagnose problems. {error_message}
Replaced with a human-friendly description of the error that occurred.  
Configuring Pages to use the error page
Next, set Pages to display the error page. You do this in the Pages section; click the Advanced Settings button, and select your page from the list. Note that this will replace all error pages across the suite - not just errors triggered by Pages itself!
 
Have a request for a theme tip? Let us know in the comments and we'll try and help out in a future tip! 
 

When IPS4 encounters an error (be it a simple 404 Not Found or a more complex configuration issue), the user sees a standard built-in error page. That's fine in many cases, but did you know you can create your own error page using our Pages app?
This is a particularly good approach for communities that use Pages for their website too. If you have built a website theme, the standard error page may not fit with your visual style, so building your own error page allows you to improve it. You might want to show some helpful links to other parts of your website, for example.
 
Creating your error page
The first step is creating your error page in Pages. Note that for this page, you must create a manual page - the Page Builder tool can't be used in this case.
In order to show the error on your page, there's two special tags you should insert in the page content. When your page is shown in response to an error, Pages will swap out these tags for the relevant text. They are:
{error_code}
Replaced with the technical error code for this error. This code identifies the exact piece of code that triggered the error, and can be given to IPS support technicians to help diagnose problems. {error_message}
Replaced with a human-friendly description of the error that occurred.  
Configuring Pages to use the error page
Next, set Pages to display the error page. You do this in the Pages section; click the Advanced Settings button, and select your page from the list. Note that this will replace all error pages across the suite - not just errors triggered by Pages itself!
 
Have a request for a theme tip? Let us know in the comments and we'll try and help out in a future tip! 
 

When IPS4 encounters an error (be it a simple 404 Not Found or a more complex configuration issue), the user sees a standard built-in error page. That's fine in many cases, but did you know you can create your own error page using our Pages app?
This is a particularly good approach for communities that use Pages for their website too. If you have built a website theme, the standard error page may not fit with your visual style, so building your own error page allows you to improve it. You might want to show some helpful links to other parts of your website, for example.
 
Creating your error page
The first step is creating your error page in Pages. Note that for this page, you must create a manual page - the Page Builder tool can't be used in this case.
In order to show the error on your page, there's two special tags you should insert in the page content. When your page is shown in response to an error, Pages will swap out these tags for the relevant text. They are:
{error_code}
Replaced with the technical error code for this error. This code identifies the exact piece of code that triggered the error, and can be given to IPS support technicians to help diagnose problems. {error_message}
Replaced with a human-friendly description of the error that occurred.  
Configuring Pages to use the error page
Next, set Pages to display the error page. You do this in the Pages section; click the Advanced Settings button, and select your page from the list. Note that this will replace all error pages across the suite - not just errors triggered by Pages itself!
 
Have a request for a theme tip? Let us know in the comments and we'll try and help out in a future tip! 
 

When IPS4 encounters an error (be it a simple 404 Not Found or a more complex configuration issue), the user sees a standard built-in error page. That's fine in many cases, but did you know you can create your own error page using our Pages app?
This is a particularly good approach for communities that use Pages for their website too. If you have built a website theme, the standard error page may not fit with your visual style, so building your own error page allows you to improve it. You might want to show some helpful links to other parts of your website, for example.
 
Creating your error page
The first step is creating your error page in Pages. Note that for this page, you must create a manual page - the Page Builder tool can't be used in this case.
In order to show the error on your page, there's two special tags you should insert in the page content. When your page is shown in response to an error, Pages will swap out these tags for the relevant text. They are:
{error_code}
Replaced with the technical error code for this error. This code identifies the exact piece of code that triggered the error, and can be given to IPS support technicians to help diagnose problems. {error_message}
Replaced with a human-friendly description of the error that occurred.  
Configuring Pages to use the error page
Next, set Pages to display the error page. You do this in the Pages section; click the Advanced Settings button, and select your page from the list. Note that this will replace all error pages across the suite - not just errors triggered by Pages itself!
 
Have a request for a theme tip? Let us know in the comments and we'll try and help out in a future tip! 
 

When IPS4 encounters an error (be it a simple 404 Not Found or a more complex configuration issue), the user sees a standard built-in error page. That's fine in many cases, but did you know you can create your own error page using our Pages app?
This is a particularly good approach for communities that use Pages for their website too. If you have built a website theme, the standard error page may not fit with your visual style, so building your own error page allows you to improve it. You might want to show some helpful links to other parts of your website, for example.
 
Creating your error page
The first step is creating your error page in Pages. Note that for this page, you must create a manual page - the Page Builder tool can't be used in this case.
In order to show the error on your page, there's two special tags you should insert in the page content. When your page is shown in response to an error, Pages will swap out these tags for the relevant text. They are:
{error_code}
Replaced with the technical error code for this error. This code identifies the exact piece of code that triggered the error, and can be given to IPS support technicians to help diagnose problems. {error_message}
Replaced with a human-friendly description of the error that occurred.  
Configuring Pages to use the error page
Next, set Pages to display the error page. You do this in the Pages section; click the Advanced Settings button, and select your page from the list. Note that this will replace all error pages across the suite - not just errors triggered by Pages itself!
 
Have a request for a theme tip? Let us know in the comments and we'll try and help out in a future tip! 
 

When IPS4 encounters an error (be it a simple 404 Not Found or a more complex configuration issue), the user sees a standard built-in error page. That's fine in many cases, but did you know you can create your own error page using our Pages app?
This is a particularly good approach for communities that use Pages for their website too. If you have built a website theme, the standard error page may not fit with your visual style, so building your own error page allows you to improve it. You might want to show some helpful links to other parts of your website, for example.
 
Creating your error page
The first step is creating your error page in Pages. Note that for this page, you must create a manual page - the Page Builder tool can't be used in this case.
In order to show the error on your page, there's two special tags you should insert in the page content. When your page is shown in response to an error, Pages will swap out these tags for the relevant text. They are:
{error_code}
Replaced with the technical error code for this error. This code identifies the exact piece of code that triggered the error, and can be given to IPS support technicians to help diagnose problems. {error_message}
Replaced with a human-friendly description of the error that occurred.  
Configuring Pages to use the error page
Next, set Pages to display the error page. You do this in the Pages section; click the Advanced Settings button, and select your page from the list. Note that this will replace all error pages across the suite - not just errors triggered by Pages itself!
 
Have a request for a theme tip? Let us know in the comments and we'll try and help out in a future tip! 
 

When IPS4 encounters an error (be it a simple 404 Not Found or a more complex configuration issue), the user sees a standard built-in error page. That's fine in many cases, but did you know you can create your own error page using our Pages app?
This is a particularly good approach for communities that use Pages for their website too. If you have built a website theme, the standard error page may not fit with your visual style, so building your own error page allows you to improve it. You might want to show some helpful links to other parts of your website, for example.
 
Creating your error page
The first step is creating your error page in Pages. Note that for this page, you must create a manual page - the Page Builder tool can't be used in this case.
In order to show the error on your page, there's two special tags you should insert in the page content. When your page is shown in response to an error, Pages will swap out these tags for the relevant text. They are:
{error_code}
Replaced with the technical error code for this error. This code identifies the exact piece of code that triggered the error, and can be given to IPS support technicians to help diagnose problems. {error_message}
Replaced with a human-friendly description of the error that occurred.  
Configuring Pages to use the error page
Next, set Pages to display the error page. You do this in the Pages section; click the Advanced Settings button, and select your page from the list. Note that this will replace all error pages across the suite - not just errors triggered by Pages itself!
 
Have a request for a theme tip? Let us know in the comments and we'll try and help out in a future tip! 
 

When IPS4 encounters an error (be it a simple 404 Not Found or a more complex configuration issue), the user sees a standard built-in error page. That's fine in many cases, but did you know you can create your own error page using our Pages app?
This is a particularly good approach for communities that use Pages for their website too. If you have built a website theme, the standard error page may not fit with your visual style, so building your own error page allows you to improve it. You might want to show some helpful links to other parts of your website, for example.
 
Creating your error page
The first step is creating your error page in Pages. Note that for this page, you must create a manual page - the Page Builder tool can't be used in this case.
In order to show the error on your page, there's two special tags you should insert in the page content. When your page is shown in response to an error, Pages will swap out these tags for the relevant text. They are:
{error_code}
Replaced with the technical error code for this error. This code identifies the exact piece of code that triggered the error, and can be given to IPS support technicians to help diagnose problems. {error_message}
Replaced with a human-friendly description of the error that occurred.  
Configuring Pages to use the error page
Next, set Pages to display the error page. You do this in the Pages section; click the Advanced Settings button, and select your page from the list. Note that this will replace all error pages across the suite - not just errors triggered by Pages itself!
 
Have a request for a theme tip? Let us know in the comments and we'll try and help out in a future tip!