bfarber

03-20-2015 We are releasing a patch for IP.Board 3.3.x and 3.4.x to address an SQL injection issue. It has been brought to our attention that specifically crafted URLs may allow an attacker to trigger an SQL error with specific configurations. To apply the patch Simply download the attached zip for your IP.Board version and upload the files to your forum server. IP.Board 3.4.x: patch3122015.zip IP.Board 3.3.x: patch3122015_33.zip If you are an IPS Community in the Cloud client running IP.Board 3.4 or above, no further action is necessary as we have already automatically patched your account. If you are using a version older than IP.Board 3.4, you should contact support to upgrade. If you install or upgrade to IP.Board 3.4.7 after the date and time of this post, no further action is necessary as we have already updated the main download zips.

We are releasing a patch for IP.Board 3.3.x and 3.4.x to address two CSRF issues and one XSS issue. It has been brought to our attention that a cross site request forgery issue exists with gravatar images that can allow a potential attacker to cause a user to store a gravatar profile photo that was not desired. Further, during internal reviews of the issue we discovered another CSRF issue that can allow an attacker to mark all private messages as read. Finally, a minor "self XSS" issue has also been patched with this update. To apply the patch Simply download the attached zip for your IP.Board version and upload the files to your forum server. IP.Board 3.3.x: patch_33x_Feb2015.zip IP.Board 3.4.x: patch_34x_Feb2015.zip If you are an IPS Community in the Cloud client running IP.Board 3.4 or above, no further action is necessary as we have already automatically patched your account. If you are using a version older than IP.Board 3.4, you should contact support to upgrade. If you install or upgrade to IP.Board 3.4.7 after the date and time of this post, no further action is necessary as we have already updated the main download zips. We extend our thanks to Daniel Price, A.K.A ShadeSpeed of the GameMaker Community for notifying us of the gravatar issue privately and promptly.

Some sites make use of multiple calendars to help differentiate what type of events are being contributed to the community. You might have a staff calendar that allows staff members to add events and a community calendar for the rest of your users. Or you may have a holidays calendar as well as a gaming "raids" calendar on your community. Individual calendars are a form of categorization in IP.Calendar, and we wanted to bring some enhancements to them in the 4.0 Community Suite. Colors You will now be able to specify colors for each calendar you create. The software will automatically suggest a new unique color each time you create a new calendar with several pre-determined colors to start with (and then falling over to randomly chosen colors if you happen to create enough calendars to use these defaults up), but you are able to specify any color you wish for any calendar you create. (As an aside for developers - you can easily implement similar "color" fields in your own forms using the form helper class IPSHelpersFormColor) Merged view If you are familiar with the current iteration of IP.Calendar, you might be wondering what good implementing calendar colors actually does. After all, the software does not show events from different calendars mixed together right? As of 4.0, IP.Calendar does indeed support a merged-calendar view. In fact, it is the default in IP.Calendar. Your users will see all events from all calendars (that they have permission to view) merged into one view, but can click a menu at the top of the page to filter by calendar if they so desire. They will see events from all calendars merged together When viewing an event the calendar it has been saved to is of course indicated here as well. The merged calendars model is supported for all of the major views in IP.Calendar: the monthly view, the weekly view, the daily view...and the new "event stream" view which we will talk about in a future blog entry (shhh). Conclusion We feel these minor changes makes Calendar more intuitive, and especially makes handling multiple calendars within your IP.Calendar installation more practical and useful. We hope you find working with multiple calendars to be easier and clearer with these changes, and we hope you find new ways to make use of the multiple calendar support present in IP.Calendar as a result of the merged views and better calendar differentiation.

IP.Calendar has supported an RSVP system for events for the last several versions, and this has been a well received addition to Calendar. Where allowed, users can request RSVP for events submitted to the calendar, and where allowed, other users can RSVP (and subsequently un-RSVP) for these events. This functionality is useful for real-world events being coordinated through your site to help event organizers know who will attend. Some minor but useful enhancements have been made to the RSVP functionality in calendar for 4.0. RSVP Limits Often times, you may only have a limited number of spots available for an event. You may only be able to accommodate 10 users or 20 users at an event, and you typically will know this up front. Subsequently, it makes sense to limit the number of users who can RSVP for a given event in such scenarios. To this end, event submitters can now limit the number of RSVP responses allowed on a per-event basis. If you know only 10 users can be accommodated at an event, you may now specify this up front. Yes? No? Maybe? While being able to RSVP for an event is useful, many users online are familiar with other attendance systems that allow you to specify yes, no or maybe when RSVP support is available. In other words, instead of simply allowing you to say "yes I'm coming", sometimes it is just as useful to allow users to specify they are not coming, or that they might attend (in which case the organizer may plan to have extra food available, for example). The 4.0 Calendar will now support yes/no/maybe responses when RSVP is requested for an event. One caveat to mention - when an upper RSVP limit has been specified, the "Maybe" option is not available. A gray area becomes apparent when there is a limit to the number of attendees allowed for an event and users begin to RSVP as "maybe". Does that fill up a spot? If not, what if they decide to come after all? It is much clearer for all involved to simply limit responses to yes or no when there is an attendee limit specified for an event. When you have RSVP'd for an event, you will be presented with the option to leave the event in case you change your mind. Download guest list When RSVP has been enabled for an event, anyone who can see the list of attendees will be able to download a guest list in PDF format. This is especially useful for the event organizer in case they need to print out the guest list to bring with them to the event. RSVP for imported events When you configure iCalendar feed imports in the admin control panel, you will now be able to enable or disable RSVP status for events from the feed. As the administrator, you had no control over whether events imported from a feed had RSVP enabled or not in previous versions of Calendar. As of 4.0, you can specify whether to enable or disable RSVP for imported events on a per-feed basis. As with 3.x, events exported through iCalendar feeds will include the attendee list with them. When events are imported through an iCalendar feed, if an attendee is specified (through the iCalendar specification) and that attendee is also a member of your site (based on their email address), the member on your site will automatically be set as RSVP'd for the event. We believe these several minor but useful enhancements to the RSVP capabilities in Calendar will make the feature more useful in real world usage scenarios, and will allow you and your event coordinators to get more out of Calendar than ever before.

IP.Calendar allows your users to schedule and share events through a centralized community calendar and supports many features that allow your community to coordinate, organize and interact with each other through the calendar. For instance, event organizers can request RSVP for events in order to note who will be attending before hand, and you can allow commenting on events submitted through IP.Calendar to allow users to share their thoughts about an event. The latest version of IP.Calendar will see some minor yet useful enhancements that will allow you and your community to make better use of IP.Calendar in a more social manner than ever before. Location support Users will be able to specify a physical location (i.e. an address) when submitting an event to the calendar in the 4.0 Community Suite calendar application. When an address is specified and Google Maps integration is enabled in the admin control panel, a map will be presented when viewing the event that allows users to see where the event will be taking place. Clicking on the map will take you to Google maps, allowing you to get directions to the event or otherwise find out more information about the location. The event location, when available, will also be included in iCalendar exports using the GEO property supported by the specification. This means when sharing your calendar events with another application that supports iCalendar imports (and supports the "GEO" property), your event location will be available in those applications as well. Downloading individual events In previous versions of the calendar, you were able to download an iCalendar export of an entire calendar on the site, but you were unable to download an individual event as an iCalendar export. The 4.0 Community Suite calendar application will now allow you to download individual events, as seen by the "Download Event" button in the previous screenshot. Users can download individual events and import them into supported calendar applications if they desire. Events are downloaded with an ".ics" extension, which is supported by Windows Calendar, Apple Calendar, Google Calendar, Outlook, Mozilla Lightning and pretty much every other calendar application available. Cover photo Another small yet useful enhancement in the next version of Calendar is the ability to upload a cover photo with your events. You may now, optionally, upload a cover photo image with your events which will be displayed as a background image in the event header. Please keep in mind that these are early screenshots and the interface is very much subject to change, however you can get an idea from this screenshot how you might end up specifying a cover photo for an event to give it some unique visual differentiation to stand out.

IP.Calendar has a few primary important views: the monthly grid view (i.e. a typical calendar table), the weekly view which lists a calendar week and any events occurring during that week, a daily view which lists all events occurring on a given day, and the actual event views where you view details about a specific event. All of these views have their usefulness, however we felt that there was a missing piece to the puzzle. During planning meetings we discussed adding a popular feature request known as an agenda view, which basically lists all events between a given time period (or from a given date forward) and while we liked the idea, we felt we could accomplish the end goal while taking the interface a step further. The calendar stream The new "stream" view is what it sounds like - a stream of calendar events listed in order of date, from oldest to newest. This calendar view is based upon a given month and will show all events occurring within that month (including recurring events). You can view the calendar stream for each month individually if you wish, just like you would view the calendar "month" view. The events are displayed as small blocks of event data. This is a general idea of what the stream looks like As you can see, events are listed from oldest to newest in a "stream", i.e. a grid of blocks showing event details. The stream is an option for end users to choose from, and the admin can set it as the default viewing method for Calendar if they wish. Conclusion We believe this new stream will accomplish the same end goal an agenda view is designed to accomplish, but in a more robust and stylish manner. We look forward to your feedback on this new enhancement to the calendar product.

Working with an image handling suite to resize uploaded images, build thumbnails, apply watermarks and perform other similar image-handling tasks has been improved in 4.0 to be easier than ever. It is important to know that many of the built-in helpers in 4.0 will automatically handle image-related tasks for you, such as building thumbnails when appropriate. In the instances where you need more control or cannot simply make use of an existing helper, however, you will find working with images is as simple as can be. First and foremost, it should be noted that ImageMagick support is now suite-wide. In past versions of our software, only IP.Gallery could make use of ImageMagick. The image handling configuration options are now part of the core framework and choosing to use ImageMagick as your image handling suite will apply to all image handling suite-wide, including attachment thumbnails, screenshots in IP.Downloads, image uploads in IP.Gallery and everywhere else that makes use of our core image handling classes. As was mentioned above, you will typically work with images by requesting a user upload one through a form. In this case, using the "Upload" form helper is the simplest route you can go for this purpose, and when doing so all image handling is done for you automatically. You need only pass an option to the helper to specify that the upload must be an image, and optionally you may restrict the maximum dimensions of the image. If you need finer-grained control or if you need to perform other manual image handling tasks, you simply use IPSImage for this. The following represents an actual test script that takes an image (named a.png), resizes it to 200x200 proportionately, and writes it to disk as b.png. The script then takes the same a.png file, resizes it to 200x200 but this time crops the image, and writes it to disk as c.png. This script honors the ACP configuration and will use GD or ImageMagick, depending upon what is selected, and will adjust the JPG quality and PNG compression levels based upon the ACP preferences. <?php require_once '../../init.php'; $resized = IPSImage::create( file_get_contents( "a.png" ) ); $resized->resizeToMax( 200, 200 ); file_put_contents( "b.png", (string) $resized ); $cropped = IPSImage::create( file_get_contents( "a.png" ) ); $cropped->crop( 200, 200 ); file_put_contents( "c.png", (string) $cropped ); Now, typically you should not expect to write directly to disk, and instead should use IPSFile::create() to store a file (which, out of the box, can store files on disk, in the database, in Amazon S3, or on a remote server using FTP). The above test script was merely written to facilitate easier testing of the image handling scripts specifically during development, but they highlight just how easy it is to work with images in 4.0. If we wanted to apply a watermark to the first image we need only call the watermark() method. <?php require_once '../../init.php'; $resized = IPSImage::create( file_get_contents( "a.png" ) ); $resized->resizeToMax( 200, 200 ); $resized->watermark( IPSImage::create( file_get_contents( "watermark.gif" ) ) ); file_put_contents( "watermarked-image.png", (string) $resized ); We hope you find the new easier to use image handling routines beneficial while developing within the IPS framework.

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.

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.

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.

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.

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.

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!

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.

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.

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.

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

We refer to the icons you can use to post to third party services such as Facebook, Twitter and Digg as "Sharelinks" in our software suite, and we consider these an important tool both for community promotion and for search engine optimization. Not only can you get links to your community out there on other large, popular sites on the internet where you might be able to drive back more traffic to your own site, but search engines will also see these links to your site on the other large popular sites, follow them, and rank the pages they reach accordingly. Share links were supported in 3.x, however while planning 4.0 we felt that the implementation could be improved, and so we've done just that. We have tidied up the interface to make managing the services easier for the average admin, provided more flexibility for third parties who wish to developer additional share link services, and we've made it much easier to use from a development stand point. Managing Sharelinks Within the admin control panel, you must be able to manage the sharelink services that are available. You may only want to offer buttons to share to Facebook and Twitter, removing clutter that you don't feel your community is familiar with. Or you may want to enable every share service link possible, because your community is full of technical-oriented users who will make use of them. Wherever you fall within this spectrum, the process should be simple and straightforward. We have removed the ability to add and delete sharelinks, because the reality is most services require far more integration than simply specifying a URL. Thus, we have made the system plugin-based, which allows developers who are familiar with the process far more control, while greatly simplifying the interface for the average administrator. If you are comfortable with adding a link and an icon, building a plugin (see below) is a very simple process. Otherwise, if you don't know what an "HTML" is, you will now be able to work with this page in a far easier manner. There is a generic settings button at the top, which allows you to globally enable and disable share links, as well as specify whether you want users to have the opportunity to automatically share links to new content with supported services. When you choose to "Edit" a given service, you can specify which groups can access that share link, and specify any service-specific settings related to that service (for instance, to change the default Twitter hash tag used when sharing via Twitter, you would click to edit the Twitter service). Integrating a New Service While we ship with some of the most popular services already supported (including support for LinkedIn sharing, new in 4.0!), it is a very simple process to add support for new services. When you build a new sharelink service and drop it into the appropriate folder, it will automatically be installed as soon as you visit the sharelinks management page in the ACP, where you can then choose to enable/disable the service and configure any available options. If you delete a plugin file, the service will automatically be deleted again when you visit this page in the ACP. No further interaction is required to install or uninstall a service, other than visiting the management page in the ACP. The basic template for a plugin file is as follows <?php namespace IPSContentShareServices; class _Servicename { /** * @brief URL to the content item */ protected $url = NULL; /** * @brief Title of the content item */ protected $title = NULL; /** * Constructor * * @param IPSHttpUrl $url URL to the content [optional - if omitted, some services will figure out on their own] * @param string $title Default text for the content, usually the title [optional - if omitted, some services will figure out on their own] * @return void */ public function __construct( IPSHttpUrl $url=NULL, $title=NULL ) { $this->url = $url; $this->title = $title; } /** * Add any additional form elements to the configuration form. These must be setting keys that the service configuration form can save as a setting. * * @param IPSHelpersForm $form Configuration form for this service * @return void */ public function modifyForm( IPSHelpersForm &$form ) { } /** * Return the HTML code to show the share link * * @return string */ public function __toString() { return "<b>Some HTML</b>"; } } The class name "_Servicename" should be the same as the filename, minus the _ (the underscore is part of hooks and plugins system in 4.0, which you can read about in a later blog entry). So this filename would be "Servicename.php" and would be located in /system/Content/ShareServices/. The modifyForm() accepts a reference to the form object that is displayed when configuring the service. Here, you can add new configuration options that will be saved automatically (the configuration options should be settings). If you need to specify any HTML or CSS that needs to be manually loaded for the service, you can add assets to both the <head> of the document, or insert content right before the closing </body> tag, depending upon the service's needs in the constructor. The __toString() magic method should return the HTML necessary to generate the share service link. It is really that simple - there are no hidden "gotchas" to watch out for. As an aside, the built in ability to email a link has been greatly simplified for third party developers as well. If you implement third party applications by extending the appropriate classes (which we will blog more about later), the ability to email a link to your page with permission checking built in will all be handled automatically for you. You don't need any plugin files specifically to facilitate emailing links to your content items in 4.0. Implementing Sharelinks in Applications To implement the sharelinks in your third party applications is equally simple. As mentioned above, assuming you extend the appropriate classes to generate content items (which will be blogged about in detail at a later date), you need only do two things to implement share service integration in your application. First, your class that extends IPSContentItem must implement the interface IPSContentShareable. This automatically enables the share links in your application and adds support for any functionality the share services utilize. Second, your template should include the appropriate sharelinks template where-ever you wish to display the share links {template="sharelinks" group="global" location="front" params="$contentItem"} If you wish to render the share links in some manner beyond our default generic rendering, you can simply use whatever HTML you need to, however we feel that most content items can utilize our generic template just fine. A Few Notes in Closing We feel that these changes will make implementing share links as easy as possible while still providing you all the flexibility you may need to customize the interaction and display of the links at every level. We have also decided to remove the "print" and "download" share links at this time. In researching their usage and their functionality, we feel that it is no longer worth maintaining these unnecessary links which simply add clutter to the page. All browsers allow you to save a page (i.e. download it) already, and all browsers allow you to print a page already. We will include a print stylesheet with 4.0, just as we did with 3.x, so when you choose to print a page the output will be better tailored for printed media. We feel, however, that retaining the links adds no real value for the vast majority of users, and is more inline with what most users encounter on other similar websites. We hope that the improvements and decluttered interface, both on the front end and the ACP, make configuring and using these services (and adding support for others) much simpler than in previous versions.