Matt's Blog

If you were a fly on the wall in the US office, you would have witnessed the following:

svnX deleting two days worth of my work (classPost.php) with a single miss-click…
FileSalvage finding classPost.php enabling me to restore it…
Chicken and egg scenarios in ipsRegistry.php finally fixed. We hope…
Tweaking the IP.Board 3 template tag format to make it a little more universal…
Excitement over Rikki’s IP.Board 3 designs…
XSLT discussion… Shame not every PHP installation has the extension enabled…
Excitement over Rikki’s javascript…
Enjoying a lively debate in the customer only forum…

Out of nowhere….

“sigur rós’s fifth lp is called “með suð í eyrum við spilum endalaust” (with a buzz in our ears we play endlessly). it will be released june 23rd worldwide (june 24th in north america) and will be available to pre-order on sigurros.com on june 2nd.”
(Source)

How exciting! It’s the first album to have a song sung completely in English, too.

More information, here.

Originally posted at IPS.com
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="now"|format="long"|relative="false"%}
{%date="1210012321"|format="manual{d m Y}"%}
{%date="-1 day"|format="long"%}

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

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"|label="Click Me"|base="public"|id="myLink"|class="linkCSS"|onclick="this.function()"%}
{%url="foo=1&bar=2"|base="public"%}

The first example will actually create the entire <a href=” … >… 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

The new method would be like so:

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

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" default="blue" />
<variable key="tdColor" oncondition="$foo == "green"" value="green" />
<variable key="tdColor" oncondition="$foo == "black"" value="black" />

<span style='color:<variable="tdColor" />'>Hello World!

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

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!

Originally posted at IPS:
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
print $this->ipsclass->input['name'];
$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();

IPB 3.0 Code
print $this->request->getField('name');
$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();

It’s worth noting that we have also applied the ArrayAccess interface to the registry, so you may access them like so:
print $this->request['name'];
$this->settings['board_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:
function __construct( ipsRegistry $registry )
{
$this->registry = $registry;
$this->member = $registry->member();
$this->request = $registry->request();
$this->settings = $registry->settings();
$this->DB = $registry->DB();
}

You could also access the ipsRegistry class directly, although this is strongly discouraged:
[code]print ipsRegistry::instance()->request()->getField(’name’);[/code]
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
$this->ipsclass->load_template('skin_boards');
print $this->ipsclass->compiled_templates['skin_boards']->board_index( $data );

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.