bfarber

Development of IP.Content 2.3 continues, and while we have many more great things in store for this release, we wanted to take a moment to tell you about two new features you can expect to see in this release. Many of the recent blog entries have described consistency improvements, SEO improvements, and other integration changes, but we wanted to make sure you knew that this release would have a couple of new "fun" features that you can use on your site as well. Certainly, we are not yet done with our IP.Content 2.3 changes, and you can expect several more blogs detailing further improvements you will see with this release, but to tide you over until then, here are two new features that we hope you will find useful. New Plugin Block: Currently Viewing Many users have asked us to add a "Currently viewing" block to our database and article pages, perhaps even to other IP.Content pages. If you are not clear on what I am referring to when I mention a "currently viewing" block, it is the block you see in many applications (the forums included) that tells you who is also viewing the current page. Rather than give you an option to add this capability to individual databases or pages, we decided to take it one step further. We have implemented a new plugin block that you can create in IP.Content to generate a "currently viewing" block, which you can now integrate onto any page you like in IP.Content (databases/articles included), as well as any other page throughout the entire IP.Board suite! Remember that IP.Content blocks can be embedded into any IP.Board skin template, allowing you to easily add "currently viewing" blocks throughout your site, at your discretion. Note that while blocks can be embedded into external pages using a javascript widget, this particular block will not properly track page viewing on those external non-IP.Board pages (because it relies on session data in IP.Board), and we do not recommend using this block on external pages as a result. With that said, you can now add a currently viewing block to your databases, articles, other IP.Content pages...and anywhere else throughout IP.Board you feel it would be useful! You can even use this block in your third party applications, though support for viewing individual pages will vary by application based on how they have configured their session plugins. Shared Media Field The shared media button, available in the WYSIWYG editors throughout IP.Board, is a powerful tool that allows you to quickly and easily insert content from across your entire suite of applications (and many third party applications!) anywhere you can post content with the WYSIWYG editor. You can share calendar events, attachments, gallery images, download manager files, and more anywhere that you can post. We have decided to make use of this powerful functionality and take it a step further with IP.Content 2.3. You can now add a "Shared Media" field to any database (including your articles section), which will act as a separate way of inserting these shared resources into your submission. The items do *not* insert into the available RTE (you can already do that by using the button available on the editor) - instead they show and list separately. You can use this powerful new capability to link your database records logically to any other content in the suite - link a database record to a calendar event, or link it to a particular file in your download manager. Reuse your attachment or gallery images in your articles. Link to blog entries about upcoming software changes in a particular version when posting an article about that version. The possibilities are vast. We have taken a quick video to show you the functionality in it's most default form - this is a brand new database with no template customizations, to give you an idea how the feature will work right out of the box. http://screencast.com/t/reRAhmzC0yE More To Come We have a lot more in store for IP.Content 2.3, and we can't wait to tell you about some of the other changes you can expect to see. We are working hard to better integrate the features available in the IP.Board framework, allowing you to make use of some of the great capabilities the framework offers in unique and powerful ways. We hope that you find these two new features useful, and we we welcome your feedback about them in the comments below. If you have other suggestions to enhance IP.Content, please be sure to leave them in the feedback forum.

Commenting is a powerful and important feature available with all of your IP.Content databases, 'Articles' included. Not only can you allow your users to comment on the database records, you can require approval of comments before they become public, you can moderate the comments as needed, and your users can get notified of new comments made on database records that they follow. Still, commenting in IP.Content was missing some important functionality that we felt was overdue to be implemented. In the process, we wanted to implement some other functionality changes to make the databases and article sections of IP.Content more powerful on the front end, and to better integrate the entire software package with the IP.Board suite. Read-on to learn about these changes, available in IP.Content 2.3. Full-Featured Comments In earlier versions of IP.Content, your users could comment on articles and other database records, and that was about it. Moderators could delete, approve, and unapprove the comments from the front end, but if you wanted to edit a comment you had to go into the ACP to do so. We are happy to announce that we have fully fleshed out the commenting system in IP.Content to make it consistent with every other application, without losing the flexibility you enjoy now (that is to say, you can still use the forums to host your comments if you so choose). We have integrated the IP.Board framework global commenting system into IP.Content, which gives us many of the capabilities you expect from a powerful commenting engine: Your moderators and your users can now edit comments on the front end, where permitted. A new per-moderator permission option has been added to let you determine which moderators are allowed to edit comments. Your users can now report comments in IP.Content (as well as database records and articles!) The commenting engine now allows the AJAX-powered "quote" option, the same as you see with the comments below this blog entry Multi-moderation has now been implemented, allowing you to check off the comments you wish to moderator and act on them all in one go. Keeping in line with the moderation changes coming in IP.Board 3.3, an unapproved comment can be either "approved" or "deleted". An approved comment can either be "hidden" or "deleted". A hidden comment can now be "unhidden" or "deleted". Commenting is fully AJAX-powered (when available). This means quoting, adding, editing and other actions all get processed by an AJAX request, rather than traditional page refreshes, creating a smoother user experience for your users For our technical-minded and modification author readers, we are now using the central commenting system plugin capability to it's fullest. Indeed, because of the multiple-database capability and the forum options for storing comments available in IP.Content, we needed to implement some small but useful changes in the central comment handler to achieve this. And, on a related note, IP.Content 2.3 will now be fully using the IP.Board classPost API to post topics, update topics, and post comments to those topics, allowing for more consistent back-end handling of data being sent to the forums. Note that there is some more work to do with comments, and we are not done just yet, but the above changes should prove useful for any site that allows comments in IP.Content. Guests Welcome! Since version 1.0, IP.Content has not allowed guests to comment on database records and articles. We are happy to report that as of IP.Content 2.3, guests will now be allowed to comment on these database records, where-permitted. As with other areas that allow commenting, guests will be prompted for a username and to fill in a CAPTCHA (if enabled), when submitting a comment on a database record. Similarly, guests can now rate database records and articles, where-permitted. If you allow guests to rate an item, we will use the IP address of the guest to verify they only rate the record once. With these two changes in place, we have removed the notice displaying above the database permission matrix in the ACP, alerting you that the permissions for rating and commenting are not honored for guests, as it is no longer needed. Database and Article Improvements As mentioned above, we have integrated the ability to report articles and database records in IP.Content 2.3. Your users will now be able to report objectionable content so that moderators can be alerted and more easily track and handle these items. Additionally, we have implemented the reputation system (e.g. the "Like" button available throughout IP.Board, or the plus/minus system if you opt to use that instead) for database records and articles. You can now issue likes and reputation against these items, beginning with IP.Content 2.3. Many of our users have asked for a way to allow more data collection for articles and database records on the front end. Specifically, you cannot collect meta tags, change an article's author, or provide a static FURL name for these records, while you are able to when submitting the same record from the ACP. We are happy to announce that this will now be possible beginning with IP.Content 2.3. There is now a per-moderator/editor option to allow extra data collection from your moderators/editors (keep in mind that super moderators on your site get all moderator capabilities automatically). If you wanted your members to be able to submit this data too, you could add your members group as a 'moderator' and only give them this permission, however we feel that these sorts of capabilities are usually best left to your site staff in real-world use. After all, you can't care about the SEO of your site on one hand, and then leave these SEO tools to use your members' discretion. The data you can now allow to be collected on the front end are: author, meta description, meta keywords, static FURL name and article template (for articles only). Authors still must be members of the site, and the field utilizes the auto-complete type-ahead available elsewhere in IP.Board. Finally, with regards to our database and article systems, you can now view, compare, edit, delete and restore revisions right from the front end! When viewing articles and database records on the front end, moderators with permission to "restore revisions" (again, super moderators already have this permission) will now be able to fully manage the revisions without anyone ever having to visit the ACP. And, as before, you can add any group you wish as a moderator, and give them only this permission if you wanted to allow members or other special users on your site the ability to manage article revisions. Front end management of revisions will allow you to better utilize IP.Content as a wiki, where desired. Quick Navigation Panel The quick navigation panel, a great new enhancement in IP.Board 3.x, allows you to easily jump around the site to areas you wish to reach without having to navigate there page by page. All applications can integrate into the quick navigation panel if they desire to, and we are happy to report that IP.Content 2.3 now makes use of this central functionality. The quick navigation panel will now show all of your pages (that you have permission to access), followed by all of your databases, and all of the categories in those databases (again, where permitted to access). Because our feedback and focus groups indicated that some pages, while technically accessible, should not necessarily show in the quick navigation panel, we have added a new per-page option that you can uncheck if you wish to exclude a page from the quick navigation panel, regardless of the user's permission to access the page. Consistency Is Key As you can see, we are working hard to ensure your IP.Content user (and moderator) experience is consistent with the rest of our software suite. At the same time, we want to ensure common actions that moderators should be able to perform, but must currently be performed by administrators, are available through the front end with IP.Content 2.3. No longer will you need to visit the ACP to tackle routine duties, or provide extra details, or edit user comments - everything can now be handled inline on the front end utilizing the powerful tools available to you and your moderators. We are working hard to bring other consistency and functionality improvements to the IP.Content front end, many in the form of better integration with the IP.Board framework. We will be blogging about these changes in due-course, and in the mean time, we hope you look forward to the improvements already discussed in this and other blog entries. If you have suggestions on how to improve the software, please post them in our IP.Content feedback forum. If you have comments about the changes discussed in this blog entry, please provide them in the space below!

Development of IP.Content 2.3 continues, and as mentioned in the introductory "What To Expect" blog entry, one area of the software we wanted to place a focus on was search engine optimization. While this particular subject can bring about heated debates regarding what is "good" and what is "bad", there are a few areas of IP.Content that we felt could use some specific improvements. Today we're going to discuss a few of the SEO improvements you can expect to see in IP.Content 2.3. Header Codes There is no denying that sending the appropriate header response code based on the results of a page request is important. If the page loads normally, as typically happens while browsing around a website, a 200 response code is returned to the browser (and spiders) to let it know everything is ok. When the page cannot load correctly for some reason, a more appropriate response code is required. If the content cannot be found, this response code should be 404, and if you do not have permission to view the content it should be 403. As Matt reported in the IP.Board 3.3 Dev Update: SEO Improvements, other non-specific errors will now return a 401 header code. This is the default that IP.Board uses, so if a more specific response code is not specified, an error page automatically issues this 401 response code now. We have taken the time to go through all IP.Content actions to update the response codes that are returned. Previously, no response code was specified, so all error pages would return the default (previously a 500, though this has changed with IP.Board 3.3, as mentioned). Now, pages that are "not found" will return a 404 response, and pages you do not have permission to access will return a 403 response code. Pages, by the way, also include database categories, articles, and other database-specific views that can be delivered (such as a request to add a new article). Meta Tag Configuration While this change really relates to improving the usability of the product more than SEO, we'll include it here since the change we are discussing relates to configuring your database meta tags. In IP.Content 2.2, each database (including the articles database) allows you to configure meta tags for that database specifically. The problem here is that you can also configure them at the page level (e.g. you can specify the meta tags for each individual page in the Page Manager area). So, once you embed a database into the page, which meta tags should be used? The ones you configured for that page, or the ones you configured for the database? When viewing categories and articles (or other database records), there are specific meta tags available for these areas as well, although they are still relevant and there is still value in customizing these separately. The decision has been made to remove per-database meta tags, and instead utilize the meta tags you configure for the page itself, in an effort to clarify the interface and remove duplicate configurations that have proven to be unnecessary and confusing. Page Titles One of the more relevant and controllable areas of search engine optimization is your page titles. IP.Content utilizes your "Page Name" as the page title (the text inserted into the <title></title> tags of the page), which works well in most scenarios. When you embed a database into a page, however, IP.Content 2.2 uses the database name as the page title. When navigating further down into the database, the category name or article/record name is instead used as the page title. Customers have requested a change in this behavior and better control of this experience, and we are happy to announce there will be several changes coming in IP.Content 2.3 to allow you better control of your page titles across the software. Beginning with IP.Content 2.3, the default page title format for databases will be as follows: Index page: Database name - Page name - Website name (or board name, if no website name) Category page: Category name - Database name - Page name - Website name (or board name, if no website name) Record page: Record name - Category name (if available) - Database name - Page name - Website name (or board name, if no website name) We have not stopped there, however. We have separated the function that handles this out so that it is now possible to write hooks to override this functionality, allowing developers to come up with other ways to enhance or modify the page title formatting. And, additionally, we have also built in a custom formatting system that power users who require further control or refinement, or simply believe a different format works better for page titles, can now utilize for complete control. If you wish to change the format of the page title beyond the default, you can now do so by adding 3 constants to your conf_global.php file, and within these constants you can use macros to create different page title formats. While more information will be posted in our documentation section on this closer to release, here is the general code to give you an idea: * define( 'CCS_PAGE_TITLE_CAT', '' ); * define( 'CCS_PAGE_TITLE_RECORD', '' ); * // Following variables will be replaced: * // {page_name} = Page name * // {database_name} = Databae name * // {category_name} = Category name (only available for CCS_PAGE_TITLE_CAT and CCS_PAGE_TITLE_RECORD) * // {record_name} = Record name (only available for CCS_PAGE_TITLE_RECORD) * // {website_name} = Website name as configured in ACP * // {board_name} = Board name as configured in ACP * define( 'CCS_PAGE_TITLE_HOME', '' ); You could thus specify "(Website Name): Record Name - Category Name" for records, or you could have "Record Name - Page Name (And some custom text here)". Ultimately, if you wish to redefine your page titles, you can now do so with relative ease, and without having to worry about future updates reverting your tweaks. But wait, there's more! We didn't want to make a few minor changes to the format of the page title and call it a day. Many users have explained that while they want to name a page something simple (i.e. "News"), because that name is used in many places across the software, they may want their page title to say something different (i.e. "News - everything you need to know about my website subject matter"). How can we accommodate this as well? We have added a new option to the page form that allows you to optionally specify a page title that is different from the page name. To be clear - the page name will continue to be used throughout IP.Content, while the page title you specify will ONLY be used in the <title></title> tags, allowing you to completely control it. It should be noted, as well, that this new field is optional, so you aren't required to fill in the same name twice for all of your pages, or edit each of your pages upon upgrade to give it a separate title. When you uncheck the box, you can now specify a separate page title We have implemented this same new functionality for categories as well, so you can now define a category page title separate from the category name, should you wish to do so. In the process of making these changes, we noticed that the breadcrumbs within databases would use the page name on the database home page, however once you navigated within the database, the database name was used in the breadcrumbs instead. We have changed the breadcrumb navigation to always use the page name, and not the database name, to improve consistency and maintain hierarchy definition of the site. Redirecting Duplicate Page Requests While working through the system we found that page requests that are different, but load the same page, do not redirect to the correct form of the URL. For instance, if I have IP.Content at "www.site.com" and my default index page is "index.html" (and I have not enabled the option to remove the page name from the URL for this page), then I can access the same page via the URL "www.site.com" or via "www.site.com/index.html". The same page is loaded from two different URLs. As a general rule for SEO, this is bad, and all URLs that point to a page should redirect to the correct form of the URL for that page. We have enhanced IP.Content to detect this scenario and it will now 301 redirect these duplicate requests to the correct form of the URL. Pages Tab The "Pages" tab in IP.Board, if you have not hidden it, links to "index.php?app=ccs" by default. The system is designed to load your default page (with a fresh install, this would be "index.html" in the root of your Page Manager), and while we have already implemented a feature to redirect duplicate URLs to the correct form of the URL as described above, we took this one step further for the Pages tab. A new hook will be included with IP.Content 2.3 that rewrites the "index.php?app=ccs" URL used for the Pages tab by default so that it links to the correct form of the URL for your default page. This will reduce the number of duplicate URL requests that have to be redirected and help ensure only one URL is used to refer to any one given page (especially your index page, likely the most important and trafficked page of your IP.Content installation). Memory System IP.Content gives you a lot of flexibility and control, allowing you to fully define the URLs of your pages. You can define the full folder and page name structure for your pages; you can define the FURL string to use for your database categories; you can even define static FURL strings for your articles and other database records. This allows you to remove any ids from all of your URLs, but the tradeoff is that if you ever change your mind and rename a page, or a category FURL string, or an article FURL string, the system has no way to know where an old URL should point. For example, say you gave a database category a FURL string of "information". Your URL to this category is "site.com/articles/_/information/". A year down the road, you want to change this information page to an FAQ, and you want to update the FURL string to reflect this. The URL to this category becomes "site.com/articles/_/faq/". After a year, search engine spiders have surely indexed the previous URL, and visitors may click it in a search engine listing to reach your site. The problem is, that old URL no longer exists, and because it was a static piece of information without an ID, IP.Content has no way of knowing where the request should be pointed to now. We have eliminated this problem with a URL memory system, automatically available for pages, categories and records/articles with a static FURL string (if you do not explicitly define a static FURL string for articles a dynamic one is used with an ID, so this problem does not exist in this scenario). If you rename a category/page/article in IP.Content 2.3, it will remember the old URL behind the scenes. If a request is received and cannot be processed, IP.Content checks it's memory system to determine if the URL previously was valid, and if so, where it pointed to. IP.Content will then 301 redirect the request to the new URL, eliminating problems with broken links when you change your pages after they have been indexed. This was a highly requested feature, and we hope it makes managing your URLs easier, and more forgiving when you change your mind later on. Wrap Up We are continuously monitoring feedback we receive from clients, and we understand that SEO is important to you. We wanted to take the time to implement useful functionality changes in the software that will help your site grow. At the same time, we want to focus on proven areas that have a real measurable effect, and that will benefit all of our customers. We believe the changes discussed in this blog entry will improve both the user experience, as well as the experience search engine spiders have while indexing your website. It should be noted, as well, that every single one of these ideas stemmed from feedback suggestions in our IP.Content feedback forum, where we encourage you to share your thoughts with us! We welcome your comments on these changes below!

In our last IP.Content blog entry, we discussed some of the major interface changes you can expect to see coming with IP.Content 2.3. These interface changes represent improvements to your work flow and enhancements to the usability of IP.Content in the ACP. As mentioned in that blog entry, thousands of changes have been made, and while we obviously cannot detail every single one of these changes, we did want to outline some of the other major changes you can expect to see. Please read on to discover further improvements made to IP.Content 2.3. Fewer steps, quicker workflow IP.Content pages and blocks utilize a wizard-based approach for adding new pages and blocks, allowing you to proceed through the process one step at a time. This is largely implemented out of necessity - certain options will change depending on earlier options. For instance, if you choose to create a plugin block you will need to select which plugin (out of the available options), while if you create a custom HTML block you will need to provide your custom HTML. While this approach works well, and we've improved parts of it over various past releases, we have identified further improvements to speed up the work flow in IP.Content 2.3. For pages, the wizard steps are now down to 3, with the 3rd step being "Done" (i.e. no action on your part needed). We have combined various steps to reduce the time it takes and number of steps you must walk through in order to create pages. This should greatly improve the amount of time it takes to create pages compared to earlier versions. For blocks, we have also combined steps to reduce the time it takes to create blocks. With feed blocks, the "Sorting" and "Limiting" steps are now combined into one. With all blocks, the caching options have been combined into an earlier step. The end result is that all of the wizard-based interfaces now have a reduced number of steps needed to complete the wizard, which means less work and waiting on your part, and ultimately quicker setup. Redesigned Media Manager The media manager page has been completely redesigned, and while we are still putting some finishing touches on this area, we feel it is far enough along to give you a sneak preview now. The same functionality as before is available, with a more intuitive and refined interface. Again, please note that this is an early preview and there are still some areas here we are working on, but hopefully this video gives you an idea of the changes to come. Preview Video: http://screencast.com/t/DjwK9flzuEDe Small changes that add up Many small changes have been made throughout the interface to provide you with a better and more useful experience when working within IP.Content. Revision and comment counts are now shown for the appropriate menu items. This allows you to know right away (before clicking through to those pages) if there are revisions or comments for a particular item. While comments are only supported in databases and articles, revisions are supported for pages, templates and blocks (in addition to databases and articles); this change has been implemented throughout the ACP interface everywhere. A small indicator badge has been added next to articles that are set to display on the frontpage. While you could always manage these articles from the "Frontpage Manager" page of the ACP, many customers have indicated they would prefer to be able to see which articles are flagged to display on the frontpage right from the Article Manager page itself. Mousing over this badge shows a tooltip, explaining what the badge represents. The filter bar available in the Manage Articles page has been added to all database 'Manage Record' pages. This feature was available in earlier versions of IP.Content, but was removed while updating the software for IP.Board 3.2. We are happy to see it back, and we know many of you will be too. When adding a page previously, you had to specify the page FURL name and the page folder separately. It was hard to visualize the resulting URL based on the pieces of data you were supplying. We have improved these options in IP.Content 2.3 to better allow you to visualize the end-result from the values you supply. When adding pages, the option to "Only edit page content" has been hidden unless you have selected a page template to use. The setting is otherwise ignored, so hiding this setting will reduce confusion and clean up the interface, only showing you relevant options to the configuration you are specifying. Some further improvements have been made to the add/edit page form. When "Cache this page" is not checked, the cache lifetime options are hidden, reducing clutter on the form. Clicking "What is caching" will show a modal box explaining how caching works so that administrators can better understand the available options. Similarly, when "Available to ALL users", the permission multi-select field is hidden, further reducing unnecessary configuration options when you are managing your pages. By showing less options unnecessarily (but not removing the functionality), we believe adding and editing pages will become easier for novice users, but just as configurable as in earlier versions. We have removed the following options from the add/edit database forms: Allow user modifications Allow comments Database open Allow ratings All of these features can already be controlled by database (and category) permissions, and having separate on/off options for these features was extraneous and unnecessary. If you don't want users to be able to rate, just don't give any of them permission to rate (we automatically hide ratings on the front end in this scenario). If you don't want users to add or edit records, don't give them permission to. There's no need to have extra settings to control these things when you can already control them elsewhere. A button has been added to the revision pages for articles, records, templates, blocks and pages to quickly clear out ALL revisions for the respective item. While you could previously click the delete button for each saved revision, a button to clear all revisions can help you more quickly clear them out when desired. When viewing templates, the number of pages or databases using the templates are shown to let you know if the template is in use. We have made this number a link, and when clicked a modal box is shown listing the pages or databases using the template, with a link to the form to edit that page or database. We have added some inline help text on some of the major pages in the ACP to better explain how you can use certain features and what options are available to you. We will continue to evolve this inline help on an as-needed basis. Consistency We identified many inconsistent areas of the ACP that we spent time bringing in line with the rest of the software to provide a more reliable and stable experience when working with various features of IP.Content. Most of these changes don't warrant much discussion, but we felt you may be interested in hearing about them nevertheless.Hundreds of language string and verbiage changes have been made to provide a more consistent experience. Cancel buttons have been added to all forms to allow you to more easily 'cancel' your action without having to rely on browser navigation or other page links. Cancel buttons displaying in the "action bar" at the top of the page have been removed, and instead moved to the bottom of all forms. The navigation bar entries on every single page have been reviewed to ensure they provide correct, reliable and expected navigational breadcrumbs. Add folder/Add category buttons throughout the ACP now show the form inside a modal box. Previously, some pages used a modal box while some of these buttons would take you to a new page to supply the category/folder title. Minor styling inconsistencies have been resolved, ensuring the interface looks the same no matter where you are. A button to jump to the 'Manage Moderators' page has been added to the database field/category/record pages. The same jump bar has been added to the manage moderators page, allowing you to easily jump back to the record/field/category management pages. Dropdown menus used when creating blocks have been changed to radio buttons. This allows you to more quickly see all of the available options without having to open the dropdown and close it to confirm the option you have selected is the one you want. On the Databases page (where your databases are listed), the name will now take you to the edit database form. This is much more consistent with the rest of the IP.Content (and IP.Board) ACP interface. The number of records and fields are now links to take you to those pages, respectively. Additionally, the number of categories and moderators are now shown, also linking you to their respective pages for thatspecific database. Codepress as an editor option has been removed. The javascript editor has not been updated in several years and no longer works with current modern browsers, so we have decided to drop it as an option. Having an option that doesn't work is worse than not having the option at all. And more... As we mentioned before, we've made thousands of changes to the ACP and can't possibly detail each and every one. Every single change made has been part of an effort to improve consistency or usability. These first round of changes will all help improve your work flow, make existing processes quicker and clearer, remove clutter and confusion from the interface, and generally help you to get on with the task at hand. We welcome further ideas to improve the interface, workflow and consistency of the application in our IP.Content feedback forum, otherwise please leave your comments below!

IP.Content, by it's nature, is largely managed via the admin control panel. While there are front-end capabilities available to allow you to distribute some of the work load to your moderators (and, in some cases, members), the majority of the setup and management is performed via the admin control panel. Additionally, because IP.Content is a framework tool designed to allow you to build your website utilizing features and APIs made available through the IP.Board suite framework, sometimes the available options can become a little overwhelming for new users. We have literally made thousands of changes to the IP.Content admin control panel interface for version 2.3, and we wanted to take some time to explain some of these changes you can expect to see with the next release. Template Help Improvements IP.Content has had a built-in help function for pages, templates and blocks for many releases now. A small button above the template editor opens a sidebar to show you the available template tags based on the area you are editing (a page, a template, or a block). We identified several ways to improve the template tag help for IP.Content 2.3 to make it more noticeable and usable, and we think these changes will make editing templates much easier in the next release. In reviewing feedback and requests, many customers seemingly did not even realize the template tag help feature was available. They had overlooked the buttons, causing them to miss this extremely valuable feature. The styling of the help was inconsistent with the rest of the ACP There was inline help and advanced help available. The advanced help showed descriptions and additional information about the inline help tags, but was otherwise duplicative of the existing inline help panel. The database help always opened a popup and often felt clunky in real-world use. Beginning with IP.Content 2.3, the buttons have been removed entirely. The inline template tag help panel will be open by default, helping you to know it is available immediately without having to discover this very useful feature. You can still close the panel if you are familiar with the available tags; closing the panel will minimize it to a small clickable vertical bar to the right of the editor, which you can then click to reopen the panel. If you close the panel, this is remembered via a cookie so that you will not have to close the panel on other pages or when working with other blocks within the ACP. For database templates, the help panel is tabbed, with one tab showing the regular template tags and one tab showing the available database variables you can utilize in the template. Database templates are context-sensitive, showing different available tags based on what kind of database template you are working with. Additionally, we have implemented "click to insert" functionality for all of the tags now. This means there will be a small button next to tags within the template tag help panel that, upon being clicked, will insert that tag into the editor for you automatically. This has been an oft-requested enhancement we are happy to announce will be available in IP.Content 2.3. Video: http://screencast.com/t/ZAZR55GJic Field auto-population What does that even mean? Well, in IP.Content 2.3 we identified many areas of the software where a value was needed, but often times you were not required to supply one, or one could be extrapolated from other data automatically. For instance, templates, fields, blocks and databases all require a unique key that is utilized throughout the software to refer to that object. Categories require a friendly URL key, and articles and other database records allow you to (optionally) specify a static FURL key. You use the database key to refer to the database when inserting it into a page; same with blocks. Generally speaking, however, most administrators don't understand what a "key" is, why it is needed, or why they need to manually supply it. Indeed - they shouldn't need to manually supply one in most cases. The software can figure this out for you. In IP.Content 2.3, we have hidden many of these fields (for non-developers, at least) and will now auto-populate the key based on the title of the content. For example, when you add a template you will no longer be prompted for a template key (unless you have enabled developer mode) - one will be set for you automatically behind the scenes. For areas where even non-developer administrators may want to specify the key, we have made the field hidden by default (and auto-populated for you), but you can still override the automatically set key manually if you wish. We have implemented this method of value auto-population in many areas of the IP.Content ACP. Additionally, when you opt to manually specify this key (where available), an AJAX callback is triggered that will ensure it is unique and automatically append a unique string to the end of it if necessary. Video: http://screencast.com/t/y5WOpYvL7xb In this video you will see the new implementation available when adding a database. The database key is automatically determined based on the name of the database you specify. When you enter a name that would result in a unique key (such as "Articles", as an articles database is provided out of the box), a unique string is automatically appended to the key real-time. Finally, you can manually override the automatic key and specify one manually, should you wish to do so. Specifying title and content fields When you create (or edit) a database, you must specify which field in that database represents the title of records submitted, and which field represents the record content. These options are available on the bottom of the second tab when adding/editing a database. When you are adding a new database, however, you run into a chicken-egg scenario - you are asked to specify these two fields, however you cannot create fields for a database until the database itself exists. Many users will finish creating the database, then create the respective fields, however they forget to go back and update the database configuration to set these field mappings. This situation creates an issue some users have run in to - your friendly URLs in that database do not work correctly, redirecting you back to the database index. We have resolved this issue in IP.Content 2.3, ensuring that the URL still works if the title field is not correctly specified (and you are using friendly URLs). However, that is not what this blog entry is about. :wink: We have added new checkboxes to the add/edit field forms to allow you to specify if a particular field represents the title or content for the database right from the field form. If you check one of these boxes while adding or editing a field, the database will be updated for you automatically. If you edit a field already marked as the title or content field, the checkbox will be checked (to indicate this to you), but disabled (to prevent you from deselecting a field as the title field and inadvertently leaving the database with no title field specified). This should help your workflow immensely when creating new databases. You will no longer need to create the database, create the title and content fields, and then update the database to specify these. Now, you can set these special fields right from the field addition form, saving you from having to do something manually which you will be likely to forget. More to come This is part 1 of a two part blog outlining some of the major interface and workflow changes you can expect to see coming in IP.Content 2.3. Stay tuned to read about further changes you can expect to see in IP.Content 2.3, with our next blog entry outlining some of the other major ACP interface changes. If you have ideas to enhance the software, please post them in our IP.Content feedback forum. Otherwise, we welcome your comments below!

IP.Content, our popular content management and creation tool, allows administrators to manage content throughout their site. You can create templates, pages, blocks that can be embedded anywhere (even outside of IP.Board!), and databases of custom data with many easy to use yet comprehensive tools built into the software. Development is underway on the next major version of IP.Content, version 2.3, and we wanted to take a moment to let you know what you can expect to see in this release. Please keep in mind that all specific features and release schedule time frames are subject to change depending on circumstances outside of our control. With that in mind, let's take a look at the areas we will be focusing on for IP.Content 2.3. Usability One of the most important areas of the software we are focusing on with 2.3 is usability. We have received and reviewed much feedback regarding the way IP.Content users utilize the many features in the software and will be placing a very heavy focus on streamlining the interface to make your work flows quicker, easier and more intuitive. Every word, button, link and form option for every page of IP.Content has been scrutinized, and we have found many areas we feel we can make more intuitive without removing functionality for advanced users. To go along with improving the ease of use of the software, we are intending to include some new functionality to help novice users get started using the software quicker. Certain requests in the forums show a pattern, and we've been paying attention to these patterns. IP.Content 2.3 should prove much easier to use, for beginning users, average webmasters, and developers alike. Consistency The IP.Board framework offers a vast array of features and functionality that can be utilized by applications tied to it, including IP.Content. While IP.Content makes use of many of these features out of the box already, we are going to be expanding the use of existing framework functionality, which will serve many important purposes: Consistency helps users better understand how the software works, and learn how to use it quicker Better use of framework functionality will improve moderation and administration of the software Expanded use of built in functionality of IP.Board will allow you and your users to utilize more features in the software There are some specific areas we will focus on with this release, and we are sure that you will be pleased with the expanded feature set and improved consistency between IP.Content and the rest of our addon applications. SEO Search engine optimization can be a challenging task with software such as IP.Content, primarily because you are in control of the majority of the final output. Nevertheless, some specific areas of focus have been identified and we will be improving some various aspects of the software to help ensure the software itself is not a hindrance in allowing you to target your site as you see fit. Strengthening Existing Features We want to take this opportunity to also strengthen some of the existing feature set of IP.Content. Certain features do not always work as some of our customers expect, and we want to ensure your experience with the software is intuitive, and produces the outcome that you expect. We are going to focus on some of the existing features that we have received feedback about to ensure they work as you expect. Before we move on to brand new features in the software that will blow you away (and we have internally identified several we wish to explore further), we want to be certain that the existing features work perfectly for you first. Stay tuned for future blog entries outlining details of the specific changes to come. We wanted to give you a high-level overview of the direction we are taking IP.Content, and the areas we are focusing on, so that you can know what to expect when we start talking specifics in the coming weeks. We are targeting spring of 2012 for a release, and in the mean time will be working closely with focus groups, alpha testers and developers to ensure the release we deliver is as great as we hope it will be. Please ensure you post feature requests in the IP.Content feedback forum, otherwise we welcome your comments in the area below!

We've already blogged about some miscellaneous changes you can expect to see coming in IP.Downloads 2.5, and hope you are excited about these enhancements and improvements to the software. We have just a few more changes we wanted to let you know about, so without further ado, and in no particular order, read on to see what else you can expect to see coming in IP.Downloads 2.5. Ability to re-rate files A minor enhancement to the existing rating system, you will now be able to re-rate files as of IP.Downloads 2.5, if your group permissions allow for it. This means if you rate a file you downloaded a 4, for example, and the author improves the file, you can re-rate the file a 5 when the new version is released. Custom field searching Many of you have requested this feature, and we are happy to announce you will now be able to search custom fields in IP.Downloads 2.5. You will be able to configure per-custom-field whether you want to allow searching in the field or not. When a custom field allows you to search it, that field will be available in the application search options on the advanced search form. Custom field searching is supported with both SQL and Sphinx searching. Linked files domain blacklist We have added a new setting to allow you to "blacklist" domains so that files cannot be linked to on those domains. The ACP setting is a textarea allowing one domain per line (with * serving as a wildcard to allow you to include subdomains). When a user links to an offsite file, the link is checked against your blacklist, and if the link points to a domain you have blacklisted, the submission will be rejected with an error message. Quick access to member reports in the ACP We have added a link on the Manage Members page to allow you to quickly look up a member report in IP.Downloads for that member. This one link can now allow you to better monitor your member activity within IP.Downloads. Other files you may be interested in There is a new ACP option to allow you to add a block on file view pages labeled "Other files you may be interested in". This block is essentially a search based on the filename for the file you are viewing, pulling in similar files that may be of interested to you. Behind the scenes, sphinx will be used if you are using sphinx for searching your site. We have ideas for future expansion of this capability based on various other factors, but we felt that a search based on the filename was the most logical way to proceed for an initial implementation. Note that while the search only utilizes the file name to find similar files, when we perform that search we look at both file names and descriptions. Wrapping up Beyond the changes we have blogged about here, we have gone through the bug tracker and resolved all outstanding bug reports. We have also implemented some various minor changes to help improve efficiency and resource usage throughout the software, allowing it to perform better than ever! We hope you are as excited as we are about IP.Downloads 2.5, and we look forward to your feedback on the upcoming software release.

IP.Downloads features a robust and powerful file submission process, allowing your users to quickly and easily upload files to your site and configure them to the specifications your site has set. Users can upload multiple files and multiple screenshots, using either the traditional uploader or the flash uploader; you can configure custom fields for users to populate, and even require them to fill in the fields; versioning is handled automatically, if enabled, and changelogs are fully supported. IP.Downloads provides much of the functionality you would ever need in a download manager out of the box, and allows you to extend this functionality as needed on a per-site basis. For IP.Downloads 2.5, we have improved some aspects of the file submission process, added some new features, and extended how the submissions are presented in some areas. Read on for further information on changes you can expect to see in the next release of IP.Downloads. Tagging I suppose I could end this section with "'nuff said", but for those of you looking for the details, we have implemented full tagging support in IP.Downloads 2.5. You can disable tagging on a per-category basis, and the system supports the pre-defined tagging system (with the ability to configure pre-defined tags on a per-category basis if you wish). You can utilize prefixes and disable prefixes on a per-category basis as well. When submitting a new file (or editing an existing one), you will be presented with the standard tagging interface as you would when submitting a topic, and the interface adapts based on how you have configured your tagging system as a whole (i.e. if you use pre-defined tags, the user will be presented with a dynamic select box to choose from the list of available tags). As mentioned, prefixes are supported, and will be highlighted before the file name (just like a prefix in the forums will show before the topic title). Tags are searchable through the global search system, and tags are shown where relevant (search results, category listings, and the file view page). Basically, all aspects of the tagging system available through the core framework have been incorporated into IP.Downloads, allowing you to configure the system to suit the needs of your site. Enhanced uploader support IP.Downloads supports the use of both the traditional uploader and the advanced flash uploader. The traditional uploader requires you to select a file, hit the 'Attach file' button, and then proceed to select more files or continue with the form submission. The flash uploader will allow you to select multiple files at once, and will upload them automatically once you have confirmed your selection. In IP.Board 3.2, we removed the ability to configure your uploader preference from the user control panel, deferring to the more intuitive inline option available on posting forms throughout IP.Board. When you are replying to or starting a new topic, you can change your uploader type right on the submission form (if you have the ability to upload attachments). This is a more logical way for users to set their preference, but a problem presented itself with the setting removal in the User Control Panel - IP.Downloads did not provide this same inline switching capability, so if a user decided he needed to use a different uploader type, he would be required to visit the forums, click to start a new topic, change his preference from here, and then return to his file submission form to continue. We have added the ability to change your uploader preference right from the IP.Downloads 2.5 submission form, allowing your users to more intuitively utilize and configure the uploading feature without having to leave the page. When you are using the traditional uploader, as mentioned above, you must click the 'Attach file' button to perform the actual file upload. Many users not familiar with the interface would often select a file and forget to click this button, proceeding to click the submit button at the end of the form before actually uploading a file. The end result is that the user sees an error message on the screen advising them that they did not upload a file, and they have to reselect the file and click upload again after the page has finished loading. With IP.Downloads 2.5, we have added a check to the form submission process to verify at least one file was uploaded before allowing the submission to continue. If no files have been uploaded, the user will be taken to the top of the page and a message will be shown to alert them that no files have been uploaded. We believe this simple enhancement will help users better understand the interface, save time for users who forgot to upload a file, and make the overall submission process clearer, particularly for newer users not familiar with the software. Version numbers IP.Downloads supports version numbering in the submission and editing processes, allowing your users to upload new versions of their file and specify the version number when doing so. The version number is then shown on the file display page along with the file name, so users can see right away what version of the file they are looking at. We have decided to expand version number support to other areas of the software for consistency. Version numbers will now be shown everywhere the file name is shown - search results, the download manager index page, category listings, and so on. By providing this information to users before clicking through to the file, users can be better informed before visiting a file if it is of interest to them, or if it has been updated since the last time they visited. You can see the version "1.0" in the tagging screenshot above, for example. Screenshot efficiency IP.Downloads presently processes all screenshot requests through a PHP backend handler, allowing it to handle many of the various configurations possible with the software. If you store screenshots on a remote FTP server, or in the database, or outside of the web root, or if you allow linked screenshots, IP.Downloads needs to take all of these various possibilities into account and present the user with the same result regardless of how the image is stored. This works well, but routing all image requests through a PHP handler increases the overhead needed to show the user a simple image, and is not necessary for the most common configurations - screenshots stored on disk in a web accessible folder. We have added a new setting to IP.Downloads 2.5 to allow you to configure your screenshot URL in the ACP. When you configure your screenshot URL, and the image is a locally stored file and exists in the configured upload folder, the screenshot will be loaded directly from the server, instead of served through a PHP script. This might sound like a very minor change on the surface, but it has tremendous resource ramifications, and will benefit the vast majority of IP.Download installations that use a common setup as described above. Further to this - you can configure your screenshot URL as a CDN URL, allowing your screenshots to be stored in a CDN and served to users from the CDN. To make use of this feature, again, you need to store your files on disk, and screenshots (only) need to be stored in a web-accessible folder. You can move your screenshots folder to your web root and update your ACP configuration if you are storing them outside of the web root directory presently, allowing you to make use of this useful change when it becomes available. Additionally, linked images will no longer be run through the PHP handler. While this means that linked images will not display a watermark or copyright stamp, if configured, and the remote images will not be proportionately resized, it resolves many miscellaneous resource considerations that apply to the current implementation: bandwidth is saved for you both by eliminating the image being downloaded to your server and by not serving it from your server to the user, linked images are no longer handled through a PHP handler, and linked images are no longer dynamically resized upon request (image processing is one of the most resource-intensive processes with PHP). This results in a much more efficient handling of linked screenshots. Note that the following will still be served through a PHP handler: Screenshots stored on a remote FTP server Screenshots stored in the database Screenshots stored in a folder that is not web-accessible Full-sized screenshots, as we need to apply the copyright stamp or watermark if configured (and cannot apply this to the actual image file, in case you wish to rebuild thumbnails later, or change your watermark image, etc.) The little changes are often the most useful These changes, while small by themselves, add up to provide a more efficient and robust experience for your users. From tagging support to better screenshot handling, we have performed a top-down review of the entire IP.Downloads product codebase to ensure that it functions the best it possibly can. Your users can expect a more fully-featured experience using the IP.Downloads software, and you can expect it to perform more efficiently on your server. We hope you enjoy these improvements to the software, and if you are interested in hearing about further IP.Download development updates, please subscribe to the IPS Company Blog!

One of the most critical areas of a download manager application is, naturally, the download process. There are many things to factor in - you want to ensure the security of your files, you want to ensure the integrity of the system, and you want to ensure a nice user experience. IP.Downloads supports many features to help you control who can download what and when throughout the software. You can enable anti-leeching settings; you can configure per-group limits on number of files or transfer consumption at the day, week and month levels; you can require that your users post in the forums in between downloading files. There are many options to ensure that you can configure your site in a manner that you feel works best. IP.Downloads 2.5 is introducing two new features to allow you to better control the experience and provide more value to subscribers or registered users on your site. Controlling the transfer rate The transfer rate is the speed at which files being downloaded are delivered to the user. Currently, IP.Downloads will simply send the file to the user as fast as your server (and their connection) will allow. For most applications this is fine, however what if you want to allow guests to download, but give them an incentive to register too? Or what if you want to offer faster downloads to your premium member groups, while still allowing your regular member groups to download files, albeit at a slower rate? IP.Downloads already supports enforcing a limited number of simultaneous downloads, so the next logical step was to allow you to configure how fast the download can be delivered. Beginning with IP.Downloads 2.5, there is now a per-group option labeled "Speed Throttling (in kB)". It is important to note now that no matter what you set this value to, a download can never be delivered faster than (1) your server can send it, and (2) you can receive it (typically based on your internet connection speed). Having said that, you can now set individual groups to use a throttled download speed, limiting how fast the file will be delivered to the user. As an example, I uploaded IP.Board (which is approximately 8MB in size) to my localhost server. Without download throttling enabled for my group, it was downloaded nearly instantly. After all, I was downloading the file from my computer to my computer, so there was no network latency or connection speeds to worry about. With the speed throttling setting configured to 1 kB/sec, when I started the download, Firefox estimated it would take an hour and 56 minutes to download the file. This is an extreme example used purely to demonstrate how the feature works. In the real world, you might allow your premium groups to have no limit, while your regular member groups or guests might be able to download at 4kB/sec, giving them an incentive to register, or upgrade to a premium membership. Live countdown before the download will begin We've most likely all been to websites where you click to start a download and suddenly a counter shows up on the screen, requiring you to wait 30 (or sometimes 60) seconds before the download will actually begin. Many sites dedicated to file-sharing specifically utilize such a setup, providing an incentive to purchase one of their unlimited monthly subscriptions to bypass this countdown. IP.Downloads 2.5 now has this functionality built in on a per-group basis. You can configure individual user groups to require a short wait period before the download will begin, and this will be honored both on the front end (visibly to the user) and on the backend (so the user cannot circumvent this wait period). When the user clicks to download a file, the countdown will begin, and the remaining wait time will be displayed on the screen. Here is a short video showing this in action. http://screencast.com/t/Ff900lsxEiL In this video, you see me initiating a download and being forced to wait 10 seconds before the download begins. And still more to come... These feature additions were some of the most oft-requested feature suggestions, and they fit perfectly with our IP.Downloads application, allowing you to provide measurable incentives to your users to register or subscribe to a premium service on your site. We have a lot more in store for IP.Downloads 2.5 still, however, so please subscribe to the IPS Company Blog if you wish to hear about further changes you can expect to see in the next major release!

Commenting is an integral and central part of our application framework. Because we have a solid commenting system in our core framework, we can easily and consistently role out commenting to each of the addon applications, while delivering a consistent experience no matter what application the user is using. While commenting itself has been available for IP.Downloads since it's inception, we wanted to improve the functionality and implement some features that we think will make commenting more useful for you, your members, and your moderators. Unapproved comments in the ModCP IP.Board 3.2.0 introduced a new centralized Moderator Control Panel - a one-stop-shop where your moderators can review everything requiring their attention throughout the site quickly and easily. This ModCP has many functions, but one important and oft-used function is the unapproved content centralization. By visiting the ModCP you can quickly and easily see all unapproved content that you (or your moderators) need to attend to. IP.Downloads 2.4 showed unapproved and broken files in the ModCP, however comments pending approval was notably missing in this minor compatibility update. Through our own use of comments in the Marketplace we quickly saw just how useful it would be to have a central place you can check to review comments pending approval. Beginning with IP.Downloads 2.5, you will now be able to view, delete, edit and approve comments in IP.Downloads from a new tab in the ModCP under the "Unapproved Content" page. This should make managing new comments that require moderator approval in your IP.Downloads installation much easier. Comments in search results It is convenient to be able to find all content across your site within a unified search interface, and IP.Board 3.2 delivers an exceptional framework to allow this to happen across all applications, both in-house and from third party developers. While IP.Downloads itself supported the central search system, comments in IP.Downloads could not be searched for at all in previous versions. Beginning with IP.Downloads 2.5, you will now be able to search for comments in IP.Downloads. Going beyond this basic addition, however, you will also be able to see new comments in IP.Downloads when using the "View New Content" tool, and you will be able to see all of the comments you have made on IP.Downloads files under the "My Content" page. These simple enhancements can provide a lot of value to your community if you heavily use or rely on the comment functionality in IP.Downloads, allowing you to easily and quickly find comments you or someone else has left across your IP.Downloads installation. Improved guest commenting Minor improvements to the guest commenting functionality have been implemented in IP.Downloads 2.5, allowing for a more consistent experience for guests across all of our addon applications. Blog introduced these improvements in an earlier version, and the necessary changes were rolled into the core IP.Board package for 3.2. As such, when you allow guests to comment in IP.Downloads beginning with version 2.5, they will be asked for their display name, a captcha will be presented (when you require this via your ACP configuration), and commenting for guests will otherwise work the same as it would for a member. More to come... For the release of IP.Downloads, we want to focus on improving the overall experience, and providing a consistent experience across all of our addon applications. We also want to ensure that the software makes use of all of the central functionality that the IP.Board framework provides for, and makes use of it in a logical, easy to use, and reliable manner. These small improvements to the commenting system can make it much more useful if your community makes use of comments in IP.Downloads, and we hope they make your job as an administrator or moderator that much easier. We have a lot more in store for IP.Downloads 2.5, so stay tuned for further updates. Please feel free to subscribe to our IPS Company Blog if you wish to be notified of future updates. If you have feature suggestions for IP.Downloads, please post them in the appropriate suggestions forum, otherwise we welcome your feedback on the forthcoming changes mentioned here in the comments section below!

IP.Chat is our AJAX-powered chatting software application, available as an addon for IP.Board. IP.Chat takes a "less is more" approach and focuses on providing a simple but powerful interface for your users to chat, real-time, on your forums. We have spent some time enhancing the functionality available in IP.Chat to make it more useful and more flexible for you and your users, and we wanted to take a moment to let you know what changes you can expect to see with the release of IP.Chat 1.4.0. All bugs flagged for correction in a future version have been resolved Often times we have items reported to the bug tracker that can be considered both a bug and a feature suggestion, or could be considered either a bug or a feature suggestion, depending upon your viewpoint. A lot of the time when we feel the report has merit, or is close enough to a bug that one might reasonably consider it to be a bug, we will flag the report for correction in a future version. We have taken the time to work through all open reports for IP.Chat that were flagged for correction in a future version to ensure we launch IP.Chat 1.4.0 on a clean slate. There weren't many to begin with, but as of the time of this blog entry there are exactly 0 open bug reports for IP.Chat as a result. Ban confirmation It was brought to our attention that when you clicked to 'ban' a user within the IP.Chat interface that no confirmation was requested from the moderator. This meant that if a moderator accidentally clicked the 'ban' option instead of another option, the user would be banned from chat until a super moderator went into the ModCP to remove the ban (or until an admin did so from the AdminCP). We have added a quick confirmation to ensure that when you click the 'ban' link that this wasn't an accident before proceeding. While this is surely a small detail, it can save you (and your users) time and hassle when a simple mistake is made. Redesigned Interface We have made some small interface improvements based on customer feedback that we feel will both make chat a little more attractive, and a little easier to follow when you have several users actively chatting with new messages popping up onto the screen quickly. The interface changes have largely been confined to the chat area itself; in other words, the changes we are talking about here are primarily focused on the list of chats. Firstly, as you'll notice, profile pictures are shown for the users who are chatting. This visual indicator can help you to more easily identify who said what, especially when compared to the names previously shown in the left hand column that could scroll quickly past. In moving the profile picture to the left, we have moved the user name over above the chat message, allowing us to stop truncating the username due to the possibility it could be longer than the space available to show it. If you take a look at the last message you will notice one other small but useful improvement - successive chats from a single user will now be grouped together. This not only saves space, but helps to create a more conversational approach to the IP.Chat interface, making it easier to read and follow the discussion. Mobile Support Not only did we redesign the primary interface, we have added a mobile interface for IP.Chat. Whether you can use IP.Chat on your mobile device will of course depend upon the device's support of the technologies IP.Chat utilizes, however for more advanced smart phones you can now utilize IP.Chat on the go in a native mobile skin. To allow IP.Chat to better function within a mobile interface, we have made some small tweaks to the functionality when utilizing the mobile skin. First and foremost, there is no embedded scrolling div (this is the area of IP.Chat that scrolls within the page on the full skin). Many mobile devices use touch screens and scrollable divs are not always supported (and when they are supported, users do not necessarily know how to actually scroll within these areas of the page). As such, all chats are pushed directly on to the screen. Because of this, we have also hardcoded the limit to the number of chats on the mobile skin to 50 to ensure the screen does not get too large. In this screenshot I have scrolled the screen down so that you can also see the list of users, which is shown below the chat messages themselves. The user links have been simplified and pulled out of a menu, but otherwise all of the same functionality is still available. The area to post a new chat is fixed to the bottom of the screen so that it is always quickly available for the user. As your user scrolls the screen up or down, the text input box and post button will always be shown right at the bottom of the screen. The best part - private chats are still supported! When you start a private chat, or a private chat is started with you, tabs will be created at the top of the window to allow you to switch between the main chat room and your private chats. We are excited about the mobile support for IP.Chat and hope your community makes good use of it! Full guest support Last, but not least, we have updated IP.Chat to allow multiple guests to join chat (if your permissions allow it). Guests will be shown as "Guest_####" (where #### is a random number) and will now be able to join the chat room and participate in the conversation. These chat room guests will be shown in the "Who's Chatting" block on the board index, and can make use of all features of IP.Chat. You can even ignore private chats from individual guests, and you can kick individual guests from the chat room. Moving forward As you can see, we have made some important improvements to IP.Chat that we feel will allow you to make better use of your software package. These changes improve upon the consistency of the software, ensuring it functions exactly as you would expect within the IP.Board framework, but still allowing it to stand out as an excellent choice for real-time conversations on your site. We have many great suggestions for future versions of IP.Chat, so if you would like to add your support to a particular suggestion, or submit your own, head on over to our IP.Chat feedback forum. Otherwise, we'd love to hear your comments regarding IP.Chat 1.4.0 below.

As part of our ongoing commitment to deliver the best community software on the market, we routinely run IP.Board through various tools designed to measure efficiency and resource usage, helping us to identify areas that could benefit from minor and major refactoring to make the software more efficient. We do this periodically with all of our software in order to ensure we have not introduced new code that will cause resource usage problems on your community. This is typically an unexciting task that does not garner much interest from the average user, but we thought some of you might enjoy hearing about some of the resource-based improvements we have made for 3.2.3. If hearing about the nitty gritty details that go into making the software used to power your community is of interest to you, read on. If not, and you just want to hear about upcoming features or service offerings, please skip this blog entry and stay tuned for next time! What are we looking at? When looking at the amount of resources our software uses, there are multiple points to consider. You have to keep an eye on memory usage, CPU usage and disk space usage. You have to consider the entire server stack too - MySQL, Apache (typically) and PHP, and of course the PHP code itself (e.g. IP.Board). There are some things within our control while developing the software, and there are some things that can only be controlled at the server level, so it is important to consider all angles (and server configurations), while tailoring the software to work in the widest array of environments possible. While we cannot control your MySQL or Apache configuration, some improvements can be made at the software level that will benefit everyone, regardless of your configuration, so we often look to these improvements first. One tool available to PHP developers that can help while you profile your code to look for improvements is xdebug, and this is where the focus of this blog entry will be. When you use xdebug to profile PHP code, a file (called a "cachegrind" file) is created that you can then load into another software package in order to view the results. The most popular tools to view cachegrind files are kcachegrind (for Linux) and Wincachegrind (for Windows). If you are not familiar with what this looks like, here's a quick screenshot to give you an idea (taken using Wincachegrind, since I'm a Windows user): Note: Times indicated are not representative of a normal page load. I run my local environment with development mode enabled which utilizes far more resources than normal, due to rebuilding of many caches, including skin cache files, on every page load. The screenshot is merely designed to give you an idea of the interface and types of information available with the tools used. So...what did we find? Well, it's rare that we find something big, because we routinely run our software through tools such as this. You generally only find huge areas that can stand for improvement when working through major code refactoring (such as IP.Board 2.x to IP.Board 3.x). We did, however, find many smaller areas of improvement that collectively can mean big resource gains when added up together. If you save 50ms of processing on a page, and that page is hit 10,000 times in a day...well, you can do the math. Static caching We found many functions that were called several times on each page load, very often with the same data, returning the same result. Without caching, the functions are required to perform the same operations repeatedly, so we added static inline caching to store the results from the processing so that future calls can just fetch from the cache, instead of reprocessing the same data, and returning the same result. Some functions where we added static inline caching for 3.2.3: IPSMember::unpackGroup() IPSMember::makeProfileLink() IPSLib::getEnabledApplications() IPSMember::setUpModerator() Unnecessary code processing Every operation a PHP script has to perform consumes some level of resources; sometimes this is negligible and sometimes this is measurable and important. When code is executed that does not need to execute, however, it is simply a waste of resources, no matter how small that may be. In reviewing the profiling results, we found some code that was executing which simply did not need to, which we removed/fixed. We found some various array checks in the output class that were unnecessary, as the array was a class property and initialized when the class was instantiated into an object. We were parsing some dates in the search results area twice, when we only need to do so once. We were parsing the post content in search results, even when we displayed the results as topics. Parsing post content is an expensive operation, so this unnecessary operation was particularly wasteful. We found that one particular IP.SEO hook is outdated and provides no benefit as of 3.2.0. This will be investigated (and potentially removed) with the next release of IP.SEO: http://community.inv...topiclinks-hook Several operations were running when displaying a mini-calendar which were unnecessary (because the results were never displayed in the skin). The IP.Downloads board index latest files hook was loading the category helper class twice, unnecessarily. Similarly, some of the functions within this class were called multiple times, unnecessarily. IP.Downloads was utilizing an unnecessary "GROUP BY" SQL clause. Generally, this requires a temp table to be created, and in this case it was unnecessary. The UCP Manage Attachments page queries for attachments even if it discovers there are none (through the SELECT COUNT(*)... query that is first run). We removed this second query when there are no attachments to retrieve. More specific changes... Additionally, we have found several more specific areas of improvement that we have corrected for 3.2.3. These areas of improvement, as a general rule, improve resource usage more than the items listed above, but are less trafficked and thus less likely to be noticeable. As such, your mileage may vary with these improvements depending on how your site is utilized by your members. We build a cache of each item's 'like' data, and store this separately so that we do not need to query all of an item's like data on every page load ('like' data here means the follow/unfollow system in IP.Board and applications). We were caching this for one hour, however the software is doing a good job of ensuring the cache is rebuilt as needed when records are deleted and so forth. Thus, we have increased this cache from one hour to one day, limiting how often the software needs to rebuild this cache. A change that we made to one of our JSON encoding routines was causing significantly more resource usage compared to previous versions. We reverted that change back to match 3.2.2, saving nearly 100ms of processing per page this occurred on. We have a call in our registry destructor that saves topic markers back to the database so that they are not lost between page loads. This is necessary, of course, in order to maintain topic markers across different browsers and computers. We found, however, that this was occurring even when you were using an application that does not utilize the item marking system in our framework (for instance, when you are browsing IP.Calendar). By adding a check in the destructor, we save the software from having to load up the topic marker library, parse all topic markers, just to save them back to the database when the application you are using does not need item marking capabilities. We discovered a minor bug with the reputation cache loading when the central comments class was utilized in some cases. In certain places, the reputation cache would not load correctly, and while the software largely corrected for this automatically, it meant using more resources than necessary to rebuild this cache because it did not load correctly the first time. By fixing this bug, we saved the software a lot of extra unnecessary processing (and fixed an unreported/undiscovered bug in the process :whistle: ). We found some applications were not loading caches (from the cache_store table) that they were using. We added these to the initialization routines for the respective applications, saving database queries later on to fetch the caches individually. We discovered a few areas that were calling IPSMember::buildDisplayData() were not caching the member data as designed. Upon inspection, this was because the member data was joined onto the main queries, rather than fetched separately, so the check in buildDisplayData() to verify the same information is being passed always failed. By refactoring how we pulled members and called this method in a few places, we allow the software to cache the results and prevent parsing of data multiple times unnecessarily. In most cases this means an extra database query, but less PHP processing - the tradeoff is worth it in this case, as the PHP processing is more expensive. In IP.Content, attachment parsing was happening in a loop for each record that was being displayed in listings. While this is not a problem by itself, per-se, we were able to refactor the code to parse all of the attachments at once, allowing us to run just one database query, instead of one per-record. Again, in IP.Content, we found that the topic posting library was being called when you were a moderator and unpublished or unapproved records were being displayed to you. The topic library was called in order to post the topic (that mirrors the article, or stores the comments, depending on your configuration), however it was not necessary since the article is not yet visible. We added some simple checks in the code to save from having to load this library unnecessarily. And last, but not least, we found a major improvement area for IP.Calendar. The mini-calendars displayed in IP.Calendar (and in IP.Content mini-calendar plugin blocks, and on the board index if you utilize the calendar mini-calendar hook) are very much static HTML. The only change that occurs in these mini-calendars is that the current day is bolded, if you are viewing the current month. We utilized some clever caching techniques (using the cache_store table) in order to save the HTML output that is generated, and then we reuse this output instead of rebuilding it repeatedly. The end result is that mini-calendars only need to rebuild once a day now, instead of on every single page load. Conclusion IP.Board and our addon applications have large, complicated code-bases. We are beyond the stage, for the most part, where you will find silver-bullet resource hogs in the code that you can fix by adding a simple database index, or changing a couple lines of code. Instead, we are always on the hunt for areas of the code that are heavily utilized (such as library methods) as any small improvements in these areas will add up to significant gains based on the sheer number of calls to the methods. The above changes may seem minor and unimportant, but the end result was that some pages, following the changes noted above, utilized anywhere from 10ms to 200ms less processing time. When you multiply that by the number of times the pages are viewed in the course of a day, you start to see very real and useful improvements in loading time, without the loss of any existing functionality. These are resource improvements that benefit all sites, from the smallest to the largest, and we are glad we could implement these for 3.2.3 to help you make the most of your community.

Since the release of IP.Board 3.2 (and our addon application updates), we have been hard at work resolving issues reported to us in order to deliver the most stable and secure community software available on the net. We are very proud of our latest releases, yet we are still working hard to deal with any issues that affect you, our customers. Before we start discussing changes you can expect to see in future versions of our addon applications, we wanted to be sure that the current releases work reliably and efficiently across the board (no pun intended). Having said that, however, we did manage to slip in a few new feature changes for the next application releases that we felt you might be interested in hearing about. IP.Content 2.2.2 IP.Content databases and articles have powerful field configuration options, allowing you to create and customize the fields available in every database (including the built in articles system). An oft-used field is the "Editor" field type, which produces a WYSIWYG editor for posting content to the database. You can optionally allow HTML in this field, which is useful when you are posting complex articles on your site. Allowing HTML in this field, however, creates a situation where one administrator may not want to translate newlines in the editor into newlines on the page, while the next administrator may expect just that to occur. For IP.Content 2.2.2 we have changed the "Allow HTML" option for each "Editor" field to a dropdown with the options "No", "Yes (change newlines to HTML line breaks)" and "Yes (do not parse newlines)". If you can use HTML in your posts in the forums, this is analogous to the per-post HTML posting options. If you choose "No", HTML in the field is not parsed at all (this is the safest option if you allow non-trusted users to post content in the database). If you choose "Yes (change newlines to HTML line breaks)", HTML is parsed as you would expect, and additionally hitting the enter key on your keyboard to produce a line break in the editor will translate to a line break in the final output. If you choose "Yes (do not parse newlines)", HTML is parsed, but newlines in the editor will not be turned into HTML newlines. This is useful if you post a lot of HTML content and wish to format in a way that is easier to read, but cannot allow line breaks to show up everytime there is a line break (for instance, if you post HTML tables and do not want newlines between table and tr tags to result in a <br /> tag in the output). If you don't allow HTML in your editor fields, nothing changes for you. If you do, however, you now have one more level of control to ensure your content is produced in exactly the manner you expect. IP.Calendar 3.2.2 I would like to take this moment to point out something here that many of our customers have overlooked recently due to the fact that IP.Calendar has traditionally been packaged with IP.Board, instead of released separately. IP.Calendar is a separate addon application; it is no longer part of IP.Board directly. This means that it can (and will) receive independent bug fix and feature updates, and subsequently it's version number will not always coincide with IP.Board. When we release IP.Board 3.2.3, you will also see a release of IP.Calendar 3.2.2. This is a minor detail, and does not affect the functionality or ability to use the software, however it is important to keep in mind when you are looking at our tracker and trying to determine if a bug fix has been released yet. With that out of the way... we wanted to tell you about a minor, but highly requested change coming with the next release of IP.Calendar. Beginning with IP.Calendar 3.2.2, users who RSVP for an event will be able to un-RSVP for the event themselves, without intervention from a moderator or the event owner. The event owner will still be able to remove any attendee from the list (if given the permission to do so in the ACP), however individual attendees will now also see the delete icon next to their name if they have RSVP'd, allowing them to remove themself from the list of attendees. IP.Nexus 1.3.2 IP.Nexus is continuing to mature as a product, and has proven itself a stable and reliable solution for monetizing your community. We have many great ideas for the next major release of IP.Nexus, however Mark has introduced a change in 1.3.2 that we felt our customers would be interested in hearing about. Beginning with IP.Nexus 1.3.2, you will now be able to issue PayPal refunds right through the IP.Nexus administrator interface. On orders made through PayPal, there will be a refund option available, which will automatically refund the payment from your PayPal account to the purchaser's account. This small but useful enhancement can save you a lot of time when managing your transaction purchases using IP.Nexus 1.3.2. And more to come... Our maintenance releases here at IPS traditionally only include bug fixes. We do this to ensure we are focusing on stabilizing the release without the potential of introducing new complexities or issues, something every developer has to be mindful of anytime a new feature is built. We decided, however, that these few small but useful changes could be introduced safely without compromising the stability of the software, and at the same time allow you some additional flexibility and functionality from your purchases. We are very excited about the changes we have in the pipeline for our future addon application updates and can't wait to start blogging about them, but until then we hope these small additions will tide you over. :smile:

It is important that members be able to follow content that they are interested in within your community. This allows members to keep track of topics of interest, increasing the likelihood they will return to your site, especially when those topics are active and new content is added to them. It is equally important that following such topics is as easy and straightforward as possible. Users do not want to jump through hoops in order to be kept up to date about changes within your site, so it is important that we make it easy for users to follow the content they are interested in, and discover when this content has changes they are interested in. We have made many changes to IP.Board 3.2 (and our addon applications) to improve the process of following content, making it easier and more consistent for your users to stay abreast of changes within your site. 'Like' System In IP.Board 3.1 we introduced a new 'like' system for our addon applications, allowing users to express their interest in content of value to them. This like system was built into the IP.Board core, allowing any application to make use of it. It allowed users to like content publicly or anonymously, permit a way for users to view who publicly liked a given piece of content, and permit users to be notified when the content is updated. While this system was a good start, we felt that it needed some basic improvements in order to be useful and clear for the average user. Firstly, the 'like' system incorporated the methods for subscribing to content - but what if you don't 'like' the content and still want to be notified? Many users would not understand that they needed to 'like' the content in order to receive notifications about it, and indeed would tell us "but I don't like it?". We recognized we needed to address this confusion concerning a core feature in order for it to be useful. Secondly, the like system was utilized for all of our addon applications, but not for forums and topics, providing an inconsistent experience for users when navigating the community as a whole. The process of following a blog entry versus following a topic was entirely disparate and inconsistent, which often leads to confusion for new users, and ultimately leads to the users feeling like they can't trust how a site will behave when they navigate from one area to another. We have taken steps to address these issues in order to provide a better experience for your users in IP.Board 3.2. We have renamed the 'like' system from 3.1 to 'follow' in IP.Board 3.2, providing a clearer association of what the functionality incorporates. Whether you like the content or not, you can follow it (publicly or anonymously) and elect to be notified of changes to the content. You can follow a content page without leaving the page, and you can still view the users who have publicly followed the content. We have also changed over the topic and forum subscription systems to use the new follow system in IP.Board 3.2, providing a consistent experience for users across the entire community, and incorporating some new functionality not available in IP.Board 3.1. The button that allows you to follow a piece of content is placed at the top of the page allowing quick and easy access for users to follow the content. When clicked, a small box will show up allowing you to choose how to be notified (if at all), and whether you want other users to know if you are following the content. In IP.Board 3.1 and prior when you choose to 'Watch this forum', you would first be directed to the user control panel to make your selection, and then redirected back to the forum once you were done. Now, you choose your options right on-screen and your selections are saved through AJAX, allowing you to easily follow content without having to jump through multiple pages to do so. This small convenience should entice your users to more frequently follow content they are interested in, increasing the likelihood of bringing them back to your site when content they follow is updated and they are notified about this. You will notice a small icon next to the follow button with a number - this tells you how many people are following the content. When clicked, you will be able to see who is publicly following the content (the number of people anonymously following the content will be shown at the bottom of the pane to prevent confusion when the button indicates 5 people are following the page, but only 2 are listed because the other 3 are following it anonymously). While this functionality was available in our addons released alongside IP.Board 3.1, as of 3.2 you can now also see which users are following a topic or forum (so long as they are not following anonymously), allowing you to get a better idea of who is interested in the content you are viewing. User Control Panel In IP.Board 3.1, users would choose whether they wanted to receive the post they were being notified about in their email notifications. We have removed this option and simply turned it always-on - an email notifying you that a topic is updated is largely irrelevant without the context that the new post provides. In our research, most users would enable this option (so long as they knew it existed), and there was little value in allowing users to get a notification email that did not contain the post they were being notified about. We have moved the 'Automatically follow topics I reply to' option to the notifications area, as this was a better home for the option. We have also removed the 'Manage Topic Subscriptions' and 'Manage Forum Subscriptions' pages of the user control panel. Because these areas are now covered by the global followed content management area, there is no value in having separate pages of the user control panel for this purpose. Lastly, we have taken the 'Content You Like' area of the user control panel from IP.Board 3.1 and pulled it out of the user control panel into a top-level search view for IP.Board 3.2. Reviewing Content You Follow Another shortcoming of the 'like' system in IP.Board 3.1 that we identified early on was that 'liking' content did not help you easily find and review that content later on. You could elect to be notified of updates to the content, but otherwise you were not presented with tools to easily see if there were updates to the content or review content you had liked to see if you should visit it again. Another issue was that the 'Content You Like' page is hidden away in the user control panel, an area many users do not regularly visit after they have set up their account. We felt that (1) this page was not appropriate to be included in a user control panel, and (2) was important enough to warrant it's own top-level page not hidden away by multiple clicks. You can now access 'Content You Follow' from the user dropdown menu at the top of the page, allowing you quicker and easier access to review the content you are following to check for updates. Additionally, this area is now part of the global search routines (searching, view new content, my content) giving users a consistent experience in reviewing the content they follow. Another important change we have made to this area was to entirely refocus it compared to IP.Board 3.1. In IP.Board 3.1, the 'Content you like' page is entirely focused on allowing you to manage the content. While you can quickly see what content you like, it is presented as a simple list, allowing you to update your preferences for that content (how to be notified and whether you wish to like the content publicly or anonymously). We felt it was much more useful to focus this area on the content itself, while still allowing users to update their preferences as and when they need to. In working to achieve the above goals and resolve the issues we identified, we feel we have created a much more useful presentation of content that a user is following, improving the user experience, and making it easier for users to review content they are following for important changes. The first thing you will notice when visiting your followed content page is that the content is presented like any other search result. You will be able to tell if topics have had new replies that you have not read, preview the topic, and generally interact with the topic like you would in other search areas (such as view new content). You can quickly jump between applications and sections within individual applications using the sidebar like you would in other search pages, providing a consistent way to review content between different applications, and even between different search views on your site. If you need to change your preferences or stop following a piece of content, you can click the 'Display Edit Options' button at the top to toggle the view. When you toggle the mode to allow updating of your preferences, you can now see how you have elected to be notified, whether you have elected to follow the content anonymously, and use the checkboxes at the right of the page to update your preferences. All of the same tools are available here as they were in 3.1, however we have simply shifted the focus for this area to the content, rather than the management of your preferences. We feel that this change will make the system much more useful for users who may need to occasionally update their preferences, but who will frequently wish to see which content they are following has updates they may be interested in reviewing. Content Discovery Our underlying goal with these changes, beyond improving consistency within the community, is to enhance the content discovery process within IP.Board. We have spent a great deal of time with IP.Board 3.2 improving our view new content, user content, and followed content views to make things simpler for users to use, produce more reliable and consistent results when used, and provide better functionality for finding the content they are interested in. Users use IP.Board in many different ways - some wish to return to the site and review topics they are following for changes, while some wish to return to the site and click 'view new content' to see what is new. Through improving the consistency between these areas, improving the options and functionality in these areas, making the available options clearer and easier to use, and ensuring the functionality works reliably and as expected, users can better expect to use your site in a manner most comfortable to their browsing style while having the tools available to them should they wish to start browsing in new ways they may have never used before. We believe the combination of the changes we have made to all of these areas will make discovering new and updated content much easier and much more enjoyable to your users, providing a better experience within your community. As there is a lot to digest in this blog entry, please start a new topic in our feedback forum if you have comments. Be sure to check the What's New in IP.Board 3.2 topic for a running list of announced changes!

The "View New Content" (commonly abbreviated to "VNC" on this community) and "My Content" search routines are important tools for most communities using IP.Board. While we have made improvements to these tools in 3.2 to improve both the reliability of both features, and the interface, we wanted to spend a little time enhancing the functionality of both tools as well. We realize that many of our customers have various suggestions and ideas for these tools, and while we cannot implement every suggestion put forth, we did want to implement some of the most useful and common requests where possible. Search In Titles In IP.Board 3.1, there is a global "Search in titles" checkbox available for all content types when using the advanced search form, however there is then an additional option for the forums content type specifically to search in "titles and posts" or "just in titles". Naturally, this is somewhat confusing and contradictory. Additionally, it limits certain functionality to the forums application alone, functionality that may be useful in other applications. We have resolved this in IP.Board 3.2 by removing the forum-specific option (the second arrow in the previous screenshot) and enhancing the global option to allow you to specify "Search title and content", "Only search in titles", and "Only search in content". This level of customization for searches in any application should help you better find content when you know where the search terms may be contained. Moving and Merging Topics In IP.Board 3.1 we added multi-moderation to the search results page, however many of our more astute customers noticed right away that the ability to merge topics and move topics was a glaring omission. This was not a mistake (there are additional challenges at the code-level with regards to forum permissions for moving topics), however we have overcome these limitations for IP.Board 3.2 and are happy to announce that you will now be able to merge and move topics right from the search results screen. Sorting and Ordering User Content In IP.Board 3.1, you are unable to sort or order a user's content, forcing you to review content from a user in a date-based fashion. While there is nothing immediately wrong with this approach, we have enhanced IP.Board 3.2 to now allow you to sort and order user content in any fashion supported by the application or content type. We expect that this small but useful change will help you better find content individual users have submitted to the community. Default VNC Method A minor change, but one we have seen requested many times on these forums, we have added an ACP setting to allow the administrator to define the default "View New Content" method. You can now specify for your new users whether they should see "Content I have not read" by default, or "Content since my last visit". Users can still overide this when viewing the VNC results, but now you will be able to define the default that you feel is best for your community. Content Filters for VNC In the previous screenshot for "My Content", you will see that there are filters to drill down to "Topics I participated in", "Topics I started", and "Posts I made". This is a useful feature when viewing a user's content ... so we decided to expand it to the VNC search results as well. The option "Posts I made" is not relevant to view new content (if you made the post, it will never be new of course), so this option is not present. However, you can now filter VNC results down to "Topics I participated in" and "Topics I started", allowing you an easy way to review new content on the community in topics that you are interested in. When combined with the new filter "Content I am following", you have a granular level of control over your content discovery process never before seen in forum software! Forum Filtering in VNC Another oft-requested feature, we have added the ability for user's to filter which forums they wish to see results from in the VNC search results screen. Under the 'Other Filters' area in VNC, you will have an option "Filter by forum", which will launch a modal popup allowing you to specify which forums you wish to see content from. These filters are remembered (between sessions and across separate computers), with an indicator to let the user know when the filter is being applied. We Hope You Enjoy! While we realize that these changes do not necessarily satisfy everyone's wishes for VNC and My Content in IP.Board 3.2, we believe they will help resolve some of the most common limitations in the system, giving you greater flexibility and control over your searches. These changes should help members better find the content they are looking for and interested in, increasing activity on your site, and increasing probability of return for new users finding their way around. We will of course continue to improve VNC and all areas of IP.Board based on our client feedback. Feel free to comment on this blog entry below or, if you have feedback unrelated to this blog entry, start a new topic in our feedback forum. If you have feedback related to changes beyond what this entry is referring to, please start a feedback topic. Be sure to check the What's New in IP.Board 3.2 topic for a running list of announced changes!

With each release of IP.Board we try to give attention to every area of the software that our customers care about. This is a challenge, of course, because all of our customers have different needs and priorities. Some users want us to make interface improvements, while some customers want us to make it easier for them to edit the interface themselves. Some customers want new features, while some customers want us to cut out "bloat". Every customer has different requirements of the software, and those requirements are important to us as they help us to improve and focus the product for you. While we do not always discuss every change we make in each release, we did want to take a moment to let our international users who translate the software via language packs know that we have made a few minor improvements that we think you'll be interested in hearing about. We realize this blog entry may not be as exciting as some of the previous entries, but rest assured that those customers who translate the software will benefit from these changes, and thus these details are important to share. IPSLib::getAppTitle() As mentioned in our recent Search/VNC Interface Improvements blog entry, we have taken some time to implement use of IPSLib::getAppTitle() throughout the search interface as appropriate. We are also updating all other areas of the software that display an application name to ensure it uses this same method, allowing us to be sure that the application title, as displayed, is appropriate based on the language pack in use. For our English-speaking customers or customers with only one language pack installed, you can still edit each application in the ACP to change the application title without having to go into the manage languages area of the ACP. Simultaneously, our international translators can specify application titles in their language packs, and those translated titles will instead be used, allowing multi-language sites and distributed language packs to better customize the display for each language. If a lot of this doesn't make sense or matter to you, don't worry about it. Ultimately this change will help translators better customize their language packs, and as this is important to our international users we are happy to work towards consolidating the application titles for this purpose. Translatable ACP Menu An issue that has long-plagued our international users has been the ability (or rather, inability) to translate the left hand menu in the IP.Board ACP. The strings that are used to generate the links in the left hand menus of the ACP are stored in XML files, which made it difficult to allow easy translation via the language system. We are happy to announce that we have overcome this limitation in 3.2, allowing translators the ability to fully translate this left hand menu in their language packs. Furthermore, third party applications can optionally make use of this new system, but will still function just fine if they don't. Within the XML files that store this left hand menu system, a language key can now be specified. Core applications store these language strings in the global admin language file, while individual applications can provide a new language file which will be auto-loaded as needed for this purpose. Translatable ACP Restrictions Similar to the reasons that caused translating the left hand menus of the ACP to be difficult, ACP restriction details are stored in XML files and were not previously translatable. We have applied the same change just discussed for the left hand menus to the ACP restrictions so that they are now translatable as well. While the core applications store these language keys in the members_admin_restrictions language file, third party applications can (optionally) include these strings in the same additional language file they would use for the left hand menus. Small Improvements Of course we are also working hard to ensure any text that is not already language abstracted is properly put into the language files so that translators can adjust the text for their own languages. We are also trying to consolidate some strings that are pieced together presently to instead use the PHP sprintf() function. This should help when translating the software to languages that might have noun or verb placement different from the English language. We have moved the settings to define the prefixes for polls, moved topics and pinned topics to the language system. Moving them to the language system will not only allow regular admins to still edit these strings, but allow translators to adjust them as needed per-language pack. And while we have not completely overhauled the language system in this release, we have plans to improve the language system as a whole in a near-future release. We recognize some of the issues our international users face using the language system (such as importing language files for individual applications) and we want to improve it for you to make using the software easier and more consistent. We hope these small steps will help you to better share language packs with the community in the mean time, while we plan bigger improvements in the future. Feel free to comment on this blog entry below or, if you have feedback unrelated to this blog entry, start a new topic in our feedback forum. Be sure to check the What's New in IP.Board 3.2 topic for a running list of announced changes!

Moderators fill an important role on your community: they help to maintain order, they help to filter content out that should not be made available, and they help to assist new users and keep the site moving in the right direction. It is important that moderators have the tools they need made available to them in a manner that is easy to use, and easy to understand. While the moderator tools in IP.Board are robust and powerful, we felt we could improve upon the existing functionality to make using and finding these moderator tools easier. A common request over the years has been for a moderator control panel to be added to IP.Board. IP.Board 3.2 will now feature a new moderator control panel where most of the moderator tools are now consolidated into one area. No longer will your moderators need to jump all around the site to do their daily tasks. For moderators, accessing the moderator control panel is a click away on any page: (Please remember that all screenshots you see are of an early pre-release build and are very much subject to change before the final release). (Please note also that we are aware of the bugs you see in any of the screenshots below - we will address them before release ;) ) Homepage Upon entering the Moderator Control Panel the first thing you will see is a quick member lookup form. This form of course uses the member look-ahead feature to assist you with finding the member you are looking for, and clicking a result will take you to the screen where you can edit or warn the user, add a note to the user's account, and review past warn logs (see our previous blog entry on the new edit member page for more details and screenshots). Reported Content If the moderator has access to manage any area of the report center, they can quickly see from this tab the open reports from all areas they can manage. There is a link to the full report center at the bottom of the page, where they can perform additional duties, review closed reports, or multi-moderate reports. It is important to note that the report center now shares this moderator control panel wrapper, so if you click to view the full report center, you can easily return to any other area in the moderator control panel afterwards. Unapproved Content One of the most common duties a moderator has to deal with is approving content that is pending approval. Previously, in IP.Board, you would have to visit each forum individually to approve content that was not yet visible. Similarly, if you can moderate the calendar, or the download manager, or any other application, you have to visit that application directly and use it's own moderator tools separately. This creates a disparate and inconsistent experience in the software for moderators, forcing them to learn how to use each moderator tool and find each moderator area separately. As of IP.Board 3.2, these moderator tools are now combined into one interface to make it easy to find content requiring approval, and easy to deal with said content. While you can still manage the topics pending approval within each forum, and approve calendar events directly from the calendar, you are not forced to go hunt these things down if you don't wish to. You will note in this screenshot that there are button links on the title bar to access: Events Pending Approval (from Calendar), Posts Pending Approval, Topics Pending Approval, and Files Pending Approval (from Download Manager). All applications in IP.Board can easily plugin to this new system in order to allow it's content pending approval to be managed in a single location. Indeed, we plan to have plugins for Gallery and Blog also available with their associated IP.Board 3.2 compatibility releases. The content on these tabs can also paginate, in the event there are many items pending approval. Managing Members (please ignore the obvious formatting issues in this screenshot - they will be fixed in the final release) We have created a page in the moderator control panel where you can now manage your members from a central location. You can see here that we have tabs for viewing banned members, suspended members, members on moderator queue, members who currently are restricted from posting, members who are banned from chat, and recently issued warnings. While banned members and members banned from chat cannot be managed from the front end at this time (banning is currently primarily an ACP-only option), for other tabs the restriction line is linked to the warn panel so that you can quickly redact post restrictions, suspensions, and similar punishments should you need to. The recent warnings tab allows you to review all warnings and notes left by your moderators quickly from one page. While there are logs available in the ACP for this purpose as well, you can now review these warnings from the front end to ensure your moderators are not abusing their powers. Your other moderators can also access this page so that they are kept in the loop of all member actions that are occurring on the site. IP Address Tools The IP Address tools available in IP.Board for moderators have been moved to the moderator control panel to provide a single place for all moderator actions and tools. The IP Address tools work similar to those available in IP.Board 3.1 and earlier versions (they are currently available in the user control panel in earlier versions of IP.Board). Announcements As with the IP Address tools, we have moved the announcements management into the moderator control panel to provide a single point of reference for all moderator tools and actions in 3.2. Deleted Content We have made some exciting changes to IP.Board 3.2 with regards to deleting posts and topics that we think you will enjoy. Firstly, the old notion of a "trash can" forum is gone. Your trash can forum will still exist upon upgrade, of course, and all of the content will still be available there. You will be able to prune it, delete the topics/posts, and perform any other functions to the content within this forum at will just as you can now. However, this forum will no longer be "special", and any settings and options related to the trash can forum will now be gone. Instead, when you delete a post or topic, a flag will now be set on that content in the database, but it will be left right where it is otherwise. It will be removed from view just as if it had actually been removed from the database, so for all intents and purposes, deletion still works the same way for moderators on the site. However, by keeping the content within the database temporarily, you and your moderators can now properly "restore" it from the moderator control panel. If you choose to restore deleted posts or topics, that content will be put right back in place as if it had never been removed. A task in IP.Board will run periodically to remove deleted content permanently after a preset number of days to ensure your database does not fill up with content that was purposefully deleted. We feel these changes will provide for a more natural flow of events for moderators, allowing them to restore deleted content properly without having to move and merge topics and posts as they do now using the trash can. While you can ignore deleted content and allow the task to remove it automatically, you can also permanently delete it from the moderator control panel without waiting if you wish. Modification Author Note: Developers who write modifications that retrieve posts and topics will need to make adjustments in their work with the release of 3.2 to ensure you do not mistakenly return content that is deleted. New methods have been added to class_forums to assist you with generating the appropriate queries, and a new class has been made available that can return posts for you easily. Here is an example of returning 5 deleted posts, for instance: $this->library = new $classToLoad( $this->registry ); $this->library->setPermissionData(); $posts = $this->library->getPosts( array( 'postType' => array( 'sdelete', 'pdelete', 'oktoremove' ), 'sortField' => 'post_date', 'sortOrder' => 'desc', 'parse' => true, 'getCount' => true, 'limit' => 10, 'offset' => $st ) ); $total = $this->library->getPostsCount(); $classToLoad = IPSLib::loadLibrary( IPSLib::getAppDir('forums') . '/sources/classes/topics.php', 'app_forums_classes_topics', 'forums' ); Yes, that's really it. The library is quite flexible and should aid you in converting your modifications to 3.2, reducing duplicate code in your modifications, and reducing potential bugs with your code, especially as new features are added to IP.Board moving forward. In Closing... We have spent some time consolidating moderator tools and making them easier to understand and easier to use for IP.Board 3.2. All of the pages you see in the screenshots above allow third party applications to easily plugin to them so that even your third party applications can be managed from this single interface (note that third party applications can also add their own sidebar tabs, should they have moderator tools that do not fall under the existing generic categories). Also, while this was not discussed above, moderators will only see and be able to access tabs that they have permission to access. In my screenshots I am logged in as an admin/super moderator so I can access all tools, but the IP address tools (for instance) will not show to regular forum moderators. As new moderator tools are made available in IP.Board, we now have an obvious home to place them so you'll never have to hunt them down in the software again. We hope you like these changes, and that they make managing your site easier than ever! Feel free to comment on this blog entry below or, if you have feedback unrelated to this blog entry, start a new topic in our feedback forum. Be sure to check the What's New in IP.Board 3.2 topic for a running list of announced changes!

It is not an uncommon task that you or a moderator might need to edit a member of your community. Whether the member has uploaded an inappropriate personal photo, posted links to a competing website in their signature, or needs to be temporarily suspended so they can "cool down", managing members is a common task that moderators carry out on every community. We are happy to announce that we have improved this functionality in IP.Board 3.2.0 to make managing your members from the front end easier than before. Some Background In IP.Board 3.1.x, there is an "Edit Member" for those with permission on every user profile, allowing you quick access to a page where you can remove inappropriate content quickly without having to login to the ACP. On the profile as well is a link to view the member's warn logs, issue a new warning, and reduce the member's current warn level, and these same links are available on each one of the member's posts in the forums. The interesting thing we have determined through various feedback sources is that many of our customers are not even aware this functionality exists in IP.Board, because it is not obvious that you can click the + and - icons next to the user's warn level where-ever it is displayed. IP.Board 3.1.x additionally allows administrators to leave notes on the user's account, but only through the ACP. These notes are then displayed in the warn logs along with any other warnings the member has received. These tools are very powerful and very useful, but also very disconnected and spread about the software, while all serving the same general purpose: managing your members. Combining The Tools In IP.Board 3.2.x, all of these tools have combined into one easy to use page. Whether you click on the user's warn log link or the edit member link, you are taken to the same page. From this tabbed page you can do all of the same things you could previously: Issue a new warning (or warning reduction) Edit the member's profile details View stored warn logs and notes Add a new note to the member account You will note in the list above that we have added the ability to leave a note on the member's account to the front end of IP.Board now, removing the requirement for an admin to login to the ACP to leave such notes and expanding the ability to moderators who previously had no ability to leave notes. Through this combined tabbed interface, you can now manage all aspects of the member from one area, making it easier than ever to deal with members that need to be dealt with, without making you skip from page to page to do so. We believe that these changes will also better showcase features in IP.Board that many customers were not even aware were possible, such as banning or suspending the member from the front end interface. Feel free to comment on this blog entry below or, if you have feedback unrelated to this blog entry, start a new topic in our feedback forum. Be sure to check the What's New in IP.Board 3.2 topic for a running list of announced changes!

Moderating your community is an important function that is carried out not by administrators alone, but often by community volunteers. For this reason, it is important to make moderating your community as easy as possible. To that end, we have made improvements to moderator capabilities in IP.Board 3.2.0, and in this blog entry we will describe some of those changes that relate to the report center specifically. The report center is a central container that all reported content is sent to, allowing moderators a single destination to review reported content, and allowing moderators to communicate privately about the content that is reported. This functionality works well and has streamlined dealing with reported content since it was first introduced in IP.Board 3.0, but we wanted to take this time to make some minor improvements to further enhance the capabilities already available. Open Reports Only Beginning with IP.Board 3.2.0, when there are open reports in the report center, ONLY those open reports will be displayed. It can be confusing to visit the report center and see a list of 200 reports when there is only 1 or 2 to deal with. We have reduced this unnecessary clutter to allow you to focus only on what needs your attention. When this happens (i.e. when there are open reports the moderator can access), a message is displayed at the top of the page indicating that this is the case, along with a link to view all reports. If there are no open reports, all reports will be shown as they are now in IP.Board 3.1.x. Are There Updates? We have also implemented topic marking tracking in the report center, allowing moderators who visit the report center to quickly identify which reports have had new activity since they last viewed the report. Additional reports from other users regarding the same content and comments made by other moderators all count as new activity, so you can now more quickly identify reports that may have further updates and may need to be reviewed again quicker than before. Many, Many Performance Improvements While working on the report center we reviewed resource usage, we profiled the database queries and PHP code execution, and we found many ways to improve performance without removing functionality. We have removed some unnecessary database queries, we have cached some of the data into cache stores (which can be stored in memcache and similar external caching engines with IP.Board), we have changed some database queries to retrieve the needed data in a more efficient manner, and we have removed and/or refactored code that we found was slower than optimal. The end result is that the report center has received many performance improvements that, combined, allow it to function faster and use less resources on your server. Improved Access Configuration Feedback we have received regarding the report center has indicated that it can be confusing or difficult to configure the access permissions for each individual plugin in the ACP. At present, you might create a new moderator group for instance, and upon doing so you will next need to visit the report center section of the ACP and edit each plugin one by one to configure the permissions for this new group (whether they can submit and/or view reports for each plugin). This functioned fine, but we recognized we could do a better job of making it easier to configure these permissions. While we have not removed the ability to configure permissions in the report center plugins as you can in IP.Board 3.1.x (you may, for example, wish to remove all access to a specific plugin temporarily and it is easier to edit the plugin in that case than it is to edit each group individually), we have extended permission configuration to the group manager in the ACP. What this means is that when you edit a group in the ACP there will now be a new tab allowing you to set the permissions for each report center plugin from the group manager, quickly and easily. This is especially useful when you are creating new groups, as you can now specify the report center permissions for the new group right from the group creation form. Conclusion We believe these changes will help make managing reported content easier. We have also pushed the report center inside our new moderator control panel....which we will discuss in our next blog entry. Stay tuned! ;) Feel free to comment on this blog entry below or, if you have feedback unrelated to this blog entry, start a new topic in our feedback forum. Be sure to check the What's New in IP.Board 3.2 topic for a running list of announced changes!