Rikki

HTML Logic is our name for the additional tags available in IPS4's templates that allow runtime logic to be executed. It comprises if/then/else statements as well as loops and more.
Since HTML Logic has access to all of the underlying PHP framework in IPS4, it's very powerful and a lot can be achieved with it. One common use is to limit certain content within a template to particular member groups. Let's see how that might be done.
 
Showing or hiding content only to guests
We'll first look at a simpler idea: showing or hiding content specifically to guests (i.e. anyone who isn't logged in). Within IPS4, the \IPS\Member::loggedIn() object contains information about the current user. Guests always have a member_id of NULL (i.e. no value), so we can simply check that value in our logic tag:
{{if \IPS\Member::loggedIn()->member_id === NULL}} This content *only* shows to guests, since they have a NULL member_id. {{endif}} {{if \IPS\Member::loggedIn()->member_id}} This content *only* shows to logged-in users since their member_id is a number, which will equal true. {{endif}}  
Showing content only to specific groups
Let's go a bit further and this time show content to specific (primary) member groups. First, you need to get the IDs for the group(s) you want to deal with. You can find this by editing the group in the AdminCP, and making a note of the id parameter in the URL. On my installation, the Administrator group is ID 4 so we'll use that in our example.
Once again, we're using the \IPS\Member::loggedIn() object, but this time we're using the member_group_id property.
{{if \IPS\Member::loggedIn()->member_group_id === 4}} This content only shows to members in the "Administrators" group (ID 4 in our example) {{endif}}  
Working with multiple groups at once
Following the code above, you could simply repeat the check against \IPS\Member::loggedIn()->member_group_id several times, for each ID you want to allow. However, since our templates allow arbitrary PHP expressions to be used, there's a neater way: use an array of member group IDs you want to allow, and check against that using PHP's in_array function. Here's an example where we only show content to group IDs 2, 4 and 6:
{{if in_array( \IPS\Member::loggedIn()->member_group_id, array( 2, 4, 6 ) )}} This content only shows to members in groups with the ID 2, 4 or 6. {{endif}}  
Have a request for a theme tip? Let us know in the comments and we'll try and help out in a future tip! 

HTML Logic is our name for the additional tags available in IPS4's templates that allow runtime logic to be executed. It comprises if/then/else statements as well as loops and more.
Since HTML Logic has access to all of the underlying PHP framework in IPS4, it's very powerful and a lot can be achieved with it. One common use is to limit certain content within a template to particular member groups. Let's see how that might be done.
 
Showing or hiding content only to guests
We'll first look at a simpler idea: showing or hiding content specifically to guests (i.e. anyone who isn't logged in). Within IPS4, the \IPS\Member::loggedIn() object contains information about the current user. Guests always have a member_id of NULL (i.e. no value), so we can simply check that value in our logic tag:
{{if \IPS\Member::loggedIn()->member_id === NULL}} This content *only* shows to guests, since they have a NULL member_id. {{endif}} {{if \IPS\Member::loggedIn()->member_id}} This content *only* shows to logged-in users since their member_id is a number, which will equal true. {{endif}}  
Showing content only to specific groups
Let's go a bit further and this time show content to specific (primary) member groups. First, you need to get the IDs for the group(s) you want to deal with. You can find this by editing the group in the AdminCP, and making a note of the id parameter in the URL. On my installation, the Administrator group is ID 4 so we'll use that in our example.
Once again, we're using the \IPS\Member::loggedIn() object, but this time we're using the member_group_id property.
{{if \IPS\Member::loggedIn()->member_group_id === 4}} This content only shows to members in the "Administrators" group (ID 4 in our example) {{endif}}  
Working with multiple groups at once
Following the code above, you could simply repeat the check against \IPS\Member::loggedIn()->member_group_id several times, for each ID you want to allow. However, since our templates allow arbitrary PHP expressions to be used, there's a neater way: use an array of member group IDs you want to allow, and check against that using PHP's in_array function. Here's an example where we only show content to group IDs 2, 4 and 6:
{{if in_array( \IPS\Member::loggedIn()->member_group_id, array( 2, 4, 6 ) )}} This content only shows to members in groups with the ID 2, 4 or 6. {{endif}}  
Have a request for a theme tip? Let us know in the comments and we'll try and help out in a future tip! 

HTML Logic is our name for the additional tags available in IPS4's templates that allow runtime logic to be executed. It comprises if/then/else statements as well as loops and more.
Since HTML Logic has access to all of the underlying PHP framework in IPS4, it's very powerful and a lot can be achieved with it. One common use is to limit certain content within a template to particular member groups. Let's see how that might be done.
 
Showing or hiding content only to guests
We'll first look at a simpler idea: showing or hiding content specifically to guests (i.e. anyone who isn't logged in). Within IPS4, the \IPS\Member::loggedIn() object contains information about the current user. Guests always have a member_id of NULL (i.e. no value), so we can simply check that value in our logic tag:
{{if \IPS\Member::loggedIn()->member_id === NULL}} This content *only* shows to guests, since they have a NULL member_id. {{endif}} {{if \IPS\Member::loggedIn()->member_id}} This content *only* shows to logged-in users since their member_id is a number, which will equal true. {{endif}}  
Showing content only to specific groups
Let's go a bit further and this time show content to specific (primary) member groups. First, you need to get the IDs for the group(s) you want to deal with. You can find this by editing the group in the AdminCP, and making a note of the id parameter in the URL. On my installation, the Administrator group is ID 4 so we'll use that in our example.
Once again, we're using the \IPS\Member::loggedIn() object, but this time we're using the member_group_id property.
{{if \IPS\Member::loggedIn()->member_group_id === 4}} This content only shows to members in the "Administrators" group (ID 4 in our example) {{endif}}  
Working with multiple groups at once
Following the code above, you could simply repeat the check against \IPS\Member::loggedIn()->member_group_id several times, for each ID you want to allow. However, since our templates allow arbitrary PHP expressions to be used, there's a neater way: use an array of member group IDs you want to allow, and check against that using PHP's in_array function. Here's an example where we only show content to group IDs 2, 4 and 6:
{{if in_array( \IPS\Member::loggedIn()->member_group_id, array( 2, 4, 6 ) )}} This content only shows to members in groups with the ID 2, 4 or 6. {{endif}}  
Have a request for a theme tip? Let us know in the comments and we'll try and help out in a future tip! 

Reminder: this blog covers the technical details of 4.0's programming. For details on 4.0's features, follow our main blog.

Reviewing controllers

Some time ago, I blogged about the javascript framework we've built for IPS4. In it, I covered the most important component: controllers. To recap, a controller is a special object within the framework, and is applied on specific elements. That element is the controller's scope, and the controller works on it to provide its functionality. For example, a simple controller might look like this:

ips.controller.register('core.global.core.example', { initialize: function () { this.on( 'click', this.showAlert ); }, showAlert: function (e) { alert( "This button's text is: " + this.scope.html() ); } });
It would be used on an element like so:

<button data-controller='core.global.core.example'>Click me</button>
Here we're registering core.global.core.example as a controller. This represents the controller path - it's in the format app.module.group.controllerName. Though it seems longwinded, this allows IPS4 to dynamically load controllers on-demand, rather than loading them all when the page is loaded. In the initialize method (called automatically), we set up an event handler for a click. When the element is clicked, you'd see an alert saying "This button's text is: Click me".

So, that's how controllers work. Almost all page behavior in IPS4 is handled through controllers. But how would you change a method in an existing controller, say if you were writing an addon, or if you had two controllers that were fairly similar, and wanted to provide a base controller they both shared?

Mixins

To enable that, we have mixins. Mixins allow you to specify functions which are inherited by objects - in this case, our controller objects. This means, using mixins we can add new functions to a controller without needing to edit the controller itself.

A mixin is defined like so:

ips.controller.mixin('addAnotherMethod', 'core.global.core.example', true, function () { this.anotherMethod = function () { alert('Inside anotherMethod'); }; });
The ips.controller.mixin method takes up to 4 parameters:

ips.controller.mixin( name, controller, automaticallyExtend, fnDefinition )
name: Name to identify this mixin
controller: The controller this mixin extends
automaticallyExtend: [optional, default false] Does this mixin automatically extend the controller (more on that below)
fnDetinition: The function definition applied to the controller

In this example, our mixin adds a method named anotherMethod to our core.global.core.example controller shown earlier.

Let's talk more about the automaticallyExtend parameter. Mixins can be applied to controllers in one of two ways - either automatically on a global basis, or manually on a case-by-case basis. Mixins are manually specified like so:

<button data-controller='core.global.core.example( addAnotherMethod )'>Click me</button>
This means the mixin is used on this element - but another element using core.global.core.example wouldn't get it. This is useful when you're building your own apps or addons; you can write simple controllers that implement base functionality, then extend them with functionality for specific cases by specifying the mixin name in your HTML. We use this ourselves - for example, we have a base table controller that handles sorting, filtering and so forth. We then have a mixin for AdminCP tables, and a mixin for front-end tables, which add functionality specific to those areas, reducing code duplication.

If you're extending an IPS controller in an IPS app, though, modifying the HTML isn't typically an option. Instead, you can specify the mixin as global, and it will be applied to all elements where that controller is used. This means you can write your own mixins that work with our default controllers without having to touch our controller code (and that's a good thing).

Advice

So that shows how to add new methods to a controller. But what if you want to work with the methods that already exist in the controller? In the above example you'd only be able to overwrite an existing method - certainly not ideal, because 1) you would break any other mixins using the default method, 2) if we made an update to a method in a later release, your mixin would break it.

To facilitate working with existing controller methods, we're using a model called advice. This adds three special methods to a mixin: before, after and around. These let you 'hook into' existing methods and provide additional code for them. Let's rewrite our example mixin from above to take advantage of it:

ips.controller.mixin('changeBackground', 'core.global.core.example', function () { this.before('showAlert', function () { this.scope.css({ background: 'red' }); }; });
Here, I'm using the before method. I'm hooking into showAlert method (from the controller), and changing the background color of the scope element. So what happens when the link is clicked? First the background changes to red, and then an alert box is shown. We've added the background changing functionality without needing to edit the controller at all. Here's two other ways of doing the same thing, using the other two special methods:

ips.controller.mixin('changeBackground', 'core.global.core.example', function () { this.after('showAlert', function () { this.scope.css({ background: 'red' }); }; this.around('showAlert', function (origFn) { this.scope.css({ background: 'red' }); origFn(); }; });
The after method is fairly self-evident. With the around method, the original function is passed in as an argument, allowing you to determine when it is executed by your mixin.

All three of these methods will stack, so multiple mixins can hook into the same method, and they'll be executed in order, each receiving the previous.

Conclusion

I hope this introduction to mixins proves useful to developers; it shows how our core app controllers can be extended in a non-destructive way, but also how your own apps can use the mixin functionality to create an inheritance model to make your life easier.

Javascript in IPS4 makes extensive use of custom events, so the preferred way of adding new functionality is to listen for appropriate events and act on them - but the mixin support described above provides a mechanism by which you can adapt existing event handlers.

HTML Logic is our name for the additional tags available in IPS4's templates that allow runtime logic to be executed. It comprises if/then/else statements as well as loops and more.
Since HTML Logic has access to all of the underlying PHP framework in IPS4, it's very powerful and a lot can be achieved with it. One common use is to limit certain content within a template to particular member groups. Let's see how that might be done.
 
Showing or hiding content only to guests
We'll first look at a simpler idea: showing or hiding content specifically to guests (i.e. anyone who isn't logged in). Within IPS4, the \IPS\Member::loggedIn() object contains information about the current user. Guests always have a member_id of NULL (i.e. no value), so we can simply check that value in our logic tag:
{{if \IPS\Member::loggedIn()->member_id === NULL}} This content *only* shows to guests, since they have a NULL member_id. {{endif}} {{if \IPS\Member::loggedIn()->member_id}} This content *only* shows to logged-in users since their member_id is a number, which will equal true. {{endif}}  
Showing content only to specific groups
Let's go a bit further and this time show content to specific (primary) member groups. First, you need to get the IDs for the group(s) you want to deal with. You can find this by editing the group in the AdminCP, and making a note of the id parameter in the URL. On my installation, the Administrator group is ID 4 so we'll use that in our example.
Once again, we're using the \IPS\Member::loggedIn() object, but this time we're using the member_group_id property.
{{if \IPS\Member::loggedIn()->member_group_id === 4}} This content only shows to members in the "Administrators" group (ID 4 in our example) {{endif}}  
Working with multiple groups at once
Following the code above, you could simply repeat the check against \IPS\Member::loggedIn()->member_group_id several times, for each ID you want to allow. However, since our templates allow arbitrary PHP expressions to be used, there's a neater way: use an array of member group IDs you want to allow, and check against that using PHP's in_array function. Here's an example where we only show content to group IDs 2, 4 and 6:
{{if in_array( \IPS\Member::loggedIn()->member_group_id, array( 2, 4, 6 ) )}} This content only shows to members in groups with the ID 2, 4 or 6. {{endif}}  
Have a request for a theme tip? Let us know in the comments and we'll try and help out in a future tip! 

HTML Logic is our name for the additional tags available in IPS4's templates that allow runtime logic to be executed. It comprises if/then/else statements as well as loops and more.
Since HTML Logic has access to all of the underlying PHP framework in IPS4, it's very powerful and a lot can be achieved with it. One common use is to limit certain content within a template to particular member groups. Let's see how that might be done.
 
Showing or hiding content only to guests
We'll first look at a simpler idea: showing or hiding content specifically to guests (i.e. anyone who isn't logged in). Within IPS4, the \IPS\Member::loggedIn() object contains information about the current user. Guests always have a member_id of NULL (i.e. no value), so we can simply check that value in our logic tag:
{{if \IPS\Member::loggedIn()->member_id === NULL}} This content *only* shows to guests, since they have a NULL member_id. {{endif}} {{if \IPS\Member::loggedIn()->member_id}} This content *only* shows to logged-in users since their member_id is a number, which will equal true. {{endif}}  
Showing content only to specific groups
Let's go a bit further and this time show content to specific (primary) member groups. First, you need to get the IDs for the group(s) you want to deal with. You can find this by editing the group in the AdminCP, and making a note of the id parameter in the URL. On my installation, the Administrator group is ID 4 so we'll use that in our example.
Once again, we're using the \IPS\Member::loggedIn() object, but this time we're using the member_group_id property.
{{if \IPS\Member::loggedIn()->member_group_id === 4}} This content only shows to members in the "Administrators" group (ID 4 in our example) {{endif}}  
Working with multiple groups at once
Following the code above, you could simply repeat the check against \IPS\Member::loggedIn()->member_group_id several times, for each ID you want to allow. However, since our templates allow arbitrary PHP expressions to be used, there's a neater way: use an array of member group IDs you want to allow, and check against that using PHP's in_array function. Here's an example where we only show content to group IDs 2, 4 and 6:
{{if in_array( \IPS\Member::loggedIn()->member_group_id, array( 2, 4, 6 ) )}} This content only shows to members in groups with the ID 2, 4 or 6. {{endif}}  
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!

HTML Logic is our name for the additional tags available in IPS4's templates that allow runtime logic to be executed. It comprises if/then/else statements as well as loops and more.
Since HTML Logic has access to all of the underlying PHP framework in IPS4, it's very powerful and a lot can be achieved with it. One common use is to limit certain content within a template to particular member groups. Let's see how that might be done.
 
Showing or hiding content only to guests
We'll first look at a simpler idea: showing or hiding content specifically to guests (i.e. anyone who isn't logged in). Within IPS4, the \IPS\Member::loggedIn() object contains information about the current user. Guests always have a member_id of NULL (i.e. no value), so we can simply check that value in our logic tag:
{{if \IPS\Member::loggedIn()->member_id === NULL}} This content *only* shows to guests, since they have a NULL member_id. {{endif}} {{if \IPS\Member::loggedIn()->member_id}} This content *only* shows to logged-in users since their member_id is a number, which will equal true. {{endif}}  
Showing content only to specific groups
Let's go a bit further and this time show content to specific (primary) member groups. First, you need to get the IDs for the group(s) you want to deal with. You can find this by editing the group in the AdminCP, and making a note of the id parameter in the URL. On my installation, the Administrator group is ID 4 so we'll use that in our example.
Once again, we're using the \IPS\Member::loggedIn() object, but this time we're using the member_group_id property.
{{if \IPS\Member::loggedIn()->member_group_id === 4}} This content only shows to members in the "Administrators" group (ID 4 in our example) {{endif}}  
Working with multiple groups at once
Following the code above, you could simply repeat the check against \IPS\Member::loggedIn()->member_group_id several times, for each ID you want to allow. However, since our templates allow arbitrary PHP expressions to be used, there's a neater way: use an array of member group IDs you want to allow, and check against that using PHP's in_array function. Here's an example where we only show content to group IDs 2, 4 and 6:
{{if in_array( \IPS\Member::loggedIn()->member_group_id, array( 2, 4, 6 ) )}} This content only shows to members in groups with the ID 2, 4 or 6. {{endif}}  
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! 
 

HTML Logic is our name for the additional tags available in IPS4's templates that allow runtime logic to be executed. It comprises if/then/else statements as well as loops and more.
Since HTML Logic has access to all of the underlying PHP framework in IPS4, it's very powerful and a lot can be achieved with it. One common use is to limit certain content within a template to particular member groups. Let's see how that might be done.
 
Showing or hiding content only to guests
We'll first look at a simpler idea: showing or hiding content specifically to guests (i.e. anyone who isn't logged in). Within IPS4, the \IPS\Member::loggedIn() object contains information about the current user. Guests always have a member_id of NULL (i.e. no value), so we can simply check that value in our logic tag:
{{if \IPS\Member::loggedIn()->member_id === NULL}} This content *only* shows to guests, since they have a NULL member_id. {{endif}} {{if \IPS\Member::loggedIn()->member_id}} This content *only* shows to logged-in users since their member_id is a number, which will equal true. {{endif}}  
Showing content only to specific groups
Let's go a bit further and this time show content to specific (primary) member groups. First, you need to get the IDs for the group(s) you want to deal with. You can find this by editing the group in the AdminCP, and making a note of the id parameter in the URL. On my installation, the Administrator group is ID 4 so we'll use that in our example.
Once again, we're using the \IPS\Member::loggedIn() object, but this time we're using the member_group_id property.
{{if \IPS\Member::loggedIn()->member_group_id === 4}} This content only shows to members in the "Administrators" group (ID 4 in our example) {{endif}}  
Working with multiple groups at once
Following the code above, you could simply repeat the check against \IPS\Member::loggedIn()->member_group_id several times, for each ID you want to allow. However, since our templates allow arbitrary PHP expressions to be used, there's a neater way: use an array of member group IDs you want to allow, and check against that using PHP's in_array function. Here's an example where we only show content to group IDs 2, 4 and 6:
{{if in_array( \IPS\Member::loggedIn()->member_group_id, array( 2, 4, 6 ) )}} This content only shows to members in groups with the ID 2, 4 or 6. {{endif}}  
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!

Security should never be an afterthought for your community. All too often, site owners consider beefing up their security only when it's too late and their community has already been compromised. Taking some time now to check and improve the security of your community and server could pay dividends by eliminating the cost and hassle of falling victim to hacking in the first place.
Let's run down 7 ways that you can protect your community with the IPS Community Suite, from security features you may not know about to best practices all communities should be following.
 
1. Be selective when adding administrators
Administrator permissions can be extremely damaging in the wrong hands, and granting administrator powers should only be done with great consideration. Granting access to the AdminCP is like handing someone the keys to your house, so before doing so, be sure you really trust the person and that their role requires access to the AdminCP (for example, would moderator permissions be sufficient for the new staff member?).
Don't forget to remove administrator access promptly when necessary too, such as the member of staff leaving your organization. Always be aware of exactly who has administrator access at any given time, and review regularly. You can list all accounts that have AdminCP access by clicking the List Administrators button on the System -> Security page.
2. Utilize Admin Restrictions
In many organizations, staff roles within the community reflect real-world roles - designers need access to templates, accounting needs access to billing, and so forth. IPS4 allows you to limit administrator access to very specific areas of the AdminCP with the Admin Restrictions feature, and even limit what can be done within those areas. This is a great approach for limiting risk to your data; by giving staff members access to only the areas they need to perform their duties, you reduce the potential impact should their account become compromised in future.
3. Choose good passwords
This seems like an obvious suggestion, but surveys regularly show that people choose passwords that are simply too easy to guess or brute force. Your password is naturally the most basic protection of your AdminCP there is, so making sure you're using a good password is essential.
We recommend using a password manager application such as 1password or LastPass. These applications generate strong, random passwords for each site you use, and store them so that you don't have to remember them.
Even if you don't use a password manager, make sure the passwords you use for your community are unique and never used for others sites too.
4. Stay up to date
It's a fact of software development that from time to time new security issues are reported and promptly fixed. But if you're running several versions behind, once security issues are made public through responsible disclosure, malicious users can exploit those weaknesses in your community.
When we release new updates - especially if they're marked as a security release in our release notes - be sure to update as promptly as you can so you receive the latest fixes. Your AdminCP will also let you know when a new version is ready for download.
5. Use .htaccess protection for your AdminCP
In addition to IPS4's own AdminCP login page, you can set up browser-level authentication, giving you a double layer of protection. This is done via a special .htaccess file which instructs the server to prompt for authentication before access to the page is granted. IPS4 can automatically generate this file for you - simply go to System -> Security in your AdminCP, and enable the "Add a secondary admin password" rule.
And it should go without saying, but to be clear: don't use the same username or password for both your .htaccess login and your admin account, or the measure is redundant!
6. Restrict your AdminCP to an IP range where possible
If your organization has a static IP or requires staff members to use a VPN, you can add an additional layer of security to your community by prohibiting access to the AdminCP unless the user's IP matches your whitelist. This is a server-level feature, so consult your IT team or host to find out how to set it up in your particular environment. If you're a Community in the Cloud customer, contact our support team if you'd like to set up this protection for your account.
7. Properly secure your PHP installation
Many of PHP's built-in functions can leave a server vulnerable to high-impact exploits, and yet many of these functions aren't needed by the vast majority of PHP applications you might run. We therefore recommend that you explicitly disable these functions using PHP's disable_functions configuration setting. Here's our recommended configuration, although you or your host may need to tweak the list depending on your exact needs:
disable_functions = escapeshellarg,escapeshellcmd,exec,ini_alter,parse_ini_file,passthru,pcntl_exec,popen,proc_close,proc_get_status,proc_nice,proc_open,proc_terminate,show_source,shell_exec,symlink,system Another critical PHP configuration setting you need to check is that open_basedir is enabled, especially if you're hosted on a server that also hosts other websites (known as shared hosting). If another account on the server is comprised and open_basedir is disabled, the attacker can potentially gain access to your files too.
Naturally, Community in the Cloud customers needn't worry about either of these steps - we've already handled it for you!
 
So there we go - a brief overview of 7 common-sense ways you can better protect your community and its users. As software developers, we're constantly working to improve the behind-the-scenes security of our software, but as an administrator, there's also a number of steps you should take to keep your community safe on the web.
If you have any tips related to security, be sure to share them in the comments!

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

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

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!

Our Pages app includes a powerful feature that allows you to create your own databases within the community. Within each database, you create custom fields (we support a number of custom types, from plain text fields, to YouTube embeds and more). And while we provide some generic, simple templates to display your data, custom templates allow you to more precisely control how your database looks in a manner best suited to your site.
Anyone who has created a Pages database will be familiar with using custom fields. You may have created a field for the title of your item, or an upload field so that the item contains a file for users to download. But beyond these straightforward uses, I wanted to explore some more advanced uses of custom fields. Fields don't necessarily have to be displayed to the user - or at least not in the usual way. We can use them as configuration options for our record display, or manipulate the data in order to show it in a different way. Let's take a look at some examples.
 
1. Adding an optional badge to records
We'll start with a fairly simple example. In our Guides section, we highlight guides that have a video tutorial by showing an 'Includes Video Guide' label on the listing:

We achieve this simply by having a Yes/No field that we turn on as needed. In the field format, we turn the Yes/No value into the label by setting the format to Custom and using this code:
{{if $formValue == 1}} <span class='ipsType_medium'><i class='fa fa-video-camera'></i> <strong>Includes Video Guide</strong></span> {{endif}}  
2. Using fields as a way to configure the record display
Fields don't necessarily need to be shown to users. Instead, we can use them as a means to configure the record display, giving us some really powerful flexibility in how we show records. In this contrived example, I'm going to create a field that changes the background color of the content.
Create a Select Box field. Each option key will be a hex color, while the value will be the name the record creator will choose. Set the field key to record_background Set the field formatting to Custom, and the format to simply: {$formValue}. This means it will output our hex value instead of the color name. In the display template assigned to this database for records, we can use the field like so: <div style='background-color: #{$record->customFieldDisplayByKey('record_background', 'listing')|raw}' class='ipsPad'> ...rest of the template... </div> Now, when you create a record, you can choose a color and that color will be used when the record is shown:
You can use this approach in others ways - toggles to control the layout of the record, or options for grid sizes, or even take an upload field for images and set the background of an element as that image.
 
3. Pass data to 3rd-party integrations
Pages has built-in support for several 3rd party integrations, such as Spotify, Soundcloud, YouTube and Google Maps. But using custom fields, you can pass data to other services too. Let's say we wanted to embed an iTunes album widget into each of our records - perhaps the album is relevant to the Pages record in some way and we hope to encourage some click-throughs. In this example, we'll use the embed.ly service. 
Create a URL custom field. Set the field key to itunes_album Set the field formatting to Custom, and the format to: <a class="embedly-card" href="{$formValue}">iTunes Album</a> <script async src="//cdn.embedly.com/widgets/platform.js" charset="UTF-8"></script> In your database display template, position the field as desired by adding: {$record->customFieldDisplayByKey('itunes_album', 'listing')|raw} Now when you add an iTunes album link to your record, you'll get an embed automatically!

This approach is great for a range of uses. Perhaps you have an Amazon Associates account and want to add a relevant product link to each of your records so that you earn a commission when users click through. Using database fields and templates in this way, it's easy to set up.
 
I hope that's given you some ideas of other ways you might use database fields in Pages. Share any interesting uses you've come up with in the comments!

Our Pages app includes a powerful feature that allows you to create your own databases within the community. Within each database, you create custom fields (we support a number of custom types, from plain text fields, to YouTube embeds and more). And while we provide some generic, simple templates to display your data, custom templates allow you to more precisely control how your database looks in a manner best suited to your site.
Anyone who has created a Pages database will be familiar with using custom fields. You may have created a field for the title of your item, or an upload field so that the item contains a file for users to download. But beyond these straightforward uses, I wanted to explore some more advanced uses of custom fields. Fields don't necessarily have to be displayed to the user - or at least not in the usual way. We can use them as configuration options for our record display, or manipulate the data in order to show it in a different way. Let's take a look at some examples.
 
1. Adding an optional badge to records
We'll start with a fairly simple example. In our Guides section, we highlight guides that have a video tutorial by showing an 'Includes Video Guide' label on the listing:

We achieve this simply by having a Yes/No field that we turn on as needed. In the field format, we turn the Yes/No value into the label by setting the format to Custom and using this code:
{{if $formValue == 1}} <span class='ipsType_medium'><i class='fa fa-video-camera'></i> <strong>Includes Video Guide</strong></span> {{endif}}  
2. Using fields as a way to configure the record display
Fields don't necessarily need to be shown to users. Instead, we can use them as a means to configure the record display, giving us some really powerful flexibility in how we show records. In this contrived example, I'm going to create a field that changes the background color of the content.
Create a Select Box field. Each option key will be a hex color, while the value will be the name the record creator will choose. Set the field key to record_background Set the field formatting to Custom, and the format to simply: {$formValue}. This means it will output our hex value instead of the color name. In the display template assigned to this database for records, we can use the field like so: <div style='background-color: #{$record->customFieldDisplayByKey('record_background', 'listing')|raw}' class='ipsPad'> ...rest of the template... </div> Now, when you create a record, you can choose a color and that color will be used when the record is shown:
You can use this approach in others ways - toggles to control the layout of the record, or options for grid sizes, or even take an upload field for images and set the background of an element as that image.
 
3. Pass data to 3rd-party integrations
Pages has built-in support for several 3rd party integrations, such as Spotify, Soundcloud, YouTube and Google Maps. But using custom fields, you can pass data to other services too. Let's say we wanted to embed an iTunes album widget into each of our records - perhaps the album is relevant to the Pages record in some way and we hope to encourage some click-throughs. In this example, we'll use the embed.ly service. 
Create a URL custom field. Set the field key to itunes_album Set the field formatting to Custom, and the format to: <a class="embedly-card" href="{$formValue}">iTunes Album</a> <script async src="//cdn.embedly.com/widgets/platform.js" charset="UTF-8"></script> In your database display template, position the field as desired by adding: {$record->customFieldDisplayByKey('itunes_album', 'listing')|raw} Now when you add an iTunes album link to your record, you'll get an embed automatically!

This approach is great for a range of uses. Perhaps you have an Amazon Associates account and want to add a relevant product link to each of your records so that you earn a commission when users click through. Using database fields and templates in this way, it's easy to set up.
 
I hope that's given you some ideas of other ways you might use database fields in Pages. Share any interesting uses you've come up with in the comments!

Our Pages app includes a powerful feature that allows you to create your own databases within the community. Within each database, you create custom fields (we support a number of custom types, from plain text fields, to YouTube embeds and more). And while we provide some generic, simple templates to display your data, custom templates allow you to more precisely control how your database looks in a manner best suited to your site.
Anyone who has created a Pages database will be familiar with using custom fields. You may have created a field for the title of your item, or an upload field so that the item contains a file for users to download. But beyond these straightforward uses, I wanted to explore some more advanced uses of custom fields. Fields don't necessarily have to be displayed to the user - or at least not in the usual way. We can use them as configuration options for our record display, or manipulate the data in order to show it in a different way. Let's take a look at some examples.
 
1. Adding an optional badge to records
We'll start with a fairly simple example. In our Guides section, we highlight guides that have a video tutorial by showing an 'Includes Video Guide' label on the listing:

We achieve this simply by having a Yes/No field that we turn on as needed. In the field format, we turn the Yes/No value into the label by setting the format to Custom and using this code:
{{if $formValue == 1}} <span class='ipsType_medium'><i class='fa fa-video-camera'></i> <strong>Includes Video Guide</strong></span> {{endif}}  
2. Using fields as a way to configure the record display
Fields don't necessarily need to be shown to users. Instead, we can use them as a means to configure the record display, giving us some really powerful flexibility in how we show records. In this contrived example, I'm going to create a field that changes the background color of the content.
Create a Select Box field. Each option key will be a hex color, while the value will be the name the record creator will choose. Set the field key to record_background Set the field formatting to Custom, and the format to simply: {$formValue}. This means it will output our hex value instead of the color name. In the display template assigned to this database for records, we can use the field like so: <div style='background-color: #{$record->customFieldDisplayByKey('record_background', 'listing')|raw}' class='ipsPad'> ...rest of the template... </div> Now, when you create a record, you can choose a color and that color will be used when the record is shown:
You can use this approach in others ways - toggles to control the layout of the record, or options for grid sizes, or even take an upload field for images and set the background of an element as that image.
 
3. Pass data to 3rd-party integrations
Pages has built-in support for several 3rd party integrations, such as Spotify, Soundcloud, YouTube and Google Maps. But using custom fields, you can pass data to other services too. Let's say we wanted to embed an iTunes album widget into each of our records - perhaps the album is relevant to the Pages record in some way and we hope to encourage some click-throughs. In this example, we'll use the embed.ly service. 
Create a URL custom field. Set the field key to itunes_album Set the field formatting to Custom, and the format to: <a class="embedly-card" href="{$formValue}">iTunes Album</a> <script async src="//cdn.embedly.com/widgets/platform.js" charset="UTF-8"></script> In your database display template, position the field as desired by adding: {$record->customFieldDisplayByKey('itunes_album', 'listing')|raw} Now when you add an iTunes album link to your record, you'll get an embed automatically!

This approach is great for a range of uses. Perhaps you have an Amazon Associates account and want to add a relevant product link to each of your records so that you earn a commission when users click through. Using database fields and templates in this way, it's easy to set up.
 
I hope that's given you some ideas of other ways you might use database fields in Pages. Share any interesting uses you've come up with in the comments!

Our Pages app includes a powerful feature that allows you to create your own databases within the community. Within each database, you create custom fields (we support a number of custom types, from plain text fields, to YouTube embeds and more). And while we provide some generic, simple templates to display your data, custom templates allow you to more precisely control how your database looks in a manner best suited to your site.
Anyone who has created a Pages database will be familiar with using custom fields. You may have created a field for the title of your item, or an upload field so that the item contains a file for users to download. But beyond these straightforward uses, I wanted to explore some more advanced uses of custom fields. Fields don't necessarily have to be displayed to the user - or at least not in the usual way. We can use them as configuration options for our record display, or manipulate the data in order to show it in a different way. Let's take a look at some examples.
 
1. Adding an optional badge to records
We'll start with a fairly simple example. In our Guides section, we highlight guides that have a video tutorial by showing an 'Includes Video Guide' label on the listing:

We achieve this simply by having a Yes/No field that we turn on as needed. In the field format, we turn the Yes/No value into the label by setting the format to Custom and using this code:
{{if $formValue == 1}} <span class='ipsType_medium'><i class='fa fa-video-camera'></i> <strong>Includes Video Guide</strong></span> {{endif}}  
2. Using fields as a way to configure the record display
Fields don't necessarily need to be shown to users. Instead, we can use them as a means to configure the record display, giving us some really powerful flexibility in how we show records. In this contrived example, I'm going to create a field that changes the background color of the content.
Create a Select Box field. Each option key will be a hex color, while the value will be the name the record creator will choose. Set the field key to record_background Set the field formatting to Custom, and the format to simply: {$formValue}. This means it will output our hex value instead of the color name. In the display template assigned to this database for records, we can use the field like so: <div style='background-color: #{$record->customFieldDisplayByKey('record_background', 'listing')|raw}' class='ipsPad'> ...rest of the template... </div> Now, when you create a record, you can choose a color and that color will be used when the record is shown:
You can use this approach in others ways - toggles to control the layout of the record, or options for grid sizes, or even take an upload field for images and set the background of an element as that image.
 
3. Pass data to 3rd-party integrations
Pages has built-in support for several 3rd party integrations, such as Spotify, Soundcloud, YouTube and Google Maps. But using custom fields, you can pass data to other services too. Let's say we wanted to embed an iTunes album widget into each of our records - perhaps the album is relevant to the Pages record in some way and we hope to encourage some click-throughs. In this example, we'll use the embed.ly service. 
Create a URL custom field. Set the field key to itunes_album Set the field formatting to Custom, and the format to: <a class="embedly-card" href="{$formValue}">iTunes Album</a> <script async src="//cdn.embedly.com/widgets/platform.js" charset="UTF-8"></script> In your database display template, position the field as desired by adding: {$record->customFieldDisplayByKey('itunes_album', 'listing')|raw} Now when you add an iTunes album link to your record, you'll get an embed automatically!

This approach is great for a range of uses. Perhaps you have an Amazon Associates account and want to add a relevant product link to each of your records so that you earn a commission when users click through. Using database fields and templates in this way, it's easy to set up.
 
I hope that's given you some ideas of other ways you might use database fields in Pages. Share any interesting uses you've come up with in the comments!

Our Pages app includes a powerful feature that allows you to create your own databases within the community. Within each database, you create custom fields (we support a number of custom types, from plain text fields, to YouTube embeds and more). And while we provide some generic, simple templates to display your data, custom templates allow you to more precisely control how your database looks in a manner best suited to your site.
Anyone who has created a Pages database will be familiar with using custom fields. You may have created a field for the title of your item, or an upload field so that the item contains a file for users to download. But beyond these straightforward uses, I wanted to explore some more advanced uses of custom fields. Fields don't necessarily have to be displayed to the user - or at least not in the usual way. We can use them as configuration options for our record display, or manipulate the data in order to show it in a different way. Let's take a look at some examples.
 
1. Adding an optional badge to records
We'll start with a fairly simple example. In our Guides section, we highlight guides that have a video tutorial by showing an 'Includes Video Guide' label on the listing:

We achieve this simply by having a Yes/No field that we turn on as needed. In the field format, we turn the Yes/No value into the label by setting the format to Custom and using this code:
{{if $formValue == 1}} <span class='ipsType_medium'><i class='fa fa-video-camera'></i> <strong>Includes Video Guide</strong></span> {{endif}}  
2. Using fields as a way to configure the record display
Fields don't necessarily need to be shown to users. Instead, we can use them as a means to configure the record display, giving us some really powerful flexibility in how we show records. In this contrived example, I'm going to create a field that changes the background color of the content.
Create a Select Box field. Each option key will be a hex color, while the value will be the name the record creator will choose. Set the field key to record_background Set the field formatting to Custom, and the format to simply: {$formValue}. This means it will output our hex value instead of the color name. In the display template assigned to this database for records, we can use the field like so: <div style='background-color: #{$record->customFieldDisplayByKey('record_background', 'listing')|raw}' class='ipsPad'> ...rest of the template... </div> Now, when you create a record, you can choose a color and that color will be used when the record is shown:
You can use this approach in others ways - toggles to control the layout of the record, or options for grid sizes, or even take an upload field for images and set the background of an element as that image.
 
3. Pass data to 3rd-party integrations
Pages has built-in support for several 3rd party integrations, such as Spotify, Soundcloud, YouTube and Google Maps. But using custom fields, you can pass data to other services too. Let's say we wanted to embed an iTunes album widget into each of our records - perhaps the album is relevant to the Pages record in some way and we hope to encourage some click-throughs. In this example, we'll use the embed.ly service. 
Create a URL custom field. Set the field key to itunes_album Set the field formatting to Custom, and the format to: <a class="embedly-card" href="{$formValue}">iTunes Album</a> <script async src="//cdn.embedly.com/widgets/platform.js" charset="UTF-8"></script> In your database display template, position the field as desired by adding: {$record->customFieldDisplayByKey('itunes_album', 'listing')|raw} Now when you add an iTunes album link to your record, you'll get an embed automatically!

This approach is great for a range of uses. Perhaps you have an Amazon Associates account and want to add a relevant product link to each of your records so that you earn a commission when users click through. Using database fields and templates in this way, it's easy to set up.
 
I hope that's given you some ideas of other ways you might use database fields in Pages. Share any interesting uses you've come up with in the comments!

Our Pages app includes a powerful feature that allows you to create your own databases within the community. Within each database, you create custom fields (we support a number of custom types, from plain text fields, to YouTube embeds and more). And while we provide some generic, simple templates to display your data, custom templates allow you to more precisely control how your database looks in a manner best suited to your site.
Anyone who has created a Pages database will be familiar with using custom fields. You may have created a field for the title of your item, or an upload field so that the item contains a file for users to download. But beyond these straightforward uses, I wanted to explore some more advanced uses of custom fields. Fields don't necessarily have to be displayed to the user - or at least not in the usual way. We can use them as configuration options for our record display, or manipulate the data in order to show it in a different way. Let's take a look at some examples.
 
1. Adding an optional badge to records
We'll start with a fairly simple example. In our Guides section, we highlight guides that have a video tutorial by showing an 'Includes Video Guide' label on the listing:

We achieve this simply by having a Yes/No field that we turn on as needed. In the field format, we turn the Yes/No value into the label by setting the format to Custom and using this code:
{{if $formValue == 1}} <span class='ipsType_medium'><i class='fa fa-video-camera'></i> <strong>Includes Video Guide</strong></span> {{endif}}  
2. Using fields as a way to configure the record display
Fields don't necessarily need to be shown to users. Instead, we can use them as a means to configure the record display, giving us some really powerful flexibility in how we show records. In this contrived example, I'm going to create a field that changes the background color of the content.
Create a Select Box field. Each option key will be a hex color, while the value will be the name the record creator will choose. Set the field key to record_background Set the field formatting to Custom, and the format to simply: {$formValue}. This means it will output our hex value instead of the color name. In the display template assigned to this database for records, we can use the field like so: <div style='background-color: #{$record->customFieldDisplayByKey('record_background', 'listing')|raw}' class='ipsPad'> ...rest of the template... </div> Now, when you create a record, you can choose a color and that color will be used when the record is shown:
You can use this approach in others ways - toggles to control the layout of the record, or options for grid sizes, or even take an upload field for images and set the background of an element as that image.
 
3. Pass data to 3rd-party integrations
Pages has built-in support for several 3rd party integrations, such as Spotify, Soundcloud, YouTube and Google Maps. But using custom fields, you can pass data to other services too. Let's say we wanted to embed an iTunes album widget into each of our records - perhaps the album is relevant to the Pages record in some way and we hope to encourage some click-throughs. In this example, we'll use the embed.ly service. 
Create a URL custom field. Set the field key to itunes_album Set the field formatting to Custom, and the format to: <a class="embedly-card" href="{$formValue}">iTunes Album</a> <script async src="//cdn.embedly.com/widgets/platform.js" charset="UTF-8"></script> In your database display template, position the field as desired by adding: {$record->customFieldDisplayByKey('itunes_album', 'listing')|raw} Now when you add an iTunes album link to your record, you'll get an embed automatically!

This approach is great for a range of uses. Perhaps you have an Amazon Associates account and want to add a relevant product link to each of your records so that you earn a commission when users click through. Using database fields and templates in this way, it's easy to set up.
 
I hope that's given you some ideas of other ways you might use database fields in Pages. Share any interesting uses you've come up with in the comments!

Our Pages app includes a powerful feature that allows you to create your own databases within the community. Within each database, you create custom fields (we support a number of custom types, from plain text fields, to YouTube embeds and more). And while we provide some generic, simple templates to display your data, custom templates allow you to more precisely control how your database looks in a manner best suited to your site.
Anyone who has created a Pages database will be familiar with using custom fields. You may have created a field for the title of your item, or an upload field so that the item contains a file for users to download. But beyond these straightforward uses, I wanted to explore some more advanced uses of custom fields. Fields don't necessarily have to be displayed to the user - or at least not in the usual way. We can use them as configuration options for our record display, or manipulate the data in order to show it in a different way. Let's take a look at some examples.
 
1. Adding an optional badge to records
We'll start with a fairly simple example. In our Guides section, we highlight guides that have a video tutorial by showing an 'Includes Video Guide' label on the listing:

We achieve this simply by having a Yes/No field that we turn on as needed. In the field format, we turn the Yes/No value into the label by setting the format to Custom and using this code:
{{if $formValue == 1}} <span class='ipsType_medium'><i class='fa fa-video-camera'></i> <strong>Includes Video Guide</strong></span> {{endif}}  
2. Using fields as a way to configure the record display
Fields don't necessarily need to be shown to users. Instead, we can use them as a means to configure the record display, giving us some really powerful flexibility in how we show records. In this contrived example, I'm going to create a field that changes the background color of the content.
Create a Select Box field. Each option key will be a hex color, while the value will be the name the record creator will choose. Set the field key to record_background Set the field formatting to Custom, and the format to simply: {$formValue}. This means it will output our hex value instead of the color name. In the display template assigned to this database for records, we can use the field like so: <div style='background-color: #{$record->customFieldDisplayByKey('record_background', 'listing')|raw}' class='ipsPad'> ...rest of the template... </div> Now, when you create a record, you can choose a color and that color will be used when the record is shown:
You can use this approach in others ways - toggles to control the layout of the record, or options for grid sizes, or even take an upload field for images and set the background of an element as that image.
 
3. Pass data to 3rd-party integrations
Pages has built-in support for several 3rd party integrations, such as Spotify, Soundcloud, YouTube and Google Maps. But using custom fields, you can pass data to other services too. Let's say we wanted to embed an iTunes album widget into each of our records - perhaps the album is relevant to the Pages record in some way and we hope to encourage some click-throughs. In this example, we'll use the embed.ly service. 
Create a URL custom field. Set the field key to itunes_album Set the field formatting to Custom, and the format to: <a class="embedly-card" href="{$formValue}">iTunes Album</a> <script async src="//cdn.embedly.com/widgets/platform.js" charset="UTF-8"></script> In your database display template, position the field as desired by adding: {$record->customFieldDisplayByKey('itunes_album', 'listing')|raw} Now when you add an iTunes album link to your record, you'll get an embed automatically!

This approach is great for a range of uses. Perhaps you have an Amazon Associates account and want to add a relevant product link to each of your records so that you earn a commission when users click through. Using database fields and templates in this way, it's easy to set up.
 
I hope that's given you some ideas of other ways you might use database fields in Pages. Share any interesting uses you've come up with in the comments!

Our Pages app includes a powerful feature that allows you to create your own databases within the community. Within each database, you create custom fields (we support a number of custom types, from plain text fields, to YouTube embeds and more). And while we provide some generic, simple templates to display your data, custom templates allow you to more precisely control how your database looks in a manner best suited to your site.
Anyone who has created a Pages database will be familiar with using custom fields. You may have created a field for the title of your item, or an upload field so that the item contains a file for users to download. But beyond these straightforward uses, I wanted to explore some more advanced uses of custom fields. Fields don't necessarily have to be displayed to the user - or at least not in the usual way. We can use them as configuration options for our record display, or manipulate the data in order to show it in a different way. Let's take a look at some examples.
 
1. Adding an optional badge to records
We'll start with a fairly simple example. In our Guides section, we highlight guides that have a video tutorial by showing an 'Includes Video Guide' label on the listing:

We achieve this simply by having a Yes/No field that we turn on as needed. In the field format, we turn the Yes/No value into the label by setting the format to Custom and using this code:
{{if $formValue == 1}} <span class='ipsType_medium'><i class='fa fa-video-camera'></i> <strong>Includes Video Guide</strong></span> {{endif}}  
2. Using fields as a way to configure the record display
Fields don't necessarily need to be shown to users. Instead, we can use them as a means to configure the record display, giving us some really powerful flexibility in how we show records. In this contrived example, I'm going to create a field that changes the background color of the content.
Create a Select Box field. Each option key will be a hex color, while the value will be the name the record creator will choose. Set the field key to record_background Set the field formatting to Custom, and the format to simply: {$formValue}. This means it will output our hex value instead of the color name. In the display template assigned to this database for records, we can use the field like so: <div style='background-color: #{$record->customFieldDisplayByKey('record_background', 'listing')|raw}' class='ipsPad'> ...rest of the template... </div> Now, when you create a record, you can choose a color and that color will be used when the record is shown:
You can use this approach in others ways - toggles to control the layout of the record, or options for grid sizes, or even take an upload field for images and set the background of an element as that image.
 
3. Pass data to 3rd-party integrations
Pages has built-in support for several 3rd party integrations, such as Spotify, Soundcloud, YouTube and Google Maps. But using custom fields, you can pass data to other services too. Let's say we wanted to embed an iTunes album widget into each of our records - perhaps the album is relevant to the Pages record in some way and we hope to encourage some click-throughs. In this example, we'll use the embed.ly service. 
Create a URL custom field. Set the field key to itunes_album Set the field formatting to Custom, and the format to: <a class="embedly-card" href="{$formValue}">iTunes Album</a> <script async src="//cdn.embedly.com/widgets/platform.js" charset="UTF-8"></script> In your database display template, position the field as desired by adding: {$record->customFieldDisplayByKey('itunes_album', 'listing')|raw} Now when you add an iTunes album link to your record, you'll get an embed automatically!

This approach is great for a range of uses. Perhaps you have an Amazon Associates account and want to add a relevant product link to each of your records so that you earn a commission when users click through. Using database fields and templates in this way, it's easy to set up.
 
I hope that's given you some ideas of other ways you might use database fields in Pages. Share any interesting uses you've come up with in the comments!

Our Pages app includes a powerful feature that allows you to create your own databases within the community. Within each database, you create custom fields (we support a number of custom types, from plain text fields, to YouTube embeds and more). And while we provide some generic, simple templates to display your data, custom templates allow you to more precisely control how your database looks in a manner best suited to your site.
Anyone who has created a Pages database will be familiar with using custom fields. You may have created a field for the title of your item, or an upload field so that the item contains a file for users to download. But beyond these straightforward uses, I wanted to explore some more advanced uses of custom fields. Fields don't necessarily have to be displayed to the user - or at least not in the usual way. We can use them as configuration options for our record display, or manipulate the data in order to show it in a different way. Let's take a look at some examples.
 
1. Adding an optional badge to records
We'll start with a fairly simple example. In our Guides section, we highlight guides that have a video tutorial by showing an 'Includes Video Guide' label on the listing:

We achieve this simply by having a Yes/No field that we turn on as needed. In the field format, we turn the Yes/No value into the label by setting the format to Custom and using this code:
{{if $formValue == 1}} <span class='ipsType_medium'><i class='fa fa-video-camera'></i> <strong>Includes Video Guide</strong></span> {{endif}}  
2. Using fields as a way to configure the record display
Fields don't necessarily need to be shown to users. Instead, we can use them as a means to configure the record display, giving us some really powerful flexibility in how we show records. In this contrived example, I'm going to create a field that changes the background color of the content.
Create a Select Box field. Each option key will be a hex color, while the value will be the name the record creator will choose. Set the field key to record_background Set the field formatting to Custom, and the format to simply: {$formValue}. This means it will output our hex value instead of the color name. In the display template assigned to this database for records, we can use the field like so: <div style='background-color: #{$record->customFieldDisplayByKey('record_background', 'listing')|raw}' class='ipsPad'> ...rest of the template... </div> Now, when you create a record, you can choose a color and that color will be used when the record is shown:
You can use this approach in others ways - toggles to control the layout of the record, or options for grid sizes, or even take an upload field for images and set the background of an element as that image.
 
3. Pass data to 3rd-party integrations
Pages has built-in support for several 3rd party integrations, such as Spotify, Soundcloud, YouTube and Google Maps. But using custom fields, you can pass data to other services too. Let's say we wanted to embed an iTunes album widget into each of our records - perhaps the album is relevant to the Pages record in some way and we hope to encourage some click-throughs. In this example, we'll use the embed.ly service. 
Create a URL custom field. Set the field key to itunes_album Set the field formatting to Custom, and the format to: <a class="embedly-card" href="{$formValue}">iTunes Album</a> <script async src="//cdn.embedly.com/widgets/platform.js" charset="UTF-8"></script> In your database display template, position the field as desired by adding: {$record->customFieldDisplayByKey('itunes_album', 'listing')|raw} Now when you add an iTunes album link to your record, you'll get an embed automatically!

This approach is great for a range of uses. Perhaps you have an Amazon Associates account and want to add a relevant product link to each of your records so that you earn a commission when users click through. Using database fields and templates in this way, it's easy to set up.
 
I hope that's given you some ideas of other ways you might use database fields in Pages. Share any interesting uses you've come up with in the comments!

Our Pages app includes a powerful feature that allows you to create your own databases within the community. Within each database, you create custom fields (we support a number of custom types, from plain text fields, to YouTube embeds and more). And while we provide some generic, simple templates to display your data, custom templates allow you to more precisely control how your database looks in a manner best suited to your site.
Anyone who has created a Pages database will be familiar with using custom fields. You may have created a field for the title of your item, or an upload field so that the item contains a file for users to download. But beyond these straightforward uses, I wanted to explore some more advanced uses of custom fields. Fields don't necessarily have to be displayed to the user - or at least not in the usual way. We can use them as configuration options for our record display, or manipulate the data in order to show it in a different way. Let's take a look at some examples.
 
1. Adding an optional badge to records
We'll start with a fairly simple example. In our Guides section, we highlight guides that have a video tutorial by showing an 'Includes Video Guide' label on the listing:

We achieve this simply by having a Yes/No field that we turn on as needed. In the field format, we turn the Yes/No value into the label by setting the format to Custom and using this code:
{{if $formValue == 1}} <span class='ipsType_medium'><i class='fa fa-video-camera'></i> <strong>Includes Video Guide</strong></span> {{endif}}  
2. Using fields as a way to configure the record display
Fields don't necessarily need to be shown to users. Instead, we can use them as a means to configure the record display, giving us some really powerful flexibility in how we show records. In this contrived example, I'm going to create a field that changes the background color of the content.
Create a Select Box field. Each option key will be a hex color, while the value will be the name the record creator will choose. Set the field key to record_background Set the field formatting to Custom, and the format to simply: {$formValue}. This means it will output our hex value instead of the color name. In the display template assigned to this database for records, we can use the field like so: <div style='background-color: #{$record->customFieldDisplayByKey('record_background', 'listing')|raw}' class='ipsPad'> ...rest of the template... </div> Now, when you create a record, you can choose a color and that color will be used when the record is shown:
You can use this approach in others ways - toggles to control the layout of the record, or options for grid sizes, or even take an upload field for images and set the background of an element as that image.
 
3. Pass data to 3rd-party integrations
Pages has built-in support for several 3rd party integrations, such as Spotify, Soundcloud, YouTube and Google Maps. But using custom fields, you can pass data to other services too. Let's say we wanted to embed an iTunes album widget into each of our records - perhaps the album is relevant to the Pages record in some way and we hope to encourage some click-throughs. In this example, we'll use the embed.ly service. 
Create a URL custom field. Set the field key to itunes_album Set the field formatting to Custom, and the format to: <a class="embedly-card" href="{$formValue}">iTunes Album</a> <script async src="//cdn.embedly.com/widgets/platform.js" charset="UTF-8"></script> In your database display template, position the field as desired by adding: {$record->customFieldDisplayByKey('itunes_album', 'listing')|raw} Now when you add an iTunes album link to your record, you'll get an embed automatically!

This approach is great for a range of uses. Perhaps you have an Amazon Associates account and want to add a relevant product link to each of your records so that you earn a commission when users click through. Using database fields and templates in this way, it's easy to set up.
 
I hope that's given you some ideas of other ways you might use database fields in Pages. Share any interesting uses you've come up with in the comments!

Our Pages app includes a powerful feature that allows you to create your own databases within the community. Within each database, you create custom fields (we support a number of custom types, from plain text fields, to YouTube embeds and more). And while we provide some generic, simple templates to display your data, custom templates allow you to more precisely control how your database looks in a manner best suited to your site.
Anyone who has created a Pages database will be familiar with using custom fields. You may have created a field for the title of your item, or an upload field so that the item contains a file for users to download. But beyond these straightforward uses, I wanted to explore some more advanced uses of custom fields. Fields don't necessarily have to be displayed to the user - or at least not in the usual way. We can use them as configuration options for our record display, or manipulate the data in order to show it in a different way. Let's take a look at some examples.
 
1. Adding an optional badge to records
We'll start with a fairly simple example. In our Guides section, we highlight guides that have a video tutorial by showing an 'Includes Video Guide' label on the listing:

We achieve this simply by having a Yes/No field that we turn on as needed. In the field format, we turn the Yes/No value into the label by setting the format to Custom and using this code:
{{if $formValue == 1}} <span class='ipsType_medium'><i class='fa fa-video-camera'></i> <strong>Includes Video Guide</strong></span> {{endif}}  
2. Using fields as a way to configure the record display
Fields don't necessarily need to be shown to users. Instead, we can use them as a means to configure the record display, giving us some really powerful flexibility in how we show records. In this contrived example, I'm going to create a field that changes the background color of the content.
Create a Select Box field. Each option key will be a hex color, while the value will be the name the record creator will choose. Set the field key to record_background Set the field formatting to Custom, and the format to simply: {$formValue}. This means it will output our hex value instead of the color name. In the display template assigned to this database for records, we can use the field like so: <div style='background-color: #{$record->customFieldDisplayByKey('record_background', 'listing')|raw}' class='ipsPad'> ...rest of the template... </div> Now, when you create a record, you can choose a color and that color will be used when the record is shown:
You can use this approach in others ways - toggles to control the layout of the record, or options for grid sizes, or even take an upload field for images and set the background of an element as that image.
 
3. Pass data to 3rd-party integrations
Pages has built-in support for several 3rd party integrations, such as Spotify, Soundcloud, YouTube and Google Maps. But using custom fields, you can pass data to other services too. Let's say we wanted to embed an iTunes album widget into each of our records - perhaps the album is relevant to the Pages record in some way and we hope to encourage some click-throughs. In this example, we'll use the embed.ly service. 
Create a URL custom field. Set the field key to itunes_album Set the field formatting to Custom, and the format to: <a class="embedly-card" href="{$formValue}">iTunes Album</a> <script async src="//cdn.embedly.com/widgets/platform.js" charset="UTF-8"></script> In your database display template, position the field as desired by adding: {$record->customFieldDisplayByKey('itunes_album', 'listing')|raw} Now when you add an iTunes album link to your record, you'll get an embed automatically!

This approach is great for a range of uses. Perhaps you have an Amazon Associates account and want to add a relevant product link to each of your records so that you earn a commission when users click through. Using database fields and templates in this way, it's easy to set up.
 
I hope that's given you some ideas of other ways you might use database fields in Pages. Share any interesting uses you've come up with in the comments!

Our Pages app includes a powerful feature that allows you to create your own databases within the community. Within each database, you create custom fields (we support a number of custom types, from plain text fields, to YouTube embeds and more). And while we provide some generic, simple templates to display your data, custom templates allow you to more precisely control how your database looks in a manner best suited to your site.
Anyone who has created a Pages database will be familiar with using custom fields. You may have created a field for the title of your item, or an upload field so that the item contains a file for users to download. But beyond these straightforward uses, I wanted to explore some more advanced uses of custom fields. Fields don't necessarily have to be displayed to the user - or at least not in the usual way. We can use them as configuration options for our record display, or manipulate the data in order to show it in a different way. Let's take a look at some examples.
 
1. Adding an optional badge to records
We'll start with a fairly simple example. In our Guides section, we highlight guides that have a video tutorial by showing an 'Includes Video Guide' label on the listing:

We achieve this simply by having a Yes/No field that we turn on as needed. In the field format, we turn the Yes/No value into the label by setting the format to Custom and using this code:
{{if $formValue == 1}} <span class='ipsType_medium'><i class='fa fa-video-camera'></i> <strong>Includes Video Guide</strong></span> {{endif}}  
2. Using fields as a way to configure the record display
Fields don't necessarily need to be shown to users. Instead, we can use them as a means to configure the record display, giving us some really powerful flexibility in how we show records. In this contrived example, I'm going to create a field that changes the background color of the content.
Create a Select Box field. Each option key will be a hex color, while the value will be the name the record creator will choose. Set the field key to record_background Set the field formatting to Custom, and the format to simply: {$formValue}. This means it will output our hex value instead of the color name. In the display template assigned to this database for records, we can use the field like so: <div style='background-color: #{$record->customFieldDisplayByKey('record_background', 'listing')|raw}' class='ipsPad'> ...rest of the template... </div> Now, when you create a record, you can choose a color and that color will be used when the record is shown:
You can use this approach in others ways - toggles to control the layout of the record, or options for grid sizes, or even take an upload field for images and set the background of an element as that image.
 
3. Pass data to 3rd-party integrations
Pages has built-in support for several 3rd party integrations, such as Spotify, Soundcloud, YouTube and Google Maps. But using custom fields, you can pass data to other services too. Let's say we wanted to embed an iTunes album widget into each of our records - perhaps the album is relevant to the Pages record in some way and we hope to encourage some click-throughs. In this example, we'll use the embed.ly service. 
Create a URL custom field. Set the field key to itunes_album Set the field formatting to Custom, and the format to: <a class="embedly-card" href="{$formValue}">iTunes Album</a> <script async src="//cdn.embedly.com/widgets/platform.js" charset="UTF-8"></script> In your database display template, position the field as desired by adding: {$record->customFieldDisplayByKey('itunes_album', 'listing')|raw} Now when you add an iTunes album link to your record, you'll get an embed automatically!

This approach is great for a range of uses. Perhaps you have an Amazon Associates account and want to add a relevant product link to each of your records so that you earn a commission when users click through. Using database fields and templates in this way, it's easy to set up.
 
I hope that's given you some ideas of other ways you might use database fields in Pages. Share any interesting uses you've come up with in the comments!

Our Pages app includes a powerful feature that allows you to create your own databases within the community. Within each database, you create custom fields (we support a number of custom types, from plain text fields, to YouTube embeds and more). And while we provide some generic, simple templates to display your data, custom templates allow you to more precisely control how your database looks in a manner best suited to your site.
Anyone who has created a Pages database will be familiar with using custom fields. You may have created a field for the title of your item, or an upload field so that the item contains a file for users to download. But beyond these straightforward uses, I wanted to explore some more advanced uses of custom fields. Fields don't necessarily have to be displayed to the user - or at least not in the usual way. We can use them as configuration options for our record display, or manipulate the data in order to show it in a different way. Let's take a look at some examples.
 
1. Adding an optional badge to records
We'll start with a fairly simple example. In our Guides section, we highlight guides that have a video tutorial by showing an 'Includes Video Guide' label on the listing:

We achieve this simply by having a Yes/No field that we turn on as needed. In the field format, we turn the Yes/No value into the label by setting the format to Custom and using this code:
{{if $formValue == 1}} <span class='ipsType_medium'><i class='fa fa-video-camera'></i> <strong>Includes Video Guide</strong></span> {{endif}}  
2. Using fields as a way to configure the record display
Fields don't necessarily need to be shown to users. Instead, we can use them as a means to configure the record display, giving us some really powerful flexibility in how we show records. In this contrived example, I'm going to create a field that changes the background color of the content.
Create a Select Box field. Each option key will be a hex color, while the value will be the name the record creator will choose. Set the field key to record_background Set the field formatting to Custom, and the format to simply: {$formValue}. This means it will output our hex value instead of the color name. In the display template assigned to this database for records, we can use the field like so: <div style='background-color: #{$record->customFieldDisplayByKey('record_background', 'listing')|raw}' class='ipsPad'> ...rest of the template... </div> Now, when you create a record, you can choose a color and that color will be used when the record is shown:
You can use this approach in others ways - toggles to control the layout of the record, or options for grid sizes, or even take an upload field for images and set the background of an element as that image.
 
3. Pass data to 3rd-party integrations
Pages has built-in support for several 3rd party integrations, such as Spotify, Soundcloud, YouTube and Google Maps. But using custom fields, you can pass data to other services too. Let's say we wanted to embed an iTunes album widget into each of our records - perhaps the album is relevant to the Pages record in some way and we hope to encourage some click-throughs. In this example, we'll use the embed.ly service. 
Create a URL custom field. Set the field key to itunes_album Set the field formatting to Custom, and the format to: <a class="embedly-card" href="{$formValue}">iTunes Album</a> <script async src="//cdn.embedly.com/widgets/platform.js" charset="UTF-8"></script> In your database display template, position the field as desired by adding: {$record->customFieldDisplayByKey('itunes_album', 'listing')|raw} Now when you add an iTunes album link to your record, you'll get an embed automatically!

This approach is great for a range of uses. Perhaps you have an Amazon Associates account and want to add a relevant product link to each of your records so that you earn a commission when users click through. Using database fields and templates in this way, it's easy to set up.
 
I hope that's given you some ideas of other ways you might use database fields in Pages. Share any interesting uses you've come up with 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! 
 

Security should never be an afterthought for your community. All too often, site owners consider beefing up their security only when it's too late and their community has already been compromised. Taking some time now to check and improve the security of your community and server could pay dividends by eliminating the cost and hassle of falling victim to hacking in the first place.
Let's run down 7 ways that you can protect your community with the IPS Community Suite, from security features you may not know about to best practices all communities should be following.
 
1. Be selective when adding administrators
Administrator permissions can be extremely damaging in the wrong hands, and granting administrator powers should only be done with great consideration. Granting access to the AdminCP is like handing someone the keys to your house, so before doing so, be sure you really trust the person and that their role requires access to the AdminCP (for example, would moderator permissions be sufficient for the new staff member?).
Don't forget to remove administrator access promptly when necessary too, such as the member of staff leaving your organization. Always be aware of exactly who has administrator access at any given time, and review regularly. You can list all accounts that have AdminCP access by clicking the List Administrators button on the System -> Security page.
2. Utilize Admin Restrictions
In many organizations, staff roles within the community reflect real-world roles - designers need access to templates, accounting needs access to billing, and so forth. IPS4 allows you to limit administrator access to very specific areas of the AdminCP with the Admin Restrictions feature, and even limit what can be done within those areas. This is a great approach for limiting risk to your data; by giving staff members access to only the areas they need to perform their duties, you reduce the potential impact should their account become compromised in future.
3. Choose good passwords
This seems like an obvious suggestion, but surveys regularly show that people choose passwords that are simply too easy to guess or brute force. Your password is naturally the most basic protection of your AdminCP there is, so making sure you're using a good password is essential.
We recommend using a password manager application such as 1password or LastPass. These applications generate strong, random passwords for each site you use, and store them so that you don't have to remember them.
Even if you don't use a password manager, make sure the passwords you use for your community are unique and never used for others sites too.
4. Stay up to date
It's a fact of software development that from time to time new security issues are reported and promptly fixed. But if you're running several versions behind, once security issues are made public through responsible disclosure, malicious users can exploit those weaknesses in your community.
When we release new updates - especially if they're marked as a security release in our release notes - be sure to update as promptly as you can so you receive the latest fixes. Your AdminCP will also let you know when a new version is ready for download.
5. Use .htaccess protection for your AdminCP
In addition to IPS4's own AdminCP login page, you can set up browser-level authentication, giving you a double layer of protection. This is done via a special .htaccess file which instructs the server to prompt for authentication before access to the page is granted. IPS4 can automatically generate this file for you - simply go to System -> Security in your AdminCP, and enable the "Add a secondary admin password" rule.
And it should go without saying, but to be clear: don't use the same username or password for both your .htaccess login and your admin account, or the measure is redundant!
6. Restrict your AdminCP to an IP range where possible
If your organization has a static IP or requires staff members to use a VPN, you can add an additional layer of security to your community by prohibiting access to the AdminCP unless the user's IP matches your whitelist. This is a server-level feature, so consult your IT team or host to find out how to set it up in your particular environment. If you're a Community in the Cloud customer, contact our support team if you'd like to set up this protection for your account.
7. Properly secure your PHP installation
Many of PHP's built-in functions can leave a server vulnerable to high-impact exploits, and yet many of these functions aren't needed by the vast majority of PHP applications you might run. We therefore recommend that you explicitly disable these functions using PHP's disable_functions configuration setting. Here's our recommended configuration, although you or your host may need to tweak the list depending on your exact needs:
disable_functions = escapeshellarg,escapeshellcmd,exec,ini_alter,parse_ini_file,passthru,pcntl_exec,popen,proc_close,proc_get_status,proc_nice,proc_open,proc_terminate,show_source,shell_exec,symlink,system Another critical PHP configuration setting you need to check is that open_basedir is enabled, especially if you're hosted on a server that also hosts other websites (known as shared hosting). If another account on the server is comprised and open_basedir is disabled, the attacker can potentially gain access to your files too.
Naturally, Community in the Cloud customers needn't worry about either of these steps - we've already handled it for you!
 
So there we go - a brief overview of 7 common-sense ways you can better protect your community and its users. As software developers, we're constantly working to improve the behind-the-scenes security of our software, but as an administrator, there's also a number of steps you should take to keep your community safe on the web.
If you have any tips related to security, be sure to share them 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! 
 

Our Pages app includes a powerful feature that allows you to create your own databases within the community. Within each database, you create custom fields (we support a number of custom types, from plain text fields, to YouTube embeds and more). And while we provide some generic, simple templates to display your data, custom templates allow you to more precisely control how your database looks in a manner best suited to your site.
Anyone who has created a Pages database will be familiar with using custom fields. You may have created a field for the title of your item, or an upload field so that the item contains a file for users to download. But beyond these straightforward uses, I wanted to explore some more advanced uses of custom fields. Fields don't necessarily have to be displayed to the user - or at least not in the usual way. We can use them as configuration options for our record display, or manipulate the data in order to show it in a different way. Let's take a look at some examples.
 
1. Adding an optional badge to records
We'll start with a fairly simple example. In our Guides section, we highlight guides that have a video tutorial by showing an 'Includes Video Guide' label on the listing:

We achieve this simply by having a Yes/No field that we turn on as needed. In the field format, we turn the Yes/No value into the label by setting the format to Custom and using this code:
{{if $formValue == 1}} <span class='ipsType_medium'><i class='fa fa-video-camera'></i> <strong>Includes Video Guide</strong></span> {{endif}}  
2. Using fields as a way to configure the record display
Fields don't necessarily need to be shown to users. Instead, we can use them as a means to configure the record display, giving us some really powerful flexibility in how we show records. In this contrived example, I'm going to create a field that changes the background color of the content.
Create a Select Box field. Each option key will be a hex color, while the value will be the name the record creator will choose. Set the field key to record_background Set the field formatting to Custom, and the format to simply: {$formValue}. This means it will output our hex value instead of the color name. In the display template assigned to this database for records, we can use the field like so: <div style='background-color: #{$record->customFieldDisplayByKey('record_background', 'listing')|raw}' class='ipsPad'> ...rest of the template... </div> Now, when you create a record, you can choose a color and that color will be used when the record is shown:
You can use this approach in others ways - toggles to control the layout of the record, or options for grid sizes, or even take an upload field for images and set the background of an element as that image.
 
3. Pass data to 3rd-party integrations
Pages has built-in support for several 3rd party integrations, such as Spotify, Soundcloud, YouTube and Google Maps. But using custom fields, you can pass data to other services too. Let's say we wanted to embed an iTunes album widget into each of our records - perhaps the album is relevant to the Pages record in some way and we hope to encourage some click-throughs. In this example, we'll use the embed.ly service. 
Create a URL custom field. Set the field key to itunes_album Set the field formatting to Custom, and the format to: <a class="embedly-card" href="{$formValue}">iTunes Album</a> <script async src="//cdn.embedly.com/widgets/platform.js" charset="UTF-8"></script> In your database display template, position the field as desired by adding: {$record->customFieldDisplayByKey('itunes_album', 'listing')|raw} Now when you add an iTunes album link to your record, you'll get an embed automatically!

This approach is great for a range of uses. Perhaps you have an Amazon Associates account and want to add a relevant product link to each of your records so that you earn a commission when users click through. Using database fields and templates in this way, it's easy to set up.
 
I hope that's given you some ideas of other ways you might use database fields in Pages. Share any interesting uses you've come up with in the comments!

Security should never be an afterthought for your community. All too often, site owners consider beefing up their security only when it's too late and their community has already been compromised. Taking some time now to check and improve the security of your community and server could pay dividends by eliminating the cost and hassle of falling victim to hacking in the first place.
Let's run down 7 ways that you can protect your community with the IPS Community Suite, from security features you may not know about to best practices all communities should be following.
 
1. Be selective when adding administrators
Administrator permissions can be extremely damaging in the wrong hands, and granting administrator powers should only be done with great consideration. Granting access to the AdminCP is like handing someone the keys to your house, so before doing so, be sure you really trust the person and that their role requires access to the AdminCP (for example, would moderator permissions be sufficient for the new staff member?).
Don't forget to remove administrator access promptly when necessary too, such as the member of staff leaving your organization. Always be aware of exactly who has administrator access at any given time, and review regularly. You can list all accounts that have AdminCP access by clicking the List Administrators button on the System -> Security page.
2. Utilize Admin Restrictions
In many organizations, staff roles within the community reflect real-world roles - designers need access to templates, accounting needs access to billing, and so forth. IPS4 allows you to limit administrator access to very specific areas of the AdminCP with the Admin Restrictions feature, and even limit what can be done within those areas. This is a great approach for limiting risk to your data; by giving staff members access to only the areas they need to perform their duties, you reduce the potential impact should their account become compromised in future.
3. Choose good passwords
This seems like an obvious suggestion, but surveys regularly show that people choose passwords that are simply too easy to guess or brute force. Your password is naturally the most basic protection of your AdminCP there is, so making sure you're using a good password is essential.
We recommend using a password manager application such as 1password or LastPass. These applications generate strong, random passwords for each site you use, and store them so that you don't have to remember them.
Even if you don't use a password manager, make sure the passwords you use for your community are unique and never used for others sites too.
4. Stay up to date
It's a fact of software development that from time to time new security issues are reported and promptly fixed. But if you're running several versions behind, once security issues are made public through responsible disclosure, malicious users can exploit those weaknesses in your community.
When we release new updates - especially if they're marked as a security release in our release notes - be sure to update as promptly as you can so you receive the latest fixes. Your AdminCP will also let you know when a new version is ready for download.
5. Use .htaccess protection for your AdminCP
In addition to IPS4's own AdminCP login page, you can set up browser-level authentication, giving you a double layer of protection. This is done via a special .htaccess file which instructs the server to prompt for authentication before access to the page is granted. IPS4 can automatically generate this file for you - simply go to System -> Security in your AdminCP, and enable the "Add a secondary admin password" rule.
And it should go without saying, but to be clear: don't use the same username or password for both your .htaccess login and your admin account, or the measure is redundant!
6. Restrict your AdminCP to an IP range where possible
If your organization has a static IP or requires staff members to use a VPN, you can add an additional layer of security to your community by prohibiting access to the AdminCP unless the user's IP matches your whitelist. This is a server-level feature, so consult your IT team or host to find out how to set it up in your particular environment. If you're a Community in the Cloud customer, contact our support team if you'd like to set up this protection for your account.
7. Properly secure your PHP installation
Many of PHP's built-in functions can leave a server vulnerable to high-impact exploits, and yet many of these functions aren't needed by the vast majority of PHP applications you might run. We therefore recommend that you explicitly disable these functions using PHP's disable_functions configuration setting. Here's our recommended configuration, although you or your host may need to tweak the list depending on your exact needs:
disable_functions = escapeshellarg,escapeshellcmd,exec,ini_alter,parse_ini_file,passthru,pcntl_exec,popen,proc_close,proc_get_status,proc_nice,proc_open,proc_terminate,show_source,shell_exec,symlink,system Another critical PHP configuration setting you need to check is that open_basedir is enabled, especially if you're hosted on a server that also hosts other websites (known as shared hosting). If another account on the server is comprised and open_basedir is disabled, the attacker can potentially gain access to your files too.
Naturally, Community in the Cloud customers needn't worry about either of these steps - we've already handled it for you!
 
So there we go - a brief overview of 7 common-sense ways you can better protect your community and its users. As software developers, we're constantly working to improve the behind-the-scenes security of our software, but as an administrator, there's also a number of steps you should take to keep your community safe on the web.
If you have any tips related to security, be sure to share them in the comments!

Reminder: this blog covers the technical details of 4.0's programming. For details on 4.0's features, follow our main blog.

Reviewing controllers

Some time ago, I blogged about the javascript framework we've built for IPS4. In it, I covered the most important component: controllers. To recap, a controller is a special object within the framework, and is applied on specific elements. That element is the controller's scope, and the controller works on it to provide its functionality. For example, a simple controller might look like this:

ips.controller.register('core.global.core.example', { initialize: function () { this.on( 'click', this.showAlert ); }, showAlert: function (e) { alert( "This button's text is: " + this.scope.html() ); } });
It would be used on an element like so:

<button data-controller='core.global.core.example'>Click me</button>
Here we're registering core.global.core.example as a controller. This represents the controller path - it's in the format app.module.group.controllerName. Though it seems longwinded, this allows IPS4 to dynamically load controllers on-demand, rather than loading them all when the page is loaded. In the initialize method (called automatically), we set up an event handler for a click. When the element is clicked, you'd see an alert saying "This button's text is: Click me".

So, that's how controllers work. Almost all page behavior in IPS4 is handled through controllers. But how would you change a method in an existing controller, say if you were writing an addon, or if you had two controllers that were fairly similar, and wanted to provide a base controller they both shared?

Mixins

To enable that, we have mixins. Mixins allow you to specify functions which are inherited by objects - in this case, our controller objects. This means, using mixins we can add new functions to a controller without needing to edit the controller itself.

A mixin is defined like so:

ips.controller.mixin('addAnotherMethod', 'core.global.core.example', true, function () { this.anotherMethod = function () { alert('Inside anotherMethod'); }; });
The ips.controller.mixin method takes up to 4 parameters:

ips.controller.mixin( name, controller, automaticallyExtend, fnDefinition )
name: Name to identify this mixin
controller: The controller this mixin extends
automaticallyExtend: [optional, default false] Does this mixin automatically extend the controller (more on that below)
fnDetinition: The function definition applied to the controller

In this example, our mixin adds a method named anotherMethod to our core.global.core.example controller shown earlier.

Let's talk more about the automaticallyExtend parameter. Mixins can be applied to controllers in one of two ways - either automatically on a global basis, or manually on a case-by-case basis. Mixins are manually specified like so:

<button data-controller='core.global.core.example( addAnotherMethod )'>Click me</button>
This means the mixin is used on this element - but another element using core.global.core.example wouldn't get it. This is useful when you're building your own apps or addons; you can write simple controllers that implement base functionality, then extend them with functionality for specific cases by specifying the mixin name in your HTML. We use this ourselves - for example, we have a base table controller that handles sorting, filtering and so forth. We then have a mixin for AdminCP tables, and a mixin for front-end tables, which add functionality specific to those areas, reducing code duplication.

If you're extending an IPS controller in an IPS app, though, modifying the HTML isn't typically an option. Instead, you can specify the mixin as global, and it will be applied to all elements where that controller is used. This means you can write your own mixins that work with our default controllers without having to touch our controller code (and that's a good thing).

Advice

So that shows how to add new methods to a controller. But what if you want to work with the methods that already exist in the controller? In the above example you'd only be able to overwrite an existing method - certainly not ideal, because 1) you would break any other mixins using the default method, 2) if we made an update to a method in a later release, your mixin would break it.

To facilitate working with existing controller methods, we're using a model called advice. This adds three special methods to a mixin: before, after and around. These let you 'hook into' existing methods and provide additional code for them. Let's rewrite our example mixin from above to take advantage of it:

ips.controller.mixin('changeBackground', 'core.global.core.example', function () { this.before('showAlert', function () { this.scope.css({ background: 'red' }); }; });
Here, I'm using the before method. I'm hooking into showAlert method (from the controller), and changing the background color of the scope element. So what happens when the link is clicked? First the background changes to red, and then an alert box is shown. We've added the background changing functionality without needing to edit the controller at all. Here's two other ways of doing the same thing, using the other two special methods:

ips.controller.mixin('changeBackground', 'core.global.core.example', function () { this.after('showAlert', function () { this.scope.css({ background: 'red' }); }; this.around('showAlert', function (origFn) { this.scope.css({ background: 'red' }); origFn(); }; });
The after method is fairly self-evident. With the around method, the original function is passed in as an argument, allowing you to determine when it is executed by your mixin.

All three of these methods will stack, so multiple mixins can hook into the same method, and they'll be executed in order, each receiving the previous.

Conclusion

I hope this introduction to mixins proves useful to developers; it shows how our core app controllers can be extended in a non-destructive way, but also how your own apps can use the mixin functionality to create an inheritance model to make your life easier.

Javascript in IPS4 makes extensive use of custom events, so the preferred way of adding new functionality is to listen for appropriate events and act on them - but the mixin support described above provides a mechanism by which you can adapt existing event handlers.

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

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

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

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

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

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!

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

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!

HTML Logic is our name for the additional tags available in IPS4's templates that allow runtime logic to be executed. It comprises if/then/else statements as well as loops and more.
Since HTML Logic has access to all of the underlying PHP framework in IPS4, it's very powerful and a lot can be achieved with it. One common use is to limit certain content within a template to particular member groups. Let's see how that might be done.
 
Showing or hiding content only to guests
We'll first look at a simpler idea: showing or hiding content specifically to guests (i.e. anyone who isn't logged in). Within IPS4, the \IPS\Member::loggedIn() object contains information about the current user. Guests always have a member_id of NULL (i.e. no value), so we can simply check that value in our logic tag:
{{if \IPS\Member::loggedIn()->member_id === NULL}} This content *only* shows to guests, since they have a NULL member_id. {{endif}} {{if \IPS\Member::loggedIn()->member_id}} This content *only* shows to logged-in users since their member_id is a number, which will equal true. {{endif}}  
Showing content only to specific groups
Let's go a bit further and this time show content to specific (primary) member groups. First, you need to get the IDs for the group(s) you want to deal with. You can find this by editing the group in the AdminCP, and making a note of the id parameter in the URL. On my installation, the Administrator group is ID 4 so we'll use that in our example.
Once again, we're using the \IPS\Member::loggedIn() object, but this time we're using the member_group_id property.
{{if \IPS\Member::loggedIn()->member_group_id === 4}} This content only shows to members in the "Administrators" group (ID 4 in our example) {{endif}}  
Working with multiple groups at once
Following the code above, you could simply repeat the check against \IPS\Member::loggedIn()->member_group_id several times, for each ID you want to allow. However, since our templates allow arbitrary PHP expressions to be used, there's a neater way: use an array of member group IDs you want to allow, and check against that using PHP's in_array function. Here's an example where we only show content to group IDs 2, 4 and 6:
{{if in_array( \IPS\Member::loggedIn()->member_group_id, array( 2, 4, 6 ) )}} This content only shows to members in groups with the ID 2, 4 or 6. {{endif}}  
Have a request for a theme tip? Let us know in the comments and we'll try and help out in a future tip! 

Security should never be an afterthought for your community. All too often, site owners consider beefing up their security only when it's too late and their community has already been compromised. Taking some time now to check and improve the security of your community and server could pay dividends by eliminating the cost and hassle of falling victim to hacking in the first place.
Let's run down 7 ways that you can protect your community with the IPS Community Suite, from security features you may not know about to best practices all communities should be following.
 
1. Be selective when adding administrators
Administrator permissions can be extremely damaging in the wrong hands, and granting administrator powers should only be done with great consideration. Granting access to the AdminCP is like handing someone the keys to your house, so before doing so, be sure you really trust the person and that their role requires access to the AdminCP (for example, would moderator permissions be sufficient for the new staff member?).
Don't forget to remove administrator access promptly when necessary too, such as the member of staff leaving your organization. Always be aware of exactly who has administrator access at any given time, and review regularly. You can list all accounts that have AdminCP access by clicking the List Administrators button on the System -> Security page.
2. Utilize Admin Restrictions
In many organizations, staff roles within the community reflect real-world roles - designers need access to templates, accounting needs access to billing, and so forth. IPS4 allows you to limit administrator access to very specific areas of the AdminCP with the Admin Restrictions feature, and even limit what can be done within those areas. This is a great approach for limiting risk to your data; by giving staff members access to only the areas they need to perform their duties, you reduce the potential impact should their account become compromised in future.
3. Choose good passwords
This seems like an obvious suggestion, but surveys regularly show that people choose passwords that are simply too easy to guess or brute force. Your password is naturally the most basic protection of your AdminCP there is, so making sure you're using a good password is essential.
We recommend using a password manager application such as 1password or LastPass. These applications generate strong, random passwords for each site you use, and store them so that you don't have to remember them.
Even if you don't use a password manager, make sure the passwords you use for your community are unique and never used for others sites too.
4. Stay up to date
It's a fact of software development that from time to time new security issues are reported and promptly fixed. But if you're running several versions behind, once security issues are made public through responsible disclosure, malicious users can exploit those weaknesses in your community.
When we release new updates - especially if they're marked as a security release in our release notes - be sure to update as promptly as you can so you receive the latest fixes. Your AdminCP will also let you know when a new version is ready for download.
5. Use .htaccess protection for your AdminCP
In addition to IPS4's own AdminCP login page, you can set up browser-level authentication, giving you a double layer of protection. This is done via a special .htaccess file which instructs the server to prompt for authentication before access to the page is granted. IPS4 can automatically generate this file for you - simply go to System -> Security in your AdminCP, and enable the "Add a secondary admin password" rule.
And it should go without saying, but to be clear: don't use the same username or password for both your .htaccess login and your admin account, or the measure is redundant!
6. Restrict your AdminCP to an IP range where possible
If your organization has a static IP or requires staff members to use a VPN, you can add an additional layer of security to your community by prohibiting access to the AdminCP unless the user's IP matches your whitelist. This is a server-level feature, so consult your IT team or host to find out how to set it up in your particular environment. If you're a Community in the Cloud customer, contact our support team if you'd like to set up this protection for your account.
7. Properly secure your PHP installation
Many of PHP's built-in functions can leave a server vulnerable to high-impact exploits, and yet many of these functions aren't needed by the vast majority of PHP applications you might run. We therefore recommend that you explicitly disable these functions using PHP's disable_functions configuration setting. Here's our recommended configuration, although you or your host may need to tweak the list depending on your exact needs:
disable_functions = escapeshellarg,escapeshellcmd,exec,ini_alter,parse_ini_file,passthru,pcntl_exec,popen,proc_close,proc_get_status,proc_nice,proc_open,proc_terminate,show_source,shell_exec,symlink,system Another critical PHP configuration setting you need to check is that open_basedir is enabled, especially if you're hosted on a server that also hosts other websites (known as shared hosting). If another account on the server is comprised and open_basedir is disabled, the attacker can potentially gain access to your files too.
Naturally, Community in the Cloud customers needn't worry about either of these steps - we've already handled it for you!
 
So there we go - a brief overview of 7 common-sense ways you can better protect your community and its users. As software developers, we're constantly working to improve the behind-the-scenes security of our software, but as an administrator, there's also a number of steps you should take to keep your community safe on the web.
If you have any tips related to security, be sure to share them in the comments!

Security should never be an afterthought for your community. All too often, site owners consider beefing up their security only when it's too late and their community has already been compromised. Taking some time now to check and improve the security of your community and server could pay dividends by eliminating the cost and hassle of falling victim to hacking in the first place.
Let's run down 7 ways that you can protect your community with the IPS Community Suite, from security features you may not know about to best practices all communities should be following.
 
1. Be selective when adding administrators
Administrator permissions can be extremely damaging in the wrong hands, and granting administrator powers should only be done with great consideration. Granting access to the AdminCP is like handing someone the keys to your house, so before doing so, be sure you really trust the person and that their role requires access to the AdminCP (for example, would moderator permissions be sufficient for the new staff member?).
Don't forget to remove administrator access promptly when necessary too, such as the member of staff leaving your organization. Always be aware of exactly who has administrator access at any given time, and review regularly. You can list all accounts that have AdminCP access by clicking the List Administrators button on the System -> Security page.
2. Utilize Admin Restrictions
In many organizations, staff roles within the community reflect real-world roles - designers need access to templates, accounting needs access to billing, and so forth. IPS4 allows you to limit administrator access to very specific areas of the AdminCP with the Admin Restrictions feature, and even limit what can be done within those areas. This is a great approach for limiting risk to your data; by giving staff members access to only the areas they need to perform their duties, you reduce the potential impact should their account become compromised in future.
3. Choose good passwords
This seems like an obvious suggestion, but surveys regularly show that people choose passwords that are simply too easy to guess or brute force. Your password is naturally the most basic protection of your AdminCP there is, so making sure you're using a good password is essential.
We recommend using a password manager application such as 1password or LastPass. These applications generate strong, random passwords for each site you use, and store them so that you don't have to remember them.
Even if you don't use a password manager, make sure the passwords you use for your community are unique and never used for others sites too.
4. Stay up to date
It's a fact of software development that from time to time new security issues are reported and promptly fixed. But if you're running several versions behind, once security issues are made public through responsible disclosure, malicious users can exploit those weaknesses in your community.
When we release new updates - especially if they're marked as a security release in our release notes - be sure to update as promptly as you can so you receive the latest fixes. Your AdminCP will also let you know when a new version is ready for download.
5. Use .htaccess protection for your AdminCP
In addition to IPS4's own AdminCP login page, you can set up browser-level authentication, giving you a double layer of protection. This is done via a special .htaccess file which instructs the server to prompt for authentication before access to the page is granted. IPS4 can automatically generate this file for you - simply go to System -> Security in your AdminCP, and enable the "Add a secondary admin password" rule.
And it should go without saying, but to be clear: don't use the same username or password for both your .htaccess login and your admin account, or the measure is redundant!
6. Restrict your AdminCP to an IP range where possible
If your organization has a static IP or requires staff members to use a VPN, you can add an additional layer of security to your community by prohibiting access to the AdminCP unless the user's IP matches your whitelist. This is a server-level feature, so consult your IT team or host to find out how to set it up in your particular environment. If you're a Community in the Cloud customer, contact our support team if you'd like to set up this protection for your account.
7. Properly secure your PHP installation
Many of PHP's built-in functions can leave a server vulnerable to high-impact exploits, and yet many of these functions aren't needed by the vast majority of PHP applications you might run. We therefore recommend that you explicitly disable these functions using PHP's disable_functions configuration setting. Here's our recommended configuration, although you or your host may need to tweak the list depending on your exact needs:
disable_functions = escapeshellarg,escapeshellcmd,exec,ini_alter,parse_ini_file,passthru,pcntl_exec,popen,proc_close,proc_get_status,proc_nice,proc_open,proc_terminate,show_source,shell_exec,symlink,system Another critical PHP configuration setting you need to check is that open_basedir is enabled, especially if you're hosted on a server that also hosts other websites (known as shared hosting). If another account on the server is comprised and open_basedir is disabled, the attacker can potentially gain access to your files too.
Naturally, Community in the Cloud customers needn't worry about either of these steps - we've already handled it for you!
 
So there we go - a brief overview of 7 common-sense ways you can better protect your community and its users. As software developers, we're constantly working to improve the behind-the-scenes security of our software, but as an administrator, there's also a number of steps you should take to keep your community safe on the web.
If you have any tips related to security, be sure to share them in the comments!

Security should never be an afterthought for your community. All too often, site owners consider beefing up their security only when it's too late and their community has already been compromised. Taking some time now to check and improve the security of your community and server could pay dividends by eliminating the cost and hassle of falling victim to hacking in the first place.
Let's run down 7 ways that you can protect your community with the IPS Community Suite, from security features you may not know about to best practices all communities should be following.
 
1. Be selective when adding administrators
Administrator permissions can be extremely damaging in the wrong hands, and granting administrator powers should only be done with great consideration. Granting access to the AdminCP is like handing someone the keys to your house, so before doing so, be sure you really trust the person and that their role requires access to the AdminCP (for example, would moderator permissions be sufficient for the new staff member?).
Don't forget to remove administrator access promptly when necessary too, such as the member of staff leaving your organization. Always be aware of exactly who has administrator access at any given time, and review regularly. You can list all accounts that have AdminCP access by clicking the List Administrators button on the System -> Security page.
2. Utilize Admin Restrictions
In many organizations, staff roles within the community reflect real-world roles - designers need access to templates, accounting needs access to billing, and so forth. IPS4 allows you to limit administrator access to very specific areas of the AdminCP with the Admin Restrictions feature, and even limit what can be done within those areas. This is a great approach for limiting risk to your data; by giving staff members access to only the areas they need to perform their duties, you reduce the potential impact should their account become compromised in future.
3. Choose good passwords
This seems like an obvious suggestion, but surveys regularly show that people choose passwords that are simply too easy to guess or brute force. Your password is naturally the most basic protection of your AdminCP there is, so making sure you're using a good password is essential.
We recommend using a password manager application such as 1password or LastPass. These applications generate strong, random passwords for each site you use, and store them so that you don't have to remember them.
Even if you don't use a password manager, make sure the passwords you use for your community are unique and never used for others sites too.
4. Stay up to date
It's a fact of software development that from time to time new security issues are reported and promptly fixed. But if you're running several versions behind, once security issues are made public through responsible disclosure, malicious users can exploit those weaknesses in your community.
When we release new updates - especially if they're marked as a security release in our release notes - be sure to update as promptly as you can so you receive the latest fixes. Your AdminCP will also let you know when a new version is ready for download.
5. Use .htaccess protection for your AdminCP
In addition to IPS4's own AdminCP login page, you can set up browser-level authentication, giving you a double layer of protection. This is done via a special .htaccess file which instructs the server to prompt for authentication before access to the page is granted. IPS4 can automatically generate this file for you - simply go to System -> Security in your AdminCP, and enable the "Add a secondary admin password" rule.
And it should go without saying, but to be clear: don't use the same username or password for both your .htaccess login and your admin account, or the measure is redundant!
6. Restrict your AdminCP to an IP range where possible
If your organization has a static IP or requires staff members to use a VPN, you can add an additional layer of security to your community by prohibiting access to the AdminCP unless the user's IP matches your whitelist. This is a server-level feature, so consult your IT team or host to find out how to set it up in your particular environment. If you're a Community in the Cloud customer, contact our support team if you'd like to set up this protection for your account.
7. Properly secure your PHP installation
Many of PHP's built-in functions can leave a server vulnerable to high-impact exploits, and yet many of these functions aren't needed by the vast majority of PHP applications you might run. We therefore recommend that you explicitly disable these functions using PHP's disable_functions configuration setting. Here's our recommended configuration, although you or your host may need to tweak the list depending on your exact needs:
disable_functions = escapeshellarg,escapeshellcmd,exec,ini_alter,parse_ini_file,passthru,pcntl_exec,popen,proc_close,proc_get_status,proc_nice,proc_open,proc_terminate,show_source,shell_exec,symlink,system Another critical PHP configuration setting you need to check is that open_basedir is enabled, especially if you're hosted on a server that also hosts other websites (known as shared hosting). If another account on the server is comprised and open_basedir is disabled, the attacker can potentially gain access to your files too.
Naturally, Community in the Cloud customers needn't worry about either of these steps - we've already handled it for you!
 
So there we go - a brief overview of 7 common-sense ways you can better protect your community and its users. As software developers, we're constantly working to improve the behind-the-scenes security of our software, but as an administrator, there's also a number of steps you should take to keep your community safe on the web.
If you have any tips related to security, be sure to share them in the comments!

Security should never be an afterthought for your community. All too often, site owners consider beefing up their security only when it's too late and their community has already been compromised. Taking some time now to check and improve the security of your community and server could pay dividends by eliminating the cost and hassle of falling victim to hacking in the first place.
Let's run down 7 ways that you can protect your community with the IPS Community Suite, from security features you may not know about to best practices all communities should be following.
 
1. Be selective when adding administrators
Administrator permissions can be extremely damaging in the wrong hands, and granting administrator powers should only be done with great consideration. Granting access to the AdminCP is like handing someone the keys to your house, so before doing so, be sure you really trust the person and that their role requires access to the AdminCP (for example, would moderator permissions be sufficient for the new staff member?).
Don't forget to remove administrator access promptly when necessary too, such as the member of staff leaving your organization. Always be aware of exactly who has administrator access at any given time, and review regularly. You can list all accounts that have AdminCP access by clicking the List Administrators button on the System -> Security page.
2. Utilize Admin Restrictions
In many organizations, staff roles within the community reflect real-world roles - designers need access to templates, accounting needs access to billing, and so forth. IPS4 allows you to limit administrator access to very specific areas of the AdminCP with the Admin Restrictions feature, and even limit what can be done within those areas. This is a great approach for limiting risk to your data; by giving staff members access to only the areas they need to perform their duties, you reduce the potential impact should their account become compromised in future.
3. Choose good passwords
This seems like an obvious suggestion, but surveys regularly show that people choose passwords that are simply too easy to guess or brute force. Your password is naturally the most basic protection of your AdminCP there is, so making sure you're using a good password is essential.
We recommend using a password manager application such as 1password or LastPass. These applications generate strong, random passwords for each site you use, and store them so that you don't have to remember them.
Even if you don't use a password manager, make sure the passwords you use for your community are unique and never used for others sites too.
4. Stay up to date
It's a fact of software development that from time to time new security issues are reported and promptly fixed. But if you're running several versions behind, once security issues are made public through responsible disclosure, malicious users can exploit those weaknesses in your community.
When we release new updates - especially if they're marked as a security release in our release notes - be sure to update as promptly as you can so you receive the latest fixes. Your AdminCP will also let you know when a new version is ready for download.
5. Use .htaccess protection for your AdminCP
In addition to IPS4's own AdminCP login page, you can set up browser-level authentication, giving you a double layer of protection. This is done via a special .htaccess file which instructs the server to prompt for authentication before access to the page is granted. IPS4 can automatically generate this file for you - simply go to System -> Security in your AdminCP, and enable the "Add a secondary admin password" rule.
And it should go without saying, but to be clear: don't use the same username or password for both your .htaccess login and your admin account, or the measure is redundant!
6. Restrict your AdminCP to an IP range where possible
If your organization has a static IP or requires staff members to use a VPN, you can add an additional layer of security to your community by prohibiting access to the AdminCP unless the user's IP matches your whitelist. This is a server-level feature, so consult your IT team or host to find out how to set it up in your particular environment. If you're a Community in the Cloud customer, contact our support team if you'd like to set up this protection for your account.
7. Properly secure your PHP installation
Many of PHP's built-in functions can leave a server vulnerable to high-impact exploits, and yet many of these functions aren't needed by the vast majority of PHP applications you might run. We therefore recommend that you explicitly disable these functions using PHP's disable_functions configuration setting. Here's our recommended configuration, although you or your host may need to tweak the list depending on your exact needs:
disable_functions = escapeshellarg,escapeshellcmd,exec,ini_alter,parse_ini_file,passthru,pcntl_exec,popen,proc_close,proc_get_status,proc_nice,proc_open,proc_terminate,show_source,shell_exec,symlink,system Another critical PHP configuration setting you need to check is that open_basedir is enabled, especially if you're hosted on a server that also hosts other websites (known as shared hosting). If another account on the server is comprised and open_basedir is disabled, the attacker can potentially gain access to your files too.
Naturally, Community in the Cloud customers needn't worry about either of these steps - we've already handled it for you!
 
So there we go - a brief overview of 7 common-sense ways you can better protect your community and its users. As software developers, we're constantly working to improve the behind-the-scenes security of our software, but as an administrator, there's also a number of steps you should take to keep your community safe on the web.
If you have any tips related to security, be sure to share them in the comments!

Security should never be an afterthought for your community. All too often, site owners consider beefing up their security only when it's too late and their community has already been compromised. Taking some time now to check and improve the security of your community and server could pay dividends by eliminating the cost and hassle of falling victim to hacking in the first place.
Let's run down 7 ways that you can protect your community with the IPS Community Suite, from security features you may not know about to best practices all communities should be following.
 
1. Be selective when adding administrators
Administrator permissions can be extremely damaging in the wrong hands, and granting administrator powers should only be done with great consideration. Granting access to the AdminCP is like handing someone the keys to your house, so before doing so, be sure you really trust the person and that their role requires access to the AdminCP (for example, would moderator permissions be sufficient for the new staff member?).
Don't forget to remove administrator access promptly when necessary too, such as the member of staff leaving your organization. Always be aware of exactly who has administrator access at any given time, and review regularly. You can list all accounts that have AdminCP access by clicking the List Administrators button on the System -> Security page.
2. Utilize Admin Restrictions
In many organizations, staff roles within the community reflect real-world roles - designers need access to templates, accounting needs access to billing, and so forth. IPS4 allows you to limit administrator access to very specific areas of the AdminCP with the Admin Restrictions feature, and even limit what can be done within those areas. This is a great approach for limiting risk to your data; by giving staff members access to only the areas they need to perform their duties, you reduce the potential impact should their account become compromised in future.
3. Choose good passwords
This seems like an obvious suggestion, but surveys regularly show that people choose passwords that are simply too easy to guess or brute force. Your password is naturally the most basic protection of your AdminCP there is, so making sure you're using a good password is essential.
We recommend using a password manager application such as 1password or LastPass. These applications generate strong, random passwords for each site you use, and store them so that you don't have to remember them.
Even if you don't use a password manager, make sure the passwords you use for your community are unique and never used for others sites too.
4. Stay up to date
It's a fact of software development that from time to time new security issues are reported and promptly fixed. But if you're running several versions behind, once security issues are made public through responsible disclosure, malicious users can exploit those weaknesses in your community.
When we release new updates - especially if they're marked as a security release in our release notes - be sure to update as promptly as you can so you receive the latest fixes. Your AdminCP will also let you know when a new version is ready for download.
5. Use .htaccess protection for your AdminCP
In addition to IPS4's own AdminCP login page, you can set up browser-level authentication, giving you a double layer of protection. This is done via a special .htaccess file which instructs the server to prompt for authentication before access to the page is granted. IPS4 can automatically generate this file for you - simply go to System -> Security in your AdminCP, and enable the "Add a secondary admin password" rule.
And it should go without saying, but to be clear: don't use the same username or password for both your .htaccess login and your admin account, or the measure is redundant!
6. Restrict your AdminCP to an IP range where possible
If your organization has a static IP or requires staff members to use a VPN, you can add an additional layer of security to your community by prohibiting access to the AdminCP unless the user's IP matches your whitelist. This is a server-level feature, so consult your IT team or host to find out how to set it up in your particular environment. If you're a Community in the Cloud customer, contact our support team if you'd like to set up this protection for your account.
7. Properly secure your PHP installation
Many of PHP's built-in functions can leave a server vulnerable to high-impact exploits, and yet many of these functions aren't needed by the vast majority of PHP applications you might run. We therefore recommend that you explicitly disable these functions using PHP's disable_functions configuration setting. Here's our recommended configuration, although you or your host may need to tweak the list depending on your exact needs:
disable_functions = escapeshellarg,escapeshellcmd,exec,ini_alter,parse_ini_file,passthru,pcntl_exec,popen,proc_close,proc_get_status,proc_nice,proc_open,proc_terminate,show_source,shell_exec,symlink,system Another critical PHP configuration setting you need to check is that open_basedir is enabled, especially if you're hosted on a server that also hosts other websites (known as shared hosting). If another account on the server is comprised and open_basedir is disabled, the attacker can potentially gain access to your files too.
Naturally, Community in the Cloud customers needn't worry about either of these steps - we've already handled it for you!
 
So there we go - a brief overview of 7 common-sense ways you can better protect your community and its users. As software developers, we're constantly working to improve the behind-the-scenes security of our software, but as an administrator, there's also a number of steps you should take to keep your community safe on the web.
If you have any tips related to security, be sure to share them in the comments!

Security should never be an afterthought for your community. All too often, site owners consider beefing up their security only when it's too late and their community has already been compromised. Taking some time now to check and improve the security of your community and server could pay dividends by eliminating the cost and hassle of falling victim to hacking in the first place.
Let's run down 7 ways that you can protect your community with the IPS Community Suite, from security features you may not know about to best practices all communities should be following.
 
1. Be selective when adding administrators
Administrator permissions can be extremely damaging in the wrong hands, and granting administrator powers should only be done with great consideration. Granting access to the AdminCP is like handing someone the keys to your house, so before doing so, be sure you really trust the person and that their role requires access to the AdminCP (for example, would moderator permissions be sufficient for the new staff member?).
Don't forget to remove administrator access promptly when necessary too, such as the member of staff leaving your organization. Always be aware of exactly who has administrator access at any given time, and review regularly. You can list all accounts that have AdminCP access by clicking the List Administrators button on the System -> Security page.
2. Utilize Admin Restrictions
In many organizations, staff roles within the community reflect real-world roles - designers need access to templates, accounting needs access to billing, and so forth. IPS4 allows you to limit administrator access to very specific areas of the AdminCP with the Admin Restrictions feature, and even limit what can be done within those areas. This is a great approach for limiting risk to your data; by giving staff members access to only the areas they need to perform their duties, you reduce the potential impact should their account become compromised in future.
3. Choose good passwords
This seems like an obvious suggestion, but surveys regularly show that people choose passwords that are simply too easy to guess or brute force. Your password is naturally the most basic protection of your AdminCP there is, so making sure you're using a good password is essential.
We recommend using a password manager application such as 1password or LastPass. These applications generate strong, random passwords for each site you use, and store them so that you don't have to remember them.
Even if you don't use a password manager, make sure the passwords you use for your community are unique and never used for others sites too.
4. Stay up to date
It's a fact of software development that from time to time new security issues are reported and promptly fixed. But if you're running several versions behind, once security issues are made public through responsible disclosure, malicious users can exploit those weaknesses in your community.
When we release new updates - especially if they're marked as a security release in our release notes - be sure to update as promptly as you can so you receive the latest fixes. Your AdminCP will also let you know when a new version is ready for download.
5. Use .htaccess protection for your AdminCP
In addition to IPS4's own AdminCP login page, you can set up browser-level authentication, giving you a double layer of protection. This is done via a special .htaccess file which instructs the server to prompt for authentication before access to the page is granted. IPS4 can automatically generate this file for you - simply go to System -> Security in your AdminCP, and enable the "Add a secondary admin password" rule.
And it should go without saying, but to be clear: don't use the same username or password for both your .htaccess login and your admin account, or the measure is redundant!
6. Restrict your AdminCP to an IP range where possible
If your organization has a static IP or requires staff members to use a VPN, you can add an additional layer of security to your community by prohibiting access to the AdminCP unless the user's IP matches your whitelist. This is a server-level feature, so consult your IT team or host to find out how to set it up in your particular environment. If you're a Community in the Cloud customer, contact our support team if you'd like to set up this protection for your account.
7. Properly secure your PHP installation
Many of PHP's built-in functions can leave a server vulnerable to high-impact exploits, and yet many of these functions aren't needed by the vast majority of PHP applications you might run. We therefore recommend that you explicitly disable these functions using PHP's disable_functions configuration setting. Here's our recommended configuration, although you or your host may need to tweak the list depending on your exact needs:
disable_functions = escapeshellarg,escapeshellcmd,exec,ini_alter,parse_ini_file,passthru,pcntl_exec,popen,proc_close,proc_get_status,proc_nice,proc_open,proc_terminate,show_source,shell_exec,symlink,system Another critical PHP configuration setting you need to check is that open_basedir is enabled, especially if you're hosted on a server that also hosts other websites (known as shared hosting). If another account on the server is comprised and open_basedir is disabled, the attacker can potentially gain access to your files too.
Naturally, Community in the Cloud customers needn't worry about either of these steps - we've already handled it for you!
 
So there we go - a brief overview of 7 common-sense ways you can better protect your community and its users. As software developers, we're constantly working to improve the behind-the-scenes security of our software, but as an administrator, there's also a number of steps you should take to keep your community safe on the web.
If you have any tips related to security, be sure to share them in the comments!

Security should never be an afterthought for your community. All too often, site owners consider beefing up their security only when it's too late and their community has already been compromised. Taking some time now to check and improve the security of your community and server could pay dividends by eliminating the cost and hassle of falling victim to hacking in the first place.
Let's run down 7 ways that you can protect your community with the IPS Community Suite, from security features you may not know about to best practices all communities should be following.
 
1. Be selective when adding administrators
Administrator permissions can be extremely damaging in the wrong hands, and granting administrator powers should only be done with great consideration. Granting access to the AdminCP is like handing someone the keys to your house, so before doing so, be sure you really trust the person and that their role requires access to the AdminCP (for example, would moderator permissions be sufficient for the new staff member?).
Don't forget to remove administrator access promptly when necessary too, such as the member of staff leaving your organization. Always be aware of exactly who has administrator access at any given time, and review regularly. You can list all accounts that have AdminCP access by clicking the List Administrators button on the System -> Security page.
2. Utilize Admin Restrictions
In many organizations, staff roles within the community reflect real-world roles - designers need access to templates, accounting needs access to billing, and so forth. IPS4 allows you to limit administrator access to very specific areas of the AdminCP with the Admin Restrictions feature, and even limit what can be done within those areas. This is a great approach for limiting risk to your data; by giving staff members access to only the areas they need to perform their duties, you reduce the potential impact should their account become compromised in future.
3. Choose good passwords
This seems like an obvious suggestion, but surveys regularly show that people choose passwords that are simply too easy to guess or brute force. Your password is naturally the most basic protection of your AdminCP there is, so making sure you're using a good password is essential.
We recommend using a password manager application such as 1password or LastPass. These applications generate strong, random passwords for each site you use, and store them so that you don't have to remember them.
Even if you don't use a password manager, make sure the passwords you use for your community are unique and never used for others sites too.
4. Stay up to date
It's a fact of software development that from time to time new security issues are reported and promptly fixed. But if you're running several versions behind, once security issues are made public through responsible disclosure, malicious users can exploit those weaknesses in your community.
When we release new updates - especially if they're marked as a security release in our release notes - be sure to update as promptly as you can so you receive the latest fixes. Your AdminCP will also let you know when a new version is ready for download.
5. Use .htaccess protection for your AdminCP
In addition to IPS4's own AdminCP login page, you can set up browser-level authentication, giving you a double layer of protection. This is done via a special .htaccess file which instructs the server to prompt for authentication before access to the page is granted. IPS4 can automatically generate this file for you - simply go to System -> Security in your AdminCP, and enable the "Add a secondary admin password" rule.
And it should go without saying, but to be clear: don't use the same username or password for both your .htaccess login and your admin account, or the measure is redundant!
6. Restrict your AdminCP to an IP range where possible
If your organization has a static IP or requires staff members to use a VPN, you can add an additional layer of security to your community by prohibiting access to the AdminCP unless the user's IP matches your whitelist. This is a server-level feature, so consult your IT team or host to find out how to set it up in your particular environment. If you're a Community in the Cloud customer, contact our support team if you'd like to set up this protection for your account.
7. Properly secure your PHP installation
Many of PHP's built-in functions can leave a server vulnerable to high-impact exploits, and yet many of these functions aren't needed by the vast majority of PHP applications you might run. We therefore recommend that you explicitly disable these functions using PHP's disable_functions configuration setting. Here's our recommended configuration, although you or your host may need to tweak the list depending on your exact needs:
disable_functions = escapeshellarg,escapeshellcmd,exec,ini_alter,parse_ini_file,passthru,pcntl_exec,popen,proc_close,proc_get_status,proc_nice,proc_open,proc_terminate,show_source,shell_exec,symlink,system Another critical PHP configuration setting you need to check is that open_basedir is enabled, especially if you're hosted on a server that also hosts other websites (known as shared hosting). If another account on the server is comprised and open_basedir is disabled, the attacker can potentially gain access to your files too.
Naturally, Community in the Cloud customers needn't worry about either of these steps - we've already handled it for you!
 
So there we go - a brief overview of 7 common-sense ways you can better protect your community and its users. As software developers, we're constantly working to improve the behind-the-scenes security of our software, but as an administrator, there's also a number of steps you should take to keep your community safe on the web.
If you have any tips related to security, be sure to share them 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! 
 

Security should never be an afterthought for your community. All too often, site owners consider beefing up their security only when it's too late and their community has already been compromised. Taking some time now to check and improve the security of your community and server could pay dividends by eliminating the cost and hassle of falling victim to hacking in the first place.
Let's run down 7 ways that you can protect your community with the IPS Community Suite, from security features you may not know about to best practices all communities should be following.
 
1. Be selective when adding administrators
Administrator permissions can be extremely damaging in the wrong hands, and granting administrator powers should only be done with great consideration. Granting access to the AdminCP is like handing someone the keys to your house, so before doing so, be sure you really trust the person and that their role requires access to the AdminCP (for example, would moderator permissions be sufficient for the new staff member?).
Don't forget to remove administrator access promptly when necessary too, such as the member of staff leaving your organization. Always be aware of exactly who has administrator access at any given time, and review regularly. You can list all accounts that have AdminCP access by clicking the List Administrators button on the System -> Security page.
2. Utilize Admin Restrictions
In many organizations, staff roles within the community reflect real-world roles - designers need access to templates, accounting needs access to billing, and so forth. IPS4 allows you to limit administrator access to very specific areas of the AdminCP with the Admin Restrictions feature, and even limit what can be done within those areas. This is a great approach for limiting risk to your data; by giving staff members access to only the areas they need to perform their duties, you reduce the potential impact should their account become compromised in future.
3. Choose good passwords
This seems like an obvious suggestion, but surveys regularly show that people choose passwords that are simply too easy to guess or brute force. Your password is naturally the most basic protection of your AdminCP there is, so making sure you're using a good password is essential.
We recommend using a password manager application such as 1password or LastPass. These applications generate strong, random passwords for each site you use, and store them so that you don't have to remember them.
Even if you don't use a password manager, make sure the passwords you use for your community are unique and never used for others sites too.
4. Stay up to date
It's a fact of software development that from time to time new security issues are reported and promptly fixed. But if you're running several versions behind, once security issues are made public through responsible disclosure, malicious users can exploit those weaknesses in your community.
When we release new updates - especially if they're marked as a security release in our release notes - be sure to update as promptly as you can so you receive the latest fixes. Your AdminCP will also let you know when a new version is ready for download.
5. Use .htaccess protection for your AdminCP
In addition to IPS4's own AdminCP login page, you can set up browser-level authentication, giving you a double layer of protection. This is done via a special .htaccess file which instructs the server to prompt for authentication before access to the page is granted. IPS4 can automatically generate this file for you - simply go to System -> Security in your AdminCP, and enable the "Add a secondary admin password" rule.
And it should go without saying, but to be clear: don't use the same username or password for both your .htaccess login and your admin account, or the measure is redundant!
6. Restrict your AdminCP to an IP range where possible
If your organization has a static IP or requires staff members to use a VPN, you can add an additional layer of security to your community by prohibiting access to the AdminCP unless the user's IP matches your whitelist. This is a server-level feature, so consult your IT team or host to find out how to set it up in your particular environment. If you're a Community in the Cloud customer, contact our support team if you'd like to set up this protection for your account.
7. Properly secure your PHP installation
Many of PHP's built-in functions can leave a server vulnerable to high-impact exploits, and yet many of these functions aren't needed by the vast majority of PHP applications you might run. We therefore recommend that you explicitly disable these functions using PHP's disable_functions configuration setting. Here's our recommended configuration, although you or your host may need to tweak the list depending on your exact needs:
disable_functions = escapeshellarg,escapeshellcmd,exec,ini_alter,parse_ini_file,passthru,pcntl_exec,popen,proc_close,proc_get_status,proc_nice,proc_open,proc_terminate,show_source,shell_exec,symlink,system Another critical PHP configuration setting you need to check is that open_basedir is enabled, especially if you're hosted on a server that also hosts other websites (known as shared hosting). If another account on the server is comprised and open_basedir is disabled, the attacker can potentially gain access to your files too.
Naturally, Community in the Cloud customers needn't worry about either of these steps - we've already handled it for you!
 
So there we go - a brief overview of 7 common-sense ways you can better protect your community and its users. As software developers, we're constantly working to improve the behind-the-scenes security of our software, but as an administrator, there's also a number of steps you should take to keep your community safe on the web.
If you have any tips related to security, be sure to share them in the comments!

Security should never be an afterthought for your community. All too often, site owners consider beefing up their security only when it's too late and their community has already been compromised. Taking some time now to check and improve the security of your community and server could pay dividends by eliminating the cost and hassle of falling victim to hacking in the first place.
Let's run down 7 ways that you can protect your community with the IPS Community Suite, from security features you may not know about to best practices all communities should be following.
 
1. Be selective when adding administrators
Administrator permissions can be extremely damaging in the wrong hands, and granting administrator powers should only be done with great consideration. Granting access to the AdminCP is like handing someone the keys to your house, so before doing so, be sure you really trust the person and that their role requires access to the AdminCP (for example, would moderator permissions be sufficient for the new staff member?).
Don't forget to remove administrator access promptly when necessary too, such as the member of staff leaving your organization. Always be aware of exactly who has administrator access at any given time, and review regularly. You can list all accounts that have AdminCP access by clicking the List Administrators button on the System -> Security page.
2. Utilize Admin Restrictions
In many organizations, staff roles within the community reflect real-world roles - designers need access to templates, accounting needs access to billing, and so forth. IPS4 allows you to limit administrator access to very specific areas of the AdminCP with the Admin Restrictions feature, and even limit what can be done within those areas. This is a great approach for limiting risk to your data; by giving staff members access to only the areas they need to perform their duties, you reduce the potential impact should their account become compromised in future.
3. Choose good passwords
This seems like an obvious suggestion, but surveys regularly show that people choose passwords that are simply too easy to guess or brute force. Your password is naturally the most basic protection of your AdminCP there is, so making sure you're using a good password is essential.
We recommend using a password manager application such as 1password or LastPass. These applications generate strong, random passwords for each site you use, and store them so that you don't have to remember them.
Even if you don't use a password manager, make sure the passwords you use for your community are unique and never used for others sites too.
4. Stay up to date
It's a fact of software development that from time to time new security issues are reported and promptly fixed. But if you're running several versions behind, once security issues are made public through responsible disclosure, malicious users can exploit those weaknesses in your community.
When we release new updates - especially if they're marked as a security release in our release notes - be sure to update as promptly as you can so you receive the latest fixes. Your AdminCP will also let you know when a new version is ready for download.
5. Use .htaccess protection for your AdminCP
In addition to IPS4's own AdminCP login page, you can set up browser-level authentication, giving you a double layer of protection. This is done via a special .htaccess file which instructs the server to prompt for authentication before access to the page is granted. IPS4 can automatically generate this file for you - simply go to System -> Security in your AdminCP, and enable the "Add a secondary admin password" rule.
And it should go without saying, but to be clear: don't use the same username or password for both your .htaccess login and your admin account, or the measure is redundant!
6. Restrict your AdminCP to an IP range where possible
If your organization has a static IP or requires staff members to use a VPN, you can add an additional layer of security to your community by prohibiting access to the AdminCP unless the user's IP matches your whitelist. This is a server-level feature, so consult your IT team or host to find out how to set it up in your particular environment. If you're a Community in the Cloud customer, contact our support team if you'd like to set up this protection for your account.
7. Properly secure your PHP installation
Many of PHP's built-in functions can leave a server vulnerable to high-impact exploits, and yet many of these functions aren't needed by the vast majority of PHP applications you might run. We therefore recommend that you explicitly disable these functions using PHP's disable_functions configuration setting. Here's our recommended configuration, although you or your host may need to tweak the list depending on your exact needs:
disable_functions = escapeshellarg,escapeshellcmd,exec,ini_alter,parse_ini_file,passthru,pcntl_exec,popen,proc_close,proc_get_status,proc_nice,proc_open,proc_terminate,show_source,shell_exec,symlink,system Another critical PHP configuration setting you need to check is that open_basedir is enabled, especially if you're hosted on a server that also hosts other websites (known as shared hosting). If another account on the server is comprised and open_basedir is disabled, the attacker can potentially gain access to your files too.
Naturally, Community in the Cloud customers needn't worry about either of these steps - we've already handled it for you!
 
So there we go - a brief overview of 7 common-sense ways you can better protect your community and its users. As software developers, we're constantly working to improve the behind-the-scenes security of our software, but as an administrator, there's also a number of steps you should take to keep your community safe on the web.
If you have any tips related to security, be sure to share them in the comments!

Security should never be an afterthought for your community. All too often, site owners consider beefing up their security only when it's too late and their community has already been compromised. Taking some time now to check and improve the security of your community and server could pay dividends by eliminating the cost and hassle of falling victim to hacking in the first place.
Let's run down 7 ways that you can protect your community with the IPS Community Suite, from security features you may not know about to best practices all communities should be following.
 
1. Be selective when adding administrators
Administrator permissions can be extremely damaging in the wrong hands, and granting administrator powers should only be done with great consideration. Granting access to the AdminCP is like handing someone the keys to your house, so before doing so, be sure you really trust the person and that their role requires access to the AdminCP (for example, would moderator permissions be sufficient for the new staff member?).
Don't forget to remove administrator access promptly when necessary too, such as the member of staff leaving your organization. Always be aware of exactly who has administrator access at any given time, and review regularly. You can list all accounts that have AdminCP access by clicking the List Administrators button on the System -> Security page.
2. Utilize Admin Restrictions
In many organizations, staff roles within the community reflect real-world roles - designers need access to templates, accounting needs access to billing, and so forth. IPS4 allows you to limit administrator access to very specific areas of the AdminCP with the Admin Restrictions feature, and even limit what can be done within those areas. This is a great approach for limiting risk to your data; by giving staff members access to only the areas they need to perform their duties, you reduce the potential impact should their account become compromised in future.
3. Choose good passwords
This seems like an obvious suggestion, but surveys regularly show that people choose passwords that are simply too easy to guess or brute force. Your password is naturally the most basic protection of your AdminCP there is, so making sure you're using a good password is essential.
We recommend using a password manager application such as 1password or LastPass. These applications generate strong, random passwords for each site you use, and store them so that you don't have to remember them.
Even if you don't use a password manager, make sure the passwords you use for your community are unique and never used for others sites too.
4. Stay up to date
It's a fact of software development that from time to time new security issues are reported and promptly fixed. But if you're running several versions behind, once security issues are made public through responsible disclosure, malicious users can exploit those weaknesses in your community.
When we release new updates - especially if they're marked as a security release in our release notes - be sure to update as promptly as you can so you receive the latest fixes. Your AdminCP will also let you know when a new version is ready for download.
5. Use .htaccess protection for your AdminCP
In addition to IPS4's own AdminCP login page, you can set up browser-level authentication, giving you a double layer of protection. This is done via a special .htaccess file which instructs the server to prompt for authentication before access to the page is granted. IPS4 can automatically generate this file for you - simply go to System -> Security in your AdminCP, and enable the "Add a secondary admin password" rule.
And it should go without saying, but to be clear: don't use the same username or password for both your .htaccess login and your admin account, or the measure is redundant!
6. Restrict your AdminCP to an IP range where possible
If your organization has a static IP or requires staff members to use a VPN, you can add an additional layer of security to your community by prohibiting access to the AdminCP unless the user's IP matches your whitelist. This is a server-level feature, so consult your IT team or host to find out how to set it up in your particular environment. If you're a Community in the Cloud customer, contact our support team if you'd like to set up this protection for your account.
7. Properly secure your PHP installation
Many of PHP's built-in functions can leave a server vulnerable to high-impact exploits, and yet many of these functions aren't needed by the vast majority of PHP applications you might run. We therefore recommend that you explicitly disable these functions using PHP's disable_functions configuration setting. Here's our recommended configuration, although you or your host may need to tweak the list depending on your exact needs:
disable_functions = escapeshellarg,escapeshellcmd,exec,ini_alter,parse_ini_file,passthru,pcntl_exec,popen,proc_close,proc_get_status,proc_nice,proc_open,proc_terminate,show_source,shell_exec,symlink,system Another critical PHP configuration setting you need to check is that open_basedir is enabled, especially if you're hosted on a server that also hosts other websites (known as shared hosting). If another account on the server is comprised and open_basedir is disabled, the attacker can potentially gain access to your files too.
Naturally, Community in the Cloud customers needn't worry about either of these steps - we've already handled it for you!
 
So there we go - a brief overview of 7 common-sense ways you can better protect your community and its users. As software developers, we're constantly working to improve the behind-the-scenes security of our software, but as an administrator, there's also a number of steps you should take to keep your community safe on the web.
If you have any tips related to security, be sure to share them in the comments!

Security should never be an afterthought for your community. All too often, site owners consider beefing up their security only when it's too late and their community has already been compromised. Taking some time now to check and improve the security of your community and server could pay dividends by eliminating the cost and hassle of falling victim to hacking in the first place.
Let's run down 7 ways that you can protect your community with the IPS Community Suite, from security features you may not know about to best practices all communities should be following.
 
1. Be selective when adding administrators
Administrator permissions can be extremely damaging in the wrong hands, and granting administrator powers should only be done with great consideration. Granting access to the AdminCP is like handing someone the keys to your house, so before doing so, be sure you really trust the person and that their role requires access to the AdminCP (for example, would moderator permissions be sufficient for the new staff member?).
Don't forget to remove administrator access promptly when necessary too, such as the member of staff leaving your organization. Always be aware of exactly who has administrator access at any given time, and review regularly. You can list all accounts that have AdminCP access by clicking the List Administrators button on the System -> Security page.
2. Utilize Admin Restrictions
In many organizations, staff roles within the community reflect real-world roles - designers need access to templates, accounting needs access to billing, and so forth. IPS4 allows you to limit administrator access to very specific areas of the AdminCP with the Admin Restrictions feature, and even limit what can be done within those areas. This is a great approach for limiting risk to your data; by giving staff members access to only the areas they need to perform their duties, you reduce the potential impact should their account become compromised in future.
3. Choose good passwords
This seems like an obvious suggestion, but surveys regularly show that people choose passwords that are simply too easy to guess or brute force. Your password is naturally the most basic protection of your AdminCP there is, so making sure you're using a good password is essential.
We recommend using a password manager application such as 1password or LastPass. These applications generate strong, random passwords for each site you use, and store them so that you don't have to remember them.
Even if you don't use a password manager, make sure the passwords you use for your community are unique and never used for others sites too.
4. Stay up to date
It's a fact of software development that from time to time new security issues are reported and promptly fixed. But if you're running several versions behind, once security issues are made public through responsible disclosure, malicious users can exploit those weaknesses in your community.
When we release new updates - especially if they're marked as a security release in our release notes - be sure to update as promptly as you can so you receive the latest fixes. Your AdminCP will also let you know when a new version is ready for download.
5. Use .htaccess protection for your AdminCP
In addition to IPS4's own AdminCP login page, you can set up browser-level authentication, giving you a double layer of protection. This is done via a special .htaccess file which instructs the server to prompt for authentication before access to the page is granted. IPS4 can automatically generate this file for you - simply go to System -> Security in your AdminCP, and enable the "Add a secondary admin password" rule.
And it should go without saying, but to be clear: don't use the same username or password for both your .htaccess login and your admin account, or the measure is redundant!
6. Restrict your AdminCP to an IP range where possible
If your organization has a static IP or requires staff members to use a VPN, you can add an additional layer of security to your community by prohibiting access to the AdminCP unless the user's IP matches your whitelist. This is a server-level feature, so consult your IT team or host to find out how to set it up in your particular environment. If you're a Community in the Cloud customer, contact our support team if you'd like to set up this protection for your account.
7. Properly secure your PHP installation
Many of PHP's built-in functions can leave a server vulnerable to high-impact exploits, and yet many of these functions aren't needed by the vast majority of PHP applications you might run. We therefore recommend that you explicitly disable these functions using PHP's disable_functions configuration setting. Here's our recommended configuration, although you or your host may need to tweak the list depending on your exact needs:
disable_functions = escapeshellarg,escapeshellcmd,exec,ini_alter,parse_ini_file,passthru,pcntl_exec,popen,proc_close,proc_get_status,proc_nice,proc_open,proc_terminate,show_source,shell_exec,symlink,system Another critical PHP configuration setting you need to check is that open_basedir is enabled, especially if you're hosted on a server that also hosts other websites (known as shared hosting). If another account on the server is comprised and open_basedir is disabled, the attacker can potentially gain access to your files too.
Naturally, Community in the Cloud customers needn't worry about either of these steps - we've already handled it for you!
 
So there we go - a brief overview of 7 common-sense ways you can better protect your community and its users. As software developers, we're constantly working to improve the behind-the-scenes security of our software, but as an administrator, there's also a number of steps you should take to keep your community safe on the web.
If you have any tips related to security, be sure to share them in the comments!

Security should never be an afterthought for your community. All too often, site owners consider beefing up their security only when it's too late and their community has already been compromised. Taking some time now to check and improve the security of your community and server could pay dividends by eliminating the cost and hassle of falling victim to hacking in the first place.
Let's run down 7 ways that you can protect your community with the IPS Community Suite, from security features you may not know about to best practices all communities should be following.
 
1. Be selective when adding administrators
Administrator permissions can be extremely damaging in the wrong hands, and granting administrator powers should only be done with great consideration. Granting access to the AdminCP is like handing someone the keys to your house, so before doing so, be sure you really trust the person and that their role requires access to the AdminCP (for example, would moderator permissions be sufficient for the new staff member?).
Don't forget to remove administrator access promptly when necessary too, such as the member of staff leaving your organization. Always be aware of exactly who has administrator access at any given time, and review regularly. You can list all accounts that have AdminCP access by clicking the List Administrators button on the System -> Security page.
2. Utilize Admin Restrictions
In many organizations, staff roles within the community reflect real-world roles - designers need access to templates, accounting needs access to billing, and so forth. IPS4 allows you to limit administrator access to very specific areas of the AdminCP with the Admin Restrictions feature, and even limit what can be done within those areas. This is a great approach for limiting risk to your data; by giving staff members access to only the areas they need to perform their duties, you reduce the potential impact should their account become compromised in future.
3. Choose good passwords
This seems like an obvious suggestion, but surveys regularly show that people choose passwords that are simply too easy to guess or brute force. Your password is naturally the most basic protection of your AdminCP there is, so making sure you're using a good password is essential.
We recommend using a password manager application such as 1password or LastPass. These applications generate strong, random passwords for each site you use, and store them so that you don't have to remember them.
Even if you don't use a password manager, make sure the passwords you use for your community are unique and never used for others sites too.
4. Stay up to date
It's a fact of software development that from time to time new security issues are reported and promptly fixed. But if you're running several versions behind, once security issues are made public through responsible disclosure, malicious users can exploit those weaknesses in your community.
When we release new updates - especially if they're marked as a security release in our release notes - be sure to update as promptly as you can so you receive the latest fixes. Your AdminCP will also let you know when a new version is ready for download.
5. Use .htaccess protection for your AdminCP
In addition to IPS4's own AdminCP login page, you can set up browser-level authentication, giving you a double layer of protection. This is done via a special .htaccess file which instructs the server to prompt for authentication before access to the page is granted. IPS4 can automatically generate this file for you - simply go to System -> Security in your AdminCP, and enable the "Add a secondary admin password" rule.
And it should go without saying, but to be clear: don't use the same username or password for both your .htaccess login and your admin account, or the measure is redundant!
6. Restrict your AdminCP to an IP range where possible
If your organization has a static IP or requires staff members to use a VPN, you can add an additional layer of security to your community by prohibiting access to the AdminCP unless the user's IP matches your whitelist. This is a server-level feature, so consult your IT team or host to find out how to set it up in your particular environment. If you're a Community in the Cloud customer, contact our support team if you'd like to set up this protection for your account.
7. Properly secure your PHP installation
Many of PHP's built-in functions can leave a server vulnerable to high-impact exploits, and yet many of these functions aren't needed by the vast majority of PHP applications you might run. We therefore recommend that you explicitly disable these functions using PHP's disable_functions configuration setting. Here's our recommended configuration, although you or your host may need to tweak the list depending on your exact needs:
disable_functions = escapeshellarg,escapeshellcmd,exec,ini_alter,parse_ini_file,passthru,pcntl_exec,popen,proc_close,proc_get_status,proc_nice,proc_open,proc_terminate,show_source,shell_exec,symlink,system Another critical PHP configuration setting you need to check is that open_basedir is enabled, especially if you're hosted on a server that also hosts other websites (known as shared hosting). If another account on the server is comprised and open_basedir is disabled, the attacker can potentially gain access to your files too.
Naturally, Community in the Cloud customers needn't worry about either of these steps - we've already handled it for you!
 
So there we go - a brief overview of 7 common-sense ways you can better protect your community and its users. As software developers, we're constantly working to improve the behind-the-scenes security of our software, but as an administrator, there's also a number of steps you should take to keep your community safe on the web.
If you have any tips related to security, be sure to share them 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! 
 

Security should never be an afterthought for your community. All too often, site owners consider beefing up their security only when it's too late and their community has already been compromised. Taking some time now to check and improve the security of your community and server could pay dividends by eliminating the cost and hassle of falling victim to hacking in the first place.
Let's run down 7 ways that you can protect your community with the IPS Community Suite, from security features you may not know about to best practices all communities should be following.
 
1. Be selective when adding administrators
Administrator permissions can be extremely damaging in the wrong hands, and granting administrator powers should only be done with great consideration. Granting access to the AdminCP is like handing someone the keys to your house, so before doing so, be sure you really trust the person and that their role requires access to the AdminCP (for example, would moderator permissions be sufficient for the new staff member?).
Don't forget to remove administrator access promptly when necessary too, such as the member of staff leaving your organization. Always be aware of exactly who has administrator access at any given time, and review regularly. You can list all accounts that have AdminCP access by clicking the List Administrators button on the System -> Security page.
2. Utilize Admin Restrictions
In many organizations, staff roles within the community reflect real-world roles - designers need access to templates, accounting needs access to billing, and so forth. IPS4 allows you to limit administrator access to very specific areas of the AdminCP with the Admin Restrictions feature, and even limit what can be done within those areas. This is a great approach for limiting risk to your data; by giving staff members access to only the areas they need to perform their duties, you reduce the potential impact should their account become compromised in future.
3. Choose good passwords
This seems like an obvious suggestion, but surveys regularly show that people choose passwords that are simply too easy to guess or brute force. Your password is naturally the most basic protection of your AdminCP there is, so making sure you're using a good password is essential.
We recommend using a password manager application such as 1password or LastPass. These applications generate strong, random passwords for each site you use, and store them so that you don't have to remember them.
Even if you don't use a password manager, make sure the passwords you use for your community are unique and never used for others sites too.
4. Stay up to date
It's a fact of software development that from time to time new security issues are reported and promptly fixed. But if you're running several versions behind, once security issues are made public through responsible disclosure, malicious users can exploit those weaknesses in your community.
When we release new updates - especially if they're marked as a security release in our release notes - be sure to update as promptly as you can so you receive the latest fixes. Your AdminCP will also let you know when a new version is ready for download.
5. Use .htaccess protection for your AdminCP
In addition to IPS4's own AdminCP login page, you can set up browser-level authentication, giving you a double layer of protection. This is done via a special .htaccess file which instructs the server to prompt for authentication before access to the page is granted. IPS4 can automatically generate this file for you - simply go to System -> Security in your AdminCP, and enable the "Add a secondary admin password" rule.
And it should go without saying, but to be clear: don't use the same username or password for both your .htaccess login and your admin account, or the measure is redundant!
6. Restrict your AdminCP to an IP range where possible
If your organization has a static IP or requires staff members to use a VPN, you can add an additional layer of security to your community by prohibiting access to the AdminCP unless the user's IP matches your whitelist. This is a server-level feature, so consult your IT team or host to find out how to set it up in your particular environment. If you're a Community in the Cloud customer, contact our support team if you'd like to set up this protection for your account.
7. Properly secure your PHP installation
Many of PHP's built-in functions can leave a server vulnerable to high-impact exploits, and yet many of these functions aren't needed by the vast majority of PHP applications you might run. We therefore recommend that you explicitly disable these functions using PHP's disable_functions configuration setting. Here's our recommended configuration, although you or your host may need to tweak the list depending on your exact needs:
disable_functions = escapeshellarg,escapeshellcmd,exec,ini_alter,parse_ini_file,passthru,pcntl_exec,popen,proc_close,proc_get_status,proc_nice,proc_open,proc_terminate,show_source,shell_exec,symlink,system Another critical PHP configuration setting you need to check is that open_basedir is enabled, especially if you're hosted on a server that also hosts other websites (known as shared hosting). If another account on the server is comprised and open_basedir is disabled, the attacker can potentially gain access to your files too.
Naturally, Community in the Cloud customers needn't worry about either of these steps - we've already handled it for you!
 
So there we go - a brief overview of 7 common-sense ways you can better protect your community and its users. As software developers, we're constantly working to improve the behind-the-scenes security of our software, but as an administrator, there's also a number of steps you should take to keep your community safe on the web.
If you have any tips related to security, be sure to share them in the comments!

Security should never be an afterthought for your community. All too often, site owners consider beefing up their security only when it's too late and their community has already been compromised. Taking some time now to check and improve the security of your community and server could pay dividends by eliminating the cost and hassle of falling victim to hacking in the first place.
Let's run down 7 ways that you can protect your community with the IPS Community Suite, from security features you may not know about to best practices all communities should be following.
 
1. Be selective when adding administrators
Administrator permissions can be extremely damaging in the wrong hands, and granting administrator powers should only be done with great consideration. Granting access to the AdminCP is like handing someone the keys to your house, so before doing so, be sure you really trust the person and that their role requires access to the AdminCP (for example, would moderator permissions be sufficient for the new staff member?).
Don't forget to remove administrator access promptly when necessary too, such as the member of staff leaving your organization. Always be aware of exactly who has administrator access at any given time, and review regularly. You can list all accounts that have AdminCP access by clicking the List Administrators button on the System -> Security page.
2. Utilize Admin Restrictions
In many organizations, staff roles within the community reflect real-world roles - designers need access to templates, accounting needs access to billing, and so forth. IPS4 allows you to limit administrator access to very specific areas of the AdminCP with the Admin Restrictions feature, and even limit what can be done within those areas. This is a great approach for limiting risk to your data; by giving staff members access to only the areas they need to perform their duties, you reduce the potential impact should their account become compromised in future.
3. Choose good passwords
This seems like an obvious suggestion, but surveys regularly show that people choose passwords that are simply too easy to guess or brute force. Your password is naturally the most basic protection of your AdminCP there is, so making sure you're using a good password is essential.
We recommend using a password manager application such as 1password or LastPass. These applications generate strong, random passwords for each site you use, and store them so that you don't have to remember them.
Even if you don't use a password manager, make sure the passwords you use for your community are unique and never used for others sites too.
4. Stay up to date
It's a fact of software development that from time to time new security issues are reported and promptly fixed. But if you're running several versions behind, once security issues are made public through responsible disclosure, malicious users can exploit those weaknesses in your community.
When we release new updates - especially if they're marked as a security release in our release notes - be sure to update as promptly as you can so you receive the latest fixes. Your AdminCP will also let you know when a new version is ready for download.
5. Use .htaccess protection for your AdminCP
In addition to IPS4's own AdminCP login page, you can set up browser-level authentication, giving you a double layer of protection. This is done via a special .htaccess file which instructs the server to prompt for authentication before access to the page is granted. IPS4 can automatically generate this file for you - simply go to System -> Security in your AdminCP, and enable the "Add a secondary admin password" rule.
And it should go without saying, but to be clear: don't use the same username or password for both your .htaccess login and your admin account, or the measure is redundant!
6. Restrict your AdminCP to an IP range where possible
If your organization has a static IP or requires staff members to use a VPN, you can add an additional layer of security to your community by prohibiting access to the AdminCP unless the user's IP matches your whitelist. This is a server-level feature, so consult your IT team or host to find out how to set it up in your particular environment. If you're a Community in the Cloud customer, contact our support team if you'd like to set up this protection for your account.
7. Properly secure your PHP installation
Many of PHP's built-in functions can leave a server vulnerable to high-impact exploits, and yet many of these functions aren't needed by the vast majority of PHP applications you might run. We therefore recommend that you explicitly disable these functions using PHP's disable_functions configuration setting. Here's our recommended configuration, although you or your host may need to tweak the list depending on your exact needs:
disable_functions = escapeshellarg,escapeshellcmd,exec,ini_alter,parse_ini_file,passthru,pcntl_exec,popen,proc_close,proc_get_status,proc_nice,proc_open,proc_terminate,show_source,shell_exec,symlink,system Another critical PHP configuration setting you need to check is that open_basedir is enabled, especially if you're hosted on a server that also hosts other websites (known as shared hosting). If another account on the server is comprised and open_basedir is disabled, the attacker can potentially gain access to your files too.
Naturally, Community in the Cloud customers needn't worry about either of these steps - we've already handled it for you!
 
So there we go - a brief overview of 7 common-sense ways you can better protect your community and its users. As software developers, we're constantly working to improve the behind-the-scenes security of our software, but as an administrator, there's also a number of steps you should take to keep your community safe on the web.
If you have any tips related to security, be sure to share them in the comments!

Security should never be an afterthought for your community. All too often, site owners consider beefing up their security only when it's too late and their community has already been compromised. Taking some time now to check and improve the security of your community and server could pay dividends by eliminating the cost and hassle of falling victim to hacking in the first place.
Let's run down 7 ways that you can protect your community with the IPS Community Suite, from security features you may not know about to best practices all communities should be following.
 
1. Be selective when adding administrators
Administrator permissions can be extremely damaging in the wrong hands, and granting administrator powers should only be done with great consideration. Granting access to the AdminCP is like handing someone the keys to your house, so before doing so, be sure you really trust the person and that their role requires access to the AdminCP (for example, would moderator permissions be sufficient for the new staff member?).
Don't forget to remove administrator access promptly when necessary too, such as the member of staff leaving your organization. Always be aware of exactly who has administrator access at any given time, and review regularly. You can list all accounts that have AdminCP access by clicking the List Administrators button on the System -> Security page.
2. Utilize Admin Restrictions
In many organizations, staff roles within the community reflect real-world roles - designers need access to templates, accounting needs access to billing, and so forth. IPS4 allows you to limit administrator access to very specific areas of the AdminCP with the Admin Restrictions feature, and even limit what can be done within those areas. This is a great approach for limiting risk to your data; by giving staff members access to only the areas they need to perform their duties, you reduce the potential impact should their account become compromised in future.
3. Choose good passwords
This seems like an obvious suggestion, but surveys regularly show that people choose passwords that are simply too easy to guess or brute force. Your password is naturally the most basic protection of your AdminCP there is, so making sure you're using a good password is essential.
We recommend using a password manager application such as 1password or LastPass. These applications generate strong, random passwords for each site you use, and store them so that you don't have to remember them.
Even if you don't use a password manager, make sure the passwords you use for your community are unique and never used for others sites too.
4. Stay up to date
It's a fact of software development that from time to time new security issues are reported and promptly fixed. But if you're running several versions behind, once security issues are made public through responsible disclosure, malicious users can exploit those weaknesses in your community.
When we release new updates - especially if they're marked as a security release in our release notes - be sure to update as promptly as you can so you receive the latest fixes. Your AdminCP will also let you know when a new version is ready for download.
5. Use .htaccess protection for your AdminCP
In addition to IPS4's own AdminCP login page, you can set up browser-level authentication, giving you a double layer of protection. This is done via a special .htaccess file which instructs the server to prompt for authentication before access to the page is granted. IPS4 can automatically generate this file for you - simply go to System -> Security in your AdminCP, and enable the "Add a secondary admin password" rule.
And it should go without saying, but to be clear: don't use the same username or password for both your .htaccess login and your admin account, or the measure is redundant!
6. Restrict your AdminCP to an IP range where possible
If your organization has a static IP or requires staff members to use a VPN, you can add an additional layer of security to your community by prohibiting access to the AdminCP unless the user's IP matches your whitelist. This is a server-level feature, so consult your IT team or host to find out how to set it up in your particular environment. If you're a Community in the Cloud customer, contact our support team if you'd like to set up this protection for your account.
7. Properly secure your PHP installation
Many of PHP's built-in functions can leave a server vulnerable to high-impact exploits, and yet many of these functions aren't needed by the vast majority of PHP applications you might run. We therefore recommend that you explicitly disable these functions using PHP's disable_functions configuration setting. Here's our recommended configuration, although you or your host may need to tweak the list depending on your exact needs:
disable_functions = escapeshellarg,escapeshellcmd,exec,ini_alter,parse_ini_file,passthru,pcntl_exec,popen,proc_close,proc_get_status,proc_nice,proc_open,proc_terminate,show_source,shell_exec,symlink,system Another critical PHP configuration setting you need to check is that open_basedir is enabled, especially if you're hosted on a server that also hosts other websites (known as shared hosting). If another account on the server is comprised and open_basedir is disabled, the attacker can potentially gain access to your files too.
Naturally, Community in the Cloud customers needn't worry about either of these steps - we've already handled it for you!
 
So there we go - a brief overview of 7 common-sense ways you can better protect your community and its users. As software developers, we're constantly working to improve the behind-the-scenes security of our software, but as an administrator, there's also a number of steps you should take to keep your community safe on the web.
If you have any tips related to security, be sure to share them in the comments!

Security should never be an afterthought for your community. All too often, site owners consider beefing up their security only when it's too late and their community has already been compromised. Taking some time now to check and improve the security of your community and server could pay dividends by eliminating the cost and hassle of falling victim to hacking in the first place.
Let's run down 7 ways that you can protect your community with the IPS Community Suite, from security features you may not know about to best practices all communities should be following.
 
1. Be selective when adding administrators
Administrator permissions can be extremely damaging in the wrong hands, and granting administrator powers should only be done with great consideration. Granting access to the AdminCP is like handing someone the keys to your house, so before doing so, be sure you really trust the person and that their role requires access to the AdminCP (for example, would moderator permissions be sufficient for the new staff member?).
Don't forget to remove administrator access promptly when necessary too, such as the member of staff leaving your organization. Always be aware of exactly who has administrator access at any given time, and review regularly. You can list all accounts that have AdminCP access by clicking the List Administrators button on the System -> Security page.
2. Utilize Admin Restrictions
In many organizations, staff roles within the community reflect real-world roles - designers need access to templates, accounting needs access to billing, and so forth. IPS4 allows you to limit administrator access to very specific areas of the AdminCP with the Admin Restrictions feature, and even limit what can be done within those areas. This is a great approach for limiting risk to your data; by giving staff members access to only the areas they need to perform their duties, you reduce the potential impact should their account become compromised in future.
3. Choose good passwords
This seems like an obvious suggestion, but surveys regularly show that people choose passwords that are simply too easy to guess or brute force. Your password is naturally the most basic protection of your AdminCP there is, so making sure you're using a good password is essential.
We recommend using a password manager application such as 1password or LastPass. These applications generate strong, random passwords for each site you use, and store them so that you don't have to remember them.
Even if you don't use a password manager, make sure the passwords you use for your community are unique and never used for others sites too.
4. Stay up to date
It's a fact of software development that from time to time new security issues are reported and promptly fixed. But if you're running several versions behind, once security issues are made public through responsible disclosure, malicious users can exploit those weaknesses in your community.
When we release new updates - especially if they're marked as a security release in our release notes - be sure to update as promptly as you can so you receive the latest fixes. Your AdminCP will also let you know when a new version is ready for download.
5. Use .htaccess protection for your AdminCP
In addition to IPS4's own AdminCP login page, you can set up browser-level authentication, giving you a double layer of protection. This is done via a special .htaccess file which instructs the server to prompt for authentication before access to the page is granted. IPS4 can automatically generate this file for you - simply go to System -> Security in your AdminCP, and enable the "Add a secondary admin password" rule.
And it should go without saying, but to be clear: don't use the same username or password for both your .htaccess login and your admin account, or the measure is redundant!
6. Restrict your AdminCP to an IP range where possible
If your organization has a static IP or requires staff members to use a VPN, you can add an additional layer of security to your community by prohibiting access to the AdminCP unless the user's IP matches your whitelist. This is a server-level feature, so consult your IT team or host to find out how to set it up in your particular environment. If you're a Community in the Cloud customer, contact our support team if you'd like to set up this protection for your account.
7. Properly secure your PHP installation
Many of PHP's built-in functions can leave a server vulnerable to high-impact exploits, and yet many of these functions aren't needed by the vast majority of PHP applications you might run. We therefore recommend that you explicitly disable these functions using PHP's disable_functions configuration setting. Here's our recommended configuration, although you or your host may need to tweak the list depending on your exact needs:
disable_functions = escapeshellarg,escapeshellcmd,exec,ini_alter,parse_ini_file,passthru,pcntl_exec,popen,proc_close,proc_get_status,proc_nice,proc_open,proc_terminate,show_source,shell_exec,symlink,system Another critical PHP configuration setting you need to check is that open_basedir is enabled, especially if you're hosted on a server that also hosts other websites (known as shared hosting). If another account on the server is comprised and open_basedir is disabled, the attacker can potentially gain access to your files too.
Naturally, Community in the Cloud customers needn't worry about either of these steps - we've already handled it for you!
 
So there we go - a brief overview of 7 common-sense ways you can better protect your community and its users. As software developers, we're constantly working to improve the behind-the-scenes security of our software, but as an administrator, there's also a number of steps you should take to keep your community safe on the web.
If you have any tips related to security, be sure to share them in the comments!

Security should never be an afterthought for your community. All too often, site owners consider beefing up their security only when it's too late and their community has already been compromised. Taking some time now to check and improve the security of your community and server could pay dividends by eliminating the cost and hassle of falling victim to hacking in the first place.
Let's run down 7 ways that you can protect your community with the IPS Community Suite, from security features you may not know about to best practices all communities should be following.
 
1. Be selective when adding administrators
Administrator permissions can be extremely damaging in the wrong hands, and granting administrator powers should only be done with great consideration. Granting access to the AdminCP is like handing someone the keys to your house, so before doing so, be sure you really trust the person and that their role requires access to the AdminCP (for example, would moderator permissions be sufficient for the new staff member?).
Don't forget to remove administrator access promptly when necessary too, such as the member of staff leaving your organization. Always be aware of exactly who has administrator access at any given time, and review regularly. You can list all accounts that have AdminCP access by clicking the List Administrators button on the System -> Security page.
2. Utilize Admin Restrictions
In many organizations, staff roles within the community reflect real-world roles - designers need access to templates, accounting needs access to billing, and so forth. IPS4 allows you to limit administrator access to very specific areas of the AdminCP with the Admin Restrictions feature, and even limit what can be done within those areas. This is a great approach for limiting risk to your data; by giving staff members access to only the areas they need to perform their duties, you reduce the potential impact should their account become compromised in future.
3. Choose good passwords
This seems like an obvious suggestion, but surveys regularly show that people choose passwords that are simply too easy to guess or brute force. Your password is naturally the most basic protection of your AdminCP there is, so making sure you're using a good password is essential.
We recommend using a password manager application such as 1password or LastPass. These applications generate strong, random passwords for each site you use, and store them so that you don't have to remember them.
Even if you don't use a password manager, make sure the passwords you use for your community are unique and never used for others sites too.
4. Stay up to date
It's a fact of software development that from time to time new security issues are reported and promptly fixed. But if you're running several versions behind, once security issues are made public through responsible disclosure, malicious users can exploit those weaknesses in your community.
When we release new updates - especially if they're marked as a security release in our release notes - be sure to update as promptly as you can so you receive the latest fixes. Your AdminCP will also let you know when a new version is ready for download.
5. Use .htaccess protection for your AdminCP
In addition to IPS4's own AdminCP login page, you can set up browser-level authentication, giving you a double layer of protection. This is done via a special .htaccess file which instructs the server to prompt for authentication before access to the page is granted. IPS4 can automatically generate this file for you - simply go to System -> Security in your AdminCP, and enable the "Add a secondary admin password" rule.
And it should go without saying, but to be clear: don't use the same username or password for both your .htaccess login and your admin account, or the measure is redundant!
6. Restrict your AdminCP to an IP range where possible
If your organization has a static IP or requires staff members to use a VPN, you can add an additional layer of security to your community by prohibiting access to the AdminCP unless the user's IP matches your whitelist. This is a server-level feature, so consult your IT team or host to find out how to set it up in your particular environment. If you're a Community in the Cloud customer, contact our support team if you'd like to set up this protection for your account.
7. Properly secure your PHP installation
Many of PHP's built-in functions can leave a server vulnerable to high-impact exploits, and yet many of these functions aren't needed by the vast majority of PHP applications you might run. We therefore recommend that you explicitly disable these functions using PHP's disable_functions configuration setting. Here's our recommended configuration, although you or your host may need to tweak the list depending on your exact needs:
disable_functions = escapeshellarg,escapeshellcmd,exec,ini_alter,parse_ini_file,passthru,pcntl_exec,popen,proc_close,proc_get_status,proc_nice,proc_open,proc_terminate,show_source,shell_exec,symlink,system Another critical PHP configuration setting you need to check is that open_basedir is enabled, especially if you're hosted on a server that also hosts other websites (known as shared hosting). If another account on the server is comprised and open_basedir is disabled, the attacker can potentially gain access to your files too.
Naturally, Community in the Cloud customers needn't worry about either of these steps - we've already handled it for you!
 
So there we go - a brief overview of 7 common-sense ways you can better protect your community and its users. As software developers, we're constantly working to improve the behind-the-scenes security of our software, but as an administrator, there's also a number of steps you should take to keep your community safe on the web.
If you have any tips related to security, be sure to share them 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! 
 

Security should never be an afterthought for your community. All too often, site owners consider beefing up their security only when it's too late and their community has already been compromised. Taking some time now to check and improve the security of your community and server could pay dividends by eliminating the cost and hassle of falling victim to hacking in the first place.
Let's run down 7 ways that you can protect your community with the IPS Community Suite, from security features you may not know about to best practices all communities should be following.
 
1. Be selective when adding administrators
Administrator permissions can be extremely damaging in the wrong hands, and granting administrator powers should only be done with great consideration. Granting access to the AdminCP is like handing someone the keys to your house, so before doing so, be sure you really trust the person and that their role requires access to the AdminCP (for example, would moderator permissions be sufficient for the new staff member?).
Don't forget to remove administrator access promptly when necessary too, such as the member of staff leaving your organization. Always be aware of exactly who has administrator access at any given time, and review regularly. You can list all accounts that have AdminCP access by clicking the List Administrators button on the System -> Security page.
2. Utilize Admin Restrictions
In many organizations, staff roles within the community reflect real-world roles - designers need access to templates, accounting needs access to billing, and so forth. IPS4 allows you to limit administrator access to very specific areas of the AdminCP with the Admin Restrictions feature, and even limit what can be done within those areas. This is a great approach for limiting risk to your data; by giving staff members access to only the areas they need to perform their duties, you reduce the potential impact should their account become compromised in future.
3. Choose good passwords
This seems like an obvious suggestion, but surveys regularly show that people choose passwords that are simply too easy to guess or brute force. Your password is naturally the most basic protection of your AdminCP there is, so making sure you're using a good password is essential.
We recommend using a password manager application such as 1password or LastPass. These applications generate strong, random passwords for each site you use, and store them so that you don't have to remember them.
Even if you don't use a password manager, make sure the passwords you use for your community are unique and never used for others sites too.
4. Stay up to date
It's a fact of software development that from time to time new security issues are reported and promptly fixed. But if you're running several versions behind, once security issues are made public through responsible disclosure, malicious users can exploit those weaknesses in your community.
When we release new updates - especially if they're marked as a security release in our release notes - be sure to update as promptly as you can so you receive the latest fixes. Your AdminCP will also let you know when a new version is ready for download.
5. Use .htaccess protection for your AdminCP
In addition to IPS4's own AdminCP login page, you can set up browser-level authentication, giving you a double layer of protection. This is done via a special .htaccess file which instructs the server to prompt for authentication before access to the page is granted. IPS4 can automatically generate this file for you - simply go to System -> Security in your AdminCP, and enable the "Add a secondary admin password" rule.
And it should go without saying, but to be clear: don't use the same username or password for both your .htaccess login and your admin account, or the measure is redundant!
6. Restrict your AdminCP to an IP range where possible
If your organization has a static IP or requires staff members to use a VPN, you can add an additional layer of security to your community by prohibiting access to the AdminCP unless the user's IP matches your whitelist. This is a server-level feature, so consult your IT team or host to find out how to set it up in your particular environment. If you're a Community in the Cloud customer, contact our support team if you'd like to set up this protection for your account.
7. Properly secure your PHP installation
Many of PHP's built-in functions can leave a server vulnerable to high-impact exploits, and yet many of these functions aren't needed by the vast majority of PHP applications you might run. We therefore recommend that you explicitly disable these functions using PHP's disable_functions configuration setting. Here's our recommended configuration, although you or your host may need to tweak the list depending on your exact needs:
disable_functions = escapeshellarg,escapeshellcmd,exec,ini_alter,parse_ini_file,passthru,pcntl_exec,popen,proc_close,proc_get_status,proc_nice,proc_open,proc_terminate,show_source,shell_exec,symlink,system Another critical PHP configuration setting you need to check is that open_basedir is enabled, especially if you're hosted on a server that also hosts other websites (known as shared hosting). If another account on the server is comprised and open_basedir is disabled, the attacker can potentially gain access to your files too.
Naturally, Community in the Cloud customers needn't worry about either of these steps - we've already handled it for you!
 
So there we go - a brief overview of 7 common-sense ways you can better protect your community and its users. As software developers, we're constantly working to improve the behind-the-scenes security of our software, but as an administrator, there's also a number of steps you should take to keep your community safe on the web.
If you have any tips related to security, be sure to share them in the comments!

Security should never be an afterthought for your community. All too often, site owners consider beefing up their security only when it's too late and their community has already been compromised. Taking some time now to check and improve the security of your community and server could pay dividends by eliminating the cost and hassle of falling victim to hacking in the first place.
Let's run down 7 ways that you can protect your community with the IPS Community Suite, from security features you may not know about to best practices all communities should be following.
 
1. Be selective when adding administrators
Administrator permissions can be extremely damaging in the wrong hands, and granting administrator powers should only be done with great consideration. Granting access to the AdminCP is like handing someone the keys to your house, so before doing so, be sure you really trust the person and that their role requires access to the AdminCP (for example, would moderator permissions be sufficient for the new staff member?).
Don't forget to remove administrator access promptly when necessary too, such as the member of staff leaving your organization. Always be aware of exactly who has administrator access at any given time, and review regularly. You can list all accounts that have AdminCP access by clicking the List Administrators button on the System -> Security page.
2. Utilize Admin Restrictions
In many organizations, staff roles within the community reflect real-world roles - designers need access to templates, accounting needs access to billing, and so forth. IPS4 allows you to limit administrator access to very specific areas of the AdminCP with the Admin Restrictions feature, and even limit what can be done within those areas. This is a great approach for limiting risk to your data; by giving staff members access to only the areas they need to perform their duties, you reduce the potential impact should their account become compromised in future.
3. Choose good passwords
This seems like an obvious suggestion, but surveys regularly show that people choose passwords that are simply too easy to guess or brute force. Your password is naturally the most basic protection of your AdminCP there is, so making sure you're using a good password is essential.
We recommend using a password manager application such as 1password or LastPass. These applications generate strong, random passwords for each site you use, and store them so that you don't have to remember them.
Even if you don't use a password manager, make sure the passwords you use for your community are unique and never used for others sites too.
4. Stay up to date
It's a fact of software development that from time to time new security issues are reported and promptly fixed. But if you're running several versions behind, once security issues are made public through responsible disclosure, malicious users can exploit those weaknesses in your community.
When we release new updates - especially if they're marked as a security release in our release notes - be sure to update as promptly as you can so you receive the latest fixes. Your AdminCP will also let you know when a new version is ready for download.
5. Use .htaccess protection for your AdminCP
In addition to IPS4's own AdminCP login page, you can set up browser-level authentication, giving you a double layer of protection. This is done via a special .htaccess file which instructs the server to prompt for authentication before access to the page is granted. IPS4 can automatically generate this file for you - simply go to System -> Security in your AdminCP, and enable the "Add a secondary admin password" rule.
And it should go without saying, but to be clear: don't use the same username or password for both your .htaccess login and your admin account, or the measure is redundant!
6. Restrict your AdminCP to an IP range where possible
If your organization has a static IP or requires staff members to use a VPN, you can add an additional layer of security to your community by prohibiting access to the AdminCP unless the user's IP matches your whitelist. This is a server-level feature, so consult your IT team or host to find out how to set it up in your particular environment. If you're a Community in the Cloud customer, contact our support team if you'd like to set up this protection for your account.
7. Properly secure your PHP installation
Many of PHP's built-in functions can leave a server vulnerable to high-impact exploits, and yet many of these functions aren't needed by the vast majority of PHP applications you might run. We therefore recommend that you explicitly disable these functions using PHP's disable_functions configuration setting. Here's our recommended configuration, although you or your host may need to tweak the list depending on your exact needs:
disable_functions = escapeshellarg,escapeshellcmd,exec,ini_alter,parse_ini_file,passthru,pcntl_exec,popen,proc_close,proc_get_status,proc_nice,proc_open,proc_terminate,show_source,shell_exec,symlink,system Another critical PHP configuration setting you need to check is that open_basedir is enabled, especially if you're hosted on a server that also hosts other websites (known as shared hosting). If another account on the server is comprised and open_basedir is disabled, the attacker can potentially gain access to your files too.
Naturally, Community in the Cloud customers needn't worry about either of these steps - we've already handled it for you!
 
So there we go - a brief overview of 7 common-sense ways you can better protect your community and its users. As software developers, we're constantly working to improve the behind-the-scenes security of our software, but as an administrator, there's also a number of steps you should take to keep your community safe on the web.
If you have any tips related to security, be sure to share them in the comments!

Security should never be an afterthought for your community. All too often, site owners consider beefing up their security only when it's too late and their community has already been compromised. Taking some time now to check and improve the security of your community and server could pay dividends by eliminating the cost and hassle of falling victim to hacking in the first place.
Let's run down 7 ways that you can protect your community with the IPS Community Suite, from security features you may not know about to best practices all communities should be following.
 
1. Be selective when adding administrators
Administrator permissions can be extremely damaging in the wrong hands, and granting administrator powers should only be done with great consideration. Granting access to the AdminCP is like handing someone the keys to your house, so before doing so, be sure you really trust the person and that their role requires access to the AdminCP (for example, would moderator permissions be sufficient for the new staff member?).
Don't forget to remove administrator access promptly when necessary too, such as the member of staff leaving your organization. Always be aware of exactly who has administrator access at any given time, and review regularly. You can list all accounts that have AdminCP access by clicking the List Administrators button on the System -> Security page.
2. Utilize Admin Restrictions
In many organizations, staff roles within the community reflect real-world roles - designers need access to templates, accounting needs access to billing, and so forth. IPS4 allows you to limit administrator access to very specific areas of the AdminCP with the Admin Restrictions feature, and even limit what can be done within those areas. This is a great approach for limiting risk to your data; by giving staff members access to only the areas they need to perform their duties, you reduce the potential impact should their account become compromised in future.
3. Choose good passwords
This seems like an obvious suggestion, but surveys regularly show that people choose passwords that are simply too easy to guess or brute force. Your password is naturally the most basic protection of your AdminCP there is, so making sure you're using a good password is essential.
We recommend using a password manager application such as 1password or LastPass. These applications generate strong, random passwords for each site you use, and store them so that you don't have to remember them.
Even if you don't use a password manager, make sure the passwords you use for your community are unique and never used for others sites too.
4. Stay up to date
It's a fact of software development that from time to time new security issues are reported and promptly fixed. But if you're running several versions behind, once security issues are made public through responsible disclosure, malicious users can exploit those weaknesses in your community.
When we release new updates - especially if they're marked as a security release in our release notes - be sure to update as promptly as you can so you receive the latest fixes. Your AdminCP will also let you know when a new version is ready for download.
5. Use .htaccess protection for your AdminCP
In addition to IPS4's own AdminCP login page, you can set up browser-level authentication, giving you a double layer of protection. This is done via a special .htaccess file which instructs the server to prompt for authentication before access to the page is granted. IPS4 can automatically generate this file for you - simply go to System -> Security in your AdminCP, and enable the "Add a secondary admin password" rule.
And it should go without saying, but to be clear: don't use the same username or password for both your .htaccess login and your admin account, or the measure is redundant!
6. Restrict your AdminCP to an IP range where possible
If your organization has a static IP or requires staff members to use a VPN, you can add an additional layer of security to your community by prohibiting access to the AdminCP unless the user's IP matches your whitelist. This is a server-level feature, so consult your IT team or host to find out how to set it up in your particular environment. If you're a Community in the Cloud customer, contact our support team if you'd like to set up this protection for your account.
7. Properly secure your PHP installation
Many of PHP's built-in functions can leave a server vulnerable to high-impact exploits, and yet many of these functions aren't needed by the vast majority of PHP applications you might run. We therefore recommend that you explicitly disable these functions using PHP's disable_functions configuration setting. Here's our recommended configuration, although you or your host may need to tweak the list depending on your exact needs:
disable_functions = escapeshellarg,escapeshellcmd,exec,ini_alter,parse_ini_file,passthru,pcntl_exec,popen,proc_close,proc_get_status,proc_nice,proc_open,proc_terminate,show_source,shell_exec,symlink,system Another critical PHP configuration setting you need to check is that open_basedir is enabled, especially if you're hosted on a server that also hosts other websites (known as shared hosting). If another account on the server is comprised and open_basedir is disabled, the attacker can potentially gain access to your files too.
Naturally, Community in the Cloud customers needn't worry about either of these steps - we've already handled it for you!
 
So there we go - a brief overview of 7 common-sense ways you can better protect your community and its users. As software developers, we're constantly working to improve the behind-the-scenes security of our software, but as an administrator, there's also a number of steps you should take to keep your community safe on the web.
If you have any tips related to security, be sure to share them in the comments!

Security should never be an afterthought for your community. All too often, site owners consider beefing up their security only when it's too late and their community has already been compromised. Taking some time now to check and improve the security of your community and server could pay dividends by eliminating the cost and hassle of falling victim to hacking in the first place.
Let's run down 7 ways that you can protect your community with the IPS Community Suite, from security features you may not know about to best practices all communities should be following.
 
1. Be selective when adding administrators
Administrator permissions can be extremely damaging in the wrong hands, and granting administrator powers should only be done with great consideration. Granting access to the AdminCP is like handing someone the keys to your house, so before doing so, be sure you really trust the person and that their role requires access to the AdminCP (for example, would moderator permissions be sufficient for the new staff member?).
Don't forget to remove administrator access promptly when necessary too, such as the member of staff leaving your organization. Always be aware of exactly who has administrator access at any given time, and review regularly. You can list all accounts that have AdminCP access by clicking the List Administrators button on the System -> Security page.
2. Utilize Admin Restrictions
In many organizations, staff roles within the community reflect real-world roles - designers need access to templates, accounting needs access to billing, and so forth. IPS4 allows you to limit administrator access to very specific areas of the AdminCP with the Admin Restrictions feature, and even limit what can be done within those areas. This is a great approach for limiting risk to your data; by giving staff members access to only the areas they need to perform their duties, you reduce the potential impact should their account become compromised in future.
3. Choose good passwords
This seems like an obvious suggestion, but surveys regularly show that people choose passwords that are simply too easy to guess or brute force. Your password is naturally the most basic protection of your AdminCP there is, so making sure you're using a good password is essential.
We recommend using a password manager application such as 1password or LastPass. These applications generate strong, random passwords for each site you use, and store them so that you don't have to remember them.
Even if you don't use a password manager, make sure the passwords you use for your community are unique and never used for others sites too.
4. Stay up to date
It's a fact of software development that from time to time new security issues are reported and promptly fixed. But if you're running several versions behind, once security issues are made public through responsible disclosure, malicious users can exploit those weaknesses in your community.
When we release new updates - especially if they're marked as a security release in our release notes - be sure to update as promptly as you can so you receive the latest fixes. Your AdminCP will also let you know when a new version is ready for download.
5. Use .htaccess protection for your AdminCP
In addition to IPS4's own AdminCP login page, you can set up browser-level authentication, giving you a double layer of protection. This is done via a special .htaccess file which instructs the server to prompt for authentication before access to the page is granted. IPS4 can automatically generate this file for you - simply go to System -> Security in your AdminCP, and enable the "Add a secondary admin password" rule.
And it should go without saying, but to be clear: don't use the same username or password for both your .htaccess login and your admin account, or the measure is redundant!
6. Restrict your AdminCP to an IP range where possible
If your organization has a static IP or requires staff members to use a VPN, you can add an additional layer of security to your community by prohibiting access to the AdminCP unless the user's IP matches your whitelist. This is a server-level feature, so consult your IT team or host to find out how to set it up in your particular environment. If you're a Community in the Cloud customer, contact our support team if you'd like to set up this protection for your account.
7. Properly secure your PHP installation
Many of PHP's built-in functions can leave a server vulnerable to high-impact exploits, and yet many of these functions aren't needed by the vast majority of PHP applications you might run. We therefore recommend that you explicitly disable these functions using PHP's disable_functions configuration setting. Here's our recommended configuration, although you or your host may need to tweak the list depending on your exact needs:
disable_functions = escapeshellarg,escapeshellcmd,exec,ini_alter,parse_ini_file,passthru,pcntl_exec,popen,proc_close,proc_get_status,proc_nice,proc_open,proc_terminate,show_source,shell_exec,symlink,system Another critical PHP configuration setting you need to check is that open_basedir is enabled, especially if you're hosted on a server that also hosts other websites (known as shared hosting). If another account on the server is comprised and open_basedir is disabled, the attacker can potentially gain access to your files too.
Naturally, Community in the Cloud customers needn't worry about either of these steps - we've already handled it for you!
 
So there we go - a brief overview of 7 common-sense ways you can better protect your community and its users. As software developers, we're constantly working to improve the behind-the-scenes security of our software, but as an administrator, there's also a number of steps you should take to keep your community safe on the web.
If you have any tips related to security, be sure to share them in the comments!

Security should never be an afterthought for your community. All too often, site owners consider beefing up their security only when it's too late and their community has already been compromised. Taking some time now to check and improve the security of your community and server could pay dividends by eliminating the cost and hassle of falling victim to hacking in the first place.
Let's run down 7 ways that you can protect your community with the IPS Community Suite, from security features you may not know about to best practices all communities should be following.
 
1. Be selective when adding administrators
Administrator permissions can be extremely damaging in the wrong hands, and granting administrator powers should only be done with great consideration. Granting access to the AdminCP is like handing someone the keys to your house, so before doing so, be sure you really trust the person and that their role requires access to the AdminCP (for example, would moderator permissions be sufficient for the new staff member?).
Don't forget to remove administrator access promptly when necessary too, such as the member of staff leaving your organization. Always be aware of exactly who has administrator access at any given time, and review regularly. You can list all accounts that have AdminCP access by clicking the List Administrators button on the System -> Security page.
2. Utilize Admin Restrictions
In many organizations, staff roles within the community reflect real-world roles - designers need access to templates, accounting needs access to billing, and so forth. IPS4 allows you to limit administrator access to very specific areas of the AdminCP with the Admin Restrictions feature, and even limit what can be done within those areas. This is a great approach for limiting risk to your data; by giving staff members access to only the areas they need to perform their duties, you reduce the potential impact should their account become compromised in future.
3. Choose good passwords
This seems like an obvious suggestion, but surveys regularly show that people choose passwords that are simply too easy to guess or brute force. Your password is naturally the most basic protection of your AdminCP there is, so making sure you're using a good password is essential.
We recommend using a password manager application such as 1password or LastPass. These applications generate strong, random passwords for each site you use, and store them so that you don't have to remember them.
Even if you don't use a password manager, make sure the passwords you use for your community are unique and never used for others sites too.
4. Stay up to date
It's a fact of software development that from time to time new security issues are reported and promptly fixed. But if you're running several versions behind, once security issues are made public through responsible disclosure, malicious users can exploit those weaknesses in your community.
When we release new updates - especially if they're marked as a security release in our release notes - be sure to update as promptly as you can so you receive the latest fixes. Your AdminCP will also let you know when a new version is ready for download.
5. Use .htaccess protection for your AdminCP
In addition to IPS4's own AdminCP login page, you can set up browser-level authentication, giving you a double layer of protection. This is done via a special .htaccess file which instructs the server to prompt for authentication before access to the page is granted. IPS4 can automatically generate this file for you - simply go to System -> Security in your AdminCP, and enable the "Add a secondary admin password" rule.
And it should go without saying, but to be clear: don't use the same username or password for both your .htaccess login and your admin account, or the measure is redundant!
6. Restrict your AdminCP to an IP range where possible
If your organization has a static IP or requires staff members to use a VPN, you can add an additional layer of security to your community by prohibiting access to the AdminCP unless the user's IP matches your whitelist. This is a server-level feature, so consult your IT team or host to find out how to set it up in your particular environment. If you're a Community in the Cloud customer, contact our support team if you'd like to set up this protection for your account.
7. Properly secure your PHP installation
Many of PHP's built-in functions can leave a server vulnerable to high-impact exploits, and yet many of these functions aren't needed by the vast majority of PHP applications you might run. We therefore recommend that you explicitly disable these functions using PHP's disable_functions configuration setting. Here's our recommended configuration, although you or your host may need to tweak the list depending on your exact needs:
disable_functions = escapeshellarg,escapeshellcmd,exec,ini_alter,parse_ini_file,passthru,pcntl_exec,popen,proc_close,proc_get_status,proc_nice,proc_open,proc_terminate,show_source,shell_exec,symlink,system Another critical PHP configuration setting you need to check is that open_basedir is enabled, especially if you're hosted on a server that also hosts other websites (known as shared hosting). If another account on the server is comprised and open_basedir is disabled, the attacker can potentially gain access to your files too.
Naturally, Community in the Cloud customers needn't worry about either of these steps - we've already handled it for you!
 
So there we go - a brief overview of 7 common-sense ways you can better protect your community and its users. As software developers, we're constantly working to improve the behind-the-scenes security of our software, but as an administrator, there's also a number of steps you should take to keep your community safe on the web.
If you have any tips related to security, be sure to share them 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! 
 

HTML Logic is our name for the additional tags available in IPS4's templates that allow runtime logic to be executed. It comprises if/then/else statements as well as loops and more.
Since HTML Logic has access to all of the underlying PHP framework in IPS4, it's very powerful and a lot can be achieved with it. One common use is to limit certain content within a template to particular member groups. Let's see how that might be done.
 
Showing or hiding content only to guests
We'll first look at a simpler idea: showing or hiding content specifically to guests (i.e. anyone who isn't logged in). Within IPS4, the \IPS\Member::loggedIn() object contains information about the current user. Guests always have a member_id of NULL (i.e. no value), so we can simply check that value in our logic tag:
{{if \IPS\Member::loggedIn()->member_id === NULL}} This content *only* shows to guests, since they have a NULL member_id. {{endif}} {{if \IPS\Member::loggedIn()->member_id}} This content *only* shows to logged-in users since their member_id is a number, which will equal true. {{endif}}  
Showing content only to specific groups
Let's go a bit further and this time show content to specific (primary) member groups. First, you need to get the IDs for the group(s) you want to deal with. You can find this by editing the group in the AdminCP, and making a note of the id parameter in the URL. On my installation, the Administrator group is ID 4 so we'll use that in our example.
Once again, we're using the \IPS\Member::loggedIn() object, but this time we're using the member_group_id property.
{{if \IPS\Member::loggedIn()->member_group_id === 4}} This content only shows to members in the "Administrators" group (ID 4 in our example) {{endif}}  
Working with multiple groups at once
Following the code above, you could simply repeat the check against \IPS\Member::loggedIn()->member_group_id several times, for each ID you want to allow. However, since our templates allow arbitrary PHP expressions to be used, there's a neater way: use an array of member group IDs you want to allow, and check against that using PHP's in_array function. Here's an example where we only show content to group IDs 2, 4 and 6:
{{if in_array( \IPS\Member::loggedIn()->member_group_id, array( 2, 4, 6 ) )}} This content only shows to members in groups with the ID 2, 4 or 6. {{endif}}  
Have a request for a theme tip? Let us know in the comments and we'll try and help out in a future tip! 

HTML Logic is our name for the additional tags available in IPS4's templates that allow runtime logic to be executed. It comprises if/then/else statements as well as loops and more.
Since HTML Logic has access to all of the underlying PHP framework in IPS4, it's very powerful and a lot can be achieved with it. One common use is to limit certain content within a template to particular member groups. Let's see how that might be done.
 
Showing or hiding content only to guests
We'll first look at a simpler idea: showing or hiding content specifically to guests (i.e. anyone who isn't logged in). Within IPS4, the \IPS\Member::loggedIn() object contains information about the current user. Guests always have a member_id of NULL (i.e. no value), so we can simply check that value in our logic tag:
{{if \IPS\Member::loggedIn()->member_id === NULL}} This content *only* shows to guests, since they have a NULL member_id. {{endif}} {{if \IPS\Member::loggedIn()->member_id}} This content *only* shows to logged-in users since their member_id is a number, which will equal true. {{endif}}  
Showing content only to specific groups
Let's go a bit further and this time show content to specific (primary) member groups. First, you need to get the IDs for the group(s) you want to deal with. You can find this by editing the group in the AdminCP, and making a note of the id parameter in the URL. On my installation, the Administrator group is ID 4 so we'll use that in our example.
Once again, we're using the \IPS\Member::loggedIn() object, but this time we're using the member_group_id property.
{{if \IPS\Member::loggedIn()->member_group_id === 4}} This content only shows to members in the "Administrators" group (ID 4 in our example) {{endif}}  
Working with multiple groups at once
Following the code above, you could simply repeat the check against \IPS\Member::loggedIn()->member_group_id several times, for each ID you want to allow. However, since our templates allow arbitrary PHP expressions to be used, there's a neater way: use an array of member group IDs you want to allow, and check against that using PHP's in_array function. Here's an example where we only show content to group IDs 2, 4 and 6:
{{if in_array( \IPS\Member::loggedIn()->member_group_id, array( 2, 4, 6 ) )}} This content only shows to members in groups with the ID 2, 4 or 6. {{endif}}  
Have a request for a theme tip? Let us know in the comments and we'll try and help out in a future tip! 

HTML Logic is our name for the additional tags available in IPS4's templates that allow runtime logic to be executed. It comprises if/then/else statements as well as loops and more.
Since HTML Logic has access to all of the underlying PHP framework in IPS4, it's very powerful and a lot can be achieved with it. One common use is to limit certain content within a template to particular member groups. Let's see how that might be done.
 
Showing or hiding content only to guests
We'll first look at a simpler idea: showing or hiding content specifically to guests (i.e. anyone who isn't logged in). Within IPS4, the \IPS\Member::loggedIn() object contains information about the current user. Guests always have a member_id of NULL (i.e. no value), so we can simply check that value in our logic tag:
{{if \IPS\Member::loggedIn()->member_id === NULL}} This content *only* shows to guests, since they have a NULL member_id. {{endif}} {{if \IPS\Member::loggedIn()->member_id}} This content *only* shows to logged-in users since their member_id is a number, which will equal true. {{endif}}  
Showing content only to specific groups
Let's go a bit further and this time show content to specific (primary) member groups. First, you need to get the IDs for the group(s) you want to deal with. You can find this by editing the group in the AdminCP, and making a note of the id parameter in the URL. On my installation, the Administrator group is ID 4 so we'll use that in our example.
Once again, we're using the \IPS\Member::loggedIn() object, but this time we're using the member_group_id property.
{{if \IPS\Member::loggedIn()->member_group_id === 4}} This content only shows to members in the "Administrators" group (ID 4 in our example) {{endif}}  
Working with multiple groups at once
Following the code above, you could simply repeat the check against \IPS\Member::loggedIn()->member_group_id several times, for each ID you want to allow. However, since our templates allow arbitrary PHP expressions to be used, there's a neater way: use an array of member group IDs you want to allow, and check against that using PHP's in_array function. Here's an example where we only show content to group IDs 2, 4 and 6:
{{if in_array( \IPS\Member::loggedIn()->member_group_id, array( 2, 4, 6 ) )}} This content only shows to members in groups with the ID 2, 4 or 6. {{endif}}  
Have a request for a theme tip? Let us know in the comments and we'll try and help out in a future tip! 

HTML Logic is our name for the additional tags available in IPS4's templates that allow runtime logic to be executed. It comprises if/then/else statements as well as loops and more.
Since HTML Logic has access to all of the underlying PHP framework in IPS4, it's very powerful and a lot can be achieved with it. One common use is to limit certain content within a template to particular member groups. Let's see how that might be done.
 
Showing or hiding content only to guests
We'll first look at a simpler idea: showing or hiding content specifically to guests (i.e. anyone who isn't logged in). Within IPS4, the \IPS\Member::loggedIn() object contains information about the current user. Guests always have a member_id of NULL (i.e. no value), so we can simply check that value in our logic tag:
{{if \IPS\Member::loggedIn()->member_id === NULL}} This content *only* shows to guests, since they have a NULL member_id. {{endif}} {{if \IPS\Member::loggedIn()->member_id}} This content *only* shows to logged-in users since their member_id is a number, which will equal true. {{endif}}  
Showing content only to specific groups
Let's go a bit further and this time show content to specific (primary) member groups. First, you need to get the IDs for the group(s) you want to deal with. You can find this by editing the group in the AdminCP, and making a note of the id parameter in the URL. On my installation, the Administrator group is ID 4 so we'll use that in our example.
Once again, we're using the \IPS\Member::loggedIn() object, but this time we're using the member_group_id property.
{{if \IPS\Member::loggedIn()->member_group_id === 4}} This content only shows to members in the "Administrators" group (ID 4 in our example) {{endif}}  
Working with multiple groups at once
Following the code above, you could simply repeat the check against \IPS\Member::loggedIn()->member_group_id several times, for each ID you want to allow. However, since our templates allow arbitrary PHP expressions to be used, there's a neater way: use an array of member group IDs you want to allow, and check against that using PHP's in_array function. Here's an example where we only show content to group IDs 2, 4 and 6:
{{if in_array( \IPS\Member::loggedIn()->member_group_id, array( 2, 4, 6 ) )}} This content only shows to members in groups with the ID 2, 4 or 6. {{endif}}  
Have a request for a theme tip? Let us know in the comments and we'll try and help out in a future tip! 

HTML Logic is our name for the additional tags available in IPS4's templates that allow runtime logic to be executed. It comprises if/then/else statements as well as loops and more.
Since HTML Logic has access to all of the underlying PHP framework in IPS4, it's very powerful and a lot can be achieved with it. One common use is to limit certain content within a template to particular member groups. Let's see how that might be done.
 
Showing or hiding content only to guests
We'll first look at a simpler idea: showing or hiding content specifically to guests (i.e. anyone who isn't logged in). Within IPS4, the \IPS\Member::loggedIn() object contains information about the current user. Guests always have a member_id of NULL (i.e. no value), so we can simply check that value in our logic tag:
{{if \IPS\Member::loggedIn()->member_id === NULL}} This content *only* shows to guests, since they have a NULL member_id. {{endif}} {{if \IPS\Member::loggedIn()->member_id}} This content *only* shows to logged-in users since their member_id is a number, which will equal true. {{endif}}  
Showing content only to specific groups
Let's go a bit further and this time show content to specific (primary) member groups. First, you need to get the IDs for the group(s) you want to deal with. You can find this by editing the group in the AdminCP, and making a note of the id parameter in the URL. On my installation, the Administrator group is ID 4 so we'll use that in our example.
Once again, we're using the \IPS\Member::loggedIn() object, but this time we're using the member_group_id property.
{{if \IPS\Member::loggedIn()->member_group_id === 4}} This content only shows to members in the "Administrators" group (ID 4 in our example) {{endif}}  
Working with multiple groups at once
Following the code above, you could simply repeat the check against \IPS\Member::loggedIn()->member_group_id several times, for each ID you want to allow. However, since our templates allow arbitrary PHP expressions to be used, there's a neater way: use an array of member group IDs you want to allow, and check against that using PHP's in_array function. Here's an example where we only show content to group IDs 2, 4 and 6:
{{if in_array( \IPS\Member::loggedIn()->member_group_id, array( 2, 4, 6 ) )}} This content only shows to members in groups with the ID 2, 4 or 6. {{endif}}  
Have a request for a theme tip? Let us know in the comments and we'll try and help out in a future tip! 

HTML Logic is our name for the additional tags available in IPS4's templates that allow runtime logic to be executed. It comprises if/then/else statements as well as loops and more.
Since HTML Logic has access to all of the underlying PHP framework in IPS4, it's very powerful and a lot can be achieved with it. One common use is to limit certain content within a template to particular member groups. Let's see how that might be done.
 
Showing or hiding content only to guests
We'll first look at a simpler idea: showing or hiding content specifically to guests (i.e. anyone who isn't logged in). Within IPS4, the \IPS\Member::loggedIn() object contains information about the current user. Guests always have a member_id of NULL (i.e. no value), so we can simply check that value in our logic tag:
{{if \IPS\Member::loggedIn()->member_id === NULL}} This content *only* shows to guests, since they have a NULL member_id. {{endif}} {{if \IPS\Member::loggedIn()->member_id}} This content *only* shows to logged-in users since their member_id is a number, which will equal true. {{endif}}  
Showing content only to specific groups
Let's go a bit further and this time show content to specific (primary) member groups. First, you need to get the IDs for the group(s) you want to deal with. You can find this by editing the group in the AdminCP, and making a note of the id parameter in the URL. On my installation, the Administrator group is ID 4 so we'll use that in our example.
Once again, we're using the \IPS\Member::loggedIn() object, but this time we're using the member_group_id property.
{{if \IPS\Member::loggedIn()->member_group_id === 4}} This content only shows to members in the "Administrators" group (ID 4 in our example) {{endif}}  
Working with multiple groups at once
Following the code above, you could simply repeat the check against \IPS\Member::loggedIn()->member_group_id several times, for each ID you want to allow. However, since our templates allow arbitrary PHP expressions to be used, there's a neater way: use an array of member group IDs you want to allow, and check against that using PHP's in_array function. Here's an example where we only show content to group IDs 2, 4 and 6:
{{if in_array( \IPS\Member::loggedIn()->member_group_id, array( 2, 4, 6 ) )}} This content only shows to members in groups with the ID 2, 4 or 6. {{endif}}  
Have a request for a theme tip? Let us know in the comments and we'll try and help out in a future tip! 

HTML Logic is our name for the additional tags available in IPS4's templates that allow runtime logic to be executed. It comprises if/then/else statements as well as loops and more.
Since HTML Logic has access to all of the underlying PHP framework in IPS4, it's very powerful and a lot can be achieved with it. One common use is to limit certain content within a template to particular member groups. Let's see how that might be done.
 
Showing or hiding content only to guests
We'll first look at a simpler idea: showing or hiding content specifically to guests (i.e. anyone who isn't logged in). Within IPS4, the \IPS\Member::loggedIn() object contains information about the current user. Guests always have a member_id of NULL (i.e. no value), so we can simply check that value in our logic tag:
{{if \IPS\Member::loggedIn()->member_id === NULL}} This content *only* shows to guests, since they have a NULL member_id. {{endif}} {{if \IPS\Member::loggedIn()->member_id}} This content *only* shows to logged-in users since their member_id is a number, which will equal true. {{endif}}  
Showing content only to specific groups
Let's go a bit further and this time show content to specific (primary) member groups. First, you need to get the IDs for the group(s) you want to deal with. You can find this by editing the group in the AdminCP, and making a note of the id parameter in the URL. On my installation, the Administrator group is ID 4 so we'll use that in our example.
Once again, we're using the \IPS\Member::loggedIn() object, but this time we're using the member_group_id property.
{{if \IPS\Member::loggedIn()->member_group_id === 4}} This content only shows to members in the "Administrators" group (ID 4 in our example) {{endif}}  
Working with multiple groups at once
Following the code above, you could simply repeat the check against \IPS\Member::loggedIn()->member_group_id several times, for each ID you want to allow. However, since our templates allow arbitrary PHP expressions to be used, there's a neater way: use an array of member group IDs you want to allow, and check against that using PHP's in_array function. Here's an example where we only show content to group IDs 2, 4 and 6:
{{if in_array( \IPS\Member::loggedIn()->member_group_id, array( 2, 4, 6 ) )}} This content only shows to members in groups with the ID 2, 4 or 6. {{endif}}  
Have a request for a theme tip? Let us know in the comments and we'll try and help out in a future tip! 

HTML Logic is our name for the additional tags available in IPS4's templates that allow runtime logic to be executed. It comprises if/then/else statements as well as loops and more.
Since HTML Logic has access to all of the underlying PHP framework in IPS4, it's very powerful and a lot can be achieved with it. One common use is to limit certain content within a template to particular member groups. Let's see how that might be done.
 
Showing or hiding content only to guests
We'll first look at a simpler idea: showing or hiding content specifically to guests (i.e. anyone who isn't logged in). Within IPS4, the \IPS\Member::loggedIn() object contains information about the current user. Guests always have a member_id of NULL (i.e. no value), so we can simply check that value in our logic tag:
{{if \IPS\Member::loggedIn()->member_id === NULL}} This content *only* shows to guests, since they have a NULL member_id. {{endif}} {{if \IPS\Member::loggedIn()->member_id}} This content *only* shows to logged-in users since their member_id is a number, which will equal true. {{endif}}  
Showing content only to specific groups
Let's go a bit further and this time show content to specific (primary) member groups. First, you need to get the IDs for the group(s) you want to deal with. You can find this by editing the group in the AdminCP, and making a note of the id parameter in the URL. On my installation, the Administrator group is ID 4 so we'll use that in our example.
Once again, we're using the \IPS\Member::loggedIn() object, but this time we're using the member_group_id property.
{{if \IPS\Member::loggedIn()->member_group_id === 4}} This content only shows to members in the "Administrators" group (ID 4 in our example) {{endif}}  
Working with multiple groups at once
Following the code above, you could simply repeat the check against \IPS\Member::loggedIn()->member_group_id several times, for each ID you want to allow. However, since our templates allow arbitrary PHP expressions to be used, there's a neater way: use an array of member group IDs you want to allow, and check against that using PHP's in_array function. Here's an example where we only show content to group IDs 2, 4 and 6:
{{if in_array( \IPS\Member::loggedIn()->member_group_id, array( 2, 4, 6 ) )}} This content only shows to members in groups with the ID 2, 4 or 6. {{endif}}  
Have a request for a theme tip? Let us know in the comments and we'll try and help out in a future tip! 

HTML Logic is our name for the additional tags available in IPS4's templates that allow runtime logic to be executed. It comprises if/then/else statements as well as loops and more.
Since HTML Logic has access to all of the underlying PHP framework in IPS4, it's very powerful and a lot can be achieved with it. One common use is to limit certain content within a template to particular member groups. Let's see how that might be done.
 
Showing or hiding content only to guests
We'll first look at a simpler idea: showing or hiding content specifically to guests (i.e. anyone who isn't logged in). Within IPS4, the \IPS\Member::loggedIn() object contains information about the current user. Guests always have a member_id of NULL (i.e. no value), so we can simply check that value in our logic tag:
{{if \IPS\Member::loggedIn()->member_id === NULL}} This content *only* shows to guests, since they have a NULL member_id. {{endif}} {{if \IPS\Member::loggedIn()->member_id}} This content *only* shows to logged-in users since their member_id is a number, which will equal true. {{endif}}  
Showing content only to specific groups
Let's go a bit further and this time show content to specific (primary) member groups. First, you need to get the IDs for the group(s) you want to deal with. You can find this by editing the group in the AdminCP, and making a note of the id parameter in the URL. On my installation, the Administrator group is ID 4 so we'll use that in our example.
Once again, we're using the \IPS\Member::loggedIn() object, but this time we're using the member_group_id property.
{{if \IPS\Member::loggedIn()->member_group_id === 4}} This content only shows to members in the "Administrators" group (ID 4 in our example) {{endif}}  
Working with multiple groups at once
Following the code above, you could simply repeat the check against \IPS\Member::loggedIn()->member_group_id several times, for each ID you want to allow. However, since our templates allow arbitrary PHP expressions to be used, there's a neater way: use an array of member group IDs you want to allow, and check against that using PHP's in_array function. Here's an example where we only show content to group IDs 2, 4 and 6:
{{if in_array( \IPS\Member::loggedIn()->member_group_id, array( 2, 4, 6 ) )}} This content only shows to members in groups with the ID 2, 4 or 6. {{endif}}  
Have a request for a theme tip? Let us know in the comments and we'll try and help out in a future tip! 

HTML Logic is our name for the additional tags available in IPS4's templates that allow runtime logic to be executed. It comprises if/then/else statements as well as loops and more.
Since HTML Logic has access to all of the underlying PHP framework in IPS4, it's very powerful and a lot can be achieved with it. One common use is to limit certain content within a template to particular member groups. Let's see how that might be done.
 
Showing or hiding content only to guests
We'll first look at a simpler idea: showing or hiding content specifically to guests (i.e. anyone who isn't logged in). Within IPS4, the \IPS\Member::loggedIn() object contains information about the current user. Guests always have a member_id of NULL (i.e. no value), so we can simply check that value in our logic tag:
{{if \IPS\Member::loggedIn()->member_id === NULL}} This content *only* shows to guests, since they have a NULL member_id. {{endif}} {{if \IPS\Member::loggedIn()->member_id}} This content *only* shows to logged-in users since their member_id is a number, which will equal true. {{endif}}  
Showing content only to specific groups
Let's go a bit further and this time show content to specific (primary) member groups. First, you need to get the IDs for the group(s) you want to deal with. You can find this by editing the group in the AdminCP, and making a note of the id parameter in the URL. On my installation, the Administrator group is ID 4 so we'll use that in our example.
Once again, we're using the \IPS\Member::loggedIn() object, but this time we're using the member_group_id property.
{{if \IPS\Member::loggedIn()->member_group_id === 4}} This content only shows to members in the "Administrators" group (ID 4 in our example) {{endif}}  
Working with multiple groups at once
Following the code above, you could simply repeat the check against \IPS\Member::loggedIn()->member_group_id several times, for each ID you want to allow. However, since our templates allow arbitrary PHP expressions to be used, there's a neater way: use an array of member group IDs you want to allow, and check against that using PHP's in_array function. Here's an example where we only show content to group IDs 2, 4 and 6:
{{if in_array( \IPS\Member::loggedIn()->member_group_id, array( 2, 4, 6 ) )}} This content only shows to members in groups with the ID 2, 4 or 6. {{endif}}  
Have a request for a theme tip? Let us know in the comments and we'll try and help out in a future tip! 

HTML Logic is our name for the additional tags available in IPS4's templates that allow runtime logic to be executed. It comprises if/then/else statements as well as loops and more.
Since HTML Logic has access to all of the underlying PHP framework in IPS4, it's very powerful and a lot can be achieved with it. One common use is to limit certain content within a template to particular member groups. Let's see how that might be done.
 
Showing or hiding content only to guests
We'll first look at a simpler idea: showing or hiding content specifically to guests (i.e. anyone who isn't logged in). Within IPS4, the \IPS\Member::loggedIn() object contains information about the current user. Guests always have a member_id of NULL (i.e. no value), so we can simply check that value in our logic tag:
{{if \IPS\Member::loggedIn()->member_id === NULL}} This content *only* shows to guests, since they have a NULL member_id. {{endif}} {{if \IPS\Member::loggedIn()->member_id}} This content *only* shows to logged-in users since their member_id is a number, which will equal true. {{endif}}  
Showing content only to specific groups
Let's go a bit further and this time show content to specific (primary) member groups. First, you need to get the IDs for the group(s) you want to deal with. You can find this by editing the group in the AdminCP, and making a note of the id parameter in the URL. On my installation, the Administrator group is ID 4 so we'll use that in our example.
Once again, we're using the \IPS\Member::loggedIn() object, but this time we're using the member_group_id property.
{{if \IPS\Member::loggedIn()->member_group_id === 4}} This content only shows to members in the "Administrators" group (ID 4 in our example) {{endif}}  
Working with multiple groups at once
Following the code above, you could simply repeat the check against \IPS\Member::loggedIn()->member_group_id several times, for each ID you want to allow. However, since our templates allow arbitrary PHP expressions to be used, there's a neater way: use an array of member group IDs you want to allow, and check against that using PHP's in_array function. Here's an example where we only show content to group IDs 2, 4 and 6:
{{if in_array( \IPS\Member::loggedIn()->member_group_id, array( 2, 4, 6 ) )}} This content only shows to members in groups with the ID 2, 4 or 6. {{endif}}  
Have a request for a theme tip? Let us know in the comments and we'll try and help out in a future tip! 

HTML Logic is our name for the additional tags available in IPS4's templates that allow runtime logic to be executed. It comprises if/then/else statements as well as loops and more.
Since HTML Logic has access to all of the underlying PHP framework in IPS4, it's very powerful and a lot can be achieved with it. One common use is to limit certain content within a template to particular member groups. Let's see how that might be done.
 
Showing or hiding content only to guests
We'll first look at a simpler idea: showing or hiding content specifically to guests (i.e. anyone who isn't logged in). Within IPS4, the \IPS\Member::loggedIn() object contains information about the current user. Guests always have a member_id of NULL (i.e. no value), so we can simply check that value in our logic tag:
{{if \IPS\Member::loggedIn()->member_id === NULL}} This content *only* shows to guests, since they have a NULL member_id. {{endif}} {{if \IPS\Member::loggedIn()->member_id}} This content *only* shows to logged-in users since their member_id is a number, which will equal true. {{endif}}  
Showing content only to specific groups
Let's go a bit further and this time show content to specific (primary) member groups. First, you need to get the IDs for the group(s) you want to deal with. You can find this by editing the group in the AdminCP, and making a note of the id parameter in the URL. On my installation, the Administrator group is ID 4 so we'll use that in our example.
Once again, we're using the \IPS\Member::loggedIn() object, but this time we're using the member_group_id property.
{{if \IPS\Member::loggedIn()->member_group_id === 4}} This content only shows to members in the "Administrators" group (ID 4 in our example) {{endif}}  
Working with multiple groups at once
Following the code above, you could simply repeat the check against \IPS\Member::loggedIn()->member_group_id several times, for each ID you want to allow. However, since our templates allow arbitrary PHP expressions to be used, there's a neater way: use an array of member group IDs you want to allow, and check against that using PHP's in_array function. Here's an example where we only show content to group IDs 2, 4 and 6:
{{if in_array( \IPS\Member::loggedIn()->member_group_id, array( 2, 4, 6 ) )}} This content only shows to members in groups with the ID 2, 4 or 6. {{endif}}  
Have a request for a theme tip? Let us know in the comments and we'll try and help out in a future tip! 

HTML Logic is our name for the additional tags available in IPS4's templates that allow runtime logic to be executed. It comprises if/then/else statements as well as loops and more.
Since HTML Logic has access to all of the underlying PHP framework in IPS4, it's very powerful and a lot can be achieved with it. One common use is to limit certain content within a template to particular member groups. Let's see how that might be done.
 
Showing or hiding content only to guests
We'll first look at a simpler idea: showing or hiding content specifically to guests (i.e. anyone who isn't logged in). Within IPS4, the \IPS\Member::loggedIn() object contains information about the current user. Guests always have a member_id of NULL (i.e. no value), so we can simply check that value in our logic tag:
{{if \IPS\Member::loggedIn()->member_id === NULL}} This content *only* shows to guests, since they have a NULL member_id. {{endif}} {{if \IPS\Member::loggedIn()->member_id}} This content *only* shows to logged-in users since their member_id is a number, which will equal true. {{endif}}  
Showing content only to specific groups
Let's go a bit further and this time show content to specific (primary) member groups. First, you need to get the IDs for the group(s) you want to deal with. You can find this by editing the group in the AdminCP, and making a note of the id parameter in the URL. On my installation, the Administrator group is ID 4 so we'll use that in our example.
Once again, we're using the \IPS\Member::loggedIn() object, but this time we're using the member_group_id property.
{{if \IPS\Member::loggedIn()->member_group_id === 4}} This content only shows to members in the "Administrators" group (ID 4 in our example) {{endif}}  
Working with multiple groups at once
Following the code above, you could simply repeat the check against \IPS\Member::loggedIn()->member_group_id several times, for each ID you want to allow. However, since our templates allow arbitrary PHP expressions to be used, there's a neater way: use an array of member group IDs you want to allow, and check against that using PHP's in_array function. Here's an example where we only show content to group IDs 2, 4 and 6:
{{if in_array( \IPS\Member::loggedIn()->member_group_id, array( 2, 4, 6 ) )}} This content only shows to members in groups with the ID 2, 4 or 6. {{endif}}  
Have a request for a theme tip? Let us know in the comments and we'll try and help out in a future tip! 

HTML Logic is our name for the additional tags available in IPS4's templates that allow runtime logic to be executed. It comprises if/then/else statements as well as loops and more.
Since HTML Logic has access to all of the underlying PHP framework in IPS4, it's very powerful and a lot can be achieved with it. One common use is to limit certain content within a template to particular member groups. Let's see how that might be done.
 
Showing or hiding content only to guests
We'll first look at a simpler idea: showing or hiding content specifically to guests (i.e. anyone who isn't logged in). Within IPS4, the \IPS\Member::loggedIn() object contains information about the current user. Guests always have a member_id of NULL (i.e. no value), so we can simply check that value in our logic tag:
{{if \IPS\Member::loggedIn()->member_id === NULL}} This content *only* shows to guests, since they have a NULL member_id. {{endif}} {{if \IPS\Member::loggedIn()->member_id}} This content *only* shows to logged-in users since their member_id is a number, which will equal true. {{endif}}  
Showing content only to specific groups
Let's go a bit further and this time show content to specific (primary) member groups. First, you need to get the IDs for the group(s) you want to deal with. You can find this by editing the group in the AdminCP, and making a note of the id parameter in the URL. On my installation, the Administrator group is ID 4 so we'll use that in our example.
Once again, we're using the \IPS\Member::loggedIn() object, but this time we're using the member_group_id property.
{{if \IPS\Member::loggedIn()->member_group_id === 4}} This content only shows to members in the "Administrators" group (ID 4 in our example) {{endif}}  
Working with multiple groups at once
Following the code above, you could simply repeat the check against \IPS\Member::loggedIn()->member_group_id several times, for each ID you want to allow. However, since our templates allow arbitrary PHP expressions to be used, there's a neater way: use an array of member group IDs you want to allow, and check against that using PHP's in_array function. Here's an example where we only show content to group IDs 2, 4 and 6:
{{if in_array( \IPS\Member::loggedIn()->member_group_id, array( 2, 4, 6 ) )}} This content only shows to members in groups with the ID 2, 4 or 6. {{endif}}  
Have a request for a theme tip? Let us know in the comments and we'll try and help out in a future tip! 

HTML Logic is our name for the additional tags available in IPS4's templates that allow runtime logic to be executed. It comprises if/then/else statements as well as loops and more.
Since HTML Logic has access to all of the underlying PHP framework in IPS4, it's very powerful and a lot can be achieved with it. One common use is to limit certain content within a template to particular member groups. Let's see how that might be done.
 
Showing or hiding content only to guests
We'll first look at a simpler idea: showing or hiding content specifically to guests (i.e. anyone who isn't logged in). Within IPS4, the \IPS\Member::loggedIn() object contains information about the current user. Guests always have a member_id of NULL (i.e. no value), so we can simply check that value in our logic tag:
{{if \IPS\Member::loggedIn()->member_id === NULL}} This content *only* shows to guests, since they have a NULL member_id. {{endif}} {{if \IPS\Member::loggedIn()->member_id}} This content *only* shows to logged-in users since their member_id is a number, which will equal true. {{endif}}  
Showing content only to specific groups
Let's go a bit further and this time show content to specific (primary) member groups. First, you need to get the IDs for the group(s) you want to deal with. You can find this by editing the group in the AdminCP, and making a note of the id parameter in the URL. On my installation, the Administrator group is ID 4 so we'll use that in our example.
Once again, we're using the \IPS\Member::loggedIn() object, but this time we're using the member_group_id property.
{{if \IPS\Member::loggedIn()->member_group_id === 4}} This content only shows to members in the "Administrators" group (ID 4 in our example) {{endif}}  
Working with multiple groups at once
Following the code above, you could simply repeat the check against \IPS\Member::loggedIn()->member_group_id several times, for each ID you want to allow. However, since our templates allow arbitrary PHP expressions to be used, there's a neater way: use an array of member group IDs you want to allow, and check against that using PHP's in_array function. Here's an example where we only show content to group IDs 2, 4 and 6:
{{if in_array( \IPS\Member::loggedIn()->member_group_id, array( 2, 4, 6 ) )}} This content only shows to members in groups with the ID 2, 4 or 6. {{endif}}  
Have a request for a theme tip? Let us know in the comments and we'll try and help out in a future tip! 

HTML Logic is our name for the additional tags available in IPS4's templates that allow runtime logic to be executed. It comprises if/then/else statements as well as loops and more.
Since HTML Logic has access to all of the underlying PHP framework in IPS4, it's very powerful and a lot can be achieved with it. One common use is to limit certain content within a template to particular member groups. Let's see how that might be done.
 
Showing or hiding content only to guests
We'll first look at a simpler idea: showing or hiding content specifically to guests (i.e. anyone who isn't logged in). Within IPS4, the \IPS\Member::loggedIn() object contains information about the current user. Guests always have a member_id of NULL (i.e. no value), so we can simply check that value in our logic tag:
{{if \IPS\Member::loggedIn()->member_id === NULL}} This content *only* shows to guests, since they have a NULL member_id. {{endif}} {{if \IPS\Member::loggedIn()->member_id}} This content *only* shows to logged-in users since their member_id is a number, which will equal true. {{endif}}  
Showing content only to specific groups
Let's go a bit further and this time show content to specific (primary) member groups. First, you need to get the IDs for the group(s) you want to deal with. You can find this by editing the group in the AdminCP, and making a note of the id parameter in the URL. On my installation, the Administrator group is ID 4 so we'll use that in our example.
Once again, we're using the \IPS\Member::loggedIn() object, but this time we're using the member_group_id property.
{{if \IPS\Member::loggedIn()->member_group_id === 4}} This content only shows to members in the "Administrators" group (ID 4 in our example) {{endif}}  
Working with multiple groups at once
Following the code above, you could simply repeat the check against \IPS\Member::loggedIn()->member_group_id several times, for each ID you want to allow. However, since our templates allow arbitrary PHP expressions to be used, there's a neater way: use an array of member group IDs you want to allow, and check against that using PHP's in_array function. Here's an example where we only show content to group IDs 2, 4 and 6:
{{if in_array( \IPS\Member::loggedIn()->member_group_id, array( 2, 4, 6 ) )}} This content only shows to members in groups with the ID 2, 4 or 6. {{endif}}  
Have a request for a theme tip? Let us know in the comments and we'll try and help out in a future tip! 

HTML Logic is our name for the additional tags available in IPS4's templates that allow runtime logic to be executed. It comprises if/then/else statements as well as loops and more.
Since HTML Logic has access to all of the underlying PHP framework in IPS4, it's very powerful and a lot can be achieved with it. One common use is to limit certain content within a template to particular member groups. Let's see how that might be done.
 
Showing or hiding content only to guests
We'll first look at a simpler idea: showing or hiding content specifically to guests (i.e. anyone who isn't logged in). Within IPS4, the \IPS\Member::loggedIn() object contains information about the current user. Guests always have a member_id of NULL (i.e. no value), so we can simply check that value in our logic tag:
{{if \IPS\Member::loggedIn()->member_id === NULL}} This content *only* shows to guests, since they have a NULL member_id. {{endif}} {{if \IPS\Member::loggedIn()->member_id}} This content *only* shows to logged-in users since their member_id is a number, which will equal true. {{endif}}  
Showing content only to specific groups
Let's go a bit further and this time show content to specific (primary) member groups. First, you need to get the IDs for the group(s) you want to deal with. You can find this by editing the group in the AdminCP, and making a note of the id parameter in the URL. On my installation, the Administrator group is ID 4 so we'll use that in our example.
Once again, we're using the \IPS\Member::loggedIn() object, but this time we're using the member_group_id property.
{{if \IPS\Member::loggedIn()->member_group_id === 4}} This content only shows to members in the "Administrators" group (ID 4 in our example) {{endif}}  
Working with multiple groups at once
Following the code above, you could simply repeat the check against \IPS\Member::loggedIn()->member_group_id several times, for each ID you want to allow. However, since our templates allow arbitrary PHP expressions to be used, there's a neater way: use an array of member group IDs you want to allow, and check against that using PHP's in_array function. Here's an example where we only show content to group IDs 2, 4 and 6:
{{if in_array( \IPS\Member::loggedIn()->member_group_id, array( 2, 4, 6 ) )}} This content only shows to members in groups with the ID 2, 4 or 6. {{endif}}  
Have a request for a theme tip? Let us know in the comments and we'll try and help out in a future tip!