Help
I will be purposely vague in this first blog entry about IP.Board 3.0's development and let our development staff get into detail in future blog entries. While not promising a set schedule, you can expect an update from a developer almost weekly going into detail about a specific change or new feature.
Our full new feature list is very long but here is a sampling for everyone. Our development team will go into detail about each one in the coming weeks and also introduce all the other additions not mentioned in this introduction.
Interface
There will be a great focus on usability and streamlining functions. The introduction of a new template engine which allows for multiple default template sets, easier skin editing, and a brand new default skin is something we are very excited about. Search engine friendly URLs will not only make your community more interesting to search engine spiders but allow for more human-friendly linking.
Control
The overhauled BB Code manager along with moving all default BB Codes to the system so you can edit them will allow forum administrators greater control over how their users interact with the community. We are implementing greater configuration options including being able to turn off features you do not use and finer controls on current features. Finer tuning your user signatures, turning specific options off, or even removing entire sections such as the calendar will allow you to gain finer control of how you want your community to be presented.
Features
There will be quite a few new features but, for now, we will save those for our upcoming blog posts to reveal what's new. A quick sampling: user reputation system, more permission configuration options, moderator enhancements, and ... lots more.
Reputation system
One of the most requested features of the past few years has been for a reputation system and we've already announced that it will be included in IP.Board 3. We're very excited to finally be releasing the details of this new feature and hope that you will enjoy this new feature!
A user's reputation will be displayed on their profile and is based on the number of points that user has. You can configure 'Reputation Levels' in the Admin CP, a level includes text and/or an image, as well as the point value needed for that level. The point value can be either positive or negative, so you could create a level system like this:
* -50 Negative Level 2
* -25 Negative Level 1
* 0 Normal Level
* 25 Positive Level 1
* 50 Positive Level 2
A user receives or loses points when other users vote up or down the content they have submitted to your community. Forum posts, gallery images, blog posts, etc will all have +/- buttons that your members can use to vote on the associated content. This system is entirely modular, which means that modification authors can also include the reputation vote buttons in their mods and your members can vote on that content as well.
The forum includes filters to view or hide posts based on the number of points that post has received. So you can choose to hide all posts that fall below -25, or any other value that you set. This system works much like the ignore user feature, the post will be hidden with an option to view it anyway. It is also possible to set an upper threshold that will highlight posts that have more than X amount of points.
The system has several configuration options as well. You can choose to allow your members to only give positive votes, or only negative votes, or both positive and negative votes. You can choose at what level content becomes 'highlighted', you can exclude specific groups from the reputation system, choose if the reputation is displayed on profiles, and choose if the total point value is displayed on a post or other type of content. You can also limit the number of positive and negative votes that a user group is allowed to give in a 24 hour period.
We hope you enjoy this first look at the new reputation system, in the coming weeks we will be releasing more information on this system, including screenshots! As always, please let us know what you think of this feature, you're feedback is invaluable in finalizing all the new features in IP.Board 3.
The "all new" Output Engine
Way, way back in the early days when we were planning IP.Board 3, a primary consideration was to completely overhaul the output engine to add several new features and to increase extensibility.
Out with the old...
The system in IP.Board 2.x is really just a perfunctory "engine" build around a few methods in a class. There was no real cohesive structure with many different files and functions accessing 'skin' methods. We decided that a virtual re-write was required.
We didn't want to be tied to a single output format. Back when IP.Board 2 was first written, there were no iPhones and the idea of actually viewing a forum on a cell phone seemed more than a little crazy. Times have changed.
...and in with the new
At first glance, the new system isn't that different from what we had in IP.Board 2. It's when you scratch the surface that its power becomes more obvious.
The first change is that you can have an unlimited depth for child skins. In IP.Board 2 you could only have one level of child skins which was very limiting to some skinners. Also, in IP.Board 2 there was a single master skin from which each skin inherited from.
While there is still a single "master" skin in IP.Board 3.0.0, it's completely transparent and instead you can set up several different "root" skins for which child skins inherit from. This instantly makes for more flexibility.
In IP.Board 3, each skin can have multiple CSS files which can be hard-positioned within the ACP to ensure the correct load order for correct cascading.
Also, each skin allows you to set group-based permissions so that you can determine exactly who can view and select skins.
And finally, guests can select a skin (as long as you give them permission to do so!)
Going Deeper: User Agents
IP.Board has a completely new user-agent system where you can add new user-agents and group together several. This system is now used for the 'search engine spider' settings.
This also means that you can tie a user agent to a specific skin. Do you want your iPod touch and iPhone users to use a specific skin? You can do that very easily within the ACP. Taking it further, you can even designate specific versions for each user agent. Do you want to take advantage of Firefox 3 or IE 8? That's very simple to do now. You can even set a range of versions very simply.
Going Deeper Still: Output Formats
The biggest change is that IP.Board can now handle multiple output formats. By this we mean that IP.Board has a plug-in architecture to allow completely different processing for HTML, XML or even WAP. This system is completely extensible so modification authors can easily write their own engine plug-ins which drop in and are available for use immediately.
Each skin must choose an output format to use which means that you can have completely different skin sets for XML and HTML bringing in even more flexbility.
You can also use a "gateway" file to set the output format. IP.Board 3 ships with two gateway files. "index.php" which is tied to the HTML output format and "xml.php" which is tied to the XML output format. This means that "index.php?showforum=1" and "xml.php?showforum=1" enable the correct output engine instantly.
Putting it Together
Take this scenario: You want to support WAP using XML with XLST templates specifically for Nokia cell phones. Done, done and done. All without having to make a single PHP modification.
Now that's a powerful system!
IP.Board 3 Centralizes Reported Content
Managing reported content in IP.Board 2 and our first party applications for IP.Board 2 is decentralized. When a user reports a post due to inappropriate content, moderators assigned to the area in question will receive either a private message or an email to alert them to the post, and it is then expected that a moderator address the inappropriate content. It can become difficult to track who has done what, whether the report has been addressed, and so on.
Luke wrote an addon for IP.Board 2 that addresses this issue and centralizes the reported content into one area. This addon was so well received (and in our opinion, needed) that (with his permission) we are incorporating his Report Center addon into IP.Board 3 out of the box.
For those of you familiar with his modification, you will already be aware of what it does and how it works. For the rest of us, here's a brief summary of how the changes work and the associated benefits.
Firstly, all reported content from all applications are added into a central repository for moderators to address. Moderator permissions are still honored, so your Gallery moderators who do not have access to moderate your forums will not be presented with these reports. By bringing everything into one area, your moderators can quickly determine how many outstanding and unresolved reports are pending action. Multi-moderation is also available in the report center so you can quickly prune reports, or change statuses for multiple reports at once.
Statuses and severity levels can be set to help you identify which reports require attention first. You can configure severity levels based on "points" for the number of times an item has been reported, and based on age (so the oldest reports will be highlighted as needing more attention). Icons can be associated with the severity levels so that you can customize the final display. Reports can have basic "open", "closed" and "active" statuses, and you can configure additional statuses as you wish.
Moderators can comment on the report in private, allowing them (and you) to leave notes about what has been done, whether the offending user has been contacted, and to ask questions. The comments cannot be deleted by the moderators, allowing you to retain a log of moderator activity on the board.
When multiple users report an item and an active report is already opened for that item, all of the subsequent reports are stored with the original report to provide a more organized system for your moderators to work with. Combined with the severity levels, this can help you to more quickly identify things that need to be addressed on the board.
You can still configure the system to send private message or email notifications when content is reported after it is added to the queue, if you prefer to still receive notifications. An indicator for moderators is added to the top of the page identifying how many active reports (that you can access) are open, and when viewing reported content an indicator is displayed to moderators if the content has been reported.
Additionally, if you use Luke's report center modification presently, your existing Report Center data will be retained upon upgrading to IP.Board 3 - we are keeping his same table names during the upgrade, so all of your current reports will still be available.
We hope the addition of this new feature will help administrators and moderators manage their community easier and with more organization than in previous versions.
IP.Board 3: Global Search
During the initial design phase for IP.Board 3, one of the first areas that we identified for a major overhaul was the search system. In IP.Board 2, each application is required to have it's own search engine, which creates many silo's of data that can not be easily searched. IP.Board 3 will introduce a new global search system that will make all of the content of your community easily searchable, no matter where that content is located. You will have the option of showing the results from all applications within one listing, or filtering your results by application.
One of our primary goals in IP.Board 3 is to dramatically increase the integration level between all of our community products, so that they feel more cohesive than in IP.Board 2. This new search system is just one example of how we are working to achieve this. However, we don't want this ease of integration to apply only to our own products, so modification authors will be able to utilize this same system for their own applications. Through the use of a simple plugin system, modification authors will be able to have content from their applications show up within the global search results.
The new search system will also be more streamlined and easier to use. The new "Advanced Search" form is much friendlier than the form in IP.Board 2 is, making it much easier to determine how to formulate your search. Additionally, every page will include a quick search box in the header that you can always use to search, no matter where in the system you are. This quick search box will also include 'live search results' that will dynamically show you a preview of your results as you type the search term in the quick search box. The live search will be context-sensitive. That is to say, if you are in a forum, it will search that forum; if you are in a topic, it will search that topic; if you are in the gallery, it will search the gallery; and so on. It provides a link to view all search results (from all applications) should you require it. Additionally, there is a setting to disable the live search should you not wish to support it on your board.
Performance has also been an issue with our current search system, our new system aims to overcome this in a variety of ways. The first is by creating a global search index, which is what powers all the features that I've mentioned previously. This global search index is much easier and quicker to search than searching the post table. Since searches will no longer be performed directly on the post table, there will no longer be any issues with locking that table during a search. To reduce the disk space overhead and make searches even quicker, the search index has a stripped down version of the content that contains no bbcode or markup of any kind.
The second way we will be improving search performance is by supporting Sphinx out of the box. Though you will need to install Sphinx yourself, once you have done so, enabling it in IP.Board 3 will be as easy as changing a setting in the ACP. You will be able to remove the full text index on the post table using either the new search index or Sphinx, which will dramatically reduce the size of that table.
The new search index will have the added benefit of enhancing other areas of the forum as well, such as the "View new posts" feature. View new posts will now include any kind of content that is searchable, so you will see forum posts, gallery images, blog posts, etc in the new post listing. There are some other enhancements as well, but we're going to save those for a future blog post.
We're very excited about these changes and we hope that you will be too.
IP.Board 3 Plugins and Hooks
Many of you have been waiting for this blog post, and I can assure you we've been equally as anxious to get it out to you, but we wanted to ensure the bulk of the system was in place first before releasing anything we had to pull back on.
General Overview
First, as used in this blog entry, the definition of a "hook" is a point in the code execution where a modification author can tell IP.Board to execute his or her code, and then return to the primary code execution. A "plugin" is a collection of hooks (any given modification may need to "hook" into 2 or 3 files, for instance, but remain one modification - which we will call a plugin).
IP.Board 3, as promised, will introduce a new hooks and plugin system for modification developers to make use of. The system is relatively extensive without a lot of "hook points" manually inserted into the source files which ultimately requires a lot of maintenance and never-ending "can you add a hook point at xyz location" requests. We wanted to provide something out of the box that would scale, that would be easy to manage and maintain, and that would accomodate most modification needs without requiring modifications to the core source code. At the same time, during development of the new hooks system we determined that we did not want to simply shift the modification responsibilities to the skin system either. While it is arguably much easier to modify the skin system than a source file, shifting responsibilities entirely would not solve the issue we are working to tackle. The ultimate goal, of course, is to allow you to enhance your board without having to modify source files to do so. This makes upgrading easier, as you don't have to reapply your mods, makes support easier, as we can easily disable your hooks without having to sift through files looking for changes, and makes adding plugins easier, as you don't have to spend 30 minutes applying code changes from an instruction file to do so.
How the hooks and plugins work for end users
There is a hooks management page in the admin control panel where all of your installed hooks are listed. You can enable and disable hooks from this page, and reposition what order they are executed in (while this generally shouldn't matter, the capability exists in case a plugin needs to hook into another plugin, for instance). You can also view detailed information about the plugin that the author has provided (such as the author name, email address and website, and all files associated with the plugin), and check your system against the minimum/maximum PHP and IPB versions the hook supports. The hooks system supports an update check URL that the author can use to notifiy you if a hook is out of date.
To install a hook, you will simply upload an XML file from the ACP interface - that's it! The hooks system, similar to the popular Universal Mod Installer for earlier versions of IP.Board, supports running necessary database queries, importing settings, language bits, skin templates, modules, tasks, help files and admin CP help files. The hook installation routine even supports a custom script callback system in case the installation routine needs to do something we don't support out of the box. Similarly, when you uninstall a hook, all of the changes are automatically reverted, and the custom script can perform additional cleanup if needed.
It's as simple as that. Import an XML file and view changes on your site immediately.
How the hooks and plugins work at the system level
When hooks are imported in the ACP, they are cached to .php files in a /hooks folder. Only hooks that are registered in the admin CP are executed, to avoid wasting resources hunting down hooks that are not being used presently.
There are three types of hooks in IP.Board 3:
* Action overloaders
* Skin overloaders
* Template hooks
Action overloaders allow you to extend an action file, allowing you to do nearly anything you can imagine. An example of this might be to extend the board index source file, add your output to $this->output, and then call parent::doExecute() to allow IP.Board to finish loading the board index with your output prepended. Or, you may want to extend a source file so that when a form is submitted, you can store additional data in the database. Most properties and methods in IP.Board are set as protected, giving you full access to them from your extended class.
Skin overloaders work similar to action overloaders, except that you are extending a skin file. A good example of why you might want to do this might be to entirely change a template's contents if the user meets a certain criteria, or if you want to prepend or append HTML to a template without requiring the user to manually edit each of their skins.
Finally, template hooks provide an extremely powerful way to manipulate the HTML output, which is what most modifications are designed to do. Before and after each foreach loop, if statement, and else statement, HTML comments are inserted into the HTML output (automatically by our skin system, so as to avoid annoying our beloved skinners) with a very specific syntax. When you register your template hook in the ACP, you specify where in the skin you want to hook into. During display, if your hook is enabled, it is executed and the HTML comment is replaced with the output returned from your hook.
Overall, this provides methods for injecting your code into source code functionality and into the final output engine, covering most cases for modification authors.
We will be providing some examples with the releases of IP.Gallery, IP.Blog and IP.Downloads. I don't want to give away any details on these just yet, but some of the things users have been begging us to do that we've always said we can't as it would require modifications to IP.Board will now be possible, allowing for a much tighter integration between our applications than has ever been possible.
How the hooks and plugins work for developers
In the admin CP when you create a new plugin, you fill in some basic details such as author, plugin name, and website. You create the hook files and then on the form when creating a new plugin you configure which files are a part of the plugin (there is no limit to the number of files you can add to a single plugin). You would then develop your work as normal.
When you go to export the plugin, you can interactively configure settings, setting groups, language bits, skin templates, modules, help files, ACP help files, custom installer/uninstaller scripts, tasks, and database changes that you want to export with the hook. If you have used the universal mod installer in the past, this system is similar, with the main difference being that you interactively configure these details in the admin CP instead of through an XML file.
When you finally export the hook, your source code is collected (as well as the source code for the install/uninstall script) and included within the XML file. The hook import routine takes care of caching the code and importing all of the data you configured to export with the plugin.
Closing
Before starting on the system we wrote down 5 different popular modifications and requests that we've seen for a while to verify that once finished we would be able to accomplish each of these modifications without actually modifying the source code in IP.Board 3 - and we've passed this baseline test. We intend to release more details on the system's specifics for modification developers closer to the release of IP.Board 3.
IP.Board 3.0 BBCode System Overhaul
BBCode is a core part of your forum system. We understand that. To that end, we've been working hard to completely rewrite and overhaul the entire bbcode handler in IP.Board 3.0. We think you'll like what is in store.
Changes since IP.Board 2.x
There are some core differences in the BBCode system we are introducing in IP.Board 3 that you may notice right away. For starters - *every* BBCode is configurable via the Admin CP. That means if you want to add "rel='nofollow'" to your urls, you can do so without editing files. If you want to change the resulting HTML for a code tag, you can do so, right there in the admin CP. Similarly, the backend treats every bbcode as "custom" as a result, and every bbcode is treated equally.
Additionally, we are changing the HTML that the bbcode parsing generates to be more XHTML compliant. Alt attributes are added to image tags. We've changed emoticons to place the emoticon code in the alt attribute, and have removed the (non-standard) emoid attribute entirely. Quotes will properly use the blockquote HTML tag (and, further, will use the "cite" HTML tag when you provide the name and link with the quoted text). Bold will now use the HTML "strong" tag and i will use the HTML "em" tag. Almost all of the bbcode HTML is being rewritten to be both more semantic, and to bring IP.Board's HTML output up to today's standards.
Additionally, the code-syntax boxes (e.g. HTML and SQL bbcode tags) are undergoing an overhaul that will make them much more flexible and allow us (and you!) to add new code languages very easily. We will be providing more information on how to do this in the future.
New features in the BBCode system
I'm sure this is what you've all been wanting to find out about. Well, here we go (in no particular order)...
* Aliases: BBcodes can now have aliases, so that more than one tag can execute the same custom bbcode. Uses? For instance, "code" and "codebox" both execute the same bbcode. Similarly, "media", "blogmedia", "flash", and "youtube" are all one bbcode that behaves the same way. (Hold your horses, we'll get to the media in a minute wink.gif )
* Single-tags now supported: You wanted to add "
". You now can.
* Option content is optional: Bet that sounded confusing. It really isn't - basically, taking the "URL" tag as an example, you can either provide the URL as the "option" to the URL tag, and display text as the "content", or you can omit the option entirely, and the content becomes the display text. This setting allows you to do the same thing with your own bbcode.
* Prevent other codes from parsing: You can prevent other bbcodes from parsing inside your own bbcode. The classic example is our "code" bbcode - you don't want smilies and other bbcodes parsing within the code bbcode when you're trying to show someone how to use them.
* PHP Plugin execution: Do you require a bit more logic to be carried out to replace the bbcode? You can utilize plugin files to do this. Plugin files have a defined interface and more information will be provided for developers near launch. Several of our default bbcodes utilize plugin files, so this should help developers more easily understand how they can be used. You will no longer need to modify built in bbcode processing files to add new bbcodes.
* Control which groups can use a bbcode: The bbcode manager now has a multiselect which allows you to specify which groups can utilize the bbcode (secondary groups also supported). So if you want admins to be able to create tables using a [table] bbcode tag, but not members, go for it.
* Control where each bbcode can be used: Want to allow images in posts, but not in signatures? Now you can configure this right from the bbcode management screens in the admin cp. This feature runs on a plugin system so modification developers can also allow you to configure which bbcodes are allowed in your custom applications.
New "default" BBCodes in IP.Board 3
I use the term "default" loosely, since everything is configurable via the ACP. In addition to all of the bbcodes you will find in IP.Board 2.x, the following default bbcodes will be available in IP.Board 3:
* "member". Usage: . This tag is a "single" tag bbcode that accepts one option, the member's display name. When parsing out the tag, the bbcode will generate the correct link to the member's profile and display "<a href='correct link'>member name</a>".
* "hr". Usage:
. Very simple bbcode which generates a horizontal rule.
* "xml" and "php". Usage:
XML contentor
$phpCode = 1;. Generates syntax-highlighted code boxes, similar to the existing SQL and HTML boxes.
* "media". Usage: http://youtube.com/videolink. Ah, the one most of you have been waiting for. The introduction of the media tag in blog was so well received, we've gone ahead and added it to the IP.Board core. You can configure the media tag matches and replacements (for those of you who own Blog 1.4, you'll know what I mean), which allows you to add new media services at will. Generic flash (the old "[flash]" bbcode in IP.Board) works through this new media tag as well. Optionally accepts "width,height" as it's option.
Sharing and formatting content couldn't get much easier that configuring what you want in the ACP!
Dull boring techie stuff
For those of you actually interested in the code aspects of the new system, we've completely rewritten the bbcode parser from the ground up. Firstly, sections should go back to the proper way of calling pre_db_parse before storing content in the database, and pre_display_parse before actually displaying it. This will ensure that bbcode can be correctly unparsed when a user edits their content.
A major change to how the formatted text is handled: it isn't! We don't do any bbcode parsing on save, storing (nearly) exactly what you submitted into the database. Instead we format the bbcode at the time of displaying the content. This means we don't have to "unparse" previously parsed bbcode, nearly eliminating any bugs in attempting to do so.
Another nice thing about this method...while you will need to rebuild your posts when you upgrade to IP.Board 3, you should never need to again. Ever. Yes, you read that right - you will need to rebuild your posts once upon upgrading to IP.Board 3....but after that, no more rebuilding posts headaches. Additionally, we intend to fully update our command-line rebuild posts routine, and we intend to introduce a task which will do this for you automatically should you wish. More information on this will be available as we get closer to launch.
Some of you may be wondering about the resource impacts of parsing a post on every display. In rewriting the bbcode engine, we've nearly completely eliminated regular expressions in our bbcode engine. Regular expressions allow you to take a "pattern" and find matches to that pattern in a block of text. This is how bbcode was found and replaced in IP.Board 2.x (and in most other bbcode engines out there). For IP.Board 3, we are talking what's called a "tokenized" approach. We use some very fast built in php functions (such as strpos and substr_replace) instead of performing massive regular expressions, making the entire bbcode parsing process much quicker. We will be profiling this in greater detail as IP.Board 3 starts wrapping up. We'll try to share the results of this profiling with you at that time.
We've also entirely rewritten the word wrap function in IP.Board. It should now be fully HTML-safe, HTML-entity-safe, and multibyte-safe...three huge problems we've repeatedly run into with the word wrap function in IP.Board 2.x. Additionally, there will now be one word-wrap function, and it properly lives in the bbcode library (though for legacy purposes, we will maintain a "redirect" function in our text handler class similar to the function in ipsclass in IP.Board 2.x).
All in all, once we get the various inevitable kinks all ironed out with using the new system, it should not only be much easier to utilize our bbcode library, but it should be much more reliable and much faster to boot!
Conclusion
We hope you like the changes in store, and we hope that the updates which many of you have waited a long time for will serve your post-formatting needs for the forseeable future. Please share your thoughts or ask any questions you may have, and we'd be happy to try to answer them for you.
Integration
We want you to integrate your community with the rest of your web site with minimal effort. To make this easier for you, we will be putting great focus on creating a new hooks system for developers, more advanced APIs, content syndication, login methods, and more. Our applications (IP.Blog, IP.Gallery, and IP.Downloads) more tightly integrated with each other and with IP.Board itself.
Coding
There will be a lot of low-level code improvements which will make working with our codebase much easier for our community of developers. Everything we do will be with an eye toward resource usage improvements to make our software lighter on servers.
Server Requirements
To take advantage of many new capabilities, we will be officially dropping support for PHP 4.x series and requiring a minimum of PHP 5.x for our software. The software will work on the MySQL 4.x database series but we will highly suggest using the MySQL 5.x version.
When?
Of course this is just the short version. Keep an eye on our blog for more detailed updates and new feature reveals in the coming weeks. And finally, when will it be released? Right now we are thinking the fourth quarter of 2008 (IP.Board, IP.Blog, IP.Gallery, and IP.Downloads will all receive a new version at the same time) but of course that's subject to change... it could very well be sooner...
-- Source: Invisionpower, own research, Alpha testing group
