Meddysong

This entry is about our IPS Community Suite 4.2 release.
Sometimes you may find situations where you want to highlight one or more replies to a content item to bring attention to a really great response. This is especially true on busy communities where you might have dozens or even hundreds of replies in a single discussion.
There is now an ability for a moderator to Recommend a reply (or multiple replies) and even leave an optional note explaining why they think you should view that post.

Moderator Permission

Optional note for recommended reply
When a reply is Recommended you will see a snippet at the top of the content item along with the optional moderator note and a link to jump right to that reply.

A topic with a recommended reply.
You can Recommend more than one reply and this feature works through IPS Community Suite in forum topic, blog entries, gallery images, and so on. You can set this permission along with other moderator permissions in the AdminCP.
We really think this will allow moderators to bring attention to some of the best replies and guide users to the best content your community has to offer.

We are well into development on IPS Community Suite 4.2 and are excited to start announcing all the new features and improvements.
Our next big release is focused on engagement with your members. You will see enhancements to our Reputation system, new ways to encourage people to register on your community, and enhancements to existing features to make them more interactive. There are also entirely new capabilities we cannot wait to show you ranging from new ways to organize content to tools to help promote your community.
Version 4.2 also features a refreshed AdminCP and default front-end design. Theme changes in 4.2 are mostly in the CSS framework so your existing themes will either work without issue or require minor changes to work in the new version.
Over the next several weeks we will be posting news entries with previews of upcoming features fairly often. Be sure to follow our News section, our Facebook, or Twitter to stay up to date.
We expect IPS Community Suite 4.2 to be out in mid-2017 with a public preview available sooner.
Everyone at IPS has worked very hard on this update and we think you will love it!

Next week, IPS will be implementing the pricing changes to our product lineup that we published in 2015. In the spirit of Black Friday and Cyber Monday, we are extending an opportunity to purchase a new license or add new applications to your existing suite at 15% off our current pricing.
To take advantage of this offer, please use coupon code IPSPROMO16 at checkout. This promotion is active starting now and valid until 1 December 2016 (EST) and applies to new purchases only. We are unable to retroactively apply the discount.
This promotion also applies to Community in the Cloud for your first month of service!
If you’ve been waiting to purchase a new license or add products to your suite, this is the last opportunity to obtain this level of pricing! Happy shopping!

IPS Community Suite allows for integrations with quite a few third party systems and also can embed content from external sites. We have added a whole new list of embed providers where you can just paste in a link to that site and a nice box will show up. For example, if I paste this link in normally:
https://twitter.com/invisionps/status/799269691579449344 I get:
You can do that will many popular sites already and we are adding a lot more:
codepen.io coub.com deviantart.com docs.com funnyordie.com gettyimages.com iFixit.com kickstarter.com meetup.com mixcloud.com mix.office.com on.aol.com reddit.com reverbnation.com screencast.com screenr.com slideshare.net smugmug.com ustream.tv Google Maps Once you enable Google Maps under Community Enhancements by entering your Google API key you can them just paste in a link to a Google Map location. So when you paste a link to a Google Map in an editor it shows like this:

Google Maps in Editor
The maps are also interactive on the screen.
REST API
We have also added quite a few more endpoints, particularly in member management, to our REST API. If you are not already familiar with the REST API it is a great way to integrate external systems with IPS Community Suite. You can both fetch and modify data in the Suite via the API. REST API documentation...
Third Party Diagnostics
This is a bit more of a technical feature so feel free to skip if it does not interest you. If you use third party plugins or applications from our Marketplace or from other sites you may occasionally encounter issues in the Suite caused by those items but it is often hard to know the root issue. There are now tools in the AdminCP to show all places in the code that third party items are modifying to help with diagnosing issues. The Suite will now also try to detect if an error it encounters is referencing a third party plugin and suggest you disable it to see if the issue is resolved.
New Support Tool

Simplified Support Tool
Though not specifically about embeds or integrations, the new Support Tool does better help diagnose issues so I thought I would give it a nice shout out. It really does help to find server problems, database issues, or outdated files that might interfere with your site. It also makes support so much easier if you submit your ticket to us via the Support Tool as it sends along a temporary login (if you allow it) for us to use. The new design simplifies the tool down to just one step and it gives you a report and suggested actions.
 
This change will be in version 4.1.17 which is scheduled to be released in early December 2016.

We are excited to announce the Leaderboard as the latest all new feature of IPS Community Suite. The new Leaderboard is designed to better highlight your most active members and content based on reputation and other metrics. The Leaderboard will greatly enhance both member and content discovery on your community.

Leaderboard Home
First you will notice the new feature of member leaders based on a specific time frame. In the example above it is set to All Time showing those members with the most reputation overall on your community. It also shows the content with the most reputation for the same timeframe so you get a snapshot of both popular members and popular content in one view.

Past Leaders
The Past Leaders tab shows the "winners" of each day in a history. The system counts all reputation made each day and logs the members who had the top reputation counts that day. Using reputation rather than post count encourages your members to post quality of quantity which is really important to any site.

Winner Profile Badge
Those who win the day also get a badge on their profile page to highlight that they were the member with the most reputation for a particular day.

Top Members
Top Members shows you a list of all members sorted by various metrics. By default you will see members sorted by reputation but you can also easily sort by total post content Suite-wide or per-app. All of these views can be linked directly to so if you wanted a menu item to show members who post the most files in Downloads you can just directly link to that sort view.

Leaderboard Settings
There are various settings to control the default behavior of the Leaderboard. You can define the default view and how many members to show which is helpful to tailor it to your needs.
We hope you enjoy this initial launch of the new Leaderboard feature. We are excited about the new content and member discovery abilities this offers and look forward to adding new options to the Leaderboard as we continue to develop!
 
This change will be in version 4.1.17 which is scheduled to be released in early December 2016.

I'm pleased to announce we're finally ready to open our new Developers area. The aim of this project has been to improve our existing developer documentation by building a central place to contain it, as well as update and expand the content available.
As of today, we have the regular documentation and REST API documentation ready to use. Over the coming weeks and months, we'll be expanding what's available further, going into more detail about the tools available within the framework. We've also started work on comprehensive Getting Started guides, that will walk you through simple developer projects from start to finish - these will be available soon, once they're complete.
If there's a particular aspect of IPS4 development that you don't feel is adequately catered for right now, please let us know! This will help us direct our efforts to the most useful places.
Enjoy!

IPS Community Suite 4.1.16 is nearing the end of development so I wanted to go over some of the new features in this upcoming release. Some are big and some are small but we always enjoy making any sort of enhancements to the Suite.
We expect 4.1.16 to go to public beta next week. If you are interested in using a public beta please check out our beta forum (clients only) with more info. We welcome as much testing as possible and our betas are considered safe to use on a live site. We do offer support for betas so, if you are technically minded, consider giving them a try.
Commerce: New Ticket Listing
We have redesigned the ticket listing view in Commerce to be much more user friendly and better use screen space. You can also now group by department which is great for organization.

 
Much like Activity Streams on the front end you can create custom views for tickets based on how you work.

The new My History view allows staff to quickly see their latest replies and actions along with some basic stats.

There are many other smaller improvement in Commerce in 4.1.16 as well. We think you will enjoy all the updates.
Security Questions
To enhance the security of your member accounts we now have a new security questions feature where you can allow your members to put in their own, personal security questions. The member will then be prompted to answer those questions for account actions you define.

Account Change Emails
Members will now receive confirmation emails when they change their email address...

and their password...

Topics per Page
You can now define the number of topics per page in forum view.

Remove all Followers
Moderators can now remove all followers from any item that allows follows. This is useful if you are archiving an old item or otherwise do not want people getting notified of new activity on an item.

Automatic Following
Your members can already choose to automatically follow content they start or reply to but now you can define this as the default behavior for all members. Your members can of course override this to their own preference.

Embed Failure Message
To answer the constant question "why didn't my media embed?" we now show you why. Regular members will just see a message indicating the Suite tried to embed but was not able to. Admins will get more information on what failed.

Suspended Member Page
When you banned/suspended a member previously they simply saw a generic permission denied message. We now show a more friendly page saying they were suspended and why.

The member can click to get the full information from the Warning System as well.

Contact Us
The contact us page now has configuration options to control where messages are sent. You can do email and even Commerce support departments now.

Announcements
Global announcements can now be restricted by member group.

And some technical stuff...
In addition to the new feature additions we have also fixed dozens of issues reported by clients. There was a particular focus on Commerce, Pages, and IPS Connect. Some other items of note:
Performance improvements in: profile view, sitemap generator, posting replies, and Activity Streams We now try to more reliably detect the AWS S3 endpoint for those using S3 file storage Tasks view will now show the last time a task ran More efficient license key checking to keep the keys from being checked too often which can slow your site down If group promotion based on date is enable the system will now auto-promote even if a member does not login If you move your site to a new URL you no longer have to update a constant if using the image proxy You can now press ctrl/cmd+enter in any editor window to submit the reply (yay!) In Commerce ticket view there are keyboard shortcuts to perform common actions (such as press 'r' to open reply box or 'n' for note) There is now logic to prevent double-posting when the initial post encounters an error on submit If your datastore (cache system) is not working properly the AdminCP will now show you a warning telling you that it needs attention.    

We were recently asked if it's possible to color code tags - the customer in question used tags as statuses on topics, and so wanted 'resolved' to be green, and so on. Despite being a great idea, this isn't something that is currently possible 'out of the box' - although we'll add it to our internal feature idea list to follow up on later!
But just because it isn't built in, that doesn't mean it isn't possible! In fact, with a little CSS, this is quite easy to achieve now.
 
Writing a CSS selector
We can do this by writing a CSS selector that matches the tag URL for the tag we want to style - a handy way to use CSS that can be applied to lots of other ideas within the suite!
Lets say we have a tag called 'resolved', and we want to make it green. Add the following CSS to your custom.css file:
.ipsTags a[href*="/tags/resolved/"] { background: SeaGreen; } html[dir="ltr"] .ipsTags a[href*="/tags/resolved/"]:before { border-color: transparent SeaGreen transparent transparent; } The first style is the main part of the tag element; the second matches the :before pseudo-selector which we use to make the 'point' of the tag.
Another tag we'll style is called 'needs help'. In this case, there's spaces in the name, which are represented by the + symbol in the URL (since it's URL-encoded). We'll make it purple this time:
.ipsTags a[href*="/tags/needs+help/"] { background: Purple; } html[dir="ltr"] .ipsTags a[href*="/tags/needs+help/"]:before { border-color: transparent Purple transparent transparent; }  
 
Supporting prefixes
This little CSS snippet won't change prefixes, however - they'll still be shown in the default color (specified by your theme settings). If you want to change prefixes too, you need to adjust the CSS as follows - replace the previous CSS with this version:
.ipsTags a[href*="/tags/needs+help/"], a.ipsTag_prefix[href*="?tags=needs+help"] { background: Purple; } html[dir="ltr"] .ipsTags a[href*="/tags/needs+help/"]:before, html[dir="ltr"] a.ipsTag_prefix[href*="?tags=needs+help"]:before { border-color: transparent Purple transparent transparent; } (Note: Notice the slightly different string we're matching in the href attribute; once you upgrade to 4.1.14, this won't be necessary - both selectors can use the same href format, e.g. /tags/needs+help/. Prior to 4.1.14, tags and prefixes used slightly different URL formats.)
That's it - now everything looks correct!
 

Topic View
 
 

Forum View
 

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

IPS4's theme system has a feature called template plugins, which are special tags that do something to the values you pass in. You'll see them throughout the templates - they look like this:
{lang="..."} This tag displays the language string for the key you pass into it, and is probably the most commonly used one. But there's many others too, so let's review some of the useful ones you can use in your themes and addons.
 
{member}
If you need to show any data about a member, the {member} tag is very useful. It's a shorthand that can display properties and call methods on a member object, so it's much neater than the manual approach. It's used like this:
// Get a property, like 'name' {member="name"} // Call a method, like 'link()' {member="link()"} By default, it will work with the currently logged-in member, but you can pass an id attribute to show data about any member:
// Show the name of member #67 {member="name" id="67"}  
{expression}
The expression tag allows you insert simple one-line PHP expressions into your templates. For example, if a variable is an array of values and you want to show one per line, instead of writing a loop, you could do:
{expression="implode( '<br>', $myArray )"}  
{prefix}
The prefix tag is unusual in that it's designed specifically for use in CSS files. It prefixes CSS styles with the various vendor prefixes, meaning instead of writing:
.myClass { -webkit-transform: scale(3) rotate(45deg); -moz-transform: scale(3) rotate(45deg); -o-transform: scale(3) rotate(45deg); transform: scale(3) rotate(45deg); } You can write:
.myClass { {prefix="transform" value="scale(3) rotate(45deg)"} }  
{hextorgb}
Continuing with the CSS theme, next there's the "Hex to RGB" tag. If you're a theme designer and want to use a theme setting value but apply some transparency, this tag will be particularly useful to you. Color theme settings are simple hex values, e.g. #000000. To apply some transparency, you need to use the rgba notation however (the 'a' meaning 'alpha channel', otherwise known as transparency). The {hextorgb} tag does this for you.
It accepts either a hex color, or a theme setting key. By default it outputs the same color in rgb notation, but if you want to add transparency, you can add an opacity parameter which will represent the alpha channel value.
{hextorgb="#ff0000"} --> rgb(255,0,0) {hextorgb="page_background" opacity="0.6"} --> rgba(235,238,242,0.6)  
{truncate}
Finally, there's the truncate tag. This tag takes some text (usually as a variable), and truncates it to the length you specify. By default it appends an ellipsis (...) to the end of the content, although this is configurable via the append parameter.
{truncate="$someLongText" length="300"} Note that this isn't designed to be used on HTML markup; you may break your page if HTML tags are included in the text. For those cases, consider using the javascript ipsTruncate widget instead.
 
I hope this overview of 5 lesser-known template tags will help you as you build themes or applications! Share your related tips in the comments.

Last week we introduced you to a couple of key new improvements in IPS Community Suite 4.1.12, the new post preview and enhanced activity streams and search. However, this is a packed release, so I wanted to quickly review what else you can expect to find when it is released this week.
Mentions
4.0 introduced mentions, and since then a frequently-requested feature is the ability to ignore notifications triggered by particular members. In 4.1.12, we enhanced the Ignore Users functionality to also allow you to block mention notifications. They will still be able to mention you in posts, but you will no longer be notified about it.

Ratings
As of 4.1.12, ratings will now display half-stars in order to be more accurate. Users will still rate whole stars out of 5 (or 10 if configured so), but the aggregated ratings displayed alongside content will be more fine-grained.
Custom date formatting
We have used built-in, automatic locale formats for dates since 4.0, but it became increasingly clear that this did not offer the flexibility that some community administrators desired. As a result, 4.1.12 re-introduces the ability to provide custom formats for dates.
Bug fixes
Amongst the handful of new features, there's over 400 other bug fixes and improvements that contribute towards the overall stability of the IPS Community Suite, as we start working towards the next major release, IPS Community Suite 4.2 which will be available later this year. Further fixes for stability in the 4.1 line will come before 4.2 is available.
 
Please check our release notes to read more about other smaller changes and fixes in 4.1.12.

We are currently beta testing our next release, 4.1.12, which contains hundreds of bug fixes, dozens of improvements, as well as a handful of new features. In this post, I want to cover some improvements we've made to two key areas: activity streams and search.
Activity Streams
The first improvement we made is to change how the expanded/condensed toggles are displayed to improve their clarity. From studying the feedback from administrators and users, we discovered that many people did not realize the view could be changed. To improve this, the toggles now explicitly say 'Condensed' and 'Expanded', making it much clearer how the view can be toggled to your own preference.

More clearly marked expand and condense options for Activity Streams
Next, a common point of feedback about Activity Streams is that clicking a result and then hitting the Back button in the browser means you are put back at the first batch of results, losing your place in the stream. In 4.1.12 we improved this so that clicking Back will load the last batch of results you were viewing, enabling you to continue browsing from whence you left off.
Finally, in the Content Types menu we added an Apply button. We discovered that users were not always sure how to save the selection of content types they had made (which automatically happened when that menu was closed). To alleviate this, the new Apply button will save the selection and close the menu, updating the stream results in real-time as expected. You can still simply click out of the menu to apply changes as well.

The new Apply button in the Content Types menu
Search
While overall improvements to search (specifically the algorithms to match and return the results) are a matter of ongoing research and refinement which we will improve in the 4.2 series and beyond, 4.1.12 sees one small improvement to the options available to users. While you have always been able to search within a particular forum, category etc. while browsing that area, you were not able to retroactively filter into particular areas after performing a more general search. IPS Community Suite 4.1.12 adds this ability to the interface, allowing you to get more specific results from a particular area of the community.
Version 4.1.12 is currently in beta testing and should be released in the next two weeks.

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

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

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

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

Occasionally you'll want to style a specific element on a specific page of your community - maybe you want to change how topic titles are shown inside a topic, or do something specific to the styles used in activity streams, without also altering other screens where the same elements are used.
Your first instinct might be to open the template editor and add some custom classnames so you can style them. This would certainly work, but the downside is your template is now customized, so any future IPS4 updates would leave the template out of date. Not ideal by any means.
Instead, you can use some helpful attributes that IPS4 adds to the body element, and then build a CSS selector around them. There's four attributes, and they always reference the current page the user is on:
data-pageApp - The application key (e.g. core, forums, cms etc.) data-pageModule - The current module with the application (e.g. pages) data-pageController - The current controller within the module (e.g. topic, page etc.) data-pageLocation - Either admin or front. So let's say we want to change how the .ipsPageHeader element looks within topic view. Our selector would look like this:
body[data-pageapp="forums"][data-pagemodule="forums"][data-pagecontroller="topic"] .ipsPageHeader { ...your styles } If you don't want to be that specific, you can just use the attributes you need. For example, if you want to change all .ipsPageHeader styles in the Forums app, you'd do:
body[data-pageapp="forums"] .ipsPageHeader { ...your styles } Tip: If you don't know the correct app/module/controller for the page you're on, you can find out by visiting the page and then viewing the page source. You'll see these attributes in the body tag near the top.
And as always, be sure you add your CSS to custom.css to keep your upgrades easy  
This theme tip is taken from our guides section.

We frequently encourage people to use custom CSS files when designing their themes. The reason for this is simple: it makes upgrading your site much easier because IPS4 can apply any changes to its own CSS files, and will leave your custom CSS files untouched. If instead you made edits to IPS4's CSS directly, it wouldn't be able to upgrade them automatically, which means more work for you, and a potentially broken UI on each upgrade.
Something that's not quite as common, but that we still strongly suggest, is using custom template bits as much as possible. The most common template you'd edit is globalTemplate, perhaps to include some extra resources in the <head>, a custom header, and maybe some footer pieces. The usual approach would be to simply add all of that custom HTML directly into globalTemplate, but my recommendation is that you instead create each piece as a custom template bit, and then include it.
With templates, it's not quite as much of a clear-cut benefit as with CSS; you'll still need to modify the original template in order to include your custom pieces of course. But there's still good reasons for doing so; it keeps your template as clean as possible, meaning if in a later upgrade you have to revert it to get the latest changes, reapplying your custom pieces is easy - you just add the template includes back in.
We've been taking this approach with all custom themes we've created since IPS4's release (dozens by my last count). We try and keep the naming convention consistent too. All custom templates are named _customABC.phtml and exist in the /front/global/ group in the core application. This puts them in an easy-to-find location, and because of the underscore prefix, they're shown at the top of the directory.

Example custom template bits in a custom theme
Using them is simple:
{template="_customHeader" group="global" app="core"}  
I hope this approach helps you keep your templates clean and more manageable! If you have any tips for working with your templates, please share them in the comments!

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!

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!

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 you use custom templates for a Pages database, you'll often need custom CSS to go along with it to provide the styling. There's two main ways of doing this:
CSS files within Pages
Pages allows you to create CSS files, and then associate them with particular custom pages of your community (you create these in the AdminCP, under Pages > Templates > CSS). So simply create your CSS file, and associate it to the page that your database is displayed on.
The benefit of this method is it applies to all themes, so it's great if you want your database to look the same on all themes. Of course, this is also the drawback - you can't easily use it for per-theme customization.
Targeting the database classname in theme CSS
Alternatively, you can target the database classname in your normal theme CSS files. When a database is inserted into a page, IPS4 helpfully adds a classname to the body element, which makes it really simple to style that page in particular. If your database key is myDatabase, then the classname added to the body element would be cCmsDatabase_myDatabase. Use this in your selectors and you can style everything exactly how you need:
.cCmsDatabase_myDatabase .ipsButton_important { /* Style important buttons differently in this database, for example */ } Combine both methods!
Of course, you can use both approaches when it makes sense. Create a CSS file within Pages for the basic structural styling that will apply regardless of which theme the user uses, and then in each theme target the database classname to customize it for that particular theme - perfect for the colors, font family and so on.

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