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', 'user@localhost.com', '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.

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

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

• 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

• 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

{%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!

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

• Edit Entry Date
• Display article count for categories
• Blog Offline Mode
• Entry author replies in comments are now highlighted
• Admins can select a 'Featured Entry' to be displayed on the blog listing

• Drag-n-drop support for reordering post form fields and categories
• Custom post form fields now automatically insert into the image view page and submission form
• Ability for admins to deny ability to members to create private albums
• Zip import support for members
• ACP language abstraction
• Slimmer templates for easier skinning
• Forum-style listing for albums
• Improved search capabilities
• Email notification options for comments and image submissions
• Image dimensions display on the image view page