Blocks are a core concept in IP.Content, allowing you to easily create widgets that you can embed on any page (within IP.Content or otherwise). IP.Content 2.1 introduces several useful updates for blocks that we believe will help you customize your pages even further than before.

Status Updates Plugin Block

IP.Board 3.1.0 improved status update functionality greatly, adding multiple status update support, commenting, and more. Along with this new functionality, the status updates sidebar plugin that is displayed on the forum index was updated to support the new features.

IP.Content 2.1.0 introduces a new plugin block that allows you to display this status update plugin on any IP.Content pages you wish.

New Feed Blocks

As of IP.Content 2.1.0, you will now be able to create feed blocks of both profile comments and status updates (and replies). This new feed block is available in addition to the previously mentioned status updates plugin block. You can filter both feeds to control what content is pulled based on the poster and receiver information (for instance, show all profile comments made by my friends, or show all profile comments received by the admin of the site). These feed types can be useful for creating social networking style pages – perhaps you want to show a feed of all profile comments for the currently logged in user, or perhaps you want to show a feed of all recent status updates from the logged in user’s friends. These new feed types can be used in creative ways to create social pages your users will love.

New Filter Options: Members Feeds

Beginning with IP.Content 2.1.0 some new filtering options have been added for member feeds. You can now restrict a member’s feed to only show members you are friends with. This can be useful to create a “friends feed”, for instance, in order to list all of a particular user’s friends. You can also now filter member feeds to only show logged in users. You could, for example, combine this with the option to only show friends for a user to show all of your currently online friends. These two new filter options can be used in creative ways to make interesting member feeds for your community.

Dynamic Filtering for Databases

In IP.Content 2.0, you can filter database and article feed blocks based on arbitrary data in up to 5 fields. This can be useful to create content-driven feeds based on specific fields in your database, however it has the drawback that the feeds are always static based upon the configuration in the ACP.

Beginning in IP.Content 2.1.0, you can now configure the database and article feeds to filter based on input variables. For instance, you can embed one of these feed blocks on a page, and then when you link to the page you can add an input variable that will allow for dynamic filtering of the content. This is probably explained easiest through an example.

Let’s say you have a page “results.php” that you have embedded a database feed block in. This ecan create a feed of results from your database based on the block configuration in the ACP. With IP.Content 2.1.0, you could set one of the custom filter fields to search one of your database fields for “@title”. The @ symbol here tells IP.Content to obtain the filter from the input variables – in this case an input variable named ‘title’. When linking users to this page, you would use a URL similar to “mysite.com/results.php?title=hello”. When IP.Content loads this page and parses the block, it will use the value from the input variable (“hello” in this example) to search in the field, finding all records that have “hello” in the title.

This feature may be hard to understand at first, but affords developers with powerful ways to create unique pages without having to manually configure feeds for every possible scenario. We will be posting some documentation on how to use this feature following the release of IP.Content 2.1.0.

We hope you find these updates to the blocks in IP.Content 2.1.0 useful and look forward to your feedback!

One of the main criteria for IP.Tracker 1.4 is to make it incredibly powerful and allow you to configure it in thousands of ways, custom to your own community and needs. Having complete control over a product allows you to make it fit in with the way your website works. As we’ve stated numerous times over the past few months, we don’t want IP.Tracker 1.4 limited to just a bug-report system, we want you to be able to use it in lots more ways than just bug reports.

We have come up with numerous framework changes to accommodate this and we can’t wait to show you some of the main changes of IP.Tracker, but these areas are not ready yet – so to carry on with our IP.Tracker 1.4 development entries we will be showing you the more advanced permission options IP.Tracker contains.

Every system needs a gatekeeper
A project management system without management is, well, just silly. We know how advanced some of the projects you use IP.Tracker for are, we know you need advanced permissions to customise it to your needs. That is why, in 1.4, we have developed a whole new permission system which will allow you to control access, and ultimately have a completely flexible system.

Moderators before 1.4
IP.Tracker has always had a moderator option, you can assign members as moderators and they can manage your bug reports – simple. They can assign versions, statuses and lock issues. They can even delete replies, basically they have the same array of options that forum moderators get, but specific to IP.Tracker. The trouble we had though, was that you could not easily restrict moderators to the built-in fields such as versions.

The main reason for this was that we added the built-in fields such as ‘fixed in’, and ‘custom fields’ years after the moderator system was made, and it was simply not flexible enough and did not have room to grow. For example, this was the default screen you would see when listing moderators in IP.Tracker 1.3.

In fact, it was so badly neglected that it would not even tell you that there were no moderators for this project! It simply gave you an empty table, providing no helpful information. Even worse, when you went to add a moderator or group it was even more neglected, a long list of boring form elements. There were also not many options pertaining to the default ‘fields’, most of the moderating power you had in 1.3 was to do with editing/deleting posts.

Once you had created a moderator, there was also no clear way to view what permissions you had given them unless you went back through the form. It was obvious this had to change.

Moderators in 1.4
We are pleased to reveal the latest copy of the moderator control panel in IP.Tracker 1.4. If you remember from our last blog entry detailing interface changes to the projects listing, you will recognise some of the changes we have made to the moderator area. One of our goals from an interface point of view is to make everything in IP.Tracker uniformed and familiar, whilst keeping it simple and professional.

Remember the screenshot of the moderator listing that I showed you above from 1.3.1? Here is the same area in IP.Tracker 1.4.

This screen is now the overview for all moderators within IP.Tracker, and can be accessed with one click – you no longer need to go through lots of projects to find the moderators you need to. IP.Tracker also quickly tells you whether or not they are a super moderator, and if they aren’t it will tell you how many projects they moderate. All of this information was not easily locatable in older versions of IP.Tracker. Let’s move onto the moderator creation screen!

As we briefly showed you with the new project creation screen, we’re trying to get rid of boring old lists which took ages trying to find the options you wanted. We’re keeping this uniform throughout the Admin CP in IP.Tracker – we don’t feel its necessary to have five different style of forms when it will just confuse the end-user. Without further ado..

Now, we’ve just shown you an awful lot, but it gives you a very good idea of how powerful IP.Tracker is, and you know all those hard-coded ‘fields’ we talked about earlier that are in IP.Tracker 1.3? IP.Tracker 1.4 includes a powerful system which means none of these are hard-coded anymore, and 3rd-party developers can create their own ‘fields’ with the exact same integration as our defaults ones! More on that in another blog entry though!

These are just the default fields we have produced at the moment, we have a lot planned for IP.Tracker 1.4, with all these new sets of permissions you can truly customise Tracker to what you want to use it for, this simply wasn’t possible in previous versions.

Moderator Permission Masks
Creating moderators can be a pain if you are adding 5 moderators with the same permission mask, even more so if you then have to go back and update every single moderator. IP.Tracker 1.4 includes a permission mask system where you can reuse permission ‘templates’ across moderators. For example, I could assign a permission mask to the moderators Keith and Stuart, and instead of updating Keith and Stuarts permissions individually I can just update the mask and they will both be updated in the process.

We won’t be showing you the interface, because it is the exact same as the screenshots I have just shown you above, minus the first tab. We reuse a lot of the same templates to keep the backend code of IP.Tracker more efficient

One more thing..
In IP.Tracker 1.3 if you wanted to view what permissions a moderator had, you had to go into the creation system and manually look it up with dozens of radio boxes looking at you – it was not for the faint hearted. If you wanted to view what projects that moderator could moderate, it was even harder – there was no central screen and it meant you had to visit every single project and see if the moderator had access there.

The very first screenshot of the 1.4 moderator area I showed you today contained this link in the moderator table.

Now, this is the first design of the feature, in fact if I am completely honest I started writing this feature 30 minutes ago. This means the basic look of the feature can, and probably will change. However, clicking ‘View Permissions’ in 1.4 does exactly what 1.3 didn’t do. It shows you all of the moderators permissions, and what projects they moderate in! Couldn’t be simpler!

Wrap-up
So, thats our moderator and permission masks area in IP.Tracker 1.4 – development as a whole has been progressing rather well, but we are still a long way off from showing you any of the front-end. As always, because it’s so early in the development phase, anything you’d like to see which involves the moderating functions of IP.Tracker, be sure to leave in the comments! Thanks!