Jump to content

Invision Community Blog

Effective moderation features are essential for online communities. Forums, blog entries and member-to-member messaging are particularly attractive for spam bots and nuisance users alike. IPS Social Suite has always been best in class when it comes to moderation features with features like the free IPS Spam Service that are completely unmatched by other web applications. Over this series of 5 blog entries I'm going to introduce you to some of the new moderation features in the IPS Community Suite 4.0.

Part 1: Setting up moderators
Part 2: Approval Queue
Part 3: Reports
Part 4: Effective Moderation
Part 5: Warnings




Sometimes content needs to be approved before it can be viewed. This can happen when:Approval is enabled for a particular member (perhaps for a particular time after giving a warning) Approval is enabled for a group (perhaps for new members until they have been registered for a certain number of days) Approval is enabled for a forum/category/etc.

Currently, if there is content requiring approval, badges display next to the forum/topic to alert moderators. While this works well it has some drawbacks: it means clicking around the community to find content, and if there's an area of your community you don't visit very often (personally I don't often check the gallery here) sometimes you might not notice something needs to be approved.

For 4.0, we wanted to improve this. There were two main goals we set: What we've created is a new area of the moderator control panel which we call the Approval Queue. When you visit the approval queue, you see the first topic/post/comment/whatever which is pending approval: As you can see, the page shows you clearly who posted it, what it is and the content. You can click on the badge on the right (in the screenshot above where it says "File Comment") to be taken directly to it if you want to see it in context. At the top, you can see 3 really clear actions: approve, skip and delete. Clicking any of these will do that action, and then immediately show you the next thing pending approval. This allows moderators to move through the queue really quickly and effortlessly. By clicking on the author's name, you can also issue a warning, flag the user as a spammer and send the user a message - all this is done without leaving the page: And when all content has been approved, you can enjoy the satisfaction of an empty queue: Here's a video of it in action: As an incidental feature - previously if a member made a post and it needed to be approved, they would get a confirmation message telling them so but wouldn't be able to see the post. This sometimes led to confusion when members missed the confirmation message and thought their post hadn't been submitted. In 4.0, users can now see their own posts which are pending approval: [*]Content from across the suite should be pulled into a single area for moderators so moderators can locate content pending approval manually. [*]Moderators should be able to act on content pending approval (usually by approving or deleting) quickly.






























  • 16,430 views
Mark
Day to day administration of your site and particularly managing member permissions has been greatly improved in IPS Community Suite 4.0. It is now easier than ever to see who has access to what but there are still times when being able to see exactly what a member sees can be useful. Perhaps a member is reporting that they can't view a section of the site or they need assistance altering settings on their account? For this reason administrators can log in to other users accounts automatically via the admin control panel where allowed.

Security

When dealing with access to other people's accounts security is of critical importance and we take this very seriously. Permissions for this are of course controlled by the ACP restrictions system so the ability can be toggled easily on a per user or group basis only to trusted administrators. The member also does not need to reveal their password to the administrator and all login actions are recorded in the logs so security and an audit trail is maintained.

Logging In

The process of logging in as a user starts in much the same way as in previous versions of the suite. When viewing a member in the ACP you simply click sign in and a new window with your user session is created.



For IPS Community Suite 4.0 we have improved several areas of this implementation. Firstly, when logging in as a user you do not lose your existing admin session. You still show logged in as yourself but acting on behalf of somebody else. The user menu updates to show this and serve as a reminder so you do not forget to log out and continue posting using another account. All actions you now perform are as if you were logged in as the user themselves. Viewing and posting permissions reflect the user you are logged in as and any content created will show as if posted by that user.



In previous versions not having this workflow was frustrating as you would log in as another user and then when you were finished need to log back out and then log back in with your administrator account. We have now made this seamless. When logging out from another user account in IPS Community Suite 4.0 you are simply returned back to your original admin session with no need to log back in.

Summary

We hope that these small but powerful changes make for a much more productive workflow. Helping members with access issues and making sure your user permissions are set up correctly should now be much more practical and intuitive.


  • 16,491 views
Andy Millne
Effective moderation features are essential for online communities. Forums, blog entries and member-to-member messaging are particularly attractive for spam bots and nuisance users alike. IPS Social Suite has always been best in class when it comes to moderation features with features like the free IPS Spam Service that are completely unmatched by other web applications. Over this series of 5 blog entries I'm going to introduce you to some of the new moderation features in the IPS Community Suite 4.0.

Part 1: Setting up moderators
Part 2: Approval Queue (New Feature)
Part 3: Reports
Part 4: Effective Moderation
Part 5: Warnings




Up until now, each application has been responsible for managing it's own moderator permissions (for example, you go and set up a moderator in the forums app, then in the gallery app, etc.) and there's been a concept of "global" or "super" moderators who can perform all moderator actions in all applications.

In IPS Community Suite 4.0, we're centralising the creation and assigning of moderator permissions, and are doing this separate from groups (so you can now make just a member a moderator without putting them in a special "moderator" group). It works very similar to Admin Restrictions in 3.x.


Here is the Moderators page:

(In this screenshot I've given moderator controls to everyone in the groups Administrators or Moderators, and to the user "Brandon")

When editing a moderator you see all of the permissions available across all applications.

This screenshot shows global moderator permissions which apply across all applications:


If you do not want to allow any of these globally, you can make them available only to certain areas - when any option is toggled off, the equivalent option will show under each application tab, along with an option to select which areas of that application it can be done in. For example, if I disable the "Can edit all content?" option, a "Downloads" tab appears with the following options:

This allows me to choose what the moderator can edit, and in which categories they can do it. A similar tab appears for each application I have installed, or additional options appear on the tabs.

Also when editing a moderator I can control permissions not related to content, for example, how they can use the warning system:

Member management permissions:

And more.


When editing a moderator, I also have the option to "Give All Permissions" which makes them akin to "global" or "super" moderators in 3.x.


When editing a member which has been given all permissions, I will see a message reminding me that if I remove any permissions they will no longer be a global moderator:
  • 21,448 views
Mark
For many years, IP.Board has featured a "Moderating Team" page where the community moderators are listed so that users can quickly and easily identify who to contact in the event they need assistance. This page has typically been a somewhat generic table-style view of users who are a moderator of some level. The page is not configurable and has limited usefulness and relevance when you consider the entirety of the suite. It is a relic of an older age and it really stood out as needing an overhaul, so that is exactly what we have done in 4.0.


Configurable

As mentioned above, the moderating team page has never been configurable in IP.Board. If a user is a moderator (either a super moderator, or a forum-level moderator) then they are displayed on this page. The users are displayed in basic alphabetical order in a table-style view and you cannot easily see which user is responsible for which roles on the site. Furthermore, if you add a moderator to another application (for instance, IP.Downloads or IP.Gallery) then they may not be displayed on this page if they aren't also a moderator in the forums.

We have completely done away with the way this page used to work and rethought it from the ground up. Its purpose is simple: show the viewing user which users on the site are "important" and their relevance to the site. To implement our goal, we have decided to make the entire page configurable.

In the admin area you can now create groupings for this page. This means that you can put some users in one group, some users in another group, and so on in order to better reflect the hierarchy of your organization. For instance, here at IPS we would list Management staff at the top, followed by Developers, followed by Support Agents, and possibly followed by community moderators. You can reorder the groups however you see fit to ensure that the most important users are listed first.

You can also now associate a template with each group. When you view the staff page, you will probably want to show a little more information for the most important users, but you may want to just show simple links to a profile for the regular community moderators. By default we will ship with 3 or 4 basic templates that we feel will allow you to display staff groups in different ways to better reflect your organization, however any administrator can add new templates by simply creating a template with the appropriate prefix in the appropriate template group.

When you add users to a group, you can specify a custom name to show (which will fall back to the member's username), you can specify a custom title to show (which will fall back to the member's title) and you can specify a bio to show. Users who are displayed on this page can edit their details right from the staff page directly.




Viewing the page

We wanted to allow this page to be set up to better reflect the staff on a community. A simple listing of moderators is no longer relevant for many users of the Community Suite - you may want one moderator to not be displayed because they only manage pre-sales questions, or you may want an administrator who is not a moderator to be displayed, or perhaps you want to create a game roster instead of displaying staff but you don't want to give those users moderator privileges on the site. Now you can do that, and you can better present the page to your users.



As you can see here, the first grouping (labeled "Management") is displayed in full width. The second grouping called "Developers" are blocks that take up half of the available width. The last grouping called "Support Agents" are rows of 4 blocks each. It is important to note that the interface is subject to change and we are still putting some finishing touches on this screen, however hopefully the screenshot will give you a good idea of how the page can be laid out to improve communication between your staff and your visitors.
  • 14,455 views
bfarber
Almost all of our applications support commenting or reviewing to some degree. You can comment on events in IP.Calendar, images in IP.Gallery and blog entries in IP.Blog, and you can review products in IP.Nexus, for instance. The differences between reviewing and commenting are subtle, yet important. Commenting allows you to say something about a content item that has been contributed, while reviewing is intended to allow you to give feedback about the item based on your experience. You should not be able to review something you have not seen or used, for instance, and you should only be able to review it once.

We have worked on developing these concepts further for 4.0, and bringing both capabilities easily to all applications in the suite.


Comments

Any application in the 4.0 suite can support commenting easily. From a development perspective, you need only create a content comment class that extends IPSContentComment (and define a few methods in this class, such as how to generate the URL to the comment), and then in your main content item class you specify this new content comment class in a specific property. For example, with IP.Downloads we have the following in the content item class

/** * @brief Comment Class */ public static $commentClass = 'IPSdownloadsFileComment';
And then there is, as you would expect, a commenting class found at IPSdownloadsFileComment which extends IPSContentComment. This comment class defines a few properties, and then defines a single url() method (which must return the URL to the comment). Almost everything else is handled automatically by the suite.

Otherwise, comments work largely similar to the way they work in 3.x. Moderators can edit, hide, approve and delete comments. You can allow certain users to reply to locked content (e.g. to leave a comment on something that is locked), but otherwise locked content cannot be commented on. You can use multi-moderation on comments and you can quote and multi-quote comments. All of the functionality you would expect to see is still present.




Reviews

There are only a few primary differences between reviews and comments.
You may only leave a single review on a content item. Once you have left a review, you will not be able to leave another. When leaving a review, you are presented with a 5-star panel from which you should select your star rating. Some applications may further restrict your ability to leave a review. For instance, there is an option in IP.Downloads to only allow users who have downloaded a file to leave a review.


As of the 4.0 Community Suite, any application can now support reviews just as easy as commenting. Further, as a developer you can support both simultaneously (and, typically, the administrator can disable one or both systems if they choose). Reviews work almost the same as comments from an implementation perspective. You create a review content comment class, and you define a specific property in the content item class. For IP.Downloads you will see this in the content item class
/** * @brief Review Class */ public static $reviewClass = 'IPSdownloadsFileReview';
And then you will find a review class at IPSdownloadsFileReview, which extends IPSContentReview (which in turn actually extends IPSContentComment). The review class for IP.Downloads, just like the commenting class, only contains a single method to define how to generate the URL, as well as a few required properties.


When reviews are left and a star rating is applied, this rating is averaged and applied to the content item. A content item could in theory support both the traditional star rating system (like you might see in IP.Downloads or even in IP.Board in the 3.x product line) and reviews at a technical level, however it is recommended to prevent confusion that you either use the traditional rating system OR reviews, but not both simultaneously. Most applications in 4.0 that support reviews will not support the traditional rating system as a result.



You will note in this screenshot that because I have not yet downloaded the file (which is an optional reviews-related restriction in IP.Downloads) that I am unable to review the file at present. When a user does not have permission to do something, the 4.0 community suite makes every effort to clearly indicate why the user is unable to accomplish a given task.

Other users reading a review can determine if they found the review helpful or not (although you are unable to specify this on your own reviews of course), and these yes/no votes are subsequently tallied in order to allow users to sort reviews by "most helpful" per the sorting buttons at the top right of the above screenshot.




Wrapping up

Applications are capable of displaying either reviews or comments (or both) in any manner they wish, however you will find that most applications in the 4.0 suite that support reviews and/or comments will display them in a fashion similar to the above screenshots (noting all the typical "these are early screenshots and the final product may appear different" disclaimers). By supporting both of these similar yet slightly different functionalities out of the box, we believe our first party applications as well as third party applications by our talented development community can really shine and allow end users to interact with the community in logical and focused ways. We hope these changes allow you to set up your own community to cater to your users in the manner best suited to your community.
  • 13,546 views
bfarber
IP.Calendar has supported basic recurring calendar events for many versions now. You can create events that recur weekly, monthly or yearly in IP.Calendar, and they will automatically show up on their specified schedule. While this capability is certainly useful, we felt it was time to enhance event recurrence capabilities in the next version of IP.Calendar.


New options

Recurring every week, month or year is useful, but there are many other ways events can recur and IP.Calendar has no provisions to accommodate those recurrence types in the 3.x IP.Calendar release. For 4.0 we have added several new recurrence-based options to the calendar.

Recur daily, weekly, monthly or yearly
In addition to the three options available in previous versions, you can now configure events to recur daily.

Recurrence frequency
You are no longer restricted to recurring every week (or month or other time period). You can now configure events to recur every 2 weeks, or every 3 months, or every 10 days, or whatever period of time you need to.

Weekly recurrence: days of the week
If your event recurs weekly, you can now specify the days of the week the event should recur on. This means you can configure an event that recurs weekly on every Tuesday and Thursday, for instance.

Recurrence timeframe
In previous versions of IP.Calendar, the end date specified when the event should stop recurring. In 4.0, the end date/time specifies when the original recurrence end date/time are. This means you can have an event that lasts 2 days and recurs annually, for instance (in other words, recurring ranged events). When configuring the event, you now have three options for specifying the recurrence information:
Never end End after a certain number of occurrences End on a certain date


You can now configure events like Christmas which never end, you can configure meetings which have a certain number of occurrences before they are finished, and you can configure recurring events that end on a certain date.


As you can see, the options have been greatly expanded to accommodate many more types of recurring events.




Some technical details

At a technical level, event recurrence data is stored as an "RRULE", just like the iCalendar specification will specify. In fact, the data should be a 1:1 equivalent. If you import iCalendar events which have recurrence capabilities not supported by calendar, those events will be skipped during the import routine (as they are presently), however there are now far fewer recurrence capabilities that are wholly unsupported.

By storing the exact RRULE value we have a few benefits over previous versions of Calendar:Event importing is simpler, as we can copy the rule directly into the database unmodified (after verifying we support all parameters) Event exporting is simpler for the same reason We can expand recurring event support in the future if necessary with few database changes necessary


Using PHP you can easily find future event recurrence details using the nextOccurrence() method.
/** * Find the next occurrence of an event starting from a specified start point * * @param IPScalendarDate $date Date to start from * @param string $type Type of date to check against (startDate or endDate) * @return IPScalendarDate|NULL */ public function nextOccurrence( $date, $type='startDate' )
This instance method is run against a calendar event, passing in a date to find the next occurrence from. You can look for either start date or end date.
  • 10,122 views
bfarber
The submissions process in IP.Downloads has a certain complexity that may not be apparent at first. As well as simple file uploads, we also support adding files from URLs and from the local file system, and screenshots can also be added in these ways. Which category you choose to submit to affects which of these options are available. In addition, via the AdminCP you can bulk-upload files - but not via the front-end.

For IP.Downloads 4, we wanted to improve this process with interface and functionality changes.

Submitting Files

Here's a video demonstration of how creating a single file record in IP.Downloads works in v4:



We've worked hard to improve the flow for users here - while they are uploading files (which may be large and take some time), they can continue adding the other file information such as screenshots and meta data. While that's happening, the upload progress is always shown at the top of the screen. In the video you'll also see how image uploading is handled, as well as prefixes in the tag system, which are now supported throughout the IPS Community Suite.

Bulk Uploading

Instead of going to the AdminCP to bulk-submit files, single- and bulk-uploads are now handled through exactly the same process on the front end. This means users can be granted bulk-upload permissions without requiring AdminCP access, a big improvement on the current implementation.

To bulk upload, a user clicks the "Submit a file" button as normal, and chooses "I want to submit multiple files at once". They see the same upload area, but this time, the file information step is handled separately after the page is submitted. Each uploaded file has a separate block for file information and its own set of screenshots.








We'll of course be showing more of the IP.Downloads homepage and file view later, but we hope that gives you a taste of what to expect in IP.Downloads in IPS4.
  • 12,600 views
Rikki
Following content is an important aspect of interacting with your community. It allows you to be notified when there are updates to the content or when other users comment on the content, and it allows you to find content you are interested in at a later date. We have taken the opportunity with 4.0 to enhance the system where-by users can follow content in the IPS Community Suite to simplify and clarify certain processes, make it easier to follow content you submit, and to be sure you are receiving the notifications you wish to receive.


Following your own content

One area of improvement that was identified during planning meetings for 4.0 was the process of following your own content. While the forums have a method in place already to follow new topics you create (or to automatically follow topics you reply to), the rest of the suite has no such similar capability in place. We wanted to make it easier for users to follow the content they are submitting to make it more likely they will be aware of comments posted to their submissions, in turn making it more likely they will return and continue to interact with the community.

In all applications in 4.0, when submitting new content you will have the ability to follow that content right away.



When replying, similarly there is an option to automatically follow the content you are replying to.



In your Notification preferences panel, you can choose to automatically follow new content submissions by default and you can choose to automatically follow content you reply to by default (in which case the appropriate checkboxes would be checked by default during submissions and commenting). These options affect your content submissions and comments across the entire suite in 4.0.


Following other content

You can follow other content submitted to the community by clicking on the "Follow" button available in the appropriate area. As with 3.x, you can follow containers (e.g. follow a forum or an IP.Downloads category), and you can follow content items (e.g. a topic or an IP.Downloads file).



You can follow content items and containers both publicly, which means others will be able to tell you are following that item, and anonymously, where you will receive notifications of updates to the item but others will not be able to see you are following it. You can choose to receive an email notification immediately when there is a reply to the content, or you can choose to receive a daily or weekly digest. Digest notifications have been expanded suite-wide and are now supported in all applications automatically. As with 3.x, you can choose to receive an email notification or an inline notification on the site (or you can choose to receive neither or both if you prefer).

One common issue encountered in IP.Board 3.x was that users would follow something, however their notification preferences were configured in a manner which meant they would never subsequently be notified of updates to the item they are following (because they have chosen not to receive neither email nor inline notifications for that follow method). The 4.0 suite recognizes this scenario and warns the user in this event.




Summary

We have worked to improve and clarify the follow system where possible in the 4.0 suite, while still retaining the same level of functionality and flexibility you have available in 3.x. The ability to automatically follow new submissions should help users remain engaged on your site when other users comment on their contributions, bringing them back and enticing them to continue contributing to your site. The improved clarification when users will not receive notifications due to their preference configuration will help reduce staff overhead in answering questions, as well as visitor confusion and frustration.

We will talk about notifications themselves in a future blog entry, however we hope these changes help improve usability and interaction with your site by your visitors.
  • 12,935 views
bfarber
Please note that this entry may be a little technical, if you do have any questions, please post them in the comments below.

A little history
IP.Board was first released over ten years ago when the web landscape was very different. A lot of emerging technologies were still trying to define new standards. Very early versions of IP.Board allowed one to specify the document character set and had a default of "ISO-8559-1" which is useful for languages that use latin based characters. This meant, for example, that if you needed Chinese characters you would need to change the character set to something more suitable. This disparity between character sets creates many challenges when working with a single code base.

UTF-8
Over the past handful of years there has been a push towards a single document character set; UTF-8. UTF-8 is a variable-width encoding that is able to show every character in the Unicode character set. This makes it suitable for latin and Chinese characters (and many many more!). Popular Javascript libraries such as jQuery require that data is sent and received with UTF-8 and many native PHP string functions prefer UTF-8. The future is very much UTF-8 and trying to keep our codebase working with any other character set is going to be more and more challenging.

IPS 4.0
Even though IP.Board 3 introduced UTF-8 as the default character set for new installations, we're aware that we still have many clients that are not using UTF-8 currently. IPS 4.0 is going to be strictly UTF-8 only which means we need to convert the data before or as part of the upgrade process.

Converting to UTF-8 isn't as simple as changing the database encoding. Merely doing this will simply corrupt the data you have in your database. We need to be a little smarter and use a script to do this work for us.

The great news is that even if you choose to convert your data to UTF-8 today, your IP.Board 3.x will run just fine and you may even find it more efficient as it doesn't have to convert lots of data on the fly.

The IPS UTF-8 Database Converter
We've written a script that can safely convert your database to UTF-8. The script does not overwrite your data until you manually confirm that the conversion process has been successful. This means that there is no risk of corrupting your existing data.

Of course, it is good practice to perform a full MySQL back-up before making any changes to the database as a precaution and we recommend that you do this.

You can download the converter and its instructions here.

How can I tell if I need to convert my database?
When you first run the converter, it'll check your database and let you know if you need to convert or not. Even if you are running UTF-8, you may not be using the correct collation (utf8_unicode_ci) so you have the option of changing your collation which is a very fast procedure and does not need a full conversion to complete.

If you first used IP.Board with IP.Board 3.0 then you may only need to change your database table collation. This isn't a required step and the IPS 4 upgrade process will perform this task if you'd prefer to wait until IPS 4.0 is released.
Support
Please note that while we're happy to provide some pointers within the client forums, this release is not officially supported by our technical support department.

Beta Release
As this is a beta release, please be aware that there may be bugs. If you do spot one, please post it to the IPS Extras bug tracker.



  • 24,455 views
Matt
A few years ago we revolutionised theme editing in IP.Board with the addition of the "Visual Skin Editor". This tool quickly became a popular way of making broad color changes to new themes to match in with an existing site or existing branding. For the first time, you could instantly view the changes you were making.

Goodbye Visual Skin Editor, hello Easy Mode Editor.
We have rewritten this tool from the ground up in IPS Suite 4.0 and renamed it the Easy Mode Editor now that it's a fully integrated part of the suite and not just a license add-on. It retains all the features you love and has a much better interface, more control and fully supports gradients. Let's take a look!

When you create a new theme, you have the option of creating an "Easy Mode" theme or a "Manual Mode" theme. As you would expect, the manual mode allows full editing of CSS and HTML. Easy mode allows you to edit the theme with an instant preview.



Once the new theme has been added you can launch it from the Theme list inside the administrator's control panel by clicking the wand button. You can still edit the HTML templates and custom CSS as normal should you need to.



The easy mode editor launches in a new browser tab or window (depending on your browser's settings). The floating palette overlay in IP.Board 3 was a little cumbersome as it took up a fair amount of room and you had to move it out of the way to view your changes. In IPS 4, we've made this a fixed sidebar which means that it doesn't have to reload when you navigate through the suite.



I've cropped out most of the public display as we're not quite ready to reveal that yet!

You can quickly colorise your new theme with the Colorize option. This chromatically changes the main colors of the suite quickly and easily.



A limitation of the Visual Skin Editor in IP.Board 3 was that it couldn't manage gradients so themes had those gradients removed and flat color applied. We now support gradients in IPS 4.0 from the Easy Mode Editor's color editing panel.



We previously blogged about the fantastic new theme settings feature in IPS 4.0. Some of these settings are now available to editing in the settings panel. This is a really quick and convenient way to change these settings.



Although the new Easy Mode Editor allows you to change most of the colors within the suite, there may be times when you want to write a few lines of custom CSS to tweak the theme a little more to your liking. We've got that covered too.



You can leave the theme as an Easy Mode theme for as long as you want. However, you may decide that you want a little more control and need to edit some of the framework CSS that underpins the suite. That's easy to do. Just choose the option to convert it to a Manual Mode theme and you are all set.



Never before has theming been so simple! This re-invented tool allows you to quickly edit your theme without fuss and you can instantly see the changes as you make them. We can't wait to see what you do with it!
  • 18,670 views
Matt
A little history

For many years, IP.Board functioned under a relatively normal model of managing a content's status. A topic, for example, was either unapproved or approved. If a moderator did not like the topic, that moderator could delete the topic. This worked well for many years, but improvements in technology and processes necessitated changes. As IPS software evolved we recognized the need to handle all content throughout the entire suite in a uniform manner, so old concepts like the "trash can" forum were no longer relevant when considering how you work with Gallery images or Download Manager files. Additionally, many sites today employ moderators that they do not wish to entrust with the complete ability to irrevocably delete content, yet they still need the moderator to be able to clean up a mess should it occur.

A few years ago, we introduced the concept of "soft delete". In practice what this meant was that when a user soft deleted a topic, the topic would be removed from general view for most users, but the topic would not actually be deleted. Administrators could choose who can view soft deleted topics, and who could "un-delete" the soft deleted topic.

Some time after this, the way topics were deleted changed as well (which was now referred to as "hard delete" in contrast to "soft delete"). If a topic was truly deleted, it would not actually be immediately removed from the database. Instead, a flag was set and the topic would be deleted from the database at some future point in time by a task. The idea was that you may need to restore something that was deleted by a moderator...but then, the software already supports a soft-delete concept to account for this, right?

When clients proved to be confused with all of the terminology (we can't blame you!), "hard delete" was renamed back to "delete", and "soft delete" was renamed to hidden. Nevertheless, behind the scenes we still had all of the various statuses to account for

Content is awaiting approval (unapproved) Content is approved and viewable (approved) Content has been hidden or soft deleted (hidden) Content has been deleted but not removed from the database yet by the task (pending deletion) Content has been deleted and is gone permanently (deleted)


And how about 4.0?

In reviewing the needs of most admins and how the process of managing the content and your moderator roles works in the real world, we decided to simplify and improve this experience.


The 4.0 Suite now has just 4 of the above statuses, and they behave in a manner you would expect.If you require moderator approval of new content, when something is submitted it will be in an unapproved status. If you do not require moderator approval of new content, that content will be approved automatically and immediately viewable. If a moderator has permission to hide content, the moderator will be able to hide any content that has been submitted. The moderator may or may not be able to see content that is hidden, and may or may not be able to restore hidden content to viewable status. (All that depends on Admin settings.) If a moderator has permission to delete content, the moderator will be able to delete content that has been submitted. Upon doing so, the content is immediately and permanently deleted.


You can configure your moderators such that they are able to hide content, delete content, or both.

As with 3.x, moderators who can see hidden content will be able to review all hidden content in the Moderator Control Panel, and those with permission to restore hidden content will be able to do so from here as well. You will not have to worry about the content you are viewing in the Moderator Control Panel is deleted or hidden, as there is only one status now.


This is an example of a very minor change that was made after careful consideration of how the software functions and should "flow" when being used in a real-world situation. It is often the case that the smallest changes can make the biggest impact in the eyes of the users.
  • 15,323 views
bfarber
IPS Connect is our in-house cross-site authentication framework utilized by IP.Board in order to facilitate sharing of login credentials on one or more of your websites. While IP.Board supports Connect out of the box (meaning administrators of two or more IP.Board installations can allow users to use the same login credentials on any site in the network with just a few clicks in the ACP), the design of the system allows for third party software to tie in to the network as well. Indeed, one of the more popular addons in our Marketplace is the Wordpress IPS Connect plugin.

We have made several changes to IPS Connect in 4.0 that we believe will help you better manage a network of sites designed to share login credentials amongst them. These changes stemmed both from our own internal use of IPS Connect and from direct user feedback in our feedback forums.


Fundamental Improvements

In IP.Board 3.4, a "master" installation has no knowledge of any "slave" installations that may call to it. Any IP.Board can be set up to call to the master installation and this mater installation will never remember that the slave has called to it in the future. While this is fine for basic login credential checking, the original design of IPS Connect introduces many limitations. For instance, updating your email address on any given site cannot cause the email address to be updated on all sites because there is no central installation that knows about any of the sites in the network. Similarly, logging in to one site cannot log you in to all sites because all of the sites on the network are not actually known at any one location (we do, however, work around this if all sites are on the same domain).

Beginning with 4.0, the master installation will "register" any site that connects to it using IPS Connect. This introduces many benefits:
If you make a change on any individual site (master or slave), that change can now be propagated to all other sites in the network. Logging in or out of any given site can log you in to all other sites (because all other sites are now "known") Requests can be queued if there are problems You can create a listing of all sites in the network from the master installation


Further, we have thought through potential issues and have implemented a queue system where-by if requests to an individual site in the network begin failing then those requests will be queued and reattempted at a later date in the order they were originally received. If failed requests start queuing on the master installation, an ACP dashboard block will show you this and let you attempt to process them manually. If the issue causing the requests to fail has been resolved, the queue can quickly clear out in this manner (vs waiting for the task to clear them out). If the issue is still occurring, however, you will be given some additional information which will be helpful in determining why the requests are failing. Finally, if the site in question has been taken offline and future requests should not be sent to it, you are given the opportunity to unregister the "slave" installation so that the master will no longer communicate with it.


More changes propagated

We found while using IPS Connect internally that we wanted certain actions to propagate across all sites on the network but IPS Connect did not handle this, and we subsequently had to develop custom hooks in-house to account for the missing functionality. As a result, with 4.0 IPS Connect will now manage a few additional capabilities.

Banning
As of 4.0, if you permanently ban a user from the admin control panel, the ban will be copied to the rest of the sites in the IPS Connect network. Bans are only propagated to other sites if initiated via the admin control panel as a security precaution. It is probable in many cases that you do not want moderator actions on one site affecting accounts on another site, so front-end bans will not be copied to other sites.

Deleting
As of 4.0, deleting users from one site in an IPS Connect network will now cause the user to be deleted on all sites in the network.

Merging
Similarly, as of 4.0 when you merge two users on a site in an IPS Connect network, the users will be merged on all sites in the network.

Password Changes
As of 4.0, password changes are fully propagated to all sites in an IPS Connect network. The net effect will be no different than IP.Board 3.4 in this regard, unless you later disable IPS Connect on a site in the network - in this case, the last used password will still be valid on that site, rather than some random password potentially stored on a "slave" installation 5 years ago that the user cannot remember.


Cross Domain Logins (and Logouts)

Beginning with 4.0, IPS Connect will now support logging in and out across different domains. Cookie restrictions (and the fact that the master installation did not register and/or remember any of the slave installations) prevented this capability with 3.4.x, so while the login credentials could be shared across domains, signing in to one installation did not sign you in to any other installation automatically (unless they were on the same domain). Similarly if you logged out of an installation you were not automatically logged out of any other installation in 3.4.x. As of 4.0, if you sign in to an installation (whether it is the master or an individual slave application), you will be redirected to the master installation, then redirected to each slave application in turn, and finally redirected back to your original destination. This is all very seamless to the end-user and largely unnoticeable. Logging out will, similarly, redirect you to each application to log you out of that application, bypassing security restrictions applied to cookies in a multi-domain environment.


Wrapping Up

Just as with IP.Board 3.4, other applications can tie in to the IPS Connect network, either as a master installation or as a slave installation. IPS Connect support has otherwise been greatly improved and now offers a much wider range of functionality, a more robust built-in SSO system, and more reliability when problems do occur via the new request queuing system. It should be noted that IPS Connect with 4.0 is NOT compatible with IP.Board 3.4.x, and sites will need to "re-register" with the master so that it can know about them. That minor limitation aside, we believe you will enjoy the great improvements coming in the next release!
  • 16,458 views
bfarber
Back in June, we announced several updates to our proprietary Spam Service, which includes influences from existing spam mitigation services (Project Honeypot and Stop Forum Spam). Today, we are announcing the release of more options to help you fine-tune the spam service for your site. These features are being released as a part of our new Enterprise Spam Service package, which is available now.


Weighting

The first feature added, as a part of this new package, is “Weighting.” With this feature, you will be able to adjust how influential the Spam Service is against registrations to your site.



As you can see, the slider here presents several options to help fine-tune the service for your site. The options presented are fairly straightforward. If you find your site to be a heavy target of spam, you can adjust the slider to Strict or Very Strict as a means of telling the spam service that registrations to your site should be evaluated more vigorously than normal, and treat all registrations with higher caution than normal.

Conversely, if you find the spam service to be too rough on registrations to your site, you can adjust the slider to Loose or Very Loose. Doing so will tell the spam service to take a step back on registrations, and treat them with less verbosity than normal.

And finally, the middle option (Normal) will simply tell the spam service to act as it does now, with no preferential influence one way or another.


Whitelisting / Blacklisting

Another feature added as the ability to define your own custom White and Black Lists for your site, providing even more granular control in addition to weighting.

First, you can define your own custom Whitelist entries.



Using this interface, you will be able to add any Email Address or IP Address to your own custom whitelist. If a member registers, and is using any IP Address or Email Address defined here, then they will automatically be flagged as Not a Spammer, and no action taken against the account by the spam service. This is useful for Administrators, Moderators, and Developers who frequently test registrations on their own sites, allowing them to do so without turning the service off.

Further, you can also define a custom Blacklist.



If you find that the spam service may not be catching a newly released spammer fast enough, and need to prevent them from accessing the site immediately, then you may add their email address or IP Address to the Blacklist. Once added, any registrations from either of those will be flagged as a spammer and will be denied registration (depending on your community settings for Code Level 4).


Calls from multiple origins

As mentioned in the previous entry, this service also allows administrators to use the spam service in Load Balanced and Cloud environments with ease, using the same license key.

The Enterprise Spam Mitigation is now available for $100/6 months as an additional add-on to your license. Please feel free to contact Sales for any additional information regarding this new service.
  • 8,792 views
Ryan Ashbrook
Reminder: this blog covers the technical details of 4.0's programming. For details on 4.0's features, follow our main blog.

Reviewing controllers

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

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

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

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

Mixins

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

A mixin is defined like so:

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

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

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

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

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

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

Advice

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

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

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

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

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

Conclusion

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

Javascript in IPS4 makes extensive use of custom events, so the preferred way of adding new functionality is to listen for appropriate events and act on them - but the mixin support described above provides a mechanism by which you can adapt existing event handlers.
  • 7,344 views
Rikki
Reminder: this blog covers the technical details of 4.0's programming. For details on 4.0's features, follow our main blog.

Introduction

For almost all applications in the IPS Social Suite (IP.Chat being the notable exception), there are three components: Each of these different types of items share many common features. For example, in all applications you can "follow" nodes and Content Items, you can like (or give reputation on) Content Items and comments. There's also searching, tagging, moderator controls (pinning, locking, etc.), sharing, reports and so on. Up until now, applications were largely in charge of managing these different components and their relationships themselves, and utilised often complicated extensions to implement the common features. In 4.0, these components are handled differently. Each component follows an , extending a central class for the component, and implementing interfaces to enable additional features. Working with objects So, taking IP.Board as an example, the classes for each of the components (forums, topics and posts) will start off like this:
[*]Categories created by the administrator. For example, forums in IP.Board, categories in IP.Downloads, calendars in IP.Calendar). In 4.0, the terminology used throughout the code for these is "Nodes". [*]Content created by users, usually (though, not always) within categories. For example, topics in IP.Board, files in IP.Downloads, events in IP.Calendar, images in IP.Gallery, personal conversations). In 4.0, the terminology used throughout the code for these is "Content Items". [*]Comments posted on Content Items by other users. In most applications these are simply called "comments" though in IP.Board they are called "posts" and in IP.Nexus and IP.Downloads they take the form of reviews.








Active Record design pattern





namespace IPSforums; class Forum extends IPSNodeModel { ... } class Topic extends IPSContentItem { ... } class Post extends IPSContentComment { ... } In , I already talked about how Nodes work and showed how easy it is to start using them. Content Items and comments are the same, with very little additional programming (only specifying a few properties to specify what database table to use and the names of the other classes they relate to), we can start using them. For example, to get a topic from the database, I just do:

an earlier blog entry


$topic = IPSforumsTopic::load( 1 ); In this example, 1 is the ID number. If I was accepting user input, I could just wrap it in a try/catch statement. I could also, rather than using load() use an alternative factory method, loadAndCheckPerms(), which automatically checks if the currently logged in user has permission to view and throws an exception if not:


try { $topic = IPSforumsTopic::loadAndCheckPerms( IPSRequest::i()->id ); } catch ( IPSContentNoPermissionException $e ) { IPSOutput::i()->error( "You do not have permission to view that topic.", 1, 403 ); } catch ( OutOfRangeException $e ) { IPSOutput::i()->error( "Could not find topic. It may have been deleted.", 2, 404 ); } In the object, properties match the columns from the database table. For example, to set the page title to the topic title, I just do:


IPSOutput::i()->title = $topic->title; There's also lots of methods available. For example, to get the IPSforumsForum object of the forum the topic belongs to, I just do:


$forum = $topic->container(); Or to get the IPSMember object of the member that posted the topic, I just do:


$author = $topic->author(); An Example: Getting the latest 5 topics One thing which is particularly easier now is that now the central classes handle common functionality, you can easily obtain data without having to worry about if everything has been accommodated - the class handles it automatically. I already showed how loadAndCheckPerms() works - for a more complicated example, let's say you wanted to get the 5 most recent topics to display in the sidebar. Previously you'd have to do a query, joining on the permissions table, providing the permission mask IDs of the current user manually, remembering to check to exclude hidden topics (unless of course, the user had permission to view hidden topics). In 3.x, it would have looked something like this:






$member = ipsRegistry::instance()->member()->fetchMemberData(); $topics = ipsRegistry::DB()->buildAndFetchAll( array( 'select' => '*', 'from' => array( 'topics' => 't' ), 'where' => ipsRegistry::getClass('class_public_permissions')->buildPermQuery( 'p', 'perm_2' ) . ( !$member['g_is_supmod'] ? ' AND queued=0' : '' ), 'add_join' => array( array( 'select' => 'p.*', 'from' => array( 'permission_index' => 'p' ), 'where' => 'p.perm_app="forums" AND p.perm_type="forum" AND p.perm_type_id=t.forum_id', 'type' => 'left', ) ) ) ); In 4.0, the same thing can be done with just one line of code:


$topics = IPSforumsTopic::getItemsWithPermission( NULL, 'start_date DESC', 5 ); Naturally, one could have written a method to do this in 3.x, but in 4.0, because it is handled centrally, it is common to all applications. If a new feature is added which affects the functionality (such as when hiding content was added), each application does not have to be updated. Adding Features I already mentioned how there are certain features, like tagging, reputation, searching, etc. which are common to Nodes and Content Items throughout all applications. In 3.x, integrating these features involved writing a usually lengthy, extension. In 4.x, implementing most of these features is as simple as adding a few elements to your class. For example, let's take tagging. In 3.x, we have lengthy . It involves creating an extension, which in the IP.Board application totals 360 lines of code. In 4.x, you simply add an interface to your class - changing this:








developer documentation for implementing tagging


class Topic extends IPSContentItem { ... } Into this:


class Topic extends IPSContentItem implements IPSContentTags { ... } That's all there is to it. Having done that, the form where a user adds or edits a topic will immediately gain a tags input field (the elements included on the form is handled centrally) and I can now call an additional method to get the tags on any topic so that I can display them in the HTML:


$tags = $topic->tags(); Here is a screenshot of the full developer documentation for tagging in 4.x: The programming method employed here is actually more suited to traits, as implementing the interface does not involve adding any additional code to your class. The reason we've chosen to do it this way though is because traits are only a feature in PHP 5.4 and above, and we wanted to support PHP 5.3. It is likely that in a future version of IPS Social Suite we will switch to using traits. Other examples Reporting In 3.x: - 502 lines for IP.Board. In 4.0: Read Markers (shows if content has been read or not) In 3.x: - 146 lines for IP.Board, plus manually marking items as read. In 4.0: Liking / Reputation In 3.x: - 222 lines for IP.Board. In 4.0: Following In 3.x: - 357 lines for forums, plus 361 lines for topics in IP.Board. In 4.0: For content items: For comments:












http://www.invisionpower.com/support/guides/_/advanced-and-developers/application/application-extension-reportplugins-r100








http://www.invisionpower.com/support/guides/_/advanced-and-developers/application/item-marking-r211








http://www.invisionpower.com/support/guides/_/advanced-and-developers/application/application-extension-reputationphp-r101








http://www.invisionpower.com/support/guides/_/advanced-and-developers/application/application-extension-like-r69









  • 12,466 views
Mark
We have seen a huge increase in people switching to us over the last year or two and want to take advantage of this momentum and offer an exciting conversion promotion. But first some information...

Our Pre-Packaged Converters

Our conversion scripts make it very easy to convert your existing community to the IPS Community Suite. The process is very simple: just install IPS, upload the converters, and then tell the converters what software you're coming from. It will ask you a few questions and then copy over your data to our format. For many systems we even include scripts to 301 redirect your old links so internal references and search engines don't get lost!

Our converters are free to use and well-tested with thousands of successful conversions. Of course converting is not an exact science and things change all the time so we are always releasing updates to make them better and faster.


Need some help?

But some clients really do not have the desire to take on the process of converting data themselves. In this case we do offer professional services for a fee to have us do it for you. Normally these fees range from $500 - $1000 but for the month of December we are offering a flat-rate fee of $350 to convert your community to IPS if it is on the list of one of our pre-made converters. Just contact sales@invisionpower.com to get started.

Even better news: if you're converting to IPS Community in the Cloud we will convert your existing database at no cost! Contact sales@invisionpower.com for full information.


Converting from something else?

If your software is not listed on our pre-made converter list we can still assist in converting. Maybe you're using something that's old, niche, or even custom. We have a lot of experience converting people to our platform and would love to assist you. Contact sales@invisionpower.com with questions.


What about 4.0?

If you follow our blog entries you know we are hard at work on the next version of our software: IPS Social Suite 4.0. When version 4.0 is released if you have an active license you will of course get access at no extra charge! Upgrading from 3.4 to 4.0 will be very easy and our staff can even do it for you if you like.


vBulletin Converter Update

Over the last several months we have seen a huge increase in interest from vBulletin users wanting to convert to IPS. As we are asked so often, we want to highlight some of the key reasons to switch to us.

We do not make you re-buy with each new major version release. So long as your IPS license is active you get access to new versions. We do not limit your support ticket access or charge extra fees. With an active license you get private access to our support staff. Our staff will install our software on your server at no extra charge. Our staff will even install major upgrades on your server at no extra charge. We have a whole community suite: forums, blog, gallery, CMS, chat, ecommerce, support, and with the flexibility of our platform the possibilities are endless. The IPS Marketplace is a great resource for our clients to get enhancements for their community. Think Apple's AppStore but for IPS products. IPS makes community software and services. That's all we do and our focus is helping you succeed not working against you.


Ready to convert? Have Questions?

You can download our free converters to give them a try. If you have questions about IPS before purchasing please email sales@invisionpower.com and we would be happy to assist. And as a reward for reading through the end there's one more thing: use the coupon code SWITCH through the end of December for 10% off your order.
  • 7,138 views
Charles
IPS is happy to offer 15% off starting now through Monday on all new purchases for both new and existing clients! This includes all software licenses and Community in the Cloud hosting. This is a great time to add on those extra Suite applications you're missing or to go ahead and try out IPS if you have always been considering us.

Just use the coupon code HOLIDAY2013 at checkout.



Conversion Promotion Coming Soon...

Are you using another community software and thinking of switching to IPS? We will be posting a great conversion promotion on Tuesday for those wanting help in converting their community data to our format. So take advantage of the 15% coupon above to order your licenses or hosting services now and then stay tuned for our conversion promotion next week!


  • 12,079 views
Charles
In IP.Board 3.x, we have a setting group where you can specify some global advertisement HTML. You can enable and disable advertisements, and you can specify code to insert into the header and footer of the page. For the forum index, forum listings and topic view pages, you can override these header and footer ad codes, and you can specify advertisement code to insert into a couple of other areas specific to those pages. If you install IP.Nexus, this setting group redirects you to the IP.Nexus advertisement control panel where you can effectively do the same thing, but with a few more options (including click and impression tracking, advertisement image uploading, automatic cutoffs for advertisements, and more).

We felt that the entire system and process was too basic when IP.Nexus was not installed, and too disorienting once you do install IP.Nexus. This setting group suddenly redirects you to another application and configuring the advertisements is an entirely different experience prior to installing this application.

Subsequently, we have done the only logical thing and consolidated the two systems and improved the functionality.

(Please be aware that, as with all early screenshots of the 4.0 Social Suite, the interface displayed in the following screenshots is very much subject to change before release)


Advertisement Configuration



First and foremost, we have consolidated the functionality provided by IP.Board and IP.Nexus in previous software releases into one control panel. Now, whether you install IP.Nexus or not, you can have powerful advertisement management at your fingertips. Installing IP.Nexus still provides additional enhanced functionality, such as the ability to sell advertisements to your members.

You can now have both HTML and image-based advertisements available, and you can create multiple advertisements for the same "location" (more on this in a minute). There is a setting available to tell the software how to pick which advertisement to show if more than one is configured for a single area (options include picking one at random, showing the newest advertisement, showing the oldest advertisement, and showing the advertisement with the least number of impressions).

You can configure start and end dates for advertisements, set them to cut off after a certain number of impressions (or clicks, in the case of image advertisements), and you can filter by status (and toggle the status from this page). If IP.Nexus is installed, an additional status of "pending" is present and supported for advertisements that have been purchased but not yet approved. Naturally once you reach any cut offs specified or the end date has passed, the advertisement will no longer be rotated.

As you can see in the screenshot, javascript is removed from the preview for security reasons.

If you have a caching engine enabled, advertisement data will be cached to improve performance.


Some new functionality

If you are already familiar with the feature set of the current release of IP.Nexus, the advertisement functionality you already know and love will be carried over to the 4.0 Suite. You can still specify which groups are exempt from seeing advertisements, for example, to help you upsell subscription packages to users on your site. In addition to the current functionality, however, we've made some great improvements.


Ability to specify SSL advertisement code
Google Ads does not have an SSL version of its advertisement code, and including their advertisements on secure pages can lead to browser warnings for your visitors. This is especially troublesome when you only use SSL for logins or for your store (IP.Nexus), as it gives an impression that the page is not secure.

Now, you can specify an alternative secure page advertisement code if you wish, or choose not to show a specific advertisement on secure pages at all.


Ability to specify multiple images
When uploading an image advertisement, you now have the option to also upload a small and/or medium version of the advertisement image. The small and medium versions, if present, will be used on the responsive layout on the alternate views for mobile devices and tablets. If not provided, the software will simply use the next best size available.

We have NOT included the ability to specify alternate HTML for the different resolutions. In our research, most advertisement partners either (1) already handle responsiveness with their own javascript code or (2) provide alternative instructions for responsive ads.


If you use a CDN such as Amazon S3 for your file storage in the 4.0 Suite, your advertisement images will be served from the CDN.


Extendable application support
As of 4.0, any and all applications that wish to support advertisements can do so via the extension system built into the software. All an application will need to do is provide an extension for the advertisement system, and then call the advertisement location in the template where they feel the advertisement should display. You can even add custom settings (so for example, the forum application can allow you to configure which forums an advertisement will be displayed in...).

Skinners can move the advertisements around however they like in their skin templates simply by moving the appropriate custom tag.


Custom locations
You can now define entirely custom locations for advertisements easily in the advertisement configuration page. Once you have defined a custom location for the advertisement, defining where to show that advertisement in your themes is as simple as inserting a tag where you want the advertisement to be displayed.


Closing

We hope these small changes will help you better manage your advertisements and provide you with the options you need to capitalize upon your community. If you have no use for advertisements, you can completely ignore this area of the software and no resources will be used by it, but if you do utilize advertisements on your community, the new tools should make it much easier to manage your site.
  • 26,200 views
bfarber
The following applications are available for beta testing:
IP.Board 3.4.6 IP.Nexus 1.5.9


This round of maintenance updates includes bug fixes for the listed applications. We would like to encourage all interested users to perform as much testing of these apps as possible.

As of the date of this post our company forums have been upgraded to these releases.

Please report any bugs you find with the beta to our bug tracker.

Please pay particular attention to the following areas:The editor, both within IP.Board (topics/posts) and in other areas (such as IP.Content articles, IP.Blog entries, etc.). Pay attention both to the editor itself (i.e. when typing out and formatting your post, and toggling the editor back and forth) and the final post that is submitted. URLs that are submitted with a post being automatically turned into a link correctly. Any IP.Nexus functionality that has to do with grouped renewals.


If you find a bug, please be certain to report it to the bug tracker. When doing so, be sure to include as much information as possible that will allow us to reproduce the issue, including what browser you are using, what version of PHP is running on your server, whether this was an upgrade or a fresh installation, and so on. Screenshots are often helpful.
As with all beta releases from IPS, these releases are not supported by our technicians until the official final releases are publicly available in our client center. Please do not upgrade your live installation using these betas, as you may find no path between these builds and the final releases that we put out. We recommended, instead, to create a copy of your live board as a test installation, and upgrade your test installation instead.

All customers with active licenses can download the betas at: http://community.inv...ower.com/qa.php

Thanks in advance! We look forward to your feedback.
  • 171,544 views
bfarber
Last week I attended ZendCon 2013, a prominent PHP developer-oriented conference designed to give industry professionals information on tools, practices and trends which will help them deliver enterprise-class software to customers. During the conference, many sponsors set up booths in order to demonstrate new products and services, and many industry professionals hold tutorials and sessions that attendees can attend in order to learn more about our trade. The conference was held in Santa Clara, CA (about an hour south of San Francisco, just outside of San Jose) from October 7th through October 10th.

I spent a lot of time at the conference focusing on tutorials and sessions that I felt might provide the most value for our company, in order to deliver better, faster and more stable software for our clients. One tutorial that I attended, for instance, focused entirely on best practices for implementing caching into software (and at the server level), and tuning settings in PHP, MySQL and Apache/NginX to deliver the highest possible performance. Another session I attended focused on Object-Oriented Javascript Programming and the future of Javascript (or, more specifically, ECMAScript 6). By the very nature of the conference, all sessions were very technical in nature, so don't feel too bad if any of this sounds like Greek to you. The point I want readers to take away is that we take our profession seriously, and IPS feels that an investment into continuing education is important for our clients.

I had the pleasure of meeting many industry professionals in the PHP world, including Andi Gutmans (CEO and co-founder of Zend Technologies), Zeev Suraski (CTO and co-founder of Zend Technologies), Elizabeth Smith (very active contributor to the PHP project and various PHP extensions), Derick Rethans (creator of XDebug, MongoDB PHP extension, and other PHP project contributions), John Coggeshall (active lead for the PHP Tidy extension) and many other wonderful contributors to the PHP ecosystem. The passion that these people share for the products and services is just amazing, and serves as a great role model for developers everywhere.

I won't spend much time getting into the nitty gritty details of each session I attended. Some were very technical in nature, while some focused on more abstract necessities of running a team of developers and managing day-to-day development duties (for example, discussing things like time management, gathering project requirements effectively, and so on). All in all, every session I attended provided useful information that I feel we can make use of to better our processes and delivery of future software releases.

As I said, here at IPS we take our profession very seriously. We will always strive to deliver the best possible software, and are thankful for the contributions of our third party developer community as well as the rest of our clients, whom provide us with bug reports and feedback that help to improve our products. We have many exciting things in store in the coming months, so stay tuned by subscribing to our company blog to be notified of changes and updates.
  • 8,803 views
bfarber
In a recent blog entry, we talked about theming in IPS Social Suite 4. More often than not, you'll want to upload a new logo, tweak a few colours, add some custom HTML or work on the global template to incorporate your existing site wrapper.

For this blog entry, I want to talk about the tools we have for more in-depth theming that professional themers will want to use to create downloadable themes for others to use.

Custom Settings
In 3.x, we have a number of system settings throughout the suite that control design decisions, such as displaying sidebars, or controlling the layout of items on a page. This isn't ideal, because we're limiting what themes can do themselves (and of course enforcing what they must support too). Instead, it would be better if these design decisions could be controlled by each individual theme, giving theme designers the freedom to be creative and display content in entirely new ways.

In IPS Social Suite 4, we've added per-theme custom settings. This enables you to create settings that are configurable by administrators when editing a theme. Even if you're not creating a theme to sell, you may want to add settings to control areas of your theme that are managed without making template edits each time you wish to make a change. For example, the default theme will have an option to add a rounded border effect to user photos. This is something that would be unnecessary as a system setting, but makes sense as a custom theme setting. Or you might want to add a setting that allows admins to toggle between showing and hiding a sidebar. There are a lot of possibilities here that would have required extensive custom code in 3.x.

When creating settings, you can choose which tab that they'll show in when editing a theme. This means you can group your settings by specific criteria such as "Colors", "Layout", etc.



Once you have created a custom setting, you're then able to use it in a HTML template or CSS file simply by using the following syntax:


{{if theme.rounded_photos}} .ipsUserPhoto { border-radius: 100px } {{endif}}

Or, if you want to use it without an IF clause, then you can simple use this:


<div> {theme="rounded_photos"} </div>

You can manage the custom settings from the theme edit form. In this screen shot, the tabs "Custom" and "Colors" are theme setting tabs.



Version Check
We've added the ability for theme creators to include a URL that is checked multiple times a day. All you as the theme creator needs to do is return a simple JSON object like this example:


{ "version": "4.0.1", "longversion": 40001, "released": 1377688587, "updateurl": "http://www.exampleurl.com/announcement.php?theme=xeonblue" }
This is a great way to notify your customers about updates to your themes.



More information is displayed when you mouse over the "Update available" badge.

Designer's Mode
There are times when you want to change many template bits and CSS files using your own development tools. The new ACP template and CSS editor is great for making edits now that it supports full syntax highlighting but for more advanced work you'll want to work with your favourite IDE and make use of its tools such as file compare and searching.
In IP.Board 3 we have the WebDav interface which allows you to work with plain .html and .css files but because it's sent over HTTP and each item needs recompiling to show changes, it's often a little sluggish and can be frustrating to work with if connection speeds start to suffer.

In IPS Social Suite 4 you can work with plain .html and .css files locally; there's no need to fire up a WebDav client. You enable designer's mode by adding a constant into constants.php. This will automatically write out the HTML and CSS files into a directory called "themes" right in your suite's root folder. You can edit these files and the changes are instantly applied to the suite making working very fast indeed.



Once you're done working in designer's mode, simply sync back the changes using the menu item on the theme's row and remove the constant.



This will copy the changes back to the database and remove any stale compiled templates and CSS files.

Diff
It's often very useful after upgrading to see which template bits have changed. The new "diff" tool instantly provides a list of changed, deleted or added template bits and CSS files. You can even download a copy as a stand-alone HTML file to distribute with your theme sets.



These advanced tools will make creating themes for IPS Social Suite 4 easier than ever before. We look forward to seeing what you create with them!
  • 18,861 views
Matt
Introduction

The IPS Social Suite needs to store lots of different files - there's attachments and profile photos uploaded by members, CSS and JavaScript files, emoticons, etc.

In IP.Board 3.x, various images got stored in different places:
Files uploaded by users get put in the /uploads directory. If you have a complicated setup, it's difficult to handle these. If you have a load-balanced cluster you need to set up an environment whereby all files are stored on a single server, or all uploaded files are synched between servers, but serving these files over a high-performance CDN can be difficult. CSS, JavaScript files, images and emoticons get put in /style_* directories. If you want to serve these over a CDN, you can do so, but you need to copy the files over yourself. Other pieces of data are written to disk as a caching mechanism. This has the same issue with load-balanced environments as file uploads. Some applications had other methods - for example, IP.Downloads allows you to store files on a remote server using FTP.


In 4.0, we wanted to pull this all together and build a much better system for storing files and build the whole system with high-performance environments in mind.


File Storage

In 4.0, you have several different ways to store files:On a local server On a remote server using FTP (which you can use to upload files to many CDN services) As binary data in the database On Amazon S3

You can set up different configurations and choose which configuration to use for different types of files. For example, if you want to store user's profile photos on Amazon S3, but you want attachments to be on the local server, or even a different Amazon S3 bucket - 4.0 can handle that. And if at any point you change your mind about which storage method you want to use, the system will automatically handle moving all the files for you.

Everywhere that writes a file will use this central system - so IP.Downloads and IP.Gallery are included too.




Caching

There are lots of places throughout the suite where the same stuff needs to be retrieved or calculated over and over - for example, certain configuration settings, language data, information about the installed applications, etc. If this data can be cached, not only does it alleviate database load, it means the PHP code doesn't need to re-process the data.

In IP.Board 3.x, some of this was stored in a particular database table and could be cached using a proper caching system - but it was difficult to configure, and not everything used it - compiled HTML templates, language strings and more were saved as files in the /cache directory, which causes difficulties for load-balanced cluster environments.

In 4.0, we've overhauled all of this. For things that need cold storage (like compiled HTML templates) - you can choose either the file system or the database for storage. The data can then cached, along with anything else which might benefit from caching (like settings, application data, etc.) using one of 5 supported caching methods:APC eAccelerator Memcached Wincache XCache

  • 25,456 views
Mark
Building off of our previous blog entry regarding the developer center, application management and distribution has been fleshed out to a point where we are ready to reveal the changes coming with the 4.0 Social Suite. Please keep in mind that while we are discussing some specific changes (and showing screenshots!) of changes you can expect to see in 4.0, everything in this blog entry is subject to change before final. With that said, let's take a look.



This screen represents the application overview screen. First, a list of all of the applications that are currently installed is presented to you in a table, with another table following this one listing the applications which are uploaded but not currently installed. You can easily install an application listed in this second table on the screen simply by clicking the install icon next to the application. A multi-redirect process is triggered which handles the application installation painlessly for the administrator.

Note that in the screenshot above, the "Create New" button is only presented because developer mode is enabled. Administrators will not normally see this button. Additionally, the gears icon next to the installed application allows you to access the developer center, and this button is only present when developer mode is enabled as well.

When clicking on an installed application, you will be presented with a list of front-end modules, allowing you to set permissions for those modules and to specify which module is the default for that application, and to enable or disable individual modules.



The lit up star icon indicates the default module - clicking the icon for any of the modules will specify that module as the default. Clicking the lock icon will allow you to specify the permissions for that module, and clicking on "Enabled" in the screenshot will toggle the module between enabled and disabled status.


Building and Distributing Applications

Beginning with the 4.0 Social Suite, building and distributing applications has been made as simple as possible. The concept of "building" an application refers to the process necessary to create all of the files distributed with the application in order to make it installable. Examples include the language strings and the skin templates associated with the application. While you work in developer mode, the software pulls these templates from files located on disk, however these skin templates and language strings need to be imported into the database for standard installations of the suite in order to be supported properly. In 3.x the way you do this is to visit each various area of the ACP and use the appropriate developer tools to first import the data, and then to export the data. This is no longer necessary with 4.0.

In 4.0 when you add most database-stored data, you do so through the developer center. This immediately puts the relevant data (such as a task or settings included with the application) into the database, as well as into the distributed files on the file system. You don't have to be concerned with building this type of data for application distribution.

Within the developer center there is a manual "Build for release" button which you can use at any time. However, most developers will likely find that they do not need to use this button, because you are given the option to build your application for release right when you go to download it. This brings us to application distribution.

In 3.x to distribute an application, after you have exported all of the various files you need to distribute to disk you would copy over the application folder, as well as any other files from other folders (e.g. javascript files in /public/js/) and then zip these folders up in order to create an application distribution you upload to the marketplace. 4.x does away with this entire process. Firstly, applications are now fully self-contained within their own directory, including javascript files, images, CSS files, skin templates, language files, and so forth. Applications no longer need to have files contained within half a dozen folders to be recognized by the suite.

Secondly, you can now directly download an application (with developer mode enabled) right from the ACP. Behind the scenes, the PharData class is utilized to build a .tar archive, and all of your application's files are pushed into this archive. You are given the opportunity when you elect to download your application to choose whether you wish to build the application or not, which is useful in case you have just made a minor bug fix and don't need to bother with importing skin templates or language files since the last time you distributed your application.


Installing Applications

We wouldn't be content with just making application distribution this simple when we can make application installation just as simple for the end user administrators. As of 4.x, while you can still extract the .tar archive you (as a developer) have distributed and manually upload the files, it is much easier to simply upload the entire application in the ACP and let the 4.0 Social Suite do it for you. When you click the "Install" button on the application overview page and select an application to install, the archive is uploaded and extracted, and then the same install process automatically executes that happens if you are installing files from disk.


Centralized "Offline" Mode

Most nodes within the software have a notion of enabled or disabled, and applications are no exception. Even in 3.x you can enable and disable applications without uninstalling them, which removes access to the application within the software. On top of this, however, almost all applications have a custom notion of "offline mode" where-by an administrator can put the application in offline mode, define a custom message to show users who attempt to visit the application, and in most cases also specify which groups can still access the application even while it is offline.

We have decided to consolidate and centralize this similar functionality, allowing for a more consistent and robust experience for the administrator. You can now put applications in offline mode (unless they are "locked", such as the system application) and specify a message to show to users and which groups can still access the application. This functionality replaces the basic enabled/disabled status, but still provides for the same end functionality.


Putting it all together

Here is a quick video showing the process of installing an application, specifying a default module and the permissions for that module, and putting the application into an offline mode.

You might notice a few quirks in the video, representative of pre-alpha software. Firstly, this is an early application export and the module title was not exported with it, so the key is displayed when you see the listing. Additionally, a full WYSIWYG editor will be presented in the popup to specify the offline message, however automatic javascript-dependency loading is something we are still working on. Nevertheless, you can see the full functionality in the video below.

http://screencast.com/t/2zK1L51Tp3I


Let us know your thoughts, and if there are any other application-management tasks that need some extra attention in 4.0, in the comments
  • 9,026 views
bfarber
IPS Social Suite 4 is a modernization of our software line and rather than just refactor existing work, we are rewriting the code from scratch which gives us a chance to really evaluate the interface elements and labels. We felt that "themes" was a much more modern and better understood term than "skins". Of course, the name is just the start, here are some of the other improvements:

Managing Themes in IPS Social Suite 4
As you would expect, the interface has been completely overhauled in IP.Social Suite 4. All the familiar elements are there but we've simplified areas and made it easier to manage your themes.



As you can see from this screen shot, theme authors can now inform customers when they have an update available for them. The interface makes use of the new IPS Social Suite 4 Trees model which means you can quickly search for theme names and re-order themes.

In IP.Board 3, you could change the logo of the suite. We've made this even easier in IP.Social Suite 4. The upload fields are easily accessible on the edit theme form. You can even upload a Facebook sharer image and favicon!


Downloading and Uploading Themes
In IPS Social Suite 4, downloading and uploading a new version of a theme could not be easier. Just select the menu item and it's done. You no longer need to navigate to separate areas of the Admin CP to do this.



Conflict Management
What happens if you upload a new version of a theme but it contains changes to templates you have also changed? You'll get a chance to review these changes and select which version to use on the conflict management page.


Editing templates and CSS
The template and CSS editor should be familiar for any existing customers. The editor is now fully syntax highlighted which will make writing and editing code so much easier.



The template syntax is now much more compact as you can see from the above screen shot. We've also added a few things to reduce the amount of template logic required.

A common need is to load a template if a condition is matched:

{{if member.isAdmin()}} {template="admin_bar"} {{endif}}
You can now put the conditional inside the template tag like so:

{template="admin_bar" if="member.isAdmin()"}
This is much easier to read and reduces a lot of visual clutter. The combination of the better template syntax and HTML 5 mark-up results in a dramatic reduction in size and complexity of often edited templates such as the globalTemplate which is commonly used to add your own site chrome.

The screenshot below shows all of the IPS Social Suite 4 globalTemplate and for comparison, part of the IP.Board 3.4 globalTemplate which is over 340 lines long!


The CSS framework much like the javascript framework has been completely rewritten and is now modular. This means that most CSS files are very small which makes looking for specific selectors much easier. In addition, upgrades are less destructive to your themes. If you made edits to the button styles, then only that one style sheet is altered leaving the rest as default. Of course, IPS Social Suite combines and minifies these separate CSS into fewer files when saved.

This blog entry is just an overview of the theme section in the Admin CP. We'll go into more detail in a later entry on the new tools available designed to make theme creation and management a breeze for theme authors. We know you will have a ton of questions but please be patient with us if we keep saying "wait for next blog entry" :smile:

  • 25,210 views
Matt