Jump to content
View in the app

A better way to browse. Learn more.

Learn more

Invision Community Blog

Show all categories

IP.Board 3.2.0: Tagging and Prefixes

As work progresses on the new interface for IP.Board 3.2.0, we can now go into some more detail about the new functionality that's already been added.

I must of course stress that the only screen shots I can show are closely cropped to not reveal too much and please keep in mind that IP.Board 3.2.0 is still very much in development so some details may change before the public reveal.

Tagging
An incredibly popular request has been the ability to 'tag' content with special keywords and then find other content tagged with the same keywords. This gives a secondary way to organise data beyond the administrator defined 'categories' and 'forums' set up.

We're very pleased to say that this functionality is now available in IP.Board 3.2.0 and we've spent some time to make sure we have a robust and thoughtful implementation.

A tale of two modes
Our tagging implementation is available in two modes:
- Open Mode: Where allowed, your members can create new tags on-the-fly and add them to content.
- Closed Mode: Where allowed, your members can select from pre-defined tags and add them to content.

We feel this gives you the best of both worlds. Some communities may not need a full tagging system, but you may wish to enforce secondary categorisation via pre-set tags that you as the administrator control. Alternatively, you may wish to throw the doors open and let your members tag their content as they see fit. The choice is yours!

As you'd expect, this feature comes with many controls. You can define the minimum and maximum number of tags per item, the minimum and maximum length of each tag and more. You can even override the pre-defined tags on a per app (and thus per-forum) basis giving full control over the tagging system.

Prefixes
Another very popular feature request is the ability to assign a custom or pre-defined prefix to a piece of content such as a topic or blog entry. In many ways this works very similarly to tagging so we've created a single system that allows the use of a tag as a prefix!

As you'd expect, you can disable prefixes and tagging on a per member or per group basis giving you complete control over your members' permissions.

You can even set the system to be used solely for prefixes by limiting the number of tags to one and enforcing the use of pre-defined tags. It really is a very flexible system.

This screen shot shows how you add tags when creating a new topic. This is in 'open' mode with prefixes enabled.


This shows a topic that has been tagged and a prefix added.


This shows the search page which is shown when you click a prefix or tag.


This shows the Admin CP settings page.


This shows the per-forum settings.


We hope you enjoy this new functionality. We'll be rolling out tagging in our applications once IP.Board 3.2.0 has been released!

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!
  • 29,983 views
Matt

IP.Board 3.2.0 Dev Update: Shared Media

The ability to easily share content within your community is important to your members. If your members submit an image to Gallery, it's quite probable they'll want to include that image in a post at some point, and there needs to be an easy way to do this. Likewise, if your members submit a file to the Download Manager, they may want to link to that file when replying to a blog entry. There are many instances where it is crucial that members be able to quickly and easily share the content they have contributed to your site within the community, and the old-fashioned method of copying and pasting a link into their post just doesn't cut it anymore.

This is functionality that many of our members have requested, many times over, and that we have been eager to build into the software. It was important for us, however, to build this in an extensible manner that allows us to include support for all of our applications without having to reinvent the wheel each time, and without having to manage the functionality individually per-application. Users expect a combined and intuitive interface that allows them to share all of their content easily, without having to visit their content pages and copy links and other data manually.

IP.Board 3.2.0 will introduce a new shared media manager to fulfill this important need.

As always, the screenshots shared in this blog entry are of a development build of IP.Board and may not represent the full and final look that ships when the next release is declared final. What you see below is subject to change up until IP.Board 3.2.0 is released.


Sharing Media

With the new editor in IP.Board 3.2.0, we have built a plugin that allows your members to access and share their previously submitted content.



When you click on this button, your shared media popup will open allowing you to browse, search and include media you wish to include in your post.



As you can see here, you can include media from many areas of the board. Because we have used a plugin system, not only can we expand capabilities in the shared media system for our own applications, but third party modification authors can also easily tie into this popup to include their own media to be shared.

Each plugin defines how it presents its shareable content. Here are screenshots of the existing areas






(Gallery areas are still under development with the continuing development of Gallery 4.0, so these areas are not yet finished and presentable)

You will see pagination at the top and bottom of the templates. This pagination uses AJAX to provide the next and previous pages without requiring a page load or a messy iframe solution.

You will also see a search bar at the bottom of the window. The search feature also utilizes AJAX and is useful for finding content you wish to share without having to page through all of your previously shared media.



Your search value is remembered when you click through tabs, but you can easily reset the tab by clicking the "Clear Search" link next to the search form. This way if you search for an attachment and don't find it, but remember that you may have submitted it to the download manager instead, you don't have to manually search again after you have switched tabs.

When you click on an item it is added to the editor as a bbcode. Once you are done, you can click the "Finish" button to make the modal box go away and continue with your post.

Upon submitting the post, IP.Board will verify you have permission to share the content you are attempting to share (i.e. to prevent a sneaky user from sharing someone else's gallery image or calendar event), and then will save the post as normal. When displaying the post, IP.Board will call each plugin that was used to let the plugin determine how to parse and display the content you are sharing. In this screenshot, I have shared a calendar event, an attachment, a blog entry, and a download manage file (in that order).



Again, each plugin can determine how to display its content. I would like to re-iterate that these are early preview screenshots and the display of our content may change between now and release, but you can see how sharing media in IP.Board 3.2.0 is a much richer and easier experience than in earlier versions, providing a much nicer end result for your contributors and the users browsing your community alike.

We have a lot of ideas for taking this new feature even further in future versions, but we felt our initial focus would best be served by ensuring the sharing process was easy for all.


What About Permissions

Permissions were a complicated subject when determining how best to handle sharing media across applications. Can I share private calendar events I have submitted? What happens if I share a gallery image in an album that a guest cannot view? What happens if I delete a blog entry that I previously shared?

These are all very pertinent questions that we had to take into account when building this new feature. While the plugin approach this system takes allows us to adapt each plugin as needed to best handle its permission checking routines, we have decided that a simple approach for this first release was the best solution. You can only share your own content, first of all. Moderators can share content of any user if they manually type in the bbcode, but will not be presented with it in the popup (this is necessary so that if a moderator edits your post the shared media will still be allowed).

If you delete the destination content that you have shared, the bbcode will simply return an empty string and nothing will show in the post where it was used.

Whatever you share will be viewable in the area you share it in. You cannot share content that is inherently private or not approved (i.e. a private calendar event, or a blog entry that is not published or is pending approval), however you can otherwise share any of your content that you wish. It is, after all, your content and you could just as easily download a file and upload it elsewhere to link to, or copy and paste a blog entry's content into the post form. If you share that content, what you see in my previous screenshot will display to anyone that can view the page you shared the content on. For instance, if you share a calendar event that a guest cannot see in a topic that a guest can see, the guest will see the parsed calendar block as in my previous screenshot. This is only a preview, and as mentioned above, there would be nothing stopping you from copying and pasting the calendar event contents to the topic anyways.

We opted against complicated permission checking when displaying pages with shared content for a few different reasons:


Most users are not going to know your permission configurations and would become confused hearing that content they shared is viewable by some but not others As mentioned, users can simply download files and upload elsewhere to link to, or copy and paste the destination contents Complicated permission checking routines would negatively affect the page loading speed, as there are more resources needed to verify all of the different permission permutations possible across all applications Content caching would potentially cause issues with shared content. While we could account for this in our applications, it would be more difficult to account for this in third party applications that can also utilize this new system.



Some Other Details

Firstly, this new media sharing tool is available anywhere that the new editor is available. That means you can share download manager files in calendar events, gallery images in blog entries, and forum attachments in download manager submissions. There are obviously a lot of possibilities here, and we expect that as third party applications embrace this new feature you will be able to share even more of your community content anywhere across your community.

The shared media tool is a custom bbcode, like all of our other bbcodes. This means you can control its use just like any other bbcode, including limiting the feature to select user groups (or disabling it entirely). You are not required to use this new feature if you don't wish to, and you can restrict it any way that you wish.

The system is entirely based on a plugin callback approach allowing third party developers to hook into it easily. I can envision sharing "issues" from tracker in forum posts, or items from other popular modifications throughout your site. The plugins are relatively simple to create and we expect to provide documentation of the system to developers shortly following the 3.2 release. It is important to note that plugins can each utilize their own permission checking and display routines, however they can also utilize our basic layouts as shown in my previous screenshots. There is a lot of flexibility in this new system for developers.

And lastly, this is only the first version of our new shared media tool. We expect to enhance and bring further capabilities to this feature in future versions of our software.


Wrap Up

We know this is a tool that everyone has been waiting for and we appreciate your patience. As always, we wanted to do this right the first time, rather than provide similar capabilities through each individual application, increasing development time, maintenance, resource usage, and so forth. By including this feature in IP.Board 3.2 we will now have a strong central framework that applications can utilize, providing for a more consistent and smoother user experience for all.

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!
  • 16,899 views
bfarber

IP.Board 3.2.0: Front-end Changes Afoot

While we aren't quite ready to show off IP.Board 3.2.0 in its entirety yet, I wanted to talk a little about what you can expect from our new front-end skin - our thinking behind development, areas we've focused on, etc.

Goals
Before development commenced, we created a list of goals that we aimed to meet. These include:


Improving the experience
We've been accused in the past of having a 'clunky' experience in some areas, so we've worked hard to improve the user experience in key areas. Some of these are usability changes, while others relate to reducing clutter on the screen or relocating elements.
Making the skin easier for 3rd party developers (and ourselves!) to use
Another focus was on making our skin - particularly the CSS - easier to use, for skinners, developers, even our own team. We've found that as new features were added, whole blocks of existing CSS were copied, pasted, then tweaked to suit the new feature. This creates some resource overhead, not to mention more work for skinners and developers. To remedy this, we've begun introducing a new approach to our CSS: more modular units that can be reused and combined easily to make many interfaces easy to implement. This will be gradually introduced throughout the skin as areas get updated in future point releases. Already, we've been able to remove large sections of old CSS as the updated areas make use of the new modular CSS.
Modernizing the display
It's been 3 years since we first began working on IP.Board 3.0, and the internet has come some way since then. We decided it was time to refresh the visual style of our default skin. While it will still be clearly recognizable as IP.Board, we've added some polish to the overall style, and made more use of technologies such as CSS3.


Areas that we've focused on
A huge number of areas have had minor tweaks here and there, too numerous to list here. But other areas have had significant updates, including:

Global wrapper
This is probably a given, since it influences the rest of the skin. Parts have been made more streamlined, with a new member & moderator bar, a new application bar that now supports as many apps as you choose to install, inline sign in and more.
Forum view
While the basic concept of listing topics inside a forum hasn't been altered, we've made big updates to the presentation, including rethinking the display of non-essential items and a new, friendly topic preview.
Topics view
As with forum view, the basic structure has not changed (familiarity is a good thing!), but numerous elements have been tweaked, changed, and tidied. All in all, reading topics should be a more pleasant experience for your users.
Profile
Our profile view was in need of overhauling, so that's what we've done! It now sports a vastly cleaner display while keeping all the relevant information accessible. Data from 3rd party apps is easily incorporated without fear of breaking the tab bar as in 3.0. In addition, we have merged profile comments and status updates, giving members a modern 'wall' in their profile.
Calendar
We've previously posted blog entries about new features you can expect to see in Calendar, and to go along with that, we've completely revamped almost every aspect of the calendar display - hopefully making it a more inviting place for your community to share events.
Registration
We identified some time ago that our registration routine was less than optimal, especially when considering communities that make use of IP.Nexus, with its ability to sell packages at registration. To remedy that, we have rethought the registration routine, to present Nexus packages in a better way, get rid of unnecessary steps along the way, and above all make it quicker for your prospective members to register
Moderation
We will elaborate on this point at a later date, but we have made the various day-to-day moderation tasks easy to access and use - a boon for your moderating team.
View New Content
Our View New Content area has steadily grown more complex as additional sorting and filtering options have been introduced, so we felt it was time to improve the display of those options to make it all a bit easier to use.
Posting Screen
We've updated the new topic/reply screen to be more streamlined, as well as integrate some new goodies that we'll talk about later.
Redirect Screens
The old-fashioned 'you are being redirected' screens are now a thing of the past. Every area has been updated to use a new inline notification display, which doesn't get in the way and fades after a few seconds.



Teasers

To whet your appetite, here's some teaser shots of the new front-end. We'll be gradually showing more as we discuss new features in later blog entries.





While these are just teaser shots, over the next few weeks we will start posting blog entries about new features on the front end that will also contain screenshots of new skin elements so keep an eye on our blog for more updates!

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!
  • 10,324 views
Rikki

IP.Board 3.2.0 Dev Update: Applications Improvements

Parts of this entry may only apply to those who create applications for IP.Board. Feel free to skip the sections that may not interest you.

In my last blog entry I mentioned the improvements we have made for the hooks system, in this new entry I'll talk about the changes we have made for applications.


Disabling an Application

When an application is disabled from the ACP a check is performed on all the enabled hooks that have it listed in their requirements and a warning will appear at the top of the page to warn the admin about disabling them.




Application Tab Permissions

We have received several requests from our customers in both the feedback forum and tickets and we decided to include it in IP.Board 3.2, you will now be able to specify for which groups the application tab will appear on the public side! The setting to control this is an easy multi-dropdown menu, furthermore we have renamed the setting "Hide Tab" to "Hide for all current and future groups?" and we have moved it under a new permissions tab.




Global Caches

As we have already mentioned for the hooks (see previous blog entry) we have added support for the "Global Caches" system in the applications too, this will allow modification developers to also specify for applications which additional caches should be loaded on each page together with the default ones. For example we will use this in our IP.Nexus application and specify the "nexus_ads" cache which is currently loaded separately on each page when the application is enabled.




Updates Checker

Unlike hooks the applications had no way to check for updates, we have now added 2 new settings "Website" and "Update URL" which are used in the same exact way as the one for the hooks (see the previous blog entry).
The updates available will show as a purple badge similar to the ones for the hooks and a counter of the updates available will show up at the top of the page as well.




Sphinx Cronjobs

When Sphinx is enabled we often have customers confused on how to setup properly the cronjobs based on the applications installed. To solve this issue we have added a menu for the old Sphinx button which contains the new "Build Cronjobs" tool. This tool will ask you to input the path to your sphinx.conf file and will then provide the proper cronjobs based on the applications installed. Furthermore, the tool will also warn you about a possible wrong path as you can see in the screenshot below.




Export Tool for Developers

Currently the information.xml file included in the xml folder of each application needs to be written manually, we have now included a tool that allows developers to easily create such file from the ACP without having to write it manually.



This is an example of the file that will be exported from the Members application:


<?xml version="1.0" encoding="UTF-8"?> <information> <data> <name>Members</name> <public_name>Members</public_name> <author>Invision Power Services, Inc.</author> <description>Manage members and groups</description> <disabledatinstall>0</disabledatinstall> <global_caches/> <website/> <update_check/> <templategroups> <template match="exact">skin_messaging</template> <template match="exact">skin_mlist</template> <template match="exact">skin_online</template> <template match="exact">skin_profile</template> <template match="exact">skin_ucp</template> </templategroups> </data> </information>

Please note that the option "disabledatinstall" will always be 0 by default unless a previous information.xml file is available and it contains a different value which will be retained. The same goes for the templates, you need to add them manually but as long as you have them in a previous xml file the export function will keep them in the new one as well.


Conclusions

As you can see from the previous screenshots we have not only added new features but also the layout of the pages has been updated as well for better usability, for example you'll notice that the applications not installed are now listed on a column on the right instead of at the bottom where it was harder to see them.



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!
  • 8,882 views
teraßyte

IP.Board 3.2.0 Dev Update: Hooks Improvements

Parts of this entry may only apply to those who create hooks for IP.Board. Feel free to skip the sections that may not interest you.

As mentioned in our previous blog entries about IP.Board 3.2 we are focusing not only on adding new features but also on improving some of the current areas as well. In this entry I'll talk about the changes we made for hooks.


Global Caches

Several times it might happen that a hook requires a specific cache on every page (like our IP.Chat hook "Chat Tab Count") but there was no way to do that apart from running a separate query on each page load. In IP.Board 3.2 we have added support in the hooks for a system called "Global Caches" which allows modders to specify a set of caches that the board will always load together with the default ones. Such caches can be selected in a new tab we have added in the hooks form and will help reduce the number of queries run.




Hook Requirements

Already in IP.Board 3.0 hooks had 4 requirements fields and nothing changed in 3.1: min/max PHP version and min/max IP.Board version. What if the hook was for a third party addon or even one of our official addons? Was that enough? We felt that the answer was no and thus we have implemented an enhanced applications requirements system.

With the new system you can now specify any installed application as a requirement while creating a hook as well as the usual PHP version. Furthermore, you can specify a minimum and/or maximum version or leave both fields set to 0 to only require the application to be installed.


In the example below the hook will require a PHP version between 5.3.0-5.3.5, a minimum IP.Board version of 3.1.1 and IP.Gallery installed.



When installing a hook that doesn't meet the requirements, a warning badge will appear before the title and a count of all the warnings for enabled hooks will be shown as well above the list.



Clicking on the warning badge will redirect you to the hook requirements page where each requirement has its own badge (ok / error) and as you can see the minimum PHP version requirement is not met.



You will also see the same requirements page when trying to enable a hook already installed that doesn't meet the requirements. In this case however you'll have the option to skip the requirements check and still enable the hook regardless.




Updates Checker

The update checker for the hooks has been enhanced and now the code can retrieve an 'update url' as well if there is an update available, previously the system simply used the hook website value if one was provided but what if the site got moved or if the modder wants the admins to go to a specific url to get directly the update rather than viewing the main page of their site?

In the old IP.Board 3.0 & 3.1 versions the update script simply returned a 0 value if there was no update or 1 for an update available, now if an update is available IP.Board will explode the string on the character | and take the second value in the array as the url. An example is available below:


1|http://www.google.it/ Additionally IP.Board 3.2 will now add also the IP.Board long version in the update URL together with the hook long version, in this way the update script can return only 1 for older versions or add also the new 'update url' variable for IP.Board 3.2+:

IP.Board 3.1: http://www.domain.com/checkHookUpdate.php?hookKey=test_hook&version=10000 IP.Board 3.2: http://www.domain.com/checkHookUpdate.php?hookKey=test_hook&boardVersion=32000&version=10000


Install a New Hook

As you may have already noticed from the screenshot above the "Install a New Hook" form is now a tab and you won't need to scroll down to the bottom of the page anymore, especially when you have a large list of hooks installed.




Conclusion

Many other small tweaks and optimizations have been implemented in the layout as you can see from the screenshots and also in the code, finally all the enhancements discussed above are available in the Hook Details page as well which contains a summary of everything concerning the hook.





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!
  • 9,665 views
teraßyte

IP.Board 3.2.0 Dev Update: ACP Restrictions Enhancements

IP.Board allows you to set "ACP Restrictions" which allow you to restrict which administrators have access to which areas of the Admin CP.

The two main pieces of feedback we hear about the ACP Restrictions system are:
- It should be easy to set up and manage ACP Restrictions, without having to check lots of boxes, but still remaining the high level of control of the current system.
- Administrators should only see the areas of the Admin CP that they have access to. Administrators should not get a "permission denied" error from clicking a link.

We recognise that particularly with addons such as IP.Content and IP.Nexus which mean the Admin CP is controlling many different sensitive aspects of your community, it is important that using ACP restrictions is becoming more common, and in IP.Board 3.2, we have improved on both these areas.


Setting Up

Setting ACP restrictions is granular - you give access to the application, the module and then areas in that module.



In previous versions of IP.Board, to give access to every area except one, you would need to check every checkbox. Now in 3.2, checking a checkbox which has "children" will automatically select all children. So if you want to give access to all areas except the "Forums" tab, you simply need to check 1 checkbox on each tab except Forums. On the other hand, if you want to give access to just the "Forums" tab, you simply check the 1 checkbox under the "Forums" tab.

If you don't want to grant access to a whole area, you can select individual permissions which will automatically select the required parents.


Restrictions In Action

The ACP will now only show areas that you have access to. For example, an Administrator who only has access to the Look & Feel section, will only see the Look & Feel section:


(The System tab always shows as the "Change My Details" page is always available)

The menu, both from the dropdowns at the top, and the menus at the side, only show the items that you have access to.

In addition, for a user likes this which can only see the Look & Feel tab and not the Dashboard, when they log in, they will be taken straight to the look and feel tab.




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!
  • 6,703 views
Mark

IP.Board 3.2.0: Easy Member Management

One of the areas we identified as requiring significant update in IP.Board 3.2.0 was the member management process. Member management is, for most communities, the most frequently-executed task that happens in the AdminCP, so it is important the process is quick and easy.

In previous 3.x releases, each different type of member (normal, banned, validating etc.) had a separate page from which you could manage that type. Once on the correct page, you check the members you want to work with, then select an action. Refresh, repeat.

In IP.Board 3.2.0, we've significantly streamlined the entire process. All types of members are now viewed in a single interface, though that interface can adapt depending on what you're viewing. Let's take a look...

Viewing Members



Notice at top-left a toggle bar, to change the member type you're viewing. Notice also that the column headers (member name and email, in this case) allow for sorting. All of this takes place dynamically - virtually no page loads are required for any action in the new Member Management section.

Searching for Members

Searching for members is easy - simply start typing in the filter box, and results are displayed live in the list.



For more specific searching, you can use advanced search to narrow your criteria.



Managing Members

Managing members is a one-click process. The available options for each member are presented as buttons; clicking an action confirms it and removes that member from the list.



Previously, you would have to (in this example) select the members to ban, scroll down, choose the appropriate action, the page would reload, then you'd have to do the same for the members you wanted to delete. In IP.Board 3.2, you can simply work your way down the list, choosing the appropriate option for each user. We expect this will be particularly useful when managing validating members.

Once you've cleared the list, the page will automatically load in another 20 members for you to manage.

You can still mass-manage members, however. Selecting some members enables the available mass-actions, and again, once you confirm, more members are loaded for you automatically.



Summary

Member Management is now essentially a one-click process - a vast improvement on previous version of IP.Board. We hope that the new process will significantly reduce the time you spend on the repetitive and time-consuming task of managing your member base.

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!
  • 13,890 views
Rikki

IP.Board 3.2.0: View New Content and Topic Marking

Of all the features we receive feedback on, view new content receives the most. To many this is their primary browsing page and it's vital that it works accurately. We've had database level topic tracking for many years. It was introduced in 2.0 and has gone through many refinements for efficiency and accuracy.

We rewrote the system in IP.Board 3.0.0 as a global framework that all applications can use via a small extensions file. This provided great flexibility and a centralized storage area for the marking data. However, there were some technical limitations which made 'View New Content' a little unreliable in certain situations due to the partial reliance on cookie data to provide a full picture of what is unread.

Another common complaint is that partially read topics 'vanish' from the view new content list as they are marked read even when some pages are left unread which leads to confusion about which topics have been fully read.

As always, we listen very carefully to feedback from our customers and this feature kept coming up time and time again so I'm very pleased to say that we've tackled these issues head on in IP.Board 3.2!

Improved View New Content Tracking
We have rewritten large sections of the view new content tracking and parsing to make it much more accurate. We now fetch the data in a large chunk and then post process it against the topic marking table to ensure complete accuracy. This means that you won't have 'read' topics showing up in your view new content list again.

Sphinx Usage
We have added a setting to enable Sphinx users to use plain SQL View New Content to avoid the 15 minute 'delay' in the results due to the delta indexes being cycled. The SQL view new content is incredibly efficient so you can still use Sphinx for the general search areas but give your members instant view new content results.

Improved Topic Marking
Purely based on the feedback we've received from our customers, we've implemented a change so that a topic with many pages isn't marked as read until the last page has been loaded. This means you can partially read a topic and come back to it later. We've made it even easier to locate your last read position with a handy link on the topic page.

Improved View New Content Overview
Another common source of confusion was our two areas "View New Content" and "View Active Content". Most people were confused by the difference and ended up loading the wrong view to locate their unread content. We have now merged these views into one single "View New Content" page. This will instantly resolve that confusion and make it much simpler to fetch the data you are looking for.

The view new content page remembers your last selection preferences and stores them in the database so next time you load the view new content page, it'll automatically use those preferences. There's no need to go into your User CP to set them anymore!

Filter by "Followed" items only
In a future blog entry, we'll discuss the change from "Watched Topics/Forums" to "Follow" but for the purpose of this entry, assume that they are synonymous.
In IP.Board 3.2.0 you can now elect to filter the view new content result set by items you follow. This will search forums and topics you are following (in other words, 'watching') and present topics inside forums that are new or topics that you're following that have new posts. This makes the view new content area much more useful as it is delivering just the content that you want to read.

Please remember that the screenshots are taken from my development board and I've made little effort to 'style' the new additions as we're planning an interface update to some of these areas.


This shows the view new content page showing all unread content from items that I follow. I am following the forum "A Test Forum 2" and the topic "Test counters" but I am not following the forum "Sub Forum".


This shows the 'view first unread post' link available on partially read topics. Clicking it takes you to the first post that you haven't read based on marking data stored in the database.

We really hope that you enjoy these new features and improvements and please keep posting your feedback, we really do listen.

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!
  • 19,552 views
Matt

IP.Board 3.2.0 Dev Update: Calendar Improvements, Part V: iCalendar Support

In our last Calendar-specific blog entry for this upcoming IP.Board 3.2 update I wanted to discuss the last big change you should expect to see: support for importing and exporting events to and from your calendar using the universally-supported iCalendar specification.

The iCalendar specification is a universal format that many applications (such as Microsoft Outlook, Google Calendar, and iCal for Mac) support, allowing applications that support the format to share events between calendars. Think of it as an RSS feed specific to calendar events (although it's important to note that it is completely unrelated and dissimilar technically to the RSS specification).


Exporting Events

Two options will be available for your members to export events from your calendars. Your members will be able to download all events in the calendar as a .ics iCalendar file, which they can then import into their calendar application of choice, or your members can subscribe to your calendar to automatically import new events as they are posted through a webcal:// protocol link. Both options are presented on most pages of the calendar so that they are easily accessible.



When clicking on a link beginning with the (unofficial) "webcal://" protocol, the user's calendar application of choice should automatically launch, importing the feed without any necessary intervention from the user. Users can also copy the link and use the link to import the calendar into an application or website (such as Google Calendar) manually.

All relevant data is included in an iCalendar export, including the event start, end and recurrence information, the event organizer information, attachments (when applicable), and RSVP attendees (when applicable).


Importing Events

It is important to note that for this release, we have opted to make event importing an admin-only option. We may likely investigate front-end support for importing events into your calendar, however we have decided to implement the iCalendar importing in this release through the ACP so as to prevent resource issues on your board. I'm sure you can imagine how your server might react if 10,000 members all decided they wanted to import their Google Calendar events into your calendar on a recurring basis. :)

The ACP provides two ways to import events:


You can upload an iCalendar file (which will usually have a .ics extension) through an upload form You can define feeds (using http://, https://, or webcal:// protocols) to import on a regular basis


When you upload a .ics file to import, you can specify which calendar you wish to import the events to, and the member you wish to save the events as (the field to specify the member uses the member look-ahead javascript to aid you in finding the correct user). The file you upload will be parsed and all data that can be extracted and honored will be imported as provided. If the event file has attendees specified, and any of those attendees are also members of your board, they will even be automatically RSVPed for the event!



If you would like to subscribe to iCalendar feeds, you can also add as many of these as you like in the ACP.



When adding or editing a feed import, you specify the calendar to import the events to, the member to import the events under (again, you can utilize our member look-ahead to assist you in finding the correct user), the frequency to check for updates, a title and the URL to the feed. Upon initially saving the feed, the first batch of events will be imported, and then regularly (based on the frequency you specify for the feed) IP.Board will automatically check the feed for new events and import any that have not yet been imported. As with uploading an .ics file manually, event attendees will automatically be RSVPed for the event if they are also members of your board.


Are there any caveats?

Well, yes there are a few caveats to keep in mind. Calendar has limited support for event recurrence at this time, so some of the more creative recurring events (for instance, an event that recurs every second Tuesday of the month) may not import as you might expect. Calendar will do it's best to read the event and import it based on the intention, however some event types may not be fully supported due to limited support for certain functionality in Calendar. The vast majority of events you will import through feeds and .ics files, however, should import just fine.


Conclusion

This concludes our 5-part series outlining improvements to the Calendar you can expect to see with the release of IP.Board 3.2.0. While we hope you enjoy the improvements being made to Calendar in IP.Board 3.2.0, please do not be discouraged if we have not added something you were hoping to see. There are many more improvements that we can make in future versions and just because something wasn't added this time around doesn't mean you won't necessarily see it in IP.Board 3.3.0 or beyond!

Let us know your thoughts in the comments area, and if you missed out on the previous blog entries regarding Calendar, feel free to take a moment to catch up:

IP.Board 3.2.0 Dev Update: Calendar Improvements, Part I: SEO Improvements IP.Board 3.2.0 Dev Update: Calendar Improvements, Part II: Consistency IP.Board 3.2.0 Dev Update: Calendar Improvements, Part III: RSVP IP.Board 3.2.0 Dev Update: Calendar Improvements, Part IV: Simplification and Interface Changes



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!
  • 11,048 views
bfarber

IP.Board 3.2.0: New reputation mode - "Like"

In IP.Board 3.0.0 we added a reputation system. This allowed your members to "up-vote" and "down-vote" a post's "reputation". This not only allows you to quickly identify "valued" replies but you can also elect to filter out replies below a certain threshold.

This system has worked very well over the past few years and our own community receives many hundreds of positive votes for good or helpful content. It's a nice visual way of saying "Thanks!'.

We have extended this system in 3.2.0 to add a new reputation 'mode' selectable from the Admin Control Panel. This new mode works in the same manner as a "like" system often seen on social networking sites.

This "like" system is an even better visual way for identifying good content and makes it more personal by leaving your name in the "like" list rather than it being an anonymous donation.

Here are some screen shots:
Note: the following screen shots have been taken from my local development board. Expect the final interface to change


Here you can see that I've "liked" this post along with some other members.


Clicking the '1 other" link brings up an inline pop-up showing exactly who has "liked" this post.

Here's a brief video showing the system in action:



We hope that you "like" this new enhancement to our reputation system and find it brings a new level of interaction with your members.

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!
  • 27,108 views
Matt

IP.Board 3.2.0: New AdminCP Style

One of the primary areas we have targeted for improvement in IP.Board 3.2 is a fresh style and usability improvements for the AdminCP. Our AdminCP has long been considered one of the best in the industry, so while we didn't want to tear up that work and start again, we did feel it was time to make substantial improvements.

Overview

First, let's take a look at a general overview of the new style:



As you can see, we've tidied up the header area. The live ACP search, which has been a hit feature, has been made more prominent (more on that later). The 'button bar' that many pages make use of has been styled more like a toolbar in a traditional application. Many other general aspects have been tweaked, such as improved typography, removing various bits of clutter on the screen and updating the drag handle to the standard used in places like GMail.

Sidebar / Menu

In 3.0/3.1, the sidebar is the primary way of navigating through an application. The downside of this is if I'm in the Forums app and I want to, for example, edit a member, I first have to click the Members app, then find the item in the sidebar, and finally arrive at the page I wanted.

We felt for an app of the size of IP.Board, more effective navigation could be done by using multi-level dropdown menus:



This makes it really speedy to get wherever you need to get. You can even navigate to your non-core applications:



The sidebar can be hidden, giving you more space on your screen for the important content. I've been using the new menu system for weeks, and I certainly couldn't imagine going back to using the sidebar as the primary navigation method. I hope this makes routine administration tasks noticeably easier for everyone.

New Item Menus

In 3.0, item rows that have additional options are displayed using the icon. While this works fine (especially when there's many options), it could be made quicker if the primary actions were buttons in their own right.

IP.Content and IP.Nexus have had the new item menus for some time, but they're now used throughout IP.Board. Primary actions (such as Edit and Delete) are displayed as buttons, while less-frequently used options remain in a dropdown menu. The row you are hovering on highlights itself for easy identification:



(Fun fact: this menu system is generated entirely with CSS3 - so it's incredibly easy for mod authors to reuse)

New Tab Bar

In IP.Board, many sections use tab bars for situations where you can edit all of your applications at once (for example, the Tools & Settings section). However, problems arise when you install lots of extra applications - the tabs can spill out of the bar and break the page layout.

To resolve this, we have added a new style of tab bar, that comfortably displays as many apps as necessary. By default, it looks like a standard tab bar:



But when many apps are installed and your browser window is not large enough to display them all, it adds smooth scrolling controls:



New Form Style

Though not a major change, we have updated forms throughout the ACP to use a slightly different layout. In 3.0, field descriptions were displayed under the field title. Where fields had long descriptions, this was unwieldy, and contributes to making forms more difficult to use than they should be.

In 3.2, we have updated the styling so that field descriptions appear directly under the field they relate to. Field titles meanwhile are right-aligned, making it really easy for your eye to travel the page and identify items:



New Live Search

I mentioned earlier that the ACP live search had been made more prominent in the interface. We hadn't expected it to be quite as popular as it is, so in 3.2, we've improved the display of the results box. Often, a search would have dozens of results, which made them difficult to scan through to find the relevant one. Live search in 3.2 breaks down the display into sections, like so:



Summary

We hope that the new navigation system and live search really makes finding what you need highly efficient, so you can get on with doing the important tasks. We hope the cosmetic and usability tweaks makes performing those tasks just a little bit easier. And, of course, we hope you like the overall styling we are going for.


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!
  • 20,082 views
Rikki

IP.Board 3.2.0 Dev Update: Calendar Improvements, Part IV: Simplification and Interface Changes

Hot on the heels of our blog entry detailing how RSVP-style events will work in Calendar as of IP.Board 3.2.0, we would like to take a moment to discuss some interface changes we have made in the next release of Calendar. Some of these changes are relatively minor, but we feel that they should improve usability and make it easier for users to understand how to use Calendar in 3.2.0. It is important to note here, since we are discussing changes to the interface specifically, that these changes are also subject to change. What you see and is discussed below should serve as an outline for some of the more important interface changes you will see in Calendar, however be advised that further changes may be in store, and what you see below is not necessarily exactly how IP.Board 3.2.0 will look upon final release. That doesn't mean, however, that we can't make you aware of the core changes now so you will be prepared when 3.2.0 is released.


Event Submission

One area we wanted to simplify a little was the event submission process. To start with, we have removed the three separate confusing button options on the calendar page ("Add Single Event", "Add Ranged Event", "Add Recurring Event") and consolidated this into just one "Add Event" button. No longer will users have to actively think about what type of event they are adding before they are even presented with the form to do so.

The event form has been overhauled to handle the addition of all three event types at once in the process. Javascript has been leveraged to show and hide fields that are not applicable to the type of event the user wishes to add, until they need to see those fields. The date picker javascript tool has been added to the form to make it easier for users to choose the date they are attempting to add, and times have been changed to a 12 hour format with an "AM" and "PM" dropdown menu, a vast improvement over the previous 24-hour format field previously used.

Because the options are all interlinked, I've taken a quick video to show you how these work. When you submit the event, calendar will figure out what type of event (single, ranged or recurring) automatically and save the event data accordingly. By figuring these details out automatically, we make it easier for the user to submit their event without having to actively think about all of the details before hand.





Getting rid of redirector links

Some of the links in past versions of Calendar where links to redirector scripts. This means that the link did not actually point to the final destination the user would arrive at, but instead pointed to an intermediary page that would do some calculations and then redirect the user to the correct location. While there is nothing fundamentally wrong with this approach, it means two page loads instead of one for the user from a technical point of view (increasing the time it takes the user to arrive at the destination page, and increasing the amount of work your server ultimately has to do to get the user to where they are going), and this is not an optimal solution from an SEO point of view. We have changed all such links in Calendar for IP.Board 3.2.0 to point to the correct destination page without using redirector intermediary pages, improving user experience, resource usage, and SEO all in one go!


Daily View

Receiving some of the biggest changes in it's general interface, the "daily view" as we call it has been completely changed in the next release of Calendar. "Daily view" is what I call the page that shows what is happening on a particular day.

As a reference point, you can view our current Calendar to see what the daily view looks like for a day that has both an event and some birthdays by looking at February 8th. In the current version of Calendar, you will see that birthdays are listed vertically at the top with a lot of wasted space to the right, while the more important events are listed at the bottom using the same exact template that is used when viewing the event itself. If you have a calendar where there is one event on the day, you ultimately end up with a "duplicate content" SEO scenario. The daily view looks (and indeed, has the same source code HTML) as the event view because both simply show the same event on the page. We wanted to make this view a little more useful than it is currently in the next release of Calendar.

Reminder: This screenshot outlines the direction we are taking with the next release of Calendar, however keep in mind that the interface is very much subject to further change before release. Consider this screenshot an early preview of the direction we are taking, rather than a final screenshot of the finished interface.



The first thing you will notice is that this view is more similar to our weekly view. You have the handy shortcuts and monthly mini-calendars in the sidebar that let you easily navigate to other areas of the calendar without having to return to the homepage first. At the top of the page we have added "Previous Day" and "Next Day" shortcuts to allow you to more easily navigate through the days in calendar as well.

We have moved the list of birthdays below the events, as we feel the user-generated events are typically more important to the community than an automatically-generated list of birthdays. The events, while similar to the full event view, are a simplified interface meant to give you an overview of the event, but not all of the details (which is more undesirable in this version of Calendar, given the new functionality available for events). The birthdays have been overhauled to provide more useful information than just the name and age (although both of these pieces of information are still available and displayed). All in all, this entire page has been overhauled to be more useful, less of a copy of the specific event view page, and to allow you to more easily navigate the system and get to where you want to go.


Navigation Changes

Similarly, we have touched up the navigation bar on every page in Calendar to make it easier to navigate back up the hierarchy to where you want to go. Most pages in Calendar in the current release will show "Board > Calendar > Calendar Name > Page Name" in the navigation bar. While this generic approach does offer some flexibility to move back up the chain, you cannot easily get back to the page you were previously on when you view an event, or a day, or a week. With the next release of Calendar, the navigation bar will be much more dynamic and natural feeling, allowing you to more easily return to your previous page without having to use your back button.

When viewing a week, the month and year has been added as a navigational bar entry to let you return back to the month. When viewing a day, the same has been done here. The most useful changes have been made to the event view page, however. The event view page now will attempt to determine where you are visiting from, so that it can better show you a navigational bar that is relevant to how you reached the page. For instance, if you are viewing the daily view and click on an event, you will now see the month and year as a navigational entry, as well as the day of the event. If you reach the event view page from the weekly view, you will have the month and year as a navigational entry, as well as the weekly view you just came from. This is particularly useful when you are viewing a ranged or recurring event, as it allows you to return to where you actually came from, rather than simply returning you to the month and year the event started in (which is not where you came from, in many cases). The end result should be a more useful navigation bar for Calendar in 3.2.


Conclusion

Many other tweaks have been implemented, and there are many more to come as our interface designer continues his work on the public interface of IP.Board 3.2. The end goal, of course, is to make Calendar easier to use, more useful to use, and more intuitive to navigate. We think the above changes work toward these goals, and we hope you find them to be welcomed changes in the next release of Calendar.


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!
  • 12,036 views
bfarber

IP.Board 3.2.0: Text Editor Part III / Live Topic Replies

This entry rounds up our series of blogs on the new text editor and how we've enhanced other areas of the interface that use it.

I recently introduced the new text editor and then showed you some basic integration such as fast reply and instant quote.

I want to now show you the last piece of this feature set and resolve a common issue when making a reply.

Quite often you're on a busy board such as ours and you're using the fast reply to make a post and when submit the post you realise that others have posted in the mean time making your reply either redundant or out of context.

To solve this, IP.Board now checks at regular intervals to see if any new posts have come through and if so, you can add them to the page.


This screen shot shows the inline notification stating that there are new replies. Clicking on the link adds the replies into the topic.

This video shows the system working. Note, for this demo I increased the polling frequency to every few seconds.



So how does it work? Will it crash my server?
It's a bit clever and no! When you start typing you trigger the polling action which checks every 3 minutes for new posts. This is a very fast and light query that requires far fewer resources than a simple page refresh. It will continue polling until you either add the reply or an hour has passed. We added this upper limit to prevent instances where a reply is started but then the member changes tabs, etc.

I hope you enjoy this feature and all the new functionality we've added in this crucial area. Making posts is the very lifeblood of your forum and making it easier to contribute can only increase the number of posts made.


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!
  • 11,444 views
Matt

IP.Board 3.2.0 Dev Update: Calendar Improvements, Part III: RSVP

As part of our continuing IP.Board 3.2.0 development update blog entries, we've already told you about some great improvements you can expect to see in Calendar with the release of IP.Board 3.2. In addition to much improved SEO capabilities in Calendar, we have also made loads of changes to improve the consistency of Calendar compared to the rest of our suite lineup. While these changes alone will make Calendar much more useful for administrators and users alike, we are most certainly not done yet. We can still squeeze some more improvements out of Calendar in 3.2.0 before moving on to other important tasks, and to that end I'd like to use this entry to discuss a new feature you will have opportunity to use in the next release of Calendar: RSVP events.

Important Note: The screenshots you will see below are taken of a very-early build of 3.2 and the interface will be subject to change. Our UX designer will be going over the RSVP changes in Calendar in greater detail in the weeks to come, so please understand that what you see below is not how the final result will appear upon release.


The Concept

Often times you will find that when creating an event on your community you want to allow users the opportunity to let you know if they will be attending or not. This is useful for both real-world events (i.e. a club meetup at a coffee shop) and for online-only events (i.e. a developer seminar). As the event organizer you may need to know how many people will be attending, and/or if specific users will be attending. It is useful to have a way to allow users to signal that they will be attending the event.

In the "real world", this is usually done through what is known as "RSVP". Basically, an RSVP is a notification from a participant to the event organizer that the participant will be attending the event.

In the next version of Calendar, users will have the ability to create events that request attendees to RSVP for the event.


Administrative Controls

Administrators can control which users can both create RSVP-requested events and which users can respond to RSVP-requested events.

For each individual calendar you create within the Calendar application, you can specify on a per-permission mask basis which users can create RSVP events, and which users can respond to RSVP events. You can also control on a per-calendar basis if the event poster is allowed to remove users who have saved an RSVP for an event or not (super moderators always have this ability). If you do not wish to use this capability in a specific calendar (or at all), you can simply not allow any users the ability to create RSVP events in the calendar.


Creating and responding to an RSVP event

Creating an RSVP-requested event is as simple as checking a box on the event submission form.

When viewing an RSVP-requested event, a new box will be shown to the user to signal that the event organizer requests attendees to RSVP, and who has already RSVPed for the event.



When you click on the RSVP button in the RSVP area, your participation status will be saved through AJAX and the attendee list will be dynamically updated. Note that if javascript is disabled, your status is saved through a normal browser redirect screen fallback.



If you have permission to remove attendees (as I do in this screenshot), a delete icon will show next to each attendee, affording you the opportunity to remove them from the list.


Wrapping Up

While we have some ideas in mind for future versions of Calendar to possibly expand the system as implemented presently, we wanted to go with a clear, simple and straight-forward approach for this first implementation of the RSVP system that we feel will be easily understood by your users (and thus, more likely to be used properly by your users as well). Creating an RSVP event is as simple as checking a box (if you have permission to do so), and signaling your attendance is as simple as clicking a button (again, if you have permission to do so). We feel this approach will make the feature more likely to be used, while still allowing us opportunities to expand the feature in the future.

Let us know what you think in the comment area below, and be sure to keep an eye out for our next blog update about Calendar, coming soon!

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!
  • 13,197 views
bfarber

IP.Board 3.2.0: New Photo Editor

One of our main goals for IP.Board 3.2.0 is to streamline the interface and make it easier to work with. We're also taking full advantage of modern techniques to ensure that IP.Board has more of an application feel by eliminating page reloads and using rich web technologies.

We've revamped the photo editor to make it easier and simpler to use. The first thing you'll notice is that if you've connected your forum account to Twitter and/or Facebook, you can quickly select to synchronise your photo with the service on the same page.

We're also using square cropped images for the user's photo for a more uniform feel and you can adjust the crop viewport if the default center crop doesn't catch all the detail.


Here's the new photo editor complete with all the options available to me for my photo.


After uploading a new custom image, I can quickly re-crop it to better capture the relevant portion of the photograph.

And finally, here's a little video of it in action!




We really hope you enjoy this new interface and we're sure it'll make changing your photo an easier and more pleasant experience!
  • 11,685 views
Matt

IP.Nexus 1.2 Dev Update: Miscellaneous Enhancements

To round up our development updates on IP.Nexus 1.2, I'd just like to mention in brief some additional features not already mentioned in previous blog entries.


Go back in Checkout

When going through the checkout, a progress bar at the top indicates what steps are still required.


Previously, once you had completed one step, you could not go back and change the information provided. In IP.Nexus 1.2, you can click on any step in the progress bar that you have already completed and will be taken back to that step.


Change Package

You can now "swap"the package that an existing purchase is using in the Admin CP.


This will apply all properties of the new package to the purchase (renewal dates, etc.) and apply any usergroup et al changes that the new package allows.


Split Support Requests

You can now split support requests and delete individual replies in the Admin CP.
Each reply now shows a checkbox in the top-right corner, when this is checked, options will appear at the bottom of the replies.


The system works across multiple pages - simply check the replies on one page, change to the next page and select any additional replies - the checked items from the first page will be remembered.


Task Frequency Change

In order to prevent time-outs when handling large amounts of data, and to generate invoices and expire purchases closer to their specified dates, all tasks in Nexus now run more frequently, with a limit on the number of items to process.
This number should be fine for most users, but can be adjusted if necessary.
  • 2,851 views
Mark

IP.Board 3.2.0: New Text Editor, Part II

I recently introduced the new text editor in 3.2.0. This new text editor brings a robust rich text editor coupled with custom BBCode and an auto-save feature.

Today, I wanted show some user interface and usability improvements we've made in this area.

Firstly, where space is tight or where you don't want to be overwhelmed with the text editor, it is shown 'minimised'. The screenshot below shows this minimised state and the editor looks just like a regular HTML text area that everyone is familiar with.



Upon clicking the text area to begin making your post, it'll expand into the full editor ready for use:



We've also gone ahead and added 'Ajax reply' and 'Ajax quoting'. This improves the responsiveness of IP.Board by removing the page reloads and gives it more of an 'app' feel by posting and updating the page instantly.

I've taken a short video of this in action. Please note that you are viewing an in-development feature so the final design is not set for both the board and the editor and also that I'm currently working in "development" mode with CKEditor which means that there is a slight pause as it loads. This will not be the case when we package it up for release.



We hope that you enjoy these enhancements to commonly used areas and that it makes a common task more enjoyable. Please do keep in mind that cosmetic style issues and such will be addressed in future blog entries.
  • 12,218 views
Matt

Spam Service Update

On 13 January 2011 we posted some information on our Spam Monitoring Service that was helping to block the huge amount of spam accounts hitting communities all over the web.

There's not much new to report - spam will always exist unfortunately - but we thought everyone would be interested to know that we were recently able to block huge ranges of attacking IP addresses.

IPS has a hosting division that provides managed community hosting for many thousands of communities. We host everyone from small, hobby sites to large enterprise clients with thousands of online users. We manage our own network and hardware to have the best possible control over the experience we can offer our clients.

We have been able to leverage our hosted network of thousands of communities to detect the signatures that the spammers were using to get past the various defenses in IP.Board. The spammers were using automated software to, for lack of a better term, brute-force their way past the reCAPTCHA service and this program left clear marks in our server logs because of the unique way it accessed the servers. Our network staff were able to, across our dozens of servers, gather up all the IP addresses used to register spam accounts and add those to the block-list on the Spam Monitoring Service.

While this is not a complete solution we were very happy to be able to detect these trends and block those spammers at the service level so the knowledge we gained from our own network could be applied to help all those with an active IP.Board license.

Fighting spam is an ongoing battle of course but we will continue to do our best to help blocking those who would try to disrupt your community. The better your community runs the better IPS grows and we take our responsibility to your community seriously.
  • 4,146 views
Charles

IP.Nexus 1.2 Dev Update: Custom Packages Improvements

IP.Nexus has always had the ability create "custom packages" - you can specify a price and renewal terms and IP.Nexus will keep a log of the purchase and generate renewal invoices.
However, some options like member group promotion, custom modules, etc. are not available in this setup - and with the addition of advertisements and hosting packages, it is necessary to be able to generate custom packages of these types also.

In IP.Nexus 1.2 we've completely rewritten how custom packages are handled to allow this flexibility.
When generating an invoice, the normal "Custom Package" option appears in the dropdown - choosing this will show you a menu of available package types just like when creating a normal package.

The next screen shows all of the options that would normally be available to normal packages (except settings which don't make sense for custom packages, such as if the product should display in the store or only be available to certain member groups):



After creating the custom package and the invoice has been paid for, it displays just like a normal purchase, both in the Admin CP and the client area:


Administrators can of course edit any of the custom package settings from this page.

  • 2,845 views
Mark

IP.Board 3.2.0: New Text Editor

Nearly ten years ago, IP.Board shipped with a pretty advanced functional editor that allowed you to quickly format your text in a rough "WYSIWYG" format. This was an exciting technology. As the main browsers started adding better support for this functionality we updated our own code to keep up.

The internet is a constantly evolving space and web browsers and technology rise and fall and keeping up with these changes gets harder and harder. This is why we've added a new editor to 3.2.0 that is developed by a dedicated team outside of Invision Power Services.

IP.Board 3.2.0 will come with the excellent CKEditor as standard. It's a well developed and well tested editor that is very extensible. It's constantly updated which means that we simply have to update the version that comes with IP.Board to get all the latest fixes.

In general use, the new editor is much better at "WYSIWYG" (rich text editing) than our own current implementation and we've extended it further.

Please keep in mind that the screenshots and videos below are using a very early development copy of IP.Board 3.2.0 and the editor will likely be skinned in a little more to match IP.Board before we release.

All the usual IP.Board tools are present
We've written a lot of plug-ins so that no functionality is lost. You can still create custom BBcodes and add buttons to the editor easily via the Admin CP and you can still use your own smilies.




Switching between modes
We love the new editor and as it supports nearly all major browsers, it's the first choice for replying and adding new topics. However, there are times when you want to edit the BBCode directly and with that in mind, you can switch between rich text editing mode and simple text mode without a page reload.




Auto Saving Text
A new and really handy feature we've added is auto save. As you type, the editor checks to see if there's any new content and if there is, it'll ping off via Ajax to save what you've written. If anything happens to your page, upon reloading you'll see it's stored your content and you can quickly restore it. You won't lose another post to a browser crash or server time out.


IP.Board saves as you go.


A refresh without posting allows you to view and optionally restore any content that has been auto saved.

We hope that you enjoy the new editor in IP.Board 3.2.0 and the extra functionality we've added. We're excited to use it ourselves!
  • 26,243 views
Matt

IP.Board 3.2.0 Dev Update: Calendar Improvements, Part II: Consistency

We are continuing to make improvements to Calendar to both bring it more in line with the rest of the suite of IPS products and to modernize the application and make it more functional and useful for our customers. If you haven't read our first blog entry describing improvements you can expect to see with Calendar in IP.Board 3.2.0, Part I: SEO Improvements, feel free to take a moment to read our last blog entry to catch up. In this entry we'll discuss some of the changes you can expect to see in the Calendar with the release of IP.Board 3.2.0 that provide for a more consistent use of the application when stacked up to our other products.


Ratings

With the next update of Calendar, you will now be able to rate events very much like you can rate topics now. Ratings are saved through AJAX, just like with topics, falling back to a normal page load and redirect if javascript is disabled on the user's browser. You can control on a per-calendar basis which permission masks have permission to rate events within the calendar. If the user has permission to change their rating via their user group configuration, they will be able to change their previously rating for any event in Calendar as well.




Reputation

As with posts within the forums, you will now be able to give the member who submits an event reputation when viewing the event in Calendar. The reputation box displays just like it would for a forum post, allowing your users to quickly and easily understand the interface and functionality. By allowing reputation to be issued for event submissions in Calendar, you provide incentive to your users to submit events in your Calendar, making it all the more useful for your entire community!




Attachments

In our continued effort to increase consistency and functionality in Calendar, we have also implemented attachments for Calendar in the next update. When submitting or editing an event, the standard attachment uploader will be shown on the event posting form. You will be able to submit attachments based on the ACP configuration, just like you would be able to for posts in the forum. You can embed the attachments anywhere within the event content, or let Calendar just append the attachments to the end of the event information, again just like a post within the forum. Attachments may be useful for Calendar to share an event poster or flyer, to share coupons for an event, or to attach documentation users may need to be informed of prior to the event, just to name a few uses.





Notifications

Users can now optionally elect to be notified of new or updated events in Calendar, allowing your site to notify users of changes to the Calendar that they may elect to be informed about. Previous versions of Calendar provided no way to push information to the user to notify them of changes in Calendar. Any user interested in an event saved to your Calendar would need to manually check on it periodically to verify any changes made to the event, which we can agree is certainly not an optimal experience or expectation. As of the next version of Calendar, users can follow both individual calendars and individual events, allowing them to be notified of additions to calendars they are following, and updates to events they follow. By letting Calendar notify your users of changes, the software becomes more functional and useful in it's prime goal, sharing event-based data with the community.




Comments

Your members will now be able to comment on events submitted to Calendar. You can control on a per-calendar basis which permission masks can comment on events in each calendar, and you can also specify whether comments must be moderated prior to becoming visible (again, on a per-calendar basis). Comments in Calendar use the central commenting class of IP.Board, meaning it works identically to all other applications (e.g., identical to the blog commenting system at the bottom of this page), allowing for a consistent interface users can understand and utilize without having to learn how to use yet another posting screen. If a user opts to follow an event to be notified of updates to the event, they will also be notified of comments made on the event, allowing your site to better communicate updates to users about content they are interested in, and driving more activity within the Calendar in the process.




"Like"

Alongside commenting, users can now "like" calendars and events (the aforementioned "follow" capability), giving them the opportunity to either show their support for the calendar/event, to be notified of updates to the calendar/event, or both. As with IP.Blog, IP.Downloads, etc., the like system is a central class within IP.Board that is reused within Calendar, again to provide a consistent interface to users that they can learn and understand once, and expect to use throughout your entire site.




Sharing

The general use share strip that you see below each topic (and elsewhere throughout our suite of applications) has been added to Calendar. This allows users to share events through social networking sites, through email, or even to print an event's details out with their printer. If Facebook support is enabled in your ACP, the Facebook "like" button will also show up for the user, allowing them to share the event on Facebook. This is likely to drive activity to your site as the user's friends see this content shared on Facebook and follow it through to your site, where they may be interested and join your site...a win-win!





I realize this blog entry is pretty concise and the above-mentioned changes are not thoroughly detailed here, however because these are consistency-based changes to bring Calendar in-line with the rest of our products, the majority of our customers will already be familiar with everything mentioned above. By bringing these changes to Calendar, we allow for more useful functionality and more consistency with the rest of our suite of applications for IP.Board. Our next blog entry for Calendar will start detailing some of the changes unique to Calendar that we believe will make it much more useful for you and for your community. Stay tuned, and if you would like to be notified when we post future blog entries, be sure to "like" our company blog.
  • 10,801 views
bfarber

IP.Nexus 1.2 Dev Update: Editing Existing Packages

Currently in IP.Nexus when a package is edited, certain factors, like the group a user is moved into when purchasing the package, only apply to new purchases.
While less of an issue for traditional products there are times, particularly with advertisement and hosting packages, where you will want to apply these changes to existing purchases.

Let's say for example, a user has purchased a product called "Premium Membership" - note how the customer is in the group "Members":


I now decide that I'm going to create a new group for people who have purchased this group called "Premium Members" and change the product settings to move members into this group when they purchase the package - note that I'm editing the package that the member bought, not creating a new package:


When I save this, I will now see a new screen which indicates the change I've made can be applied to existing purchases:


If I choose the bottom option, no further action will be performed - the package will save and the changes will apply to new purchases only.
If I choose the top option, IP.Nexus will go through all existing purchases and make the change:


And all of the appropriate changes will be applied:




You can change almost any field for similar behaviour - removing the usergroup for example would move everyone back into their original groups, enabling the license key settings would cause license keys to be generated, for hosting accounts changing the allowances will update the account on the server, etc.

The system will also notice if you have customised a purchase and keep your changes in such a situation.
For example, let's say you've manually edit a customer's bandwidth allowance on their hosting account - when IP.Nexus goes to update the purchase it will notice the value has been customised and leave that particular setting alone (and update other settings as usual).

Of course, changes made in this way are logged on the customer page as normal, as if done manually.
  • 2,885 views
Mark

Gallery 4: Mobile Skin

As the beta process for Gallery continues, I've found the time to implement the mobile theme that can be used by any mobile handset's browser or by the iPhone app we have available for free in the App Store.

The mobile theme is lightweight as expected and makes good use of the small cropped thumbs as well as the new 'small' image that is created. This saves a lot of bandwidth which will be a huge relief to those that don't have a good 3G signal.

I'll be updating Gallery here later today so you can see this live. The mobile theme will be available with Gallery 4.0 Beta 3.

The Gallery homepage:


If you scroll down you can access the global and member albums:


Album view:


Viewing an image:




I hope that you enjoy this new functionality when it's available!
  • 4,600 views
Matt

IP.Nexus 1.2 Dev Update: Custom Customer Fields

IP.Nexus can ask the customer for various information (like their full name, postal address and phone number) when registering purchasing an item. This information is required for shipping, some payment gateways and the anti-fraud system.
Up until now, these fields were static - only the hard-coded fields were available and you could only specify all or no fields were required at registration or checkout.

In IP.Nexus 1.2, we've made these fields customisable - you can choose which should show where, which should be required and add and reorder fields as you see fit.



This means, that you could, for example, add a "Company" field, which would show alongside the others:


Of course, users can also edit custom fields in the client area, and administrators can edit them from the customer page.
Whenever the details is changed, it is logged to the customer history page as one would expect:


Administrators can also search by custom fields both from the quick-search in the menu, and the main customer search form:



This also means that since existing fields can be edited, you can now reorder or remove options from the "Country" field. You can also specify if "State" should be required or not.
  • 3,643 views
Mark

Platform

Solutions

Guides

Help & Resources

Account

Navigation

Search

Search

Configure browser push notifications
Chrome (Android)
  1. Tap the lock icon next to the address bar.
  2. Tap Permissions → Notifications.
  3. Adjust your preference.
Chrome (Desktop)
  1. Click the padlock icon in the address bar.
  2. Select Site settings.
  3. Find Notifications and adjust your preference.