Jump to content
View in the app

A better way to browse. Learn more.
Invision Community

A full-screen app on your home screen with push notifications, badges and more.

To install this app on iOS and iPadOS
  1. Tap the Share icon in Safari
  2. Scroll the menu and tap Add to Home Screen.
  3. Tap Add in the top-right corner.
To install this app on Android
  1. Tap the 3-dot menu (⋮) in the top-right corner of the browser.
  2. Tap Add to Home screen or Install app.
  3. Confirm by tapping Install.

Invision Community Blog

Show all categories

Upcoming Release Candidate

The first release candidate of IP.Board 3.0.0 is coming very soon. Everyone here at IPS wants to thank all of our customers who took their time to test the various beta releases of IP.Board to date. We also want to thank those who participated in the IPB3 preview forum and gave their pre-beta feedback.

IPS believes that the public beta process was an important part of this process. Although the process took longer than we originally anticipated, it is our firm belief that taking feedback and testing results from our customer base has created a great product we can all be proud of. Not only did we fix various bugs and issues but we also took the time to make certain changes to IPB3 when people pointed out areas we thought were great but turned out not so great. Granted it took time to make those changes but the end results are very good for all. That is the beauty of collaborating with our customers and are happy with the outcome.

Frequently Asked Questions

We are receiving various questions about the upcoming releases. Here are a few below. Some are repeats but good to review.


What is a Release Candidate?

A release candidate is a version of the software between the beta phase and a final release. Once we post the first release candidate of IP.Board 3.0.0 you can safely assume that we consider the software stable enough to use on your live community. Everyone here at IPS is very excited to reach this milestone of development. Note that technical support and service is not available until we reach the final, supported version. Keep in mind that, although this is a release candidate, there will probably still be some bugs and issues so make your decision to use the software carefully.

Is there a cost to upgrade?

So long as you have a current and active support/upgrade license there is no cost to upgrade to IPB3. Also, if you are on IPS Hosting, there is no cost to upgrade. If your Standard license is expired you can renew it for $25. If you need help just contact customer service.

Can you upgrade my board for me?

We will be happy to upgrade your board when IP.Board 3.0.0's final version is released. However, we do not provide support services for the release candidate stage. Keep in mind that all active IP.Board licenses come with free upgrade services so you can upgrade your install yourself or our staff would be happy to do it for you at no cost to you.

What about IP.Blog/Gallery/Downloads?

The release candidates for the applications will be available just a few days after IP.Board's release candidate. We are staggering the releases so bug reports can be confirmed that they are only regarding IP.Board itself. On the final release day, all applications will be released right along with IP.Board. Please note that the updates to the applications did not contain any major changes at this time but instead were updated to work with IP.Board 3.0.0's code. One of the very first updates made after IP.Board 3.0.0's final release will be major upgrades to the applications.

Will IP.Board 3.0.0 be encoded?

The beta releases were encoded so we could control the releases and how long they were in use. Starting with RC1, IP.Board 3.0.0 will not be encoded.




IP.Board 3.0.0 RC 1 will be out very soon. We hope you all enjoy!
  • 3,866 views
Charles

IP.Board 3.0.0 Development Update

We released IP.Board 3.0.0 Beta 5 last week and the release has gone very well so we are preparing to enter the Release Candidate phase of development. Thanks to everyone who has downloaded the various beta releases and posted bug reports. Please continue to do so! The more we can fix before final release the better for all.

A release candidate is a version of the software between the beta phase and a final release. Once we post the first release candidate of IP.Board 3.0.0 you can safely assume that we consider the software stable enough to use on your live community. Everyone here at IPS is very excited to reach this milestone of development.

Keep in mind this will not be the final, supported version. There will probably be bugs but hopefully nothing that will cause any major issues. So, although it's not a beta anymore, still consider this information before you upgrade your live community. If you cannot stomach a few bugs or areas not working perfectly you may want to wait before upgrading. :)

The upcoming release candidate for IP.Board 3.0.0 will also be the first release that is not encoded. We hope that our community developers will jump right in and start writing hooks and alternate skins. We have quite a bit of developer documentation already written and we will get that out for everyone as soon as possible.

For the sanity of our support department, keep in mind that release candidates do not come with technical support service. Once IP.Board 3.0.0 is released as a final version then support services will be offered.

Expect the first release candidate of IP.Board 3.0.0 in the next two weeks or so. Thank you again!
  • 3,836 views
Charles

Introducing IP.Converge Modules

IP.Converge is designed to be an open platform allowing any application to share a common authentication method. This allows sites on different servers, and using different products, to let users access it with a 'global' login.

Unfortunately due to limitations within IP.Converge, only a handful of IPS applications utilised it. However, with the recent introduction of IP.Converge 1.1, functionality has been added to allow 3rd-party applications which use a different password hashing system, to integrate with Converge itself.

Being able to integrate popular products seamlessly was an opportunity we simply could not miss! We have noticed that modifications integrating products such as Joomla and Wordpress with IP.Board were so commonly requested, that we had to do something about it.

Introducing IP.Converge Modules
As many of you will be aware of, we have a team of Community Developers who actively develop and maintain our community-projects; IP.Tracker and IP.Shoutbox. We now have a new project that has been in development for some time, IP.Converge Modules. We are starting off with modules for integrating Joomla, WordPress and WordPress MU with IP.Converge and further modules will follow in the near future. You may have read our community developers talking about the development of these on the forums already.

This new range of community projects should prove a popular addition. Available for beta testing, we currently have IPC.Joomla and IPC.WordPress, a separate module is available for WordPress MU users (IPC.WordPress MU). These Converge-ready applications will integrate your existing Converge applications with these popular products. If you wanted to, you could link up multiple Joomla/WordPress installations with your IP.Board, as Converge supports this very well.

For the first release, the modules will offer simple integration compatible with IP.Converge, however in the near future more extension sets will be available for download. These extension sets will each offer a different level of integration for the products, but for now we are simply focusing on integrating these popular products.

To avoid confusion surrounding the products named 'JIB' and 'WIB' developed by Brandon D, IPC.Joomla, IPC.WordPress and IPC.WordPress MU are in fact the new 'JIB' and 'WIB'. Brandon D has been leading this new community project, and therefore work on his two old projects has been carried over to this community project.

You can download the beta releases of these Converge modules here, and the new forums have now been revealed, please feel free to ask any questions there! The Resource site's community project page has also been updated to reflect this new addition! Finally, a new bug tracker project has been set up to allow you to report bugs in these modules.

These converge modules require the PHP version that the product requires, for example to install IPC.Joomla, you will need a PHP version which is compatible with Joomla itself.

IP.Converge 1.1.0 RC 2
To go alongside this release, the second release-candidate of IP.Converge is now available for download for those with an active IP.Board license. Please continue to report any bugs you find in the IP.Converge bug tracker.

In order to install the Converge modules, you must be using at least IP.Converge 1.1 RC 2.

We hope that these new two projects will go a long way and prove to be a very popular addition.
  • 7,815 views
Alex

IP.Converge 1.1

IP.Converge is designed to be an open platform allowing any website or application to make use of its features. However, due to some limitations and the complexity of writing the modules, it's only been used by IP.Board until now.
In IP.Converge 1.1 we have added the features developers need to make almost any application IP.Converge-ready.

Username support
One of the most frequently requested features for IP.Converge from both developers and end-users is username support. Some applications don't support e-mail address-authentication which IP.Converge natively uses and many end-users would simply prefer to log in with their username.
In IP.Converge 1.1 developers can now set IP.Converge to send usernames to their applications instead of e-mail addresses.
We have also added a transparent layer into IP Board 3 so that even if you are using IP.Converge, you can log into IP Board using your username.
Users will also be able to change their username on one application and have it update across all your IP.Converge applications, just like e-mail addresses and passwords.

Sending non-md5 password
A lot of applications don
  • 9,597 views
Mark

IP.Board 3: Friendly URL Enhancements

Since we unveiled the new friendly url feature on our preview board, we have received a lot of feedback on how it could be improved with regards to maintaining good search engine optimization (SEO). Every feature we add has to be weighed against the impact to efficiency and memory usage. We understand that not every customer has the luxury of a dedicated server. We want to ensure the very best experience for a wide variety of hosting environments.

However, in this case we felt we could make some improvements to the friendly url feature without compromising efficiency. The new settings can add some small overhead, but we felt that those who wanted the very best optimized content would accept that.

Meta Tags
I have added a way to add meta tags to the final content through:



$this->registry->output->addMetaTag( 'name', 'content' );

This is used internally to add a meta tag for 'indentifier-url' and 'description'. The description is the first post of a topic; a forum description or the user's "About Me" information using the signature if no "About Me" information is present. You can use this interface in your own code to add more tags if desired.

Robots.txt
A primary concern for those interested in SEO is duplicate content. There are many ways to access a single topic due to the different variables that are used; pagination and search strings are a few examples. To help limit the duplicate pages indexed, IP.Board now ships with an example "robots.txt" file for you to edit and upload to your root directory.

Redirecting 'old style' links
Another concern was that the old style links, for example: index.php?showtopic=10, are still able to access pages. This is necessary so that you do not lose bookmarks or traffic from currently indexed links. You can now choose to redirect with an optional "301 Moved Permanently" header to the new link format. This is transparent to the end user but will help search engines locate the correct copy of your content.

Incorrect Permalink Handling
The new friendly URLs are often based on user generated content. For example, a topic called "My Great Topic" will have the permalink "/topic/10/my-great-topic/". Now, when this topic title is edited, the permalink will change too. For this reason IP.Board allowed access to the topic as long as the topic ID was present, so all of the following links resulted in the same topic being shown:

/topic/10/my-great-topic/
/topic/10/my-edited-topic-title/
/topic/10/
/topic/10/i-just-made-this-up/

The downside to this is that some may consider this duplicate content. You can now opt to redirect with a "301 Moved Permanently" header to the correct permalink. This again is transparent to the end user but it will help search engines locate the correct copy to index. You can also opt for IP.Board to simply add a 'robots' meta tag with the value 'noindex' if you do not wish to redirect. This will tell the search engine to not index that URL.

We hope that these improvements will be seen as a good first step in basic SEO without impacting performance.
  • 7,809 views
Matt

IP.Board 3 Facebook Connect

IP.Board will now support a basic implementation of Facebook Connect as an option for logging into IP.Board and associating their account with the same login as their Facebook account. This feature will be off by default and can be optionally enabled by the administrator. We will have a technical specifications draft available in our knowledgebase upon release for those who care, but the basics are as follows:

You must first register an "application" on Facebook's website pointing to the integration file included with IP.Board 3. You then must enter some basic keys that Facebook provides in your ACP. Users will have the ability to use Facebook Connect to login to your site. They will also have the ability to either associate their Facebook account with an existing IP.Board account, or create a new IP.Board account. Basic profile data such as avatar, profile picture, "About Me", and status will be synced to IP.Board from Facebook
We have purposely kept the complexity of the various syncing options available through Facebook Connect to a minimum. We have many ideas on how we would like to expand the capabilities in the future, but we wanted to keep this integration basic for the time being.

Facebook Connect support will be available with the second beta release of IP.Board, and will be available on the preview site to test with beginning Monday.

We hope you enjoy!
  • 14,372 views
bfarber

IP.Board Standard License and Conversion Sale

As we get closer to the final release of IP.Board 3.0.0 we have seen a huge increase in the number of clients converting to our software and services from other community software platforms. Of course we are always very excited to help anyone move to IP.Board and this is the best time to do the conversion. You can start getting familiar with IP.Board on the current 2.3.6 version and our staff can easily upgrade you to version 3.0.0 when it is available at no extra charge.

In addition to converting customers we have also seen an increase in IPB Standard License sales as new customers buy IPB now who are excited about the upcoming 3.0.0 release and want to get familiar with IPB now.

IP.Board Standard License Sale

Starting 9:00 am EST January 5, 2009 and ending 5:00 pm EST January 9, 2009 the price of an IP.Board Standard License will be reduced from $149.99 to $129.00 to allow everyone a chance to purchase IPB at this special, reduced price. The 6-month renewal price will remain the same.

Free Conversion Service

Our staff will convert your database to IPB at no cost to you. This is a savings off the normal $60.00 conversion fee! This applies to all software listed on the conversion information page. To take advantage of this offer, just email [email protected] by January 9th and our conversion team will take care of your database conversion for you. You will need to have an active IPB license to take advantage of this offer.



Please email [email protected] if you have any questions. Thank you!
  • 6,312 views
Charles

IP.Board 3.0.0 Beta 1 Refreshed

For complete information on the IP.Board 3.0.0 Beta 1 release please read the full announcement.

We have refreshed the download of IP.Board 3.0.0 Beta 1 to address a few critical bugs that were reported yesterday. The refresh is as of the time of this blog entry. We focused on installation bugs and core usability bugs for this small refresh so more people could install IP.Board 3.0.0 Beta 1 before the end of the year. Note that not all bugs marked as fixed in the bug tracker will be fixed in this build of the beta.

You can download the beta again from the client area and reinstall it as you did before. There is no need to download the beta again if you downloaded it after the time of this entry for the first time. Also, hosting customers can now download the beta in the "development tools" category in their download area.

Ioncube Encoding

IP.Board betas are Ioncube encoded so we can ensure that reported bugs are directly related to the code and not to modifications. While we do not mind people modifying, you can imagine how frustrating it can be trying to track down a bug that turns out is not even related to IP.Board's code.

Some have reported problems with installing using Ioncube. There are a few topics in the IPB3 preview forum which may help those unfamiliar with using Ioncube.

The final version of IP.Board 3.0.0 will not be Ioncube encoded.

PHP Version Compatibility

Beta 1 requires PHP 5.2.1 or greater to operate. We will be working on changes in the next betas to lower the version of PHP required closer to 5.1 or possibly 5.0. We will provide more information on those changes as they are available.

Reporting Bugs

Please search the bug tracker for a description on the bug you have found before submitting the report. We appreciate bug reports but it does slow things down when duplicate reports are submitted. This will become more important as bugs are fixed in preparation for Beta 2 but the fixes not yet released as it will slow down development if we have to sort through duplicate reports. Thanks for searching before posting - it makes a huge difference.



Thanks for all your help and happy bug hunting!
  • 1,990 views
Charles

IP.Board 3.0 Beta Approaching

As announced in our last blog entry, we are working diligently to clean up any problem areas in IP.Board 3.0 and to finish up the admin control panel so that we can deliver a beta release of our software to all of our users before the end of this month.

Things are taking shape nicely. Rikki has the admin control panel nearly finished and we've cleared out hundreds of bug reports since the preview site was first launched. We are very hopeful that by the time everyone has their hands on a beta version of IP.Board 3.0, you'll find all of the biggest potential issues have already been dealt with.

Additionally, the Blog, Gallery and Download Manager applications are coming along nicely as well. All of the application code has been converted, and we're working on skinning these modules so that we can put up previews for you to start testing. Look for the first of these modules to be launched very soon on the preview site so you can begin testing it.

In preparation for the upcoming beta release of IP.Board 3.0, we have put together this script which you can upload to your server in order to test for support of our latest version. Please note the following requirements:

PHP v5.1.0 or higher (5.2.0 or higher preferred) MySQL 4.1 or higher (5.0 or higher preferred) SPL, GD2 and libxml2 PHP modules installed This script will test for everything IP.Board 3.0 requires, except for MySQL. Please consult with your host if you are not sure if you are running MySQL 4.1 or higher.

check_requirements.php

To use this script:
Upload the file to your server somewhere that is web accessible. For example, you can upload the file to your forum root directory where "conf_global.php" is located. Visit the file in your webserver. For instance, visit http://yoursite.com/forums/check_requirements.php (replacing yoursite.com/forums/ with the appropriate domain and path to the script you just uploaded). Verify there are no "FAIL" marks reported. If there are any items that fail the check, you will need to consult with your host about updating your server, moving you to another server that supports all of the requirements for IP.Board 3, or contacting another host that does. We do not rely on any proprietary modules for PHP, so the majority of our users shouldn't have any problems. :)

We look forward to getting the first beta out so everyone can continue testing the software and the new admin control panel. More information to follow!
  • 4,699 views
bfarber

IP.Board 3.0.0 Status Update

The IP.Board 3.0 preview has been going quite well and we have received some good feedback and ideas for version 3.0 which we have already implemented. This blog entry will outline some of the changes that have been implemented in 3.0 since the preview was made available. Other than the changes listed here there have been lots of minor skin interface improvements and many bug fixes too numerous to go into.

Search Index

For a long time we have been looking at ways to solve a problem with global searching. Searching is very resource intensive and we are under pressure to deliver a comprehensive search that is both quick and light on the server. One solution we implemented on the preview board was a search index. This index contained the text from various sources such as posts, blogs and calendar events.

The search index was successful in making global searching quick and efficient but it was limited by MySQL itself. While it worked well on smaller boards, there was an issue with scaling in that MySQL does not deal very well with large tables. While the posts table would often lock in normal searching, the search index table would lock in many more situations thereby eliminating any benefits it brought to IPB. Also, when upgrading to IPB 3 the search index needed to be built which could potentially take many hours. This is obviously undesirable.

We also found that it limited what you could search for and how the results were displayed. For these reasons we have decided to remove the search index option in IPB 3.0. We will instead work on enhancing the normal search system (including some of the good ideas from the preview site) and large search solutions such as Sphinx. Removing the search index will not impact the overall ability to search and find content you are looking for and we will work on the normal search routines to make displaying the search results easier to work with.

Gravatar Support

Gravatar is as service that hosts your avatar so you can have the same avatar on the various communities you visit. It also allows you to centrally update your avatar and have it show up all over the web. You just sign up on their site and then enter your email address you registered with Gravatar in IPB 3.0's settings area.

Warn Panel Updates

The warn panel has been updated to allow for moderators to be able to better control troublesome members and posts without administrator intervention. Enhancements include:


Option to "ban" a member permanently from the warn panel Increase or decrease warn value by a custom value (rather than just +1 or -1) for super moderators only Ability to unapprove (hide) all member's posts and/or topics made with the last X days/hours Member's current reputation and other general information now displayed on warn panel

Mutual Friends

Adding and removing friends is now a mutual option in that if you add someone as a friend you will also appear on their profile as a friend. The same goes for removing a friend: if you remove a friend you are also removed from their friend list.

Reputation Logs

Administrators can now edit a member's reputation points. They can also view the record of ratings that member has left for others and the ratings others have left for that member.

Enhanced Watched Topics/Forums

The listing of watched topics and forums in your user settings now displays the number of new topics or posts since your last visit. You can click this link to be taken to the forum listing showing only those new topics since your last visit.

Filter Forum by New Topics

You can now filter a forum using the filter options bar at the bottom of the page to show only new topics posted since your last visit.

Public Polls

The option to allow public polls is now in the admin area. Public polls are like normal polls but they show the name of the members who voted and what they voted for in the poll. Administrators can also optionally allow members to delete their vote and re-vote in polls. This new feature only functions with newly-created polls. Administrators can switch a poll from private to public only if the poll has had no votes.



IP.Board 3.0.0 Release

The preview testing and feedback has been going so well that we have decided to reevaluate our release schedule. We will still have a downloadable beta version of IP.Board 3.0.0 out by the end of this year but a final version will not be out by the end of this year. Because the preview site has become so useful, we are treating it as a "pseudo-beta" and using it to test various features and learn about how IPB 3.0 behaves in a production environment. Although this will delay our final release until early next year, it brings the benefit of a much shorter beta-release cycle since IPB is being so heavily tested now. This means that we will have fewer beta releases before moving on to the final release. It also means that the final release of IPB will be as good as it can be which is good for everyone.

We believe that this short delay until the final release will be beneficial for all as the final version of IPB 3.0 will be as stable as it can be on day one.

Thanks to everyone for your help and ideas. We will keep you updated on our progress in the coming weeks.

  • 5,722 views
Charles

IP.Board 3.0.0 Preview Now Open to All

The IP.Board 3.0 preview has been going very well. Lots of bugs have been reported and, more importantly, fixed already. The feedback we have received has been very valuable and we have already implemented some of the good ideas our customers have presented us. Thanks again!

We are now ready to open the preview up to the general public. You can visit the preview at http://ipb3preview.ipslink.com and login with the same email address and password you use in the IPS client area or company forums.

A few things to keep in mind:

This is a preview of alpha software. We are not quite to the beta stage so please keep in mind that there are some areas still being finished up. The preview has been open for a couple weeks now to our customer base so lots of feedback and bugs have been posted. Have a look around what is already there before posting new info. Thanks!

As we have reviewed in previous blog entries, IP.Board 3.0.0 is very different from the version 1.x or 2.x series. So far the feedback from our private testing group has been great and everyone loves the new look and feel. We can never please everyone :) so please be civil if you do not like something that is purely a matter of opinion and offer a constructive suggestion we can consider if you feel something can be improved.

IP.Board 3.0.0 is feature-frozen at this point. We will not be adding any new features but are happy to consider enhancements to those already included. We will always have version 3.1 for feature additions and one of the best parts of 3.0's architecture is adding new features along with upgrading is much easier than the 2.x series so upgrades can be developed and released much faster.



We hope you enjoy!
  • 4,623 views
Charles

IP.Board 3.0.0 Public Preview Coming Soon

We are preparing the first public preview of IP.Board 3.0.0 alpha and look forward to everyone's feedback and help in testing. It is our current plan to preview IP.Board 3.0.0 alpha the second half of next week (around Nov 10 2008 +/- a day or two). As promised, those in the customer group on the IPS forums will receive the preview a bit earlier. Keep an eye on our company blog for updates.

The public preview will be on a special web site and will not be available for download. You can use the same login as the IPS company forums to login.


A few important notes...

This will be a preview of alpha software. We are not quite to the beta stage so please keep in mind that there are some areas still being finished up. We believe all functionality should be working properly but there are parts of the software that need some skin work. Some of the newest areas, like the new PM system, could use some extensive testing.

We ask that you help us test the functionality, click around the preview copy and report those issues that you find in the special area of our Bug Tracker for the IP.Board 3.0.0 alpha preview (will be available on preview day). When reporting please be careful to look over all already reported bugs to be sure not to submit duplicates. Do your best to try to break it... so we can then fix it.

As we have reviewed in previous blog entries, IP.Board 3.0.0 is very different from the version 1.x or 2.x series. So far the feedback from our private testing group has been great and everyone loves the new look and feel. We can never please everyone :) so please be civil if you do not like something that is purely a matter of opinion and offer a constructive suggestion we can consider if you feel something can be improved.

IP.Board 3.0.0 is feature-frozen at this point. We will not be adding any new features but are happy to consider enhancements to those already included. We will always have version 3.1 for feature additions and one of the best parts of 3.0's architecture is adding new features along with upgrading is much easier than the 2.x series so upgrades can be developed and released much faster.

Upcoming Beta Releases

We will use the public preview for our first round of testing and performance evaluation. Depending on how the public preview goes we will begin releasing downloadable betas. Expect updates on the beta release schedule in the week following the public preview.

Components like Blog, Gallery, and Downloads will have their own testing phase so please keep and eye out for those.



Thank you for your interest and everyone at IPS is looking forward to the public preview. We hope you are too and that you enjoy it!
  • 7,228 views
Charles

IP.Board 3.0 Miscellaneous Features

We've been blogging for a while about some of the bigger changes you will see when IP.Board 3 is released. Things like enhanced bbcode management, hooks and plugins, and personal conversations, for example, tend to be a bit more interesting to read than smaller features. However, we wanted to take a moment to discuss some of the other smaller features being added to IP.Board that we haven't talked about yet.

Minimum posts to view forum
You can now configure forums to only allow access if you have reached a minimum post count.

Minimum posts to post in forum
Similar to the previous setting, you can require members to have a certain post count before they can post in individual forums.

Only allow posters to see their own topics
A very commonly requested feature, you can now configure forums so that posters can only see their own topics. Of course moderators and admins can view all topics in the forum. This allows you to create "help-desk" style forums without the need for additional software.

HTTPS login form
You can now force your login page urls to utilize https via a simple ACP setting. You are still responsible for obtaining an SSL certificate and installing it to your server properly.

"Performance Mode"
We have several larger customers who have a relatively stationary amount of traffic, but have huge spikes at times (e.g. sports teams have huge spikes in traffic on game nights, typically). During these spikes it is often desirable to disable unnecessary features to maintain site stability, rather than purchase hardware to handle temporary spikes in traffic. The performance mode setting allows you to easily disable many features that can save resources with the click of a button. The system remembers the previous setting values so that when the spike dies down you can disable performance mode and return your site to it's previous configuration.

Registration "question and answer"
In IP.Board 3 you will be able to configure questions and associated answers which will be randomly added to the registration form to help combat automated registrations (spam bots).

Loading javascript files from Google
Google offers a service that allows you to load the prototype and scriptaculous files from their servers rather than your own. This offloads 2 http requests to Google's servers from your own, while allowing them to manage the proper cache and expiration headers for the files.

Guest selectable skins and languages
Guests can now change their skin and language selections if you offer multiple skins or languages. Note that skins can be configured to only be available to certain groups, so you can fine-tune which skins guests can select from.

Better topic/forum subscription controls
You can now unsubscribe individual members from all forums and topics from the edit member page of the ACP, and you can unsubscribe all members from individual forums from the forum management page.

More control over "friends"
You can now disable the friends feature globally via a setting, and individually on a per-group basis (e.g. to prevent validating members from using the friends feature).

Hide last post info for a forum
If you have a forum where different users have different configurations as to which topics they can view, you can hide the forum's last post info on the board index via a setting. This information is cached to improve performance, so it does not utilize permission-based lookups, thus the ability to hide it helps prevent topic information from being leaked.

Contact fields as custom profile fields
All of the contact fields (yahoo, aim, msn, etc.) are now custom profile fields, allowing you to more easily configure them to your liking (or remove them alltogether). Additionally, by default Jabber and Skype will be available for configuration.

Force an entire group to be anonymous
If you would like to force an entire group (administrators or banned members, for instance) to be anonymous upon login, you can do so easily now.

Moderate posts of an entire group globally
You can now configure a group to be moderated across the entire site via a group setting. This will force all of the group's posts and topics to be placed into a moderation queue before they are visible, regardless of individual forum settings.

Per-group signature restrictions
You can now control the maximum number of images, lines of text, and image dimensions for signatures on a per-group basis.


Here's a taste of some of the new features we haven't previously discussed (at least in any detail) which we hope you'll like. Let us know what you think!
  • 7,729 views
bfarber

IP.Board 3.0 and Blog, Gallery and Downloads

With the upcoming release of IP.Board 3, we will of course be updating our first-party components to be compatible with the new architecture. Releases of IP.Blog, IP.Gallery and IP.Downloads will be available alongside IP.Board 3.0 so that you can update everything at the same time and not have to worry about when your components will be ready.

We are working with the community project teams to help them get releases of Tracker and Shoutbox ready for 3.0 as well. They should be available at, or shortly after, the release of 3.0 to help ensure a more seamless move forward to our latest platform.

We've determined that initially for the big release, we will only be working for application compatibility between our components. We wanted to spend all of our time focusing on IP.Board itself to ensure maximum stability, especially given the fact that we are working on an entirely new platform. This means that you won't really notice any new features to speak of with the Blog, Gallery and Downloads updates. You will, however, notice much better integration between the applications and the board itself, and an updated look and feel for all applications. Some examples of this include


Integrated searching - one search form will search everything All application caches managed from cache management screen. All skin data managed from template editor screen. Ability to edit all group settings from group management page. All application permissions handled from one location. Ability to show gallery or blog data on board index through hooks
Shortly after the dust settles following the big releases, and everything is calmer and stable, we will be working on "big" updates for our first-party application addons. At this point, we are still discussing what new features would best serve our customers for Blog, Gallery and Downloads. Below is a list we've discussed that we think you'll like. What do you think of it so far?

IP.Blog
Site/group blog - a blog that can be created belonging to no individual member, but rather to the site as a whole (i.e. a company blog) or a group (i.e. a developer blog) Proper user-customizable headers RSS blogs - allow members to import their remote blog into your board "Blog this post" support

IP.Gallery
Ability to crop, rotate, dynamically resize images. Use Javascript for front end, then re-generate image using GD on backend when user saves. Fancy slideshow feature. Something like Flickr, but done completely in Javascript (no flash needed), little simpler probably. Better album control based on friendships - only allow friends to view album, allow friends to submit to your album, etc. Sub-albums Image tagging Correct category/album markers (ala IPB) Allow users to choose album covers from images in an album
IP.Downloads
Better and more abstracted support for file records. Ultimately the goal would be to allow you to submit multiple files to a single file record. Uses would include "contributed files", breaking single files into "parts" (i.e. for large movies), and multiple screenshots per record, for instance. Support for mirrors Ability to shut off "resume breakpoints" Better category control - template type system perhaps with ability to selectively override without ditching entire template More reliable upload progress meter Correct category markers (ala IPB) File tagging Dynamic and session-based download urls (when you start a download, create a new "url" for it that is only accessible for that session and is destroyed afterwards to further prevent hotlinking)
These are just some ideas we're floating around. Final feature lists will be determined after the release of IP.Board 3.0.

We know many of you have been wondering how component updates will be handled with this release, and we've stayed quiet mainly because we weren't certain what we'd be able to accomplish. Hopefully this information will help you plan your site updates accordingly.
  • 4,644 views
bfarber

IP.Board 3: Administration Improvements

Introduction
Administration is an important part of running your site. You need to be able to control your site the way you want to, and you need to be able to do it as quickly as possible. Not everyone has an hour or two to hunt down a setting, after all. Once you start to factor in the fact that other applications (such as IP.Blog, IP.Gallery and IP.Downloads) can integrate into this same administration control panel there are new challenges to take into account as well.

With IP.Board 3 we've made improvements to the ACP in an attempt to help streamline common administrator actions and make the overall work flow clearer and easier.

Navigation
Navigation is a tricky thing to manage once a project becomes as large as IP.Board has. We've broken navigation down into multiple areas to help you drill down and find what you are looking for. Firstly, each application is listed at the top of the page - that way you can jump to whatever application you need to edit right away (no more navigating to the "Components" tab to edit IP.Gallery categories, for example). Then, along the left hand column you will find an expandable menu which provides access to the main pages of the application, similar to IP.Board 2. For applications requiring it, context links and tabbing are then utilized within the main area of the page to facilitate your work flow. We realize without screenshots it may be hard to visualize the new ACP, but a primary goal throughout the whole process was to retain a level of familiarity so that existing admins will find navigating very natural, while improving the process where-ever possible.

Searching
One complaint we've heard over the years is that new administrators frequently have trouble finding where they need to go in the ACP. Searching is a natural inclusion to help people find what they need, and can even be helpful for seasoned administrators as a shortcut to get where you need to go quicker. We have added a live-search facility to the admin control panel to help you find what you need much much easier (and before anyone asks - yes, "live search" is like the search on apple.com :rolleyes: ). The settings page already had search functionality in IP.Board 2, but we felt that wasn't good enough. Many times the "setting" you are looking for is found when editing a group, not actually in the main site settings area.

To that end, the live search searches "settings", "pages" and "acp help" files. We have also included a method of adding keywords to these sections so that if we find many users are looking for an area through a specific keyword, we can easily add that keyword into the system so that searching for it will return the results people are looking for.

We will need your help once IP.Board 3 goes into beta testing with identifying areas that need keywords added for new administrators. What a wonderful way for all of you who are so eager to help out to give back to the community! And you don't even need to know PHP or HTML for this. :D

Better Integration
While we have mostly already gone into detail on this front in other blog entries, just to recap on the subject within the context of this blog entry, improvements have been made to areas of the ACP that people frequently need to plugin to in order to help improve usability overall. For instance, an application can now show per-group settings on the actual group edit form, instead of having to provide a separate disconnected page in the application itself (for instance, the "Group Settings" page of IP.Gallery - these settings are now directly include on the edit group form instead). Similarly, applications can plugin to the edit member pages of the ACP, all with no file editing required. Settings for an application can, as they could in IP.Board 2, still be included within the settings area of the ACP. This means you can edit a group and control all of it's settings, without having to go to each application separately to update settings for the group.

Permission Editing
Many applications have a permission matrix - a grid of checkboxes that control what each permission mask can do within that application. This system works so well that we centralized the functionality in IP.Board 3 to make it easier to reuse and control. In doing so, we've also created an easy method of updating settings for every application on a per-permission set level. That is to say, if you want to update the permissions for users in the "Validating" group, you can do so globally from one page - for all applications at once. Remove calendar permissions, forum permissions, and gallery access all at once, without having to visit each application individually.

Going along with this, many users have been confused with how permission sets and groups relate to each other. We hear often from administrators that they created a new group - now how do they set the permissions for that group? To make this easier to understand and manage, when adding a new group there is a field that will allow you to fill in a new permission mask name (if you want to set permissions for the new group differently from other groups). After you save the new group, you will be redirected to the page that allows you to edit that group's permissions globally. You no longer have to create the mask first, set all the permissions (in each application separately, as well) and then add the group afterwards, selecting the new mask. Now it can all be done in one simple, easy to understand work flow.

Template Editing
I can't give out too many details on the template editor interface *just* yet I'm afraid, but let's just say that template editing has been entirely overhauled. We have put a lot of thought into ways of making it easier to edit templates, CSS and macros to hopefully help administrators work through their skins in a much much easier fashion. Some improvements that you may find interesting:
HTML Syntax highlighting of skins when editing the templates in the ACP Condensed HTML templates make it much easier to edit an entire "page" without having to edit 8 separate templates that will be compiled into one page No more separate "Global board header and footer wrapper" area. We have, instead, made a wrapper template which includes the content of this area as well as the global_board_header, global_board_footer, member_bar, navigation, and a few other common areas shown on every page AJAX CSS editing. This was actually a specific request from Rikki - apparently it's rather inconvenient to scroll 3 pages down in the CSS file, edit a color, save it, and end up at the top of the file/textarea and have to find where you were at again. Go figure. Anyways - when you save a CSS file now, it uses AJAX to save the contents, and the page remains stationary so you don't lose your place.
Reordering content
Remember all those lovely reordering dropdown menus (e.g. in the forum management screen)? Or those wonderful up/down arrow combinations (e.g. in the component management screen)? While they certainly served their purpose, they were identified for IP.Board 3 as being both inconsistent and, well, old.

All areas utilizing reordering functionality for all of our applications will use drag-n-drop + AJAX javascript functionality in IP.Board 3. Want to move a forum up one spot, just drag it up there and you're done.

In Closing
We think you will find that all in all the ACP area will be much easier to navigate and utilize in IP.Board 3. Once we get into the public beta testing stages and you get a chance to review our changes we'll be eager to hear your opinions and suggestions on the new and improved administration area.
  • 5,864 views
bfarber

IP.Board 3: Kernel Improvements

Since IP.Board 2, we've had a "kernel" of classes which IP.Board uses but do not depend on IP.Board to use. A selection of these kernel classes includes DB management, file uploads, emailing, RSS parsing and reading, XML parsing and reading and our proprietry archive format XMLArchive.

For example, you could use "classUpload.php" and "classImage.php" in your own modifications or extensions to handle uploads and GD thumbnail generation. You would not have to initialize the registry or do anything else other than just include the file and use it.

As we took the plunge and went ahead with making PHP 5 a requirement, we were able to make some long-awaited improvements. Here are the high-lights.

Custom Fields
Josh has completely re-written custom field handling within IP.Board and this class ties it altogether. Josh uses just about every PHP 5 trick in the book including abstract classes, interfaces and ArrayAccess to provide a simple clean interface that can be used in almost any project. It doesn't have to be limited to just IP.Board's custom profile fields.

Graphing
Remco has extended this class to include many new graph types including "funnel", "bubble" and "radar" graphs so that presenting data is more relevant. As IP.Board 3.0.0 develops, we'll be making good use of these new methods for statistic reporting within the ACP.

GD and ImageMagick
Brandon virtually started from scratch with our GD image creation. He also wrote a class for imagemagick offering more choice for those who have it installed. It's now very simple to resize an image or add a watermark.


$image->init( array( 'image_path'    => "/path/to/images/",                       'image_file'    => "image_filename.jpg" ) );   //Set max width and height $image->resizeImage( 600, 480 ); // Add a watermark $image->addWatermark( "/path/to/watermark/trans.png" ); $image->displayImage();
$image = new classImageGd();










XML Parsing and Creating
We've had a class for XML parsing and creating since IP.Board 2 but it was a kludge of PHPs then primative XML handling extension and a hand-rolled class for when the XML engine wasn't available. These methods functioned well but were known to be memory intensive.
Thankfully, PHP 5 has much better native XML handling which I took full advantage of when rewriting this class.
I looked at simpleXML intially but found it too, well, simple for our needs so I went ahead and used the full DOM methods. This gives us full control over both reading and creating XML documents.

Here's how simple it is to create a new XML document:


$xml->newXMLDocument();   /* Create a root element */ $xml->addElement( 'productlist', '', array( 'name' => 'myname', 'version' => '1.0' ) ); /* Add a child.... */ $xml->addElement( 'productgroup', 'productlist', array( 'name' => 'thisgroup' ) ); $xml->addElementAsRecord( 'productgroup',                                             array( 'product', array( 'id' => '1.0' ) ),                                             array( 'description' => array( 'This is a description' ),                                                    'title'         => array( 'Baked Beans' ),                                                    'room'         => array( '103', array( 'store' => 1 ) )                                                 )                         ); $xml->addElementAsRecord( 'productgroup',                                             array( 'product', array( 'id' => '2.0' ) ),                                             array( 'description' => array( 'This is another description' ),                                                    'title'         => array( 'Green Beans' ),                                                    'room'         => array( '104', array( 'store' => 2 ) )                                                 )                         );                         $xmlData = $xml->fetchDocument();
$xml = new classXML( 'utf-8' );























This will produce this document:


  <productgroup name="thisgroup">   <product id="1.0">    <description>This is a description</description>    <title>Baked Beans</title>    <room store="1">103</room>   </product>  <product id="2.0">    <description>This is another description</description>    <title>Green Beans</title>    <room store="2">104</room>   </product>  </productgroup> </productlist>
<productlist name="myname" version="1.0">














This is how you'd parse that document:


/* Grabbing specific data values from all 'products'... */ foreach( $xml->fetchElements('product') as $products ) {     print $xml->fetchItem( $products, 'title' ) . "\"; } /* Prints: */ Baked Beans Green Beans
$xml->loadXML( $xmlData );











I'm sure you can appreciate how simple it is to use these new XML features!

XMLArchive
I created our XMLArchive format for IP.Board as a way of combining several files into one without using tar or zip which can be troublesome on some servers. XMLArchive is very simply file data in a basic XML format. I rewrote the class to make it easier to use and to add more functionality.

Here's how to read an archive:

$archive->read( "/path/to/archive.xml" ); print $archive['someDir/file.html'];
$archive = new classXMLArchive();



As you can see, we use PHPs ArrayAccess to transparently allow access to the contents of the fileset from the main class handle.

Here's how to create an archive:

$archive->add( "someDir" ); $archive->add( "anotherDir/anotherFile.html" ); $archive->add( "Create a new file from scratch!", "anotherDir/brandNewFile.html" ); # Save gzipped $archive->saveGZIP( "/path/to/archive.xml.gzip" ); # Save normally $archive->save( "/path/to/archive.xml" ); # Just return the data $archive->getArchiveContents();
$archive = new classXMLArchive();












For simplicity's sake, there is now just one interface to add files: "add()". Personally, the fewer function names to remember the better!

Naturally, this blog entry does not cover all the changes and improvements within the kernel classes but it does go some way to showing just how much energy we've invested in ensuring that IP.Board is as robust and efficient as it can be.
  • 2,941 views
Matt

IP.Board 3.0 Search Engine Optimization

We receive requests quite frequently to "add SEO to IPB". This is a very difficult request to quantify and to fulfill. What is SEO? What is wrong with IPB's positioning to search engines presently? What can be done better?

We've seen some suggestions over time that make sense, and some we feel would be better left to modifications. While we are not jumping full force into the "SEO" arena with IPB 3, we have made changes throughout the software that we believe will help you position yourself better for search engine indexing. This blog post will touch on a few of these changes.

Semantically correct HTML
The word "semantic" means the study of meaning in communication. Basically, when used in the context of an HTML document, to state that the source code is semantic means that the HTML tags used are appropriate for their representations. It wasn't too long ago that tables were used to position elements in your browser window, and 1x1px gif images were used to pad areas so things looked nice. Those days are (almost) long gone, and today's modern web pages are focusing on producing HTML source code that makes sense, while separating styling to CSS documents and javascript to external javascript files.

When IPB 3 ships it will validate as xHTML valid, and the source code will be semantically correct. Deprecated HTML tags and excessive and unnecessary tags (such as 3-layer nested divs) are not used, and the javascript is not obtrusive (*see comments). Screen readers and search engine spiders should find it much easier to read a topic generated by IPB 3 than IPB 2. Furthermore, all functions should work (although in some cases to a lesser degree) when javascript is not available. Heading tags are used properly and feature keywords related to the content on the page. They also cascade in a defined format so that they represent the content in a meaningful way.

*Note: HTML will be semantic and javascript unobtrusive to the extent possible. There are thousands of configurations, literally, and with so many browsers, options and features it is hard to make a blanket guarantee of this sort. Rikki has explained more about our goals for the skin in another blog entry if you are interested in the new skin.

Microformat support
Microformats are common ways to represent similar data. For instance, it is not uncommon for a random website to have some sort of news or articles data and some sort of user profile page for each user. Microformats were developed so that these common things could be represented in a common way to help further the web. By utilizing microformats, other webpages and scripts can parse your page and extract valuable data that they can then share. Even Internet Explorer 8 will be making use of Microformats for some of it's cooler new features, while other browsers already do or are also planning to.

IP.Board 3 makes use of several microformats to help your document make sense to tools that can read and understand these formats. Specifically, we are making use of the hCard, hCalendar, rel-nofollow, rel-tag, and rel-home microformats. We also make use of some other common relationship attributes where appropriate (such as "rel='help'" for the link to the help documentation), even though they are not necessary full-fledged microformats at this time. Furthermore, we will continue exploring and watching microformats, and applying them as they develop and relate to IPB.

rel='nofollow' Support
This is another common request we receive: making all posted links in topics utilize the "rel='nofollow'" attribute appropriately. Many users, on the other hand, have asked that we do not implement this. The idea is that search engines should understand "rel='nofollow'" to mean that the webmaster is not endorsing the link, so when the search engine follows it, the search engine shouldn't penalize the website the link is hosted on should they determine it was a bad link, or irrelevant to the linking site.

We have added a setting to allow users to enable this without having to make source code modifications. The rel='nofollow' attribute will be automatically appended to all urls posted and parsed through the normal bbcode routines when the setting is enabled.

Removal of "(Powered by Invision Power Board)" from board index
For years, since the beginning of IPB, the page title of the board index page has had "(Powered by Invision Power Board)" added to it if you did not purchase copyright removal. We did not disallow users from removing this text, however, and many users did.

We've gone ahead and bit the bullet, and removed this text from the base release.

Removal of "lo-fi" version
The lofi version in IP.Board was meant to provide a toned-down basic representation of the current topic or forum. It was useful for both search engines and mobile browsers. It was so useful, in fact, that many times when you reach an IPB in a search engine listing you will actually end up at the lo-fi page instead of the full-version page.

In IP.Board 3 we have removed the lofi version entirely in favor of the new output engine capabilities. A mobile skin can be set directly through the admin control panel, negating the necessity for an entirely different script to serve the content. This is the great thing about the MVC pattern for all you developers - leave the model and controller alone, and just change the view itself.

The relationship to search engine optimization comes into play when you consider that the lo-fi version and the full version are essentially duplicating the content from one another, and a commonly held belief exists that search engines penalize you for duplicate content. While we can't speak for what any given search engine actually does, we did feel this feature was deprecated and no longer needed given advances in the skin system in IPB, and have removed it entirely.

Changing of modes moved to user control panel
It's not uncommon for a search engine to index a link to a topic on a site running IP.Board, and for some unknown reason decide the topic is best represented when "&mode=outline" is added to the URL. While this doesn't stop you from visiting the page, it DOES change the layout of the page, and for newcomers some of the alternate layouts may not be as easy to follow when they first visit your site.

Many users do utilize the different layout options (which are handled on a per user-account basis) so we did not feel it wise to remove these options. Instead, we have moved the ability to change the layout of topics to the user control panel. This should stop search engines from indexing topics with "mode" parameters in them, reducing confusion for visitors actually clicking the link to visit your site.


Additional features
Additionally, we've already gone over a few other changes that are related to better search engine positioning which we need not repeat here. Just as a brief recap, you may also be interested in reading these blog entries


Friendly URLs will be in IPB3 New user agent management used for search engine spider configuration (in addition to other things)

There are many more minor but important improvements buried deep within IP.Board 3 that should help you keep your site listed in search engines appropriately. While we won't jump on the SEO bandwagon and advocate certain styles of running your site or formatting your urls, we are doing our part to bring basic functionality our users have requested with regards to their site's optimization into reality with IPB 3.
  • 15,068 views
bfarber

IP.Board 3: Networking And Integration

Brandon blogged a while back about IP.Board's integration points.

I wanted to spend a moment discussing the features within IP.Board 3 that all you integrate the board with your website and to create your own network.

Member Management
Since IP.Board 2, we've had, what we call, "Log In Modules". This is basically a mini-framework to allow custom code to be used easily when authenticating and registering members. For example, if you had a database full of members and you wanted for them to be able to use their existing usernames and passwords, you could add a log in module to query your database or other system (via SOAP, XML-RPC, etc) for authentication.

This system has been enhanced based on user feedback and IP.Board now ships with modules for LDAP and OpenID which will make it much easier to use existing authentication.

Networking
The log in modules also tie into our 'IP.Converge' product which allows you to share authentication details across multiple IP.Board installations. The IP.Boards don't even need to be on the same server! In fact, we use Converge and the log in modules ourselves so that our customers can use the same log in details on the forum as they do in our ticket center.
You could use this functionality to share members across many forums, creating a true network of members.

Using the IP.Board Engine
We've made no secret that IP.Board 3 is a complete rewrite. The new framework makes full use of PHP 5 and incorporates many timesaving features that you can instantly make use of.

It's common for our customers to ask how they can use certain parts of IP.Board within their own website. For example, they'd like to show a list of recent topics or posts. That's no problem as we've had an API class interface since IP.Board 2.

However, if you wanted to send data to IP.Board, such as a new post or new personal message; things got tricky. Even using a template bit required a lot of code copying.

For example, if you wanted to make use of our database engine or templating engine, you would need to copy a lot of 'index.php' so that it set up ipsclass correctly. With IP.Board 3, that is no longer required. You can use our engine in your own scripts as simply as this:


  require_once( IPS_ROOT_PATH . 'sources/base/ipsRegistry.php' );    $registry = ipsRegistry::instance();  $registry->init();
require_once( './initdata.php' );





Those few lines of code give you access to: Caches, settings, member management, database management and more.

Writing your own code
Quite often, you want to add some IP.Board functionality to your own website. With IP.Board 3.0.0 it's very simple.

You want to add a new post? No problem, simply use that code above and add:


    $postClass = new classPostForms( $registry );  $postClass->setForumID( $forumID );  $postClass->setForumData( $this->registry->class_forums->forum_by_id[ $forumID ] );  $postClass->setTopicTitle( "My Topic" )  $postClass->setPostContent( "Hello, I am post content!" );  $postClass->setAuthor( $memberID );    try  {      $postClass->addTopic();  }  catch( Exception $error )  {      print $error->getMessage();  }
require_once( IPSLib::getAppDir( 'forums' ) . '/sources/classes/post/classPost.php' );

















It's really as simple as that! Note the try -> catch block? That's consistent with all the new API-like functions. We take advantage of the PHP 5 exception handler to return information on what went wrong. We also list all the possible exceptions that are returnable in the phpDoc for that function.

Of course, seasoned modification authors will already be familiar with functions similar to those present in IP.Board 2's API system. The good news here is that this functionality doesn't require an API bridge anymore, it's the exact same code that is used in the normal posting routines.

Do you want to send a new personal conversation to someone in your own code? Simple!


  $messengerFunctions = new messengerFunctions( $registry );  $messengerFunctions->sendNewPersonalTopic( $toMemberID, $fromMemberID, $invitedUserIDArray, $msgTitle, $msgContent );
require_once( IPSLib::getAppDir( 'members' ) . '/sources/classes/messaging/messengerFunctions.php' );



Want to get a list of PMs in your own code?


  $messengerFunctions = new messengerFunctions( $registry );  $messengerFunctions->getPersonalTopicsList( $memberID, 'in' );
require_once( IPSLib::getAppDir( 'members' ) . '/sources/classes/messaging/messengerFunctions.php' );



Another common request is to use IP.Board's templates in your own projects, again this is as simple as:


  require_once( IPS_ROOT_PATH . 'sources/base/ipsRegistry.php' );    $registry = ipsRegistry::instance();  $registry->init();    print $registry->output->getTemplate( $templateGroup )->templateName( $templateArguments);
require_once( './initdata.php' );







There really is so much that you can do. Listing them all would make for a very large blog entry indeed! We will of course be providing a lot of documentation on these new features.

Combine this functionality with the new hooks and plug-ins system and you've got a very quick way to build new code using our core. We're very excited to see what you do with it!
  • 4,841 views
Matt

IP.Board 3: Personal Conversations

Around ten years ago, I was hard at work on one of the first 'Private Message' modifications for a board that has long ceased to exist. At the time it was an exciting novelty to be able to message another board member. These days it's an expected feature for any seriously considered forum software.

Not much has really changed with messaging's core features. Sure, the interface has become a little smarter and there have been a few little bells and whistles added such as message tracking but ultimately it's still sort-of email based in functionality.

This was a limitation I noted when developing IP.Dynamic. In fact, almost two years ago, I blogged about Personal Topics, the next logical step in private messaging.

Enter Personal Conversations
As, with most of IP.Board 3.0.0's new features, personal conversations - as we like to call them - have been a popular request. A request that we have now fulfilled! Why bother CC-ing and forwarding messages to other members when you can invite them right into the conversation?

How it Works
Where you would normally 'compose' a new message, you now 'start a new conversation'. The form looks largely the same. However, instead of there being a space to "CC" other members, there are boxes for you to invite other members. How many members you can invite is up to the administrator as it's limited to your group settings. In fact, the admin could remove your ability to invite other members completely if they desired to return to a more traditional messaging system.

The recipient and each invited member will be notified they have a new message (in terms of notification, a message is either a new conversation or a reply to any existing conversation). The new conversation will appear in both their "Inbox" and their "New" folders. It will remain in their "new" folder until its read and then it will only be available in the inbox. Why? Well, because of the magic folders. But more of that in a moment.

The conversation looks largely the same as a normal topic does; linearly sorted with the newest replies last. There is even a "fast reply" form much like you use when replying to topics. This instantly makes it easier to view previous replies and keep the 'thread' of conversation without having to delving into your 'sent' folder to see what you replied with.

The topic starter (and any participating super moderator) can choose to 'block' any participant that is blockable. Immunity from being blocked is granted by the "Not Ignorable" setting. This means you can ensure that you (the admin) can never be blocked from a conversation you are participating in. When a participant is blocked, the topic vanishes from their folders until they are unblocked.

Each participant apart from the topic starter can choose to leave a conversation at any time. Once the participant has left the conversation, it is only available in the magic "Finished" folder and the replies no longer count towards your space allowance. The topic starter cannot re-invite you but you can choose to rejoin the conversation at any time.

The topic starter can choose to invite more members (up to their invite allowance) at any time from the conversation display screen. Each participant can also view all participants and see the last time they read the conversation.

Magic Folders
This is the term we give to certain folders that are not editable or removable. They are: "New", "Finished", "All" and "My Conversations". Topics in "New" and "My Conversations" can also be in other folders. "My Conversations" is the default location for any conversation you start. You can then move into another folder -- but it will always be accessible from "My Conversations".
"New" simply lists any new personal conversations or any personal conversations with new replies. So, you could have a conversation in "My Folder". When it receives a new reply, it will also be listed in "New" until you read it.
"Finished" simply lists all the conversations you've left, allowing you to rejoin if desired.
"All", as the name implies, lists all the conversations you are participating in as either a starter, recipient or invitee.

We think this is a very exciting step forward for personal communication and opens up new ways to communicate via the forum. Ten years is a long time to wait for change. We hope you find it worth the wait!
  • 12,717 views
Matt

IP.Board 3 Testing Procedures

As we get further along in the development cycle for IP.Board 3 an obvious step that we will be taking on soon is general testing of the new codebase. While this happens with every release, both internally and publicly, it is even more important for a release as immense as IP.Board 3. The entire underlying codebase has changed and vigorous testing will be needed to iron out all of the issues us developers have missed.

With every test phase of a product release, we frequently get barraged with requests from customers asking to be a part of the testing process. We wanted to let everyone know that we have come up with a process for IP.Board 3 that we think will please everyone - everyone will be able to test the new release if they wish to. :)

Progress is happening at an astounding rate, and right now we're working through bugs that we have identified and putting finishing touches on much of the software. The skin is still heavily being developed and worked on, both on the front end and in the admin control panel. Trust me when I say we're just as eager to get people in and show off what we've been working on as you guys are to see it. Please bear with us as we continue working on these rather unexciting yet necessary steps. We know you're anxious to see it and we want to ensure that what we deliver is what you are expecting. To that end, please also understand that future blog entries may be a little less exciting than they have been for the last several weeks.

All of us have begun testing IP.Board 3 internally. As we discover unfinished areas or bugs, we are working hard to rectify these things to get IP.Board 3 as stable as possible. We are still working through bug reports from previous versions of IP.Board, as well, to get IP.Board 3 off to a fresh start with as few bugs as possible.

Once we feel that IP.Board 3 is relatively stable, and that we have worked through all of the issues we have found internally, we will be inviting our customers (you!) to take a look and to give us your feedback. This first stage of testing we expect to remain tightly controlled, with us hosting a copy of IP.Board 3 and providing you access to this copy. You will be able to use the features and we would love for you to report back your comments on the functionality, the skin, and any issues you find. More information about what we will be looking for exactly will be available once we reach this point.

After we have ironed out all the bugs and addressed all of the feedback we can, we (as per our usual procedures) will be updating our company forum. This helps give us a chance to really test out the new release in a live environment. You'd be surprised at some of the issues that never come up during development and basic testing that come up when you move to a live environment. This also helps give us a chance to test the software under a real-world usage scenario, giving us information about resource usage and areas of the software that we feel need improvement to be able to handle today's large forums. We are dedicated to ensuring that IP.Board 3 runs efficiently so that you can don't have to worry about how your site runs, but rather how you run your site.

Finally, once we've gotten to this point and feel we've nailed down all of the bugs we can (or at least most of them) and we feel the software is stable and resource-friendly, we will open up IP.Board 3 for public beta testing. This is the point where you will be able to download IP.Board 3 and install it on your own servers (but not upgrade your live website) so that you can test it to ensure that our next generation release will meet your needs. There are, quite literally, thousands of different configuration scenarios and hundreds of different server environments out there, and this stage of testing gives us a chance to help make sure IP.Board will run properly and bug-free in as many setups as possible.

Throughout this process, we will be contacting modification authors, community project teams, and skinners to help get them started as well. We would love for IP.Board 3 to launch and have resources available right from the start, or as shortly there-after as possible. While we have no control over third parties integrating with our software, we will do what we can to assist these developers so that our customers will have as short a wait as possible for the software they need to run their sites.

From there, we plan to follow the normal routines we follow for release. We will correct reported bugs, test them internally, and release public betas for further testing. When we feel we are ready for release, we will put out a "Release Candidate" version of the software. This release is one that, to our knowledge, should be ready for prime time, but we are providing another chance for customers to test it and report back any issues that they have found so that they may be addressed before we release the software as "final" for general public usage.

We know everyone is excited about IP.Board 3, and eager to get a look at what we've been working on for the last several months. We are eager to show it off, and are looking forward to the testing phases described above. These phases give us invaluable feedback from the most important users - you!
  • 4,497 views
bfarber

IP.Board 3: Friendly URLs at last!

Possibly the most often requested feature we've had since the very first version of IP.Board is 'friendly URLs'.

Although this sounds like you'd expect your URLs to greet you with a self-empowerment phrase first thing in the morning, it really relates to making the board generated URLs a little more attractive to both humans and search engines.

I am being very careful to avoid the phrase "Search Engine Optimization" in this opening few paragraphs despite it being used often in the request for friendly URLs. What we've added will definitely help with SEO but it's not a complete solution and neither is it intended to be.

So, what do you have?
In a nutshell: friendly URLs! The process to create and manage them is far more interesting than the end result, but more on that in a moment. Lets first look at some examples of the new URLs.

Here's a few sample URLs from IPB 2.3.x:

To show a forum (My Test Forum):
www.board.com/forums/index.php?showforum=10

To show a topic (My Test Topic):
www.board.com/forums/index.php?showtopic=99

To show a user (Matt Mecham):
www.board.com/forums/index.php?showuser=30

There's nothing wrong with those URLs. They are short and concise and they spider very well, but we can do a little better to make them more attractive.

If you are on a Windows webserver, you can use the 'query' string method which presents URLs like this:

www.board.com/forums/index.php?/forum/10/my-test-forum
www.board.com/forums/index.php?/topic/99/my-test-topic
www.board.com/forums/index.php?/user/30/matt-mecham

If you are on an apache based web server you can make use of the 'path_info' method:

www.board.com/forums/index.php/forum/10/my-test-forum
www.board.com/forums/index.php/topic/99/my-test-topic
www.board.com/forums/index.php/user/30/matt-mecham

Even better, if you can manage your own .htaccess files, you can make use of the mod_rewrite functionality. For convenience, the mod_rewrite code is generated for you. The end result looks like this:

www.board.com/forums/forum/10/my-test-forum
www.board.com/forums/topic/99/my-test-topic
www.board.com/forums/user/30/matt-mecham

What would happen if you used accented characters like this: M
  • 20,047 views
Matt

IP.Board 3 Error Handling Improvements

It is necessary in any application to handle error situations. The most common method of handling such a situation is to issue an alert to the user so that they know an error has occurred. While this is sufficient in most cases to resolve the problem, we wanted to address IP.Board's error handling routines a little bit with the upcoming release to try to make them a little more useful.

Firstly, we've gone through all of the errors that are issued, and clarified and separated them. No more obscure "Sorry, some required files are missing" error messages when doing something as simple as visiting a topic that has been deleted. The error messages should be much easier for the end user to understand with the upcoming release.

In addition to updating the error messages themselves, we've added unique error codes to each and every message. The error codes follow a defined format so that in the event you need to submit a ticket and reference an error message you received, by providing the error code our technicians can look up more information on the error and easily find where and how it was triggered. This should help make technical support more efficient for all of us.

At some point following the release of IP.Board 3.0, we intend to make public this error codes database so that users can easily look up more information on errors when they need to by themselves.

Further to this, we've added error logging. By default, certain errors will trigger a log to be generated. Generally, these logs are only generated when an error has occurred that could indicate a user is attempting to bypass security restrictions. Some administrators may want to trap more errors, however (perhaps even all generated errors), and as such we've added a setting that allows you to force IP.Board to log all errors above a given level (levels range from 1 through 5). Additionally, you can opt to be notified of all errors triggered above a certain level. For instance, if you want to know about all level 5 (serious) errors encountered right away, you can have the board email you when such an error is generated. This can help you administrate your board more effectively and securely by identifying issues you didn't know existed (for instance, in a custom modification), and can help our technical support drill down on issues that are unique to your site.

The log pruning task has been updated to support the new error log tables so you can prevent it from growing too large.

We have some more ideas for improvements to the error system in general to provide more value and assistance for you and your users. Errors are a necessary part of application development, but we are doing our part to make them as friendly and manageable as possible.

If you have more ideas for improvements to the error management system in IP.Board 3 please share them with us below!
  • 3,969 views
bfarber

IP.Board 3: Topic Marking Overhaul

Topic markers have evolved quite a bit over the past few years. What started out as being an almost secondary concern has become quite an important part of the user experience.

A Very Brief History
Early versions of IP.Board relied on cookies to track read topics. This worked fairly well but it wasn't without problems. Anything to do with cookies is always a little flaky. There is a very finite amount of information you can store and browsers have a habit of eating them or not setting them correctly. The biggest complaint, however, is that topics that you have read on one computer do not stay read on another computer.

IP.Board 2 introduced topic markers that are stored in a database table. This greatly increased stability and allowed the read topics to remain read regardless of computer used.

However, this did lead to some performance issues on busier boards as the topic marker table is often in demand whcih can result in locking issues and processes queueing. Also, the code wasn't centralized and sprawled through different files making maintenance very difficult.

Learning From Experience
It was obvious we needed to centralize all the code and create a common, simple public interface as a matter of course. We also wanted to allow our other applications (such as blog and gallery) to use this system without having to copy code. Making it truly extensible also allows modification authors to use this centralized system without having to maintain their own code.

Next up was the performance issue. How could we increase performance without losing functionality? The most obvious answer was to store the read topics in the user's session. This was fine in principle but there were obstacles to overcome. First of all, session handling in IP.Board 2 is not entirely centralized. There is a class but it is not used exclusively. Other files such as register.php and login.php are allowed to modify the session table without telling other classes what it did. When you're trying to preserve data, this cannot be allowed. Also, session handling in general isn't an exact science. IP addresses change meaning new sessions can be created several times during a single visit.

The solution to these problems must be robust, centralized and extensible.

So, what's new?
First up was tightening up session handling. All session management is now performed through a single class (publicSessions). Other files that need to manage sessions are done so via publicSessions. This allows this one class to keep tight control over the session data.

The biggest challenge was to allow sessions to handle the marker data and only allowing the markers to be written back to the database table when the session is deleted. The theory is sound and simple but the execution a little trickier. The gory details of which are explained a littler further down for the technically minded.

In brief, the system loads the markers from the database table when a new member session is created. The markers are saved in with the rest of the session data when the session is updated at the end of a page view (to update the running time and location, etc). This continues until the session is due to be removed, for example, when the member is no longer active and the session is older than the allowed time. The sessions to be removed are captured and allowed to be examined by other classes. The item marking class examines these sessions and writes back the marker information to the marker database. The system also makes use of cookies to give some permanence for guests and those that are not logged in. The cookies are limited to the last 100 items read to prevent cookies being sent that are too large.

The end result is a much leaner system which should be much more efficient and presents a very simple public interface. Here's some sample code to give you a taste:


$itemMarking->markRead( array( 'forumID' => 2, 'topicID' => 10 ) ); # To fetch the read status of an item if ( $itemMarking->isRead( array( 'forumID' => 2, 'itemID' => 99, 'itemLastUpdate' => 1200098989 ) ) === TRUE ) {     .... } # To fetch the last time an item was marked $lastMarked = $itemmarking->fetchTimeLastMarked( array( 'forumID' => 2, 'itemID' => 99 ) );
# To mark an item read (an item is a topic for the forums 'application')











Modification authors can write their own plug-ins and make use of the system with minimal coding effort.

Listen Up, Here Comes The Science Bit
For the more technically minded, this section explains how the system works within the new IP.Board 3.0.0 framework.

The first challenge was to make proper use of __construct and __destruct within PHP 5. This is very straightforward in the case of __construct; this is run when the class is initialized. There are no problems with that. The item marking class grabs and filters the cookie data and also grabs and filters the session item marking data in __construct.

The real issue is with __destruct. Specifically the order in which they are called. In PHP 5.0.0 to PHP 5.2.4 they are called in the order they were created. This means that by the time __destruct() is called in item Marking the DB connection has been closed which isn't at all helpful. This is because the DB is set up before classItemMarking. Now, as of PHP 5.2.5 the __destruct order has been reversed. This means that the DB connection will still be available.
However, that's not very convenient for code that has to be robust on different platforms and with unpredictable version of PHP. Another solution was needed.

Thankfully register_shutdown_function() executes before any __destruct() calls, so we can reliably use this. There is a __myDestruct function in the ipsRegistry class which calls __myDestruct() in all the registry child classes (DB, Member, Request, Cache, Settings, etc). The member registry class makes use of this to fire a manual destruct function within itemMarking to allow it to save back any data for deleted sessions and to provide information for the session update. A __myDestruct fires within the public session class to actually update the sessions and delete the expired ones.

Phew! As you can see, there's a lot going on behind the scenes in IP.Board 3.0.0 which makes full use of all PHP 5 has to offer.
  • 4,251 views
Matt

IP.Board 3: Skin update

We wanted to use this blog entry to bring you an update on the brand new IPB3 skin. In my previous entry, I didn't go into any detail about the skin itself, but I did introduce the Style Guide and some goals/ambitions for the front-end interface. We're now at a stage where we can talk about the skin itself.

Whereas most of our other entries explain one particular feature in-depth, this post will be more of a quick-fire overview of some of things we're implementing on the front-end of IPB3, and some other tidbits.

Popup Windows
We took the decision to try and eliminate all popup windows from IPB3. Popup windows create several problems: in this day and age, you can't guarantee a user will even see them due to popup blockers, and secondly, with the myriad devices accessing the internet now, you can't be sure that a popup window will be supported, or a good user experience.

Instead, where browsers support it, inline ajax-populated popups are being used. Where browsers don't support it, the user is taken to the content like they would any other page. Our goal is to keep the entire experience confined to one browser window/tab, as I believe it should be. This includes friends management and warning management (for moderators).

Unobtrusive Javascript
Going hand-in-hand with the above was a desire to make IPB fully usable even if you had javascript disabled. As such, we've worked to make every feature, as far as is possible, available and usable even without javascript. There are some exceptions to this, e.g. the post editor (although you can still post, you'll just see a textarea), but on the whole we're on our way to making IPB3 much more accessible than IPB2.

Getting at user information
IPB has a lot of relevant information about each user, but presently it can be tedious to access the important details quickly since you have to go to their profile, taking you out of your workflow. New to IPB3 is a user card which can be accessed almost anywhere; wherever you see a username, simply hover over it to get all the relevant information for that user, including photo, contact details and reputation. This has been implemented in such a way that skinners and modders can also integrate it incredibly easily. We've also added a new bbcode which allows users to create these special links from within their posts.

Better uploading tools
In the past we've had numerous calls for TRUE multiple attachments. You'll be pleased to know that we've fully integrated SWFUpload into IPB3 for webservers that support it (which should be most). For those unfamiliar with this tool, it allows users to select multiple files in the Open dialog, and javascript then manages the upload queue for you. Another cool improvement is we now support upload progressbars with no additional server requirements! In addition, if you upload images, you'll see a thumbnail immediately, making it easy to insert the right image to your post, right where you want it.

Searching
The search form and results page have both been completely redesigned. Since the search mechanism in IPB3 underwent such a big change in being able to search all applications at once, we needed a new interface that made this easy to use. The result is a search form that adapts, showing you additional filters based on the applications you've chosen to search. The search results page combines all results from the applications you selected, but also allows you to show the results from just one application at a time. And finally, multiple results from one object (e.g. several matching posts in one topic) are grouped together so it's really easy to see the breakdown of your results.

Other significant improvements
While almost every page of IPB3 has been recoded from scratch and improved, some areas have undergone more changes than most. I'll cover them briefly so you know what you can expect when we unveil the skin:


Improved board index
One of the first steps I made when developing the new skin was to look at each major page and figure out if it could be made more useful than it is now. One result of this process was to improve the board index - and the new hooks system made this possible. The board index now features a collapsible sidebar, showing relevant information such as recent topics, top posters and more. Naturally, since this is hook-based, mod authors will be able to easily add their own data to this area.

User control panel
The control panel was a big focus right from the start. We first knew we were going to remove the messenger from the UCP, since it didn't fit conceptually. What was left has been redesigned, with settings broken down into tabbed sections, showing only the menu for that section - this should prevent new users from being overwhelmed when they open their UCP and seeing so many links.

Messenger
As noted above, the Messenger is now its own complete section, reducing clutter.

User profiles
User profiles have been redesigned, bringing them more into line with what users might expect from their favorite social networking sites. One new feature we're excited about is a Recent Activity feed, which allows you to see quickly what content a user has contributed recently, be it topics or posts, calendar events, images and more. This is made possible by the search index, which we covered in a previous post.

Media tag
We've added a new bbcode tag, which will insert all kinds of media right into a post. If you put a YouTube link in a media tag, it'll insert the YouTube player; similarly, if you link to a Flickr album, it'll insert a Flickr slideshow. New media handlers can be created in the ACP for those sites we don't support out of the box, while still using the same tag - making it really simple for your users.

Quick PM
One last feature to mention - we have implemented a Quick PM feature, which allows you to PM a member from topic view without leaving the page. We hope this increases personal communication, and reduces the chance of topics going off-topic.


I hope that gives you some idea of what you can look forward to with regards to the front-end appearance of IPB3. We'll be previewing the actual design of the skin in the coming weeks as we ramp up testing, so if you have any questions, comments or suggestions on the things I've covered here, now is a good time to get them out!
  • 6,197 views
Rikki

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.