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!