Invision Community Blog

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!

2,914 views

Matt

September 4, 200817 yr

IP.Board 3: 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.

18,655 views

Josh

September 2, 200817 yr

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 to help them learn the new system, as well as examples of how to accomplish various things without modifying the source code, through our official resource site.

16,604 views

bfarber

August 28, 200817 yr

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.

4,138 views

bfarber

August 26, 200817 yr

IP.Board 3.0 Integration Made Easier

IP.Board has grown a lot over the years, however at the core of it, addons have always been just that - additional software layered onto IP.Board. Some points of integration have existed to allow things to work smoothly together, but code separation has forced most functionality in IP.Board and components to also remain separated. One of our primary goals with IP.Board 3 is tighter integration of the core software and the addons, and to that end we have been working on many integration points throughout the software.

While we won't get into an exhaustive list here, we'll go into a few of the more noticable areas of integration in IP.Board.

A common occurrence with addon modules for IP.Board is the need to provide group and member settings. Previously you would need to modify the source code for those forms, or build an entirely new page for admins to manage those settings. andIP.Board 3 addresses this issue by making the group member editing forms modular. Your application can provide a class that will allow you to both output form HTML to be added to the forms, and to process that submitted form data to be saved when the form is submitted. The end result? Your applications can add add settings to the group and member forms without having to directly modify the IP.Board files, and without having to create entirely new pages. The end result for admins allows them to manage all of their group and member settings in one place without having to guess where they need to jump around to in order to configure their groups and members.

IP.Board can now pull RSS feeds from each application and handle the general grunt work - your application need only provide the actual RSS content to output. This allows for IP.Board to add the RSS HTML link tags onto every page, instead of you having to manually output the RSS link somewhere. This makes it easier for both visitors and browsers to find all of the RSS feeds available on the site.

We discussed how each application can now make use of our centralized permissions management system in a previous blog entry. Likewise we discussed how you can integrate into the new centralized search system in IP.Board 3, allowing your application to be indexed globally and be available in the centralized search system.

Of course cache loading and session management/parsing from IP.Board 2 is still possible in IP.Board 3, as is the ability to integrate with the user control panel. There have been some small enhancements to all of these areas as well. For instance, you must define in your caches array all of the information necessary to rebuild your cache - afterwards rebuilding your cache (from any file in IP.Board) becomes as easy as

$this->cache->rebuildCache( 'cache_name', 'application' );

You can determine which areas you will be showing the text-editor throughout your application, allowing administrators to enable and disable individual bbcodes throughout your application to their liking.

The ipb_member_sync.php file has been completely scrapped and rewritten to run in a similar modular fashion, allowing each application to define it's own requirements when a member is deleted. This makes it easier to fix broken content from members when they are deleted by allowing you a chance to clean it up during deletion.

For developers, this means you can much more easily take advantage of all of the available framework and code in IP.Board without having to reinvent the wheel each time, so to speak. And for administrators, this means it will now be much easier to find what you are looking for, and much quicker to make global changes to your entire site at once.

There are many more integration points throughout IP.Board 3, but the above should give you a small idea of some ways we are making it easier for third-party developers to make their application feel more like a part of the site and less like a separate addon. Stay tuned for more information on our brand new hooks and plugins system next week!

9,525 views

bfarber

August 21, 200817 yr

IP.Board 3: Global Permissions

When we began planning IP.Board 3, the global search system was one of the first features that we decided would be essential. We've already talked about the global search, now we're going to tell you about the permissions system that makes the global search and other features possible.

In previous versions of IP.Board, every application had to maintain it's own permission tables and database information. This created many different permission systems that all had to be separately maintained. When you added a new permission set, you would have to go to the forums section, the gallery section, the calendar, and so on to set up permissions. This system has quickly grown cumbersome to use from a user standpoint, and difficult to integrate with from a developer stand point.

IP.Board 3 will introduce a new global permission system that every application can use, including modifications. Rather than maintaining separate permissions, all permissions are now stored in a permission index table. This table is generic enough to be used by any application. Each application will include a simple configuration class that will tell IP.Board how to use the permission index for that particular application. The system currently supports a 'view' permission and 6 'custom' permissions, the custom permissions are defined by the configuration class for each application. The view permissions is what we use for permission checking during a global search, or any other feature that uses the search index.

Currently the permission configuration looks something like this:

private $mapping = array( 'view' => 'perm_view', 'read' => 'perm_2', 'reply' => 'perm_3', 'start' => 'perm_4', 'upload' => 'perm_5', 'download' => 'perm_6' ); private $perm_names = array( 'view' => 'Show Forum', 'read' => 'Read Topics', 'reply' => 'Reply Topics', 'start' => 'Start Topics', 'upload' => 'Upload', 'download' => 'Download', ); All your application will need to do is edit these values and IP.Board will know how to handle permissions for your application. If you wanted to check the reply permission, you would simply do this:

$this->registry->class_permissions->check( 'reply', $perm_row ); In the Admin CP, if you want to show a permission editor, all you need is this:

$permissions->adminPermMatrix( 'type_of_permission', $perm_row); This will return the full HTML for a permission editing matrix, to save that matrix you would do this:

$permissions->savePermMatrix( $this->request['perms'], $perm_type_id, 'type_of_permission' );

In that example, if you were editing a forum, then the perm_type_id would be the id of that forum.

We hope that this system is going to make integration much easier for mod authors, as well saving them from having to develop their own systems for managing permissions. We will be providing documentation and example code for this system via the resources site later in development.

While developers will receive most of the benefits from this new system, it does allow for an important user level feature as well, the ability to manage all permissions from one screen. Now when you edit or add a permission set, you will see Forums, Gallery, Downloads, and any modification that uses the system all on one screen. This saves you from having to jump all over the system to edit permissions for any one set, which we think is going to be a great time saver.

This new permission system is a very important step in one of our primary goals, integrating all applications as closely as possible. In our next blog post we're going to tell you about even more of the integration features you can expect from IP.Board 3!

4,169 views

Josh

August 19, 200817 yr

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

5,300 views

Josh

August 14, 200817 yr

Language Management in IP.Board 3

Over the past few years our international user base has grown by leaps and bounds, and we want to do our best to support those users and make sure that IPB is a great solution for them. Toward that end, one of our goals for IP.Board 3 is to dramatically improved our language management system. So today I want to introduce you to a few of the upgrades that you can expect to see in that system.

First off, we want to ensure that the entire system can be translated, this includes the Admin CP. You will be able to create and distribute combined language packs that will cover both the front end and the Admin CP. For administrators, your language of choice will of course carry over to both, without the need of selecting your language for both the Admin CP and the front end.

You will also be able to assign a 'locale' to a language pack, which allows IP.Board to format all dates and number specifically for that language pack. Additionally, both the Admin CP and the front end will use UTF-8 as the default encoding type. There will also be no need to translate images for a language, as the new skin will not utilize any images with text.

The language bits themselves are now stored in the database directly and cached to flat files. When you are editing a language pack, you will be able to see the default English string while you translate the string. You will also have the option of reverting language bits back to the default English string. Every string now includes a version number, which will let you know what version that string was last updated in. If you translate a string in IP.Board 3.0.0, and then that string is modified by us in IPB 3.0.1, the language manager will let you know that your translation is out of date and needs to be updated. It's possible to bring up a list of all out of date language entries, as well as a list of all entries that have not yet been translated.

We've also added a search feature to the language system, that will make it easy to find specific text within the language packs. For example, if you wanted to replace all instances of the word 'forums' with 'boards', you can search for 'forums' and the system will show you everywhere that word is used.

Each application can include an XML file that specifies all of the language strings for that application. This file will automatically be processed by the application installer, making it easy for modification authors to distribute language strings with their applications. They will also be able to make use of the string versioning and the application upgrade system will handle updating the strings and letting you know if any of them are now out of date.

So those are some of the changes that you can expect to see in the new language system. We hope that these features will be useful to our international users. If you have any questions/comments about the new language system, please let us know!

8,093 views

Josh

August 12, 200817 yr

Template tags, revisited

A while ago, I posted about the new template tags system in IP.Board 3.0.0.

After some initial feedback on the syntax and having developed the system further, I felt it was worth revisiting in our blog.

The template tag system is still based on PHP classes (extends and implements, PHP5 fans) which act as plug-ins. These plug-ins are only run when the templates are cached which makes the system very fast and very efficient.

The new tag syntax is very straightforward and easy to remember: {parse plugin="data" option="value" option2="value2"}

The updated system also allows you to embed tags, which we'll see later.

First off, here are the tags which are currently being used in IP.Board 3.0.0

Expression
This tag is used to parse an in-line PHP expression which returns a value. This can be any inbuilt PHP function or any IP.Board function.

{parse expression="intval($data['count'])"}
{parse expression="IPSText::alphanumerical_clean( $data['value'] )"}

This makes it very easy to format data on the fly and removes the need for obsessive intval'ing in your code to ensure that a correct value is displayed such as a zero rather than nothing at all!

Template
This tag is used to insert any other template bit from IP.Board.

{parse template="pageLinks" group="skin_global" params="$data['start'], $data['end']"}

The benefit of this tag is immediately obvious. You don't have to 'hack' the PHP sources to re-use template bits.

Variable
This tag is used to set and alter a template variable.

To set up a variable with they key 'className':
{parse variable="className" default="tdRow1" oncondition="$data['foo'] == 'bar'" value="tdRow2"}

To alter the variable based on different data:
{parse variable="className" oncondition="$data['foo'] == 'foo'" value="tdRow3"}

To use the variable:
{parse variable="className"}

Lets look at a practical example:

{parse variable="className" default="row1" oncondition="$data['banned'] === TRUE" value="rowBanned"}
<foreach loop="$key => $data">
<div class="{parse variable="className"}">
</foreach>

Striping
While Rikki was working on the new IP.Board skin, he mentioned that it would be very handy to have some kind of tag that could handle the 'zebra' striping (the alternate row colours when viewing a forum list, etc).

To set up a striping tag:
{parse striping="someKey" classes="tdrow1, tdrow2, tdrow3"}

To use a striping tag:
{parse striping="someKey"}

When parsed, this tag will cycle through the classes, repeating the cycle if required.

Let's look at a practical example:

{parse striping="rows" classes="row1, row2"}
<foreach loop="$data as $key => $value">
<div class="{parse striping="rows"}">$key = $value</div>
</foreach>

AddToHead
It can be difficult to adhere to strict standards when dealing with templates and piece-meal code. Often you compromise and have javascript and CSS scattered throughout the finished document.

IP.Board allows you to add content to the document <head> very quickly and simply:
{parse addtohead="/js/someScript.js" type="javascript"}
{parse addtohead="/css/someCSS.css" type="css"}
{parse addtohead="<script>alert('boo')</script>" type="raw"}

Date
In previous versions of IP.Board, all the date processing was performed inside the PHP code which made it very hard to customize the date formats beyond what was allowed in the Admin CP.
Now, IP.Board allows you to process dates using the date tag in templates.

Examples:
{parse date="now"}
{parse date="1765346750" relative="1" format="long"}
{parse date="-1 hour" format="manual{d, m, Y}"}

URL
IP.Board 3 allows a very easy way to format URLs without having to reply on special PHP variables.

Examples:
{parse url="showtopic=1" base="public"}
{parse url="showforum=5" base="publicWithApp"}
{parse url="photo1.jpg" base="upload"}

Format Number
IP.Board 3 allows a quick and easy to to access the built in "format_number" function.

Example:
{parse format_number="123456"}

Replacement
To keep our tags uniform, we've removed the old 'macro' tag (<{MACRO_HERE}>) and replaced it with the new 'replacements' tag:

{parse replacement="macroKey"}

Of course, the real power in this system is that you can very quickly and simply create your own template tags and drop them in the template tags folder for them to be available instantly.

9,162 views

Matt

August 5, 200817 yr

IP.Shoutbox 1.0.0 Beta 1 + IP.Tracker 1.2.0 Beta 1

We are pleased to announce that the beta releases of IP.Shoutbox 1.0.0 and IP.Tracker 1.2.0 are now available for immediate download!

IP.Tracker
IP.Tracker is a bug/issue tracking system, it allows members and staff to track certain issues, for examples, bugs within a project you are working on, or even building a house! IP.Tracker supports statuses, severities, and much much more to bring you an extensible Tracker to use however you wish to.

IP.Tracker 1.2.0 builds upon what was available in previous releases, whilst adding vital features such as sub-projects, custom fields, an advanced search library, and better database recognition of when an issue has been read.

IP.Tracker 1.2.0 has been developed by the Tracker team (krocheck, Jaggi, and Alex) but as stated in a previous blog entry, we will be introducing ways so that you, the community, can assist coding features, and fixing bugs.

Here is a list of the main changes in IP.Tracker 1.2.0

Subprojects - We have added functionality allowing you to add subprojects to an existing project Custom Fields - Custom fields have now been implemented, and are very advanced, you can choose to only show a custom field in a certain project, and in the project edit screen, you can edit how custom fields are display in that particular project. Custom fields now also support permissions Advanced Search - We have now added advanced search to IP.Tracker, and you can also search within a particular issue Database recognition - We have changed how the database records if an issue is read, and there are no longer issues with it, as cookies are no longer used. We have also changed how issue changes are recorded to allow better recognition (statuses, severities etc.) Last post information on project overview - A rather simple, but informative feature. Projects will now display last posts on the right hand column, just like IP.Board

As said, these are the main features in 1.2.0, however when we are nearer a stable release, we will post a full changelog.

We hope you like the changes in IP.Tracker, we certainly do! To discuss IP.Tracker 1.2.0, please use this topic.

IP.Shoutbox
IP.Shoutbox is our feature-rich chat room for your IP.Board without the need for Java, Flash or any other browser dependency!

One of the main concerns people had about the base we chose for IP.Shoutbox was server load, and query counts. We are pleased to inform you that the two developers, myself, and Brandon have been going through the code to try and reduce this as much as possible, and we think you will be impressed. Wherever possible, the majority of the content is cached, and this has rapidly shown in the query count. The original base code has 16 queries per page load, IP.Shoutbox has as little as 8, 5 of those being IPB queries themselves. We have got IP.Shoutbox down to three queries per page load, we said you'd be impressed!

1.0 is mainly a code rewrite, however more features will be added in future releases once the new code base is complete. There are a few changes from the base modification, outlined below:

No file edits - We promised we would do this, and we have, all that is needed is a simple skin edit, which also gives you the power of limiting the global shoutbox to certain skins! Moderators - IP.Shoutbox now supports both groups and individual members, whilst the base only supported individual members

To discuss IP.Shoutbox, please use this topic.

Lastly we would like to express huge thanks to the developers for these two, amazing products: krocheck, Jaggi, Alex, vadim88, and terabyte!
As we said, this blog entry is a bit vague, but we will be posting more details over at the Community Projects page at IPS Resources when the time comes!

5,497 views

Alex

July 28, 200817 yr

Lifting the lid on the registry

In a previous blog entry on IP.Board 3.0's new framework, I mentioned that at the core of the new framework is something called 'ipsRegistry'. This blog post will go into more detail and will be of interest to modification authors.

Overview
IP.Board, like most complex applications, has a need for 'core' data, like settings, session and input data ($_GET, $_POST, etc). There is also a need for a database connection and access to global objects like cached data. It would be incredibly wasteful to make each file and class set up a database connection, load any cached data, authorize the browser session and build up any settings. This could happen many time in any IP.Board view.

Clearly there is a need for a way to initialize this data once and then pass it throughout the application. This is exactly what the ipsRegistry is for. Previous versions of IP.Board relied on the 'ipsclass' object as a registry; but this quickly became tarnished without clear boundries as more and more data was attached to it. It was more of a global variable than anything else. The new registry is composed of clearly defined objects. Also in previous versions initialization of the settings, caches, input data, sessions, etc was handled over a scattering of classes and files. The new registry is a single point for this initialization. This initialization occurs when init() is called. This makes it much easier to use IPS registry data in your own scripts and modifications. Previously you would have needed to copy out half of the default index.php. Now your scripts can be as simple as:

require_once( 'classes/base/ipsRegistry.php' ); /* Call init which loads up input, caches, settings, creates the DB handle, authorizes and loads the member $registry = ipsRegistry::instance()->init(); print $registry->request()->getField('foo'); $registry->DB()->do_update( 'table', array( 'foo' => 'bar' ); ); print ( $registry->member()->getProperty('member_id') ) ? 'Hello ' . $registry->member()->getProperty('members_display_name') : 'You are a guest';
require_once( 'conf_data.php' );

Gathering Input from URLs and Forms
One key part of IP.Board's initialization was the sanitization of $_GET and $_POST into a clean array. This was vital to the overall security of the board. IP.Board 3.0 as a 'request' registry object for this and all functions relating to this initialization (parse_key, parse_value, etc). This is available via either $this->request->getField('foo') or $this->request['foo']. This effectively replaces $this->ipsclass->input['foo'];

Cached Data
There are many improvements to the caching backend which we'll go into more detail in a later blog entry. The cache registry object simply returns the cache when requested via $this->registry->cache()->getCache('forums'); The cache is loaded and unpacked during initialization so you do not need to manually call it.

The Database
So much of the database code has been refactored that it's almost a separate blog on its own. Here, I'll concentrate on the registry object. The main function is getDB() which is interfaced via $this->DB (or ipsRegistry: :D B() when outside of class scope). This is a simple function to return the DB object which is set up during initialization via setDB(). This happens transparently when the file is included and init() called (which is done so by ipsController.php). You may set up more connections by specifying a key, for example:

return $this->registry->DB( 'newConnection' )->build_and_exec_query( array( 'select' => '*', 'from' => 'table' ) );
$this->DB->setDB( 'mysql', 'newConnection', '[email protected]', 'password', 'localhost' );

Settings
The setting cache is loaded and unpacked during initialization. This registry object merely returns the setting when requested via $this->settings->getSetting('foo') or $this->settings['foo'].

Member Information
Previously member information was scattered through 'ipsclass'. IP.Board's member registry centralizes this information. This object sets up the incoming IP address, browser and operating system and attaches it to the member class. It also authorizes the current browser session (via cookies or an inline URL) and loads up the session member and builds up the permission arrays. All this is done during initialization meaning there is less to do on the front end.

I hope this post has given you some insight into the IPS registry and the improvements it brings not only to IP.Board itself, but also to modification authors who will find their workload greatly reduced by automatic set up of all the required information. If you find that you do not need all of this information set up, then you can write a child class of ipsRegistry and alter the 'protected' functions to prevent them from initializing.

4,223 views

Matt

July 25, 200817 yr

IPSR: Featured resource and Community Projects

Since our recent updates to the resources site the feedback received has been great. We have managed to address a lot of the feedback, and we hope you like the changes we have made.

One of the changes was the new Featured Resource. We have now revealed the featured resource for July, as usual, this page will go into a lot of detail about the resource, the author, and will also feature screenshots. We have also implemented the archive section which allows you to go back in time and view all previous featured resources we have had at IPS Resources. Now that is out of the way, we go onto the main part of this blog post, information regarding our two community projects: IP.Tracker, and IP.Shoutbox.

IP.Tracker

IP.Tracker 1.1.0 has been received brilliantly, and we recently released an update to address issues found in 1.1.0, we would like to thank everyone that took their time to help test the release and make it as good as possible! IP.Tracker is now splitting into two stages: 1.2.0 will be available for IP.Board 2.3.x as 1.1.0 was and will also be ported for IP.Board3. Shortly after that time, a new release will be out for IP.Board3 with new features (2.0.0), however it will only work on IP.Board3.

Development has been rolling onto a stage where, in the next few weeks, we will be able to open up the beta testing process once again. IP.Tracker 1.2 builds and improves upon what was there in 1.1. Vital features such as sub-projects and custom fields are included with this release and we have finally rewrote the 'issue read' code. IP.Tracker can now tell whether you have read an issue or not, with no cookies!

Other features included in this release include latest post information (the same as on the main board index). We are also implementing a few new changes to the system to better record when a status, severity, etc. has been changed, however, there is nothing new on your end for it at this present stage. We have implemented the changes to the system now to prepare us for 2.x.x. A couple of features which will be introduced need the code implementing now so the features have a lot of information to work off when they arrive.

As it stands, IP.Tracker 1.2 is featured locked, and is again being worked on by the developers: Alex, krocheck, and Jaggi. However, we invite you to help us code the 2.x.x series, please read below to find out more!

IP.Shoutbox

Our community-driven shoutbox, IP.Shoutbox, is moving along nicely. We do not know of a release date for the first beta, and therefore we cannot give you much information about it. We'd like to make one thing clear, we have had a few users asking about the security of this modification because of the base we chose, please note, that said modification is a base for the project, and the end result will not resemble it at all in terms of code. The two developers, myself, and bfarber will be going through the code to make sure its safe, secure, and doesn't have high server loads. That's as much as we can really say on Shoutbox at this stage, but stay tuned for more updates!

Community Projects - Redefining what 'community' means

When we first announced the community-driven project scheme, we wanted it to be just that: community-driven. Many developers have told us that the main reason they cannot contribute to the projects is due to lack of up-to-date code. Over the past few weeks, we have been adding functionality to allow license holders to view the SVN code allowing you to code as we code. You will not be able to commit to our code, but upon release of IP.Tracker 1.2.0, there will be a subcategory setup for you to submit code changes, and bug fixes. This process is not yet complete and is still in development and will only start when IP.Tracker 1.2.0 is installed here at the company forums. We will keep you updated with news about this process and we hope this may encourage more of you to contribute to the community projects.

Hopefully this blog entry has been of interest to you and we can't wait to be able to show you the previews of IP.Tracker, and IP.Shoutbox. They are shaping up to be brilliant products!

1,576 views

Alex

July 18, 200817 yr

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 ;) ) 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: bfarber. 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 content or

$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 "" 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.

10,379 views

bfarber

July 15, 200817 yr

3.0 Applications Framework

IP.Board has grown a lot over the years. We've added new functionality through the components framework, allowing us to deliver first-party supported addons such as IP.Gallery, IP.Blog and IP.Downloads. Our Community Projects leverage this infrastructure to provide even more value for your board, and third party developers have produced wonderful components utilizing the same infrastructure on their own.

As IP.Board has progressed, we've seen challenges with the integration and continued separation of these components. We don't want our addons modifying core IP.Board files - this makes upgrading IP.Board a much more challenging task than it should be. At the same time, the components should seamlessly integrate into the core of the site so that everything can be managed together, and common code libraries can be shared.

IP.Board 3.0 introduces our new application framework which will replace traditional "components". The software "out of the box" comes with 5 applications. There are 3 default applications: System (which includes things like template editing and settings, things that are not specific to any section, but are part of the core of the site as a whole), Members (member management, group management, and similar functionality), and IP.Board itself (forum and moderator management, for example).

Further to this, the core of IP.Board 3.0 supports IPS-provided addons, and third party addons, which will function the same as our integrated built in applications. We provide 2 IPS addons out of the box: Calendar and Portal.

Applications can be disabled globally (i.e., you can easily shut off or turn on the Calendar, for example). The IPS and third party addons operate identically, and utilize the same fully-featured application framework our built in applications use. You can easily add settings, adjust the secondary menus, build in permission routines and determine cache loading/updating routines, and much much more simply by utilizing this framework in specific ways (for instance, providing a specific file in a specific location within your application).

We hope that the new framework will help third party developers (and ourselves!) to be able to segregate code so that it does not interfer with the core IP.Board code, while at the same time being able to fully integrate into both the front end of the site, and the admin control panel.

We will be providing some guides and developer information with the launch of IP.Board 3.0. For instance, we plan to provide an overview of exactly how we convert one of our first-party components over to the new framework to show developers exactly how they can convert their own code base.

This new framework should be utilized for fully-featured sections or addons. More information will be forthcoming in future blog entries on how to utilize new plugin and hook functionality provided with IP.Board 3.0 for addons that don't require separate "sections", and thus don't require use of the full application architecture.

2,428 views

bfarber

July 7, 200817 yr

IPS Resources back online

Thank you for your patience while we made our improvements to the resource site! There are some exciting changes we would like to point out to help you navigate through the new features.

Homepage Updates

We've made a few improvements to the homepage, with more to come. Immediately, you will notice we have separated the left column to show 'Top' listings and the right column to show 'Latest' listings. We've also separated out modifications and skins to help you more quickly find the latest updates you are interested in.

Featured Resources

Once a month we will be posting a resource spotlight in the new 'Featured Resources' section. In each spotlight we will give you an overview of the resource with some basic statistics and a link to view or download it, a list of features or highlights for the resource, some screenshots, and a short interview with the author. The resources will include anything submitted to the Downloads or Articles areas. Please be sure to check out the featured resource for June!

Community Projects

IP.Tracker has been out for some time and has been a huge success. As a result, we will slowly be introducing more community projects to our customers. Next up will be IP.Shoutbox - a fully functional and comprehensive shoutbox system for your forum. The project is based on Dean's "D22-Shoutbox" and he is working closely with us on updating and preparing it for release. More information to follow soon...

In the mean time, please check out our new Community Projects page for more information on our community projects.

IP.Tracker 1.1.0

The first, stable release of the 1.1 series for one of our community projects, IP.Tracker, is now available to download. Over the past few months, this new version has been tested among many of you and we would like to thankyou for your help in finding all the bugs in this release. Huge thanks to krocheck and Jaggi for doing their work on IP.Tracker, you've done a great job!

Paid Resources

There are hundreds of resources available for sale from many authors who contribute to this site, and many of our users are interested in these resources. There are some drawbacks here

The user may have a hard time vouching for the trustworthiness of a paid resource The user may not know a specific resource they are interested in exists Paid resources are often not welcome on sites that host free resources for download, so authors have a hard time getting the word out about their work A user may not be sure which paid resource they are interested in if more than one solution fits their needs
The resources site will now allow mod and skin authors to list paid resources in our download manager. The authors have to agree to certain guidelines, and if the guidelines are not met or maintained their work will be de-listed and not allowed back on the site. This helps users to verify that a solution is being properly maintained, fixed, updated and supported.

Paid resources will show up with a small symbol in our downloads database so you will more quickly know if a file is for sale or not. Filters have been added to the bottom of the download pages so you can easily filter out (or in!) paid resources in the event you don't want to see them (or only want to see paid solutions). Payment for a third-party solution is handled by the third party directly, and the download link will take you to their site to complete the transaction and download the work. Consider our database a helpful listing so you can better realize what kind of options are available to you. Authors can consider our database a useful tool to help them advertise the work they've put so much time and effort into.

Miscellaneous

Our company forums have undergone a slight re-organization in the resource sections to help you better identify where topics should be posted and found.

We've also added a "Most Recent Resources" feed at the top of the resource forums so you can stay up to date on new works submitted to the resource site.

Additionally, at long last, the resources site is now linked from the main company website at http://invisionpower.com - we hope this helps everyone discover all of the resources we have available to them that they may never even have known existed.

Finally, we would like to extend our sincerest thanks to our IPS Resources team for all of their hard work and dedication in expanding the resource site!

We look forward to your feedback and hope you enjoy the updates!

3,003 views

Alex

June 19, 200817 yr

IP.Nexus

Recent advances in technology coupled with a tremendous increase in online awareness have had a profound effect on the growth of online communities. To better serve both present and future customers and in the interest of furthering our position as a leader in online community development, we are pleased to announce that we will immediately increase and refocus all development resources to the enhancement and expansion of our community offerings.

While we will evaluate the position of IP.Nexus in the marketplace at a later date, we recognize that the core of IPS is our community product and solution line and as such, our priority lies with the continued growth and enhancement of that very core. We will be allowing the current beta of IP.Nexus to expire on July 31 and will revisit our content management and business services plans after our upcoming releases of our community software products including IP.Board, IP.Gallery, IP.Blog, and IP.Downloads.

In coming weeks and months, please expect significant improvements to our existing community line as well as new components which compliment existing products. We're very excited about what the future holds and are confident that you will be equally pleased with the increased quality and speed at which we will be able to deliver new products and services.

Thank you all for your continued support and stay tuned for further updates!

7,343 views

Lindy

June 19, 200817 yr

Introducing IP.Shoutbox

In our efforts to improve the services offered to you through IPS Resources, we will soon be releasing another community-driven project, IP.Shoutbox. Much like IP.Tracker, this will be an IPS-sponsored project written by you, the community.

We have approached two people who we feel will do a great job on IP.Shoutbox, these two are currently working very hard to produce a beta of the modification. The developers we have chosen are vadim88, and Shawn Dean. These two will keep you up-to-date regarding the status of this project via the IP.Shoutbox forum. IP.Shoutbox is based on Deans modification 'D22-Shoutbox', and he will be working very closely with us on this component.

IP.Shoutbox has been written with IPB3 in mind, for example, the javascript uses the prototype library to allow the move to IPB3 be all that much easier, the code will be commented throughout so people looking to get involved will know what function is doing what, please remember, even though we have two developers who will start this project off, this is a community-driven project, if and when you find bugs, and you know how to fix them, please provide the fix as it makes it all that much easier for the developers! If you have code contributions, please feel free to submit them in the IP.Shoutbox forum, we welcome your input!

As with all community projects, IP.Shoutbox will be offered for free via IPS Resources for current license holders. We will be posting more updates about this project and the updates coming to IPS Resources shortly.

7,210 views

Alex

June 18, 200817 yr

Resource Site Updates

Our new resource site has been online for a few months now and the feedback has been great so we are going to enhance the offerings and further involve our community of resource authors. Some upcoming changes include:

Forum Organization

We will be reorganizing and adding new forums to the company forums resource section to make it easier to navigate and find information. You will also soon notice a feed from the resource site to the company forums featuring new activity, most popular resources, and more.
Resource Spotlight

Once a month, we will feature a resource and do a short interview with the author of that resource so you can get to know them and what they created. We hope that everyone enjoys these features and they help introduce our customer community to all the great resources that are available to them.

Community Projects

The IP.Tracker bug tracker community project has been very well received so we are looking at introducing more. If you are not aware, our community projects are projects that we sponsor but the community actually creates and are offered at no charge. IPS provides resources for programming, hosting, etc. and the customer community writes all the needed code for the project. We already have a new community project lined up and will be announcing that in the next week.

More to come

Also coming very soon is a ranking list of the most used resources, ability to list paid resources, better linking with our main site, and more. Keep an eye out for more updates.

Please expect some downtime on the resources site over the next several days as we implement these new services. Thanks everyone!

1,778 views

Charles

June 16, 200817 yr

IPB3: Banned User Management

The term 'ban' in IP.Board has a relatively loose definition and can often mean many different things. IP.Board supports an array of useful features to control access to the board, or in this case to restrict access to the board. Some examples of what 'ban' may refer to are

IP address ban filters Email address ban filters Username ban filters Placing a user in the 'Banned' group Suspending the user so that they cannot access the board temporarily Additionally an administrator can prevent a user from posting for a set amount of time, or require preview of all of their posts for a set amount of time.

Many users have asked us to make it easier to ban users - frequently an administrator finds that they want to do more than just one of the above actions, and usually against a specific user account who has been causing problems.

IP.Board 3 will help administrators control who can (and cannot) access their board. While all of the above features are still in place and can be accessed individually just as in IP.Board 2.x, there is now a centralized "Ban User" panel that an administrator can use when they are taking action against a specific user account.

When viewing the user account, there is a button you can click labeled "Ban User" (if the user is already banned, the button will read "Unban User"). Upon clicking this button, an AJAX popup window will present you with many options.

Firstly, IP.Board now supports a true "banned member" status, separate from their actual user group. This means you can ban a member without moving them into another group (for instance, if you do not want to upset the user's friends on your board).

The ban management panel will also allow you to move the user to another group (e.g. the "Banned" group included by default with the IP.Board installation routine). You can also ban the user's email address and username right from the popup window.

Additionally, every IP address that IP.Board can find that the user has used will be listed, and you will be able to ban each IP address just by checking the box next to each one.

Lastly, there is a textarea box provided on the popup that will allow you to enter in a note (which saves to the typical user notes area) for future reference.

As a convenience, links to suspend the member temporarily, remove the user's posting rights, and require moderator preview of the user's posts appear in the window, in case you determine you would rather take one of those actions instead.

The unban panel provides exactly the same options, but in reverse, allowing you to move the user back to their normal member group, remove their email address, usernames and IP address from the ban filters, and to remove the banned flag on their account, reversing the changes you just made.

Account management is important to administrators, and IP.Board 3 is taking steps to make such management that much simpler.

13,724 views

bfarber

June 12, 200817 yr

IPB 3: Styling IPBoard 3

One of the first items we determined for IPBoard 3 was that it was going to ship with a brand new skin. Our current skin has been with us since the first release of IPB2, and the style goes back even further than that. The Pro skin was introduced more recently, but its main intention was to simplify, rather than bring a significant update.

And so, the responsibility for designing and implementing the new skin came to me. This is a huge undertaking, both in terms of scope and sheer scale. The skin is the most visible part of any product; it is what forms your first impression, it is the part you use every moment. In addition, since we have big upgrades to the template system coming (detailed here), every aspect of the skin must be redone, from scratch. IPBoard is a huge application, so this is no mean feat.

Objectives
Before even considering the visual appearance of the skin, I wanted to set down some objectives for it. These are:

- Ensure semantic markup as far as reasonably possible
- Ensure XHTML validation (1.0 Strict)
- Ensure Javascript is unobtrusive

These objectives have real benefits for the modern web. Semantic markup is not only good for screenreaders, but it provides a solid base for skinners. When all stylistic decision is removed from the XHTML, those decisions can now be made in the CSS alone. My goal with the new skin is to minimize the need to edit templates, and semantic markup forms a part of this. The hope is the majority of skins will be achieved simply by editing CSS - I'm sure admins will appreciate how much easier upgrading will be when templates remain largely identical across skins!

Another great benefit of semantic code is that we will now be able to serve a printer-specific stylesheet, and do away with the 'print-view' code in IPB itself.

Javascript
IPBoard 3 is going to ship with the PrototypeJS library. I've always believed that the new generation of Javascript libraries are a big step forward for Javascript usability, so I'm looking forward to making use of them (Nexus beta testers will know we already use it heavily in that product). PrototypeJS allows developers to focus on writing features, rather than fixing cross-browser compatibility issues or poor support for a particular part of the language. We'll be making use of the excellent event-handling capabilities to get as much Javascript as possible out of the IPBoard templates.

Skins shipping with IPBoard 3
Our plan right now is to ship at least 3 skins with IPBoard 3. These will be: the default 'fancy' skin; a simplified skin intended to be used as a base for skinners; and a mobile skin, a lightweight version designed for use on mobile devices. This last skin will do away with the present lo-fi version, and become a full-fledged 'light' alternative, complete with posting, searching and so forth.

Style Guide
To ensure all developers within IPS are on the same track when writing XHTML and CSS, I developed a style guide that we will be using internally. This formalizes the practices we will be using and should help to ensure consistent output. I want to make the guide available to the public partly for review, but primarily so that our modding and skinning community can ensure their code follows our standards too, if they wish. Your feedback and thoughts on the guide are welcome.

IPS_style_guide.doc

Feedback
I'm deliberately avoiding showing the progress on the new skins, but they are underway. Once they are nearer to completion we will begin previewing the design itself. For now, I just wanted to introduce you to our line of thinking and aims for the interface side of IPBoard 3 development. If you have any feedback on things I've mentioned here, or more general feedback about improvements you'd like to see in the IPB3 skin, I encourage you to leave a comment.

9,066 views

Rikki

May 30, 200818 yr

Advancing the Login Manager

IP.Board 2 included a login manager utility in the admin control panel. Using this tool, you could tell IP.Board to authenticate login requests against third party databases, LDAP installations, or against IP.Converge, for example. You could even write up your own login methods and authenticate against any external data source of your choosing (i.e. the IP.Board 2.3 OpenID module). We used the login manager for conversions too - if you converted from another forum software, our login manager can understand the old password hashing schemes so that you do not need to reset all of your users' passwords (in most cases).

IP.Board 3 takes the login manager even further.

The login forms on the front end are all being consolidated into one template. This will make it easier to ensure that every time a login form is displayed, the same login form is displayed. You won't have to add options to multiple templates, as you did in IP.Board 2, if you want to customize the login form in any way. The login form has also been made "smart". Because you could potentially have a login method that requires a username and a login method that requires an email address, we decided to dumb down the form a little bit. You will be asked for your "sign in name" now (just one field) and IP.Board will figure out if you submitted an email address or a username.

We've removed the option of "passthrough" or "onfail" from the login manager. It is no longer needed, as you can now chain login methods together. For instance, you may want to try to authenticate a user against the local database first (if the account exists), but if that fails, load the member from a remote database. Or you may want to allow a user to login using one of a number of data sources you maintain. This functionality is now possible. The login methods in the admin control panel are reordered using drag-n-drop to make it easy to control which order they are checked in.

Some login methods need extra information from you. For instance, if you use LDAP, IP.Board would need to know the LDAP server host name, your username and password to login to LDAP to check the user, and so on. In IP.Board 2, this information is entered into a configuration PHP file. IP.Board 3 presents this information in the admin control panel to make it easier for you to check and update whenever you may need to.

In IP.Board 2 when a member is added to the local database after authenticating through a remote data source, the member would be required to fill in a display name, and potentially their email address, even if that information already existed in the remote source. In IP.Board 3, there is much more control over this at the login method level - you can pull ANY data you want from a remote source and use it in IP.Board. At the very least, this means if there is an email address and a username available in your remote data source, the user most likely will not be required to visit an intermediary screen before being allowed access to your forums. The name and email will be stored automatically, making for a very seamless login experience.

IP.Converge has received a slight update too - if you have IP.Converge enabled on your board, your users (who have already logged into the forum and configured their account) will now be able to use their username to login (if you enable username logins in the ACP). Behind the scenes IP.Board will find their email address and authenticate through IP.Converge using their email address, but your users won't have to know that.

Additionally, OpenID has being added to IP.Board 3 as a supported login method. If you are not familiar with OpenID, it is basically an emerging protocol allowing you to control your own login authentication. You submit a url to sites that support OpenID (such as Yahoo, Wordpress, Flickr, and AOL) and then you are taken to that URL to verify the request really is from you. You may be required to login to your OpenID provider to confirm what information you are allowing to be sent back to the requester (in this case, your forums). After you confirm this information, you will be automatically logged into your forum. Additionally, as long as the user allows their name and email address to be sent back to the forums, their account will be fully created and functional. IP.Board will support OpenID 1 and OpenID 2 with the Simple Registration, Attribute Exchange, and PAPE extension modules (meaning email, username, date of birth and gender will all be supported and remembered by IP.Board, and that you can supply a policy url to the OpenID provider). Please note that we will be using the PHP OpenID libraries from JanRain for the OpenID backend support.

If you don't need any of this functionality, it won't impact you at all! For those of you who have been requesting it, however, IP.Board 3 should cover all your bases.

4,224 views

bfarber

May 23, 200818 yr

IPB 3: Making Templating Easier

HTML logic has been a feature of Invision Power Board for quite some time now. Although we didn't make much use of the '<foreach>' tag so that skins could be backwards compatible, we did make good use of the <if> <else /> logic. Now that we have a clean slate with v3.0, we can really make some positive changes.

Invision Power Board 3.0 makes full use of the existing HTML logic and adds some more functionality. This allows for some dramatic customization without touching any of the PHP code. Where possible, each 'view' (board index, topic listing, viewing a topic) has a single template. Previous versions 'stitched' together several templates (as many as 30!) to create a single page view. This meant that some items were fixed and unable to be moved. For example, on the board index, it was not possible to move the board stats above the list of forums. Likewise it was not possible to move the active users below the board statistics.

Now you can. You can move any item to any place for that view without having to edit the PHP files themselves. This will really open up designer's creativity and allow some really unique looking templates.

Another leap forward for Invision Power Board 3 is the ability to use display logic in the templates themselves. Naturally, we were always able to use <if> and <else /> but you can now use the following standard tags:

The Date Tag:
Examples:

{%date="1210012321"|format="manual{d m Y}"%} {%date="-1 day"|format="long"%}
{%date="now"|format="long"|relative="false"%}

For the first time, you can now explicitly specify a date format on a per-use basis. The tag accepts either a unix 'timestamp' or a human string like 'now', '-1 day', 'tomorrow', etc. The format parameter can either be a standard IPB date format (long, short, joined, etc) or a manual PHP Date format.

The Parse Tag:
Examples:

<parse expression="substr( $data['name'], 0, 10 )" />
<parse expression="sprintf( "14", "There are %s apples in the bag" )" />

This parse tag allows you to make on-the-spot parsing using PHP code. This tag is replaced with the value returned from PHP.

The URL Tag:
Examples:

{%url="foo=1&bar=2"|base="public"%}
{%url="foo=1&bar=2"|label="Click Me"|base="public"|id="myLink"|class="linkCSS"|onclick="this.function()"%}

The first example will actually create the entire <a href='' ... >...</a> HTML chunk whereas the second example will only return a formatted URL. The main reason for this tag is to prevent hardcoded entire URLs or even fixing part of the URL to a setting. In IPB 2.3 it wasn't unusual to see this:

<a href='{$this->ipsclass->base_url}&act=login'>Log In</a>

The new method would be like so:

<a href='{%url="act=login"|base="public"%}'>Log In</a>

The 'base' value being 'public' tells the template engine to use the public URL and not the ACP url. The real power of this feature lies in the return value being automatically fed via formatURL() which can return a friendly URL if friendly URLs are enabled.

The Variable Tag:
Example:

<variable key="tdColor" oncondition="$foo == "green"" value="green" /> <variable key="tdColor" oncondition="$foo == "black"" value="black" /> <span style='color:<variable="tdColor" />'>Hello World!</span>
<variable key="tdColor" default="blue" />

In this example, depending on $foo having a value of green:

<span style='color:green'>Hello World!</span>

This tag allows you to decide in the template itself how part of the template should display without having to edit PHP code. This is a handy tag for use in foreach blocks to alternate between colours when showing posts, topics, etc.

Custom Tags
The tags URL and date tags shown above use the {%tag="foo"|param="bar"%} format. These are actually custom plug-ins. You can write your own custom plug ins and they are available immediately within the templates. You could even modify the default plug-ins to change their behaviour.

We're looking forward to how these new tools are used in your own templates!

6,759 views

Matt

May 15, 200818 yr

IPB 3: Creating a new framework using PHP 5

One of the biggest discussions we had during Invision Power Board 3.0's planning was whether or not to drop support for PHP 4 and require a minimum of PHP 5. The advantages of using only PHP 5 were numerous and we really felt like we could increase security and efficiency by taking advantage of the new PHP 5 features. This decision became much easier when we learned that PHP 4 was no longer being developed.

To really see the benefit of using PHP 5, one must first consider how Invision Power Board's new framework is made possible by PHP 5.

Although Invision Power Board 1 and 2 were loosely based on the 'front controller' design pattern, it had no real framework to hang the code on. The closest it had to one was the 'ipsclass' super-class.

'ipsclass' was a convenient method of transporting various classes and functions around Invision Power Board. Convenient, but not ideal. One had to pass this 'super-class' from class to class forcing PHP 4 to use a reference (and being severely punished when forgetting!). This super-class contained almost all the 'core' functionality of Invision Power Board. Member, input and database objects were attached along with numerous other classes and functions. None of which was ordered in any logical format.

We have recoded Invision Power Board 3.0's framework from the ground up. We have done away with the 'ipsclass' super-class and employed the 'Controller -> Command -> View' pattern. This allows us to quickly add new code and to allow fast refactoring of our existing code. This pattern is built upon the 'IPS Registry'. This is a singleton class which maintains interfaces to several other registry objects (database, request, settings and member). Each of these objects maintains a clear place within the registry. This allows us to pass core data through the different levels of our pattern. Other functions from 'ipsclass' are moved into singtons: "IPSLib"; disparate functions that do not belong elsewhere, "IPSText"; functions for parsing and cleaning text, "IPSCookie"; functions to handle cookie management and "IPSMember"; functions that deal with loading, saving and parsing members. This offers a clear structure with clear boundries for each singleton class. Being singletons, you do not need to pass or reference the class in other files.

Here's an example:

IPB 2.3 Code

$value = $this->ipsclass->settings['board_name']$id = $this->ipsclass->member['id'];$this->ipsclass->input['f'] = 2;print $this->ipsclass->get_cookie('foo');$text = $this->ipsclass->txt_alphanumerical_clean( $text );print $this->ipsclass->class_forums->build_info();
print $this->ipsclass->input['name'];

IPB 3.0 Code

$value = $this->settings->getSetting('board_name');$id = $this->member->getProperty('member_id');$this->request->setField( 'f', 2 );print IPSCookie::get('foo');$text = IPSText::alphanumerical_clean( $text );print $this->registry->getClass('class_forums')->build_info();
print $this->request->getField('name');

It's worth noting that we have also applied the ArrayAccess interface to the registry, so you may access them like so:

$this->settings['board_name'];
print $this->request['name'];

Although the code examples use $this->request, $this->member, etc, these are set up in a constructor. You would pass the IPS Registry singleton into the class. Here's a typical constructor:

{ $this->registry = $registry; $this->member = $registry->member(); $this->request = $registry->request(); $this->settings = $registry->settings(); $this->DB = $registry->DB();}
function __construct( ipsRegistry $registry )

You could also access the ipsRegistry class directly, although this is strongly discouraged:

print ipsRegistry::instance()->request()->getField('name');
PHP 5 offers a much better OOP (object orientated programming) environment where references are assigned automatically. You can also chain along functions, which we make great use of. This allows us to do some neat trickery, like so:

IPB 2.3 Code

print $this->ipsclass->compiled_templates['skin_boards']->board_index( $data );
$this->ipsclass->load_template('skin_boards');

IPB 3.0 Code

print $this->registry->getClass('output')->getTemplate('boards')->board_index($data);

You'll note that you no longer have to implicitly load the template anymore. This is handled within the 'getTemplate' function if it's not already loaded. This object is then returned for use to chain onto 'board_index()'. This simple adjustment of code makes for less manual code and less room for error.

We are also making great use of PHP 5 abstract classes and interfaces to define extensible classes. This will make it much easier and clearer for others writing their own additions to Invision Power Board. Having a clear interface to work with will reduce errors in development and formalize how you may access Invision Power Boards class structures.

The 'controller -> command' structure is built so that you may add new modules and sections dynamically without the need to change a single line of code elsewhere in the script. Modification authors can just drop in new folders and Invision Power Board will run them when called correctly via a URL. The controller makes use of variables in a URL and safely loads a command file if a matching command file is located. For example: "appcomponent=core&module=global&section=login" is mapped to "applications/core/modules_public/global/login.php". We make use of the Reflection class functions to ensure that any potential command file is a sub-class of the controller to prevent the risk of tampering.

We've barely scratched the surface, but it's clear that Invision Power Board 3's framework is very powerful and code-efficient. This is only made possible by the advancements in PHP 5 that we've taken full advantage of.

8,121 views

Matt

May 8, 200818 yr

IP.Board 3.0 Development Introduction

We are moving rapidly on IP.Board 3.0 development along with its related IP.Blog, IP.Gallery, and IP.Downloads updates. As we approach being able to post these updates for a preview and an eventual release we think we are getting close enough that we can start talking about some of the new features we have planned.

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.

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.

Oracle Database
Due to slowing demand over the past few years, we have decided to discontinue supporting Oracle database system. We will continue to support MySQL and Microsoft SQL Server.

Subscriptions Manager
Again, due to slowing demand, we have decided to stop updating the subscriptions manager in IP.Board. We will be fixing all current known bugs to make the system compatible with IP.Board 3.0 so those currently using the subscriptions manager will still be able to upgrade. Anyone currently using the subscriptions manager will still be able to upgrade and everything will work normally for you. From there, we will be looking for community developers to keep it up to date. We will be posting a blog entry when ready to ask for assistance in keeping the subscriptions manager up to date. Anyone wishing to use our new IP.Nexus commerce system when it's available will be able to migrate as well.

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...

7,519 views

Charles

April 30, 200818 yr

Platform

Solutions

Guides

Help & Resources

Configure browser push notifications

Chrome (Android)

Chrome (Desktop)

Safari (iOS 16.4+)

Safari (macOS)

Edge (Android)

Edge (Desktop)

Firefox (Android)

Firefox (Desktop)