• Integrated searching - one search form will search everything
• All application caches managed from cache management screen.
• All skin data managed from template editor screen.
• Ability to edit all group settings from group management page.
• All application permissions handled from one location.
• Ability to show gallery or blog data on board index through hooks

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

• Ability to crop, rotate, dynamically resize images. Use Javascript for front end, then re-generate image using GD on backend when user saves.
• Fancy slideshow feature. Something like Flickr, but done completely in Javascript (no flash needed), little simpler probably.
• Better album control based on friendships - only allow friends to view album, allow friends to submit to your album, etc.
• Sub-albums
• Image tagging
• Correct category/album markers (ala IPB)
• Allow users to choose album covers from images in an album

• Better and more abstracted support for file records. Ultimately the goal would be to allow you to submit multiple files to a single file record. Uses would include "contributed files", breaking single files into "parts" (i.e. for large movies), and multiple screenshots per record, for instance.
• Support for mirrors
• Ability to shut off "resume breakpoints"
• Better category control - template type system perhaps with ability to selectively override without ditching entire template
• More reliable upload progress meter
• Correct category markers (ala IPB)
• File tagging
• Dynamic and session-based download urls (when you start a download, create a new "url" for it that is only accessible for that session and is destroyed afterwards to further prevent hotlinking)

• HTML Syntax highlighting of skins when editing the templates in the ACP
• Condensed HTML templates make it much easier to edit an entire "page" without having to edit 8 separate templates that will be compiled into one page
• No more separate "Global board header and footer wrapper" area. We have, instead, made a wrapper template which includes the content of this area as well as the global_board_header, global_board_footer, member_bar, navigation, and a few other common areas shown on every page
• AJAX CSS editing. This was actually a specific request from Rikki - apparently it's rather inconvenient to scroll 3 pages down in the CSS file, edit a color, save it, and end up at the top of the file/textarea and have to find where you were at again. Go figure. Anyways - when you save a CSS file now, it uses AJAX to save the contents, and the page remains stationary so you don't lose your place.

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

$image = new classImageGd();

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

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

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

$xml = new classXML( 'utf-8' );

This will produce this document:

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

<productlist name="myname" version="1.0">

This is how you'd parse that document:

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

$xml->loadXML( $xmlData );

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

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

Here's how to read an archive:

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

 $archive = new classXMLArchive();

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

Here's how to create an archive:

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

 $archive = new classXMLArchive();

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

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

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

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

require_once( './initdata.php' );

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

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

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

    $postClass = new classPostForms( $registry );  $postClass->setForumID( $forumID );  $postClass->setForumData( $this->registry->class_forums->forum_by_id[ $forumID ] );  $postClass->setTopicTitle( "My Topic" )  $postClass->setPostContent( "Hello, I am post content!" );  $postClass->setAuthor( $memberID );    try  {      $postClass->addTopic();  }  catch( Exception $error )  {      print $error->getMessage();  }

require_once( IPSLib::getAppDir( 'forums' ) . '/sources/classes/post/classPost.php' );

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

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

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

  $messengerFunctions = new messengerFunctions( $registry );  $messengerFunctions->sendNewPersonalTopic( $toMemberID, $fromMemberID, $invitedUserIDArray, $msgTitle, $msgContent );

require_once( IPSLib::getAppDir( 'members' ) . '/sources/classes/messaging/messengerFunctions.php' );

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

  $messengerFunctions = new messengerFunctions( $registry );  $messengerFunctions->getPersonalTopicsList( $memberID, 'in' );

require_once( IPSLib::getAppDir( 'members' ) . '/sources/classes/messaging/messengerFunctions.php' );

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

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

require_once( './initdata.php' );

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

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

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

 # To mark an item read (an item is a topic for the forums 'application')

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

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

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

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

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

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

• Improved board index
  One of the first steps I made when developing the new skin was to look at each major page and figure out if it could be made more useful than it is now. One result of this process was to improve the board index - and the new hooks system made this possible. The board index now features a collapsible sidebar, showing relevant information such as recent topics, top posters and more. Naturally, since this is hook-based, mod authors will be able to easily add their own data to this area.
  
  
• User control panel
  The control panel was a big focus right from the start. We first knew we were going to remove the messenger from the UCP, since it didn't fit conceptually. What was left has been redesigned, with settings broken down into tabbed sections, showing only the menu for that section - this should prevent new users from being overwhelmed when they open their UCP and seeing so many links.
  
  
• Messenger
  As noted above, the Messenger is now its own complete section, reducing clutter.
  
  
• User profiles
  User profiles have been redesigned, bringing them more into line with what users might expect from their favorite social networking sites. One new feature we're excited about is a Recent Activity feed, which allows you to see quickly what content a user has contributed recently, be it topics or posts, calendar events, images and more. This is made possible by the search index, which we covered in a previous post.

• -50 Negative Level 2
• -25 Negative Level 1
• 0 Normal Level
• 25 Positive Level 1
• 50 Positive Level 2

• Action overloaders
• Skin overloaders
• Template hooks

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

    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!

• 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

• 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