ipbfuck

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.

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!

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.

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! 
 

We are wrapping up testing in preparation of version 4.1.10 release. This is a follow up to 4.1.9 which introduced a lot of great enhancements.
Changes in 4.1.10 include:
Instant notifications are now dismissible. The sidebar has been added back to the Activity Stream pages. You can now sort by most downloaded in Downloads app.  The ModeratorCP and AdminCP IP Address Tools now allow you to track the IP addresses used to vote in polls. A new setting has been added to disable the RSS feed for activity streams. A new setting has been added to specify the minimum display name length. Adds a new "can unban" moderator permission separate to the "can edit profiles" permission being used previously. IP addresses now show in reports. There is now a constant-level setting to disable the ACP IP address check in case of being locked out of the ACP. Several improvements to Commerce to make some features clearer: the Shipping Rates configuration pages now indicate to the admin if a potential mistake has been made, the front-end indicates to admins if no support departments have been set up, and the renewal settings wording has been clarified. And of course countless bugs fixed and performance enhancements. View our full release notes for more details.
If you are an existing IPS client and enjoy testing pre-release software, a beta release of 4.1.10 is available. We always appreciate help testing upcoming releases.
We are already well into development on 4.1.11 which include some larger feature changes and additions.

We have updated a few of our embed options in version 4.1.9. Our goal was to make the embeds more user friendly and give admins more control over embed in general.
When you paste in a link from common services like YouTube, Twitter, and so on the system tries to embed a nice box instead of just a link. For example, if I pasted in this link:
https://twitter.com/invisionps/status/708019275521363968 It would create this box:
New in version 4.1.9 you can now optionally choose to revert the automatic embed back to a simple text link.
So in the above example, when I pasted in my Twitter link, I saw a bar come up giving me the option to revert back to a link. This is useful when you do not want a formatted embed box but instead simply want to reference something and get the visitor to click the link. It is also useful when you want to reference something as part of a single sentence and not have a break in the flow that an embedded content box creates.
There is also a new AdminCP setting to completely disable embeds across your entire Suite. Some clients have communities where they like to keep things down to just simple, plain text. You could always disable formatting option button in the editor and now you can also disable automated embeds.
As a reminder, the following formats are supported with our embed system. Simply paste a link to any of these services and you will get a nice, rich embed experience that really encourages engagement on your community.
College Humor Facebook Flickr Gfycat Google+ Hulu Instagram SoundCloud Spotify Ted Twitter Vimeo Vine YouTube You can also embed links to anything inside of the IPS Community Suite. So you could paste a link to another forum topic in the comment on a Gallery image and it will show a preview of that topic rather than a simple link.
We are always open to suggestions so feel free to post in our feedback forum. Thank you!

We have released version 4.1.9 with many bug fixes, performance improvements, and feature enhancements. Our thanks to the QA team and all our clients who participated in the beta release.
This is also a security release so please upgrade as soon as possible. All Suites will see the red alert banner show.
To be notified of updates as soon as they are available you can add an email address in your AdminCP under General Configuration.
 
New or Changed Features
When your link auto-embeds in a post such as with an image, YouTube video, Twitter link, etc. an option will now display to revert the embed back to a plain text link if you do not want the embed. New setting to disable embedding. Facebook/Twitter integration improvements If you are an administrator and encounter a system error, additional debug output will now display. Regular members will see the normal error message. Custom Fields for Support Requests in Commerce now show on the front-end. If an advertisement is set up with a main image, but not smaller images for tablets/mobiles, the ad would not show at all on tablets/mobiles. This has changed so the main image will display on all devices unless smaller images are provided. Topics scheduled to automatically lock or unlock will now reflect this in the topic listing and when viewing the topic. Placing a link to a Facebook status will embed when possible. When viewing a report, the container (for example, the forum) the content is from is displayed. Three character searches are now allowed in the Admin CP Live Search. The Account Settings page now uses vertical rather than horizontal tabs to prevent overflow. If Gravatar is enabled, and a user has not defined an profile photo, then their email address will be used to fetch from Gravatar unless explicitly set not to. Gfycat embeds now use their oEmbed endpoint rather than their JS API. Using Amazon CloudFront as https provider will now be recognized as valid secure connection. The member REST API endpoint will now return custom fields. The Developer Center for Plugins now shows the filename in the list of hooks, and when editing a hook, a breadcrumb includes a link back to the list. Inline notifications can now be dismissed Efficiency improvements to the search index You can now close a poll independently of the topic You may want to read a bit more on our embed improvements:
And Activity Stream improvements:
We are well into development on version 4.1.10 which will follow along soon. Keep an eye on our Release Notes for updates on what will be coming in that release.
If you have any issues please open a support ticket. You can also submit reports to our bug tracker. Thank you!