BN_IT_Support

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!

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!

Our Pages CMS is one of our most popular applications as we are continuing to improve it based on feedback. New in 4.1.13 includes:
Designer’s Mode HTML Editing
This update allows you to edit your HTML mode pages inside the designer's mode file system. Any edits you make, once saved in your text editor are instantly available which makes it much faster to build HTML pages with Pages.

 
Database Template Improvements
We listened to a lot of feedback about templating within the AdminCP for Pages and one common request was for a way to delete a group of database templates and to rename those groups. When you import databases, the template group names are created unique but you may want to change this to something more memorable. You will see here that the dialog also shows you which databases this template is used.

 
Page titles when using databases
Currently, when you add a database to a page, the page title is replaced with the database name. This may not always be desirable, and you may want the page title to remain in all database URLs (such as record view). There is now an option for this per database.

Relational Field Improvements
Now when you create a relational link between databases, you can opt to show which records link to the relational record. To give you an example, say you had a database for actors, and a database for movies, and you created a link on the actors record to show which movies they star in; now when viewing the movie, it will show you a list of the actors.

 
More Filterable Fields
We added both "Date" and "YesNo" field types to be filterable when viewing a list of records. When you use the Date type, you can select a date range for listing articles.

We also added the ability to use any custom field set as filterable to be used when creating a database feed widget.

 
Unique Fields
Another popular request was to allow a way to force unique entries for custom fields. This means that when enabled, only one record per database can have the same value. This is enabled when creating or editing a field.

 
Other improvements
You can now quickly delete an entire media folder via the AdminCP.

You can now quickly see which databases are used on which pages via the AdminCP page list.

 
And we added a way to programatically fetch a custom field value via the $record object. Currently, you need to use something like $record->field_12 which works well until you import that database to another installation. The fields are renumbered so this syntax no longer works. We made it possible to use the field key like so $record->field_{my_key_name_here}. Not only does this solve the issue when importing databases, it is also much more readable and easier to remember!

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. I wanted to introduce one of those new features: post preview.
Long-time users of our software will know that a post preview function was a standard feature, but we took the decision to not include it in the initial IPS4 release. It had a couple of drawbacks:
it only applied to certain pages, such as topic view - other WYSIWYG editors simply didn't get a preview the workflow wasn't very good for modern web apps, requiring a round-trip to the server and a full page refresh When IPS4 was released, we felt that the built-in rendering of the editor was a sufficient preview of how the end result would appear. However, while analyzing ongoing customer and user feedback for IPS4 in its first year of release, we have seen that a preview still has a use. There are some circumstances when a true WYSIWYG experience is just not possible such as using more advanced formatting (like LaTeX) or when admins create certain custom editor plugins.
As a result, we rethought post preview. We wanted to ensure that all editors could be previewed, and that it didn't have a clunky workflow. In addition, since IPS4 uses a responsive theme, we wanted to give users the opportunity to preview how their post would look on different devices.
Here's the result, and what will be available in 4.1.12:

Post preview in IPS Community Suite 4.1.12
The preview is shown by clicking a new button on the toolbar (meaning it can be moved, removed, etc. just like the other default buttons). When the preview loads, the toolbar allows the user to resize it to different device sizes. If they are on desktop, they can also view it at tablet at phone sizes; on a tablet, it can also be viewed at phone size.
So now we not only show a true preview of what content will look like when posted, but we also allow you to preview how it will look on other devices. Of course that preview is just a best-guess since different devices have different window sizes but it does give you an idea.
We hope this reimagining of an old feature for a more modern web will please end-users and make posting content a more accurate process. Stay tuned for more updates on what's included in 4.1.12!
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!

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 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.