35 odpowiedzi w tym temacie

[EXPERTO]

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!

[EXPERTO]

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.

[EXPERTO]

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.

[EXPERTO]

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.

[EXPERTO]

The "all new" Output Engine
Posted by Matt, Sep 4 2008, 02:45 PM in IP.Board

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.

[EXPERTO]

IP.Board 3: Skin update

We wanted to use this blog entry to bring you an update on the brand new IPB3 skin. In my previous entry, I didn't go into any detail about the skin itself, but I did introduce the Style Guide and some goals/ambitions for the front-end interface. We're now at a stage where we can talk about the skin itself.

Whereas most of our other entries explain one particular feature in-depth, this post will be more of a quick-fire overview of some of things we're implementing on the front-end of IPB3, and some other tidbits.

Popup Windows
We took the decision to try and eliminate all popup windows from IPB3. Popup windows create several problems: in this day and age, you can't guarantee a user will even see them due to popup blockers, and secondly, with the myriad devices accessing the internet now, you can't be sure that a popup window will be supported, or a good user experience.

Instead, where browsers support it, inline ajax-populated popups are being used. Where browsers don't support it, the user is taken to the content like they would any other page. Our goal is to keep the entire experience confined to one browser window/tab, as I believe it should be. This includes friends management and warning management (for moderators).

Unobtrusive Javascript
Going hand-in-hand with the above was a desire to make IPB fully usable even if you had javascript disabled. As such, we've worked to make every feature, as far as is possible, available and usable even without javascript. There are some exceptions to this, e.g. the post editor (although you can still post, you'll just see a textarea), but on the whole we're on our way to making IPB3 much more accessible than IPB2.

Getting at user information
IPB has a lot of relevant information about each user, but presently it can be tedious to access the important details quickly since you have to go to their profile, taking you out of your workflow. New to IPB3 is a user card which can be accessed almost anywhere; wherever you see a username, simply hover over it to get all the relevant information for that user, including photo, contact details and reputation. This has been implemented in such a way that skinners and modders can also integrate it incredibly easily. We've also added a new bbcode which allows users to create these special links from within their posts.

Better uploading tools
In the past we've had numerous calls for TRUE multiple attachments. You'll be pleased to know that we've fully integrated SWFUpload into IPB3 for webservers that support it (which should be most). For those unfamiliar with this tool, it allows users to select multiple files in the Open dialog, and javascript then manages the upload queue for you. Another cool improvement is we now support upload progressbars with no additional server requirements! In addition, if you upload images, you'll see a thumbnail immediately, making it easy to insert the right image to your post, right where you want it.

Searching
The search form and results page have both been completely redesigned. Since the search mechanism in IPB3 underwent such a big change in being able to search all applications at once, we needed a new interface that made this easy to use. The result is a search form that adapts, showing you additional filters based on the applications you've chosen to search. The search results page combines all results from the applications you selected, but also allows you to show the results from just one application at a time. And finally, multiple results from one object (e.g. several matching posts in one topic) are grouped together so it's really easy to see the breakdown of your results.

Other significant improvements
While almost every page of IPB3 has been recoded from scratch and improved, some areas have undergone more changes than most. I'll cover them briefly so you know what you can expect when we unveil the skin:

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



Media tag
We've added a new [media] bbcode tag, which will insert all kinds of media right into a post. If you put a YouTube link in a media tag, it'll insert the YouTube player; similarly, if you link to a Flickr album, it'll insert a Flickr slideshow. New media handlers can be created in the ACP for those sites we don't support out of the box, while still using the same [media] tag - making it really simple for your users.

Quick PM
One last feature to mention - we have implemented a Quick PM feature, which allows you to PM a member from topic view without leaving the page. We hope this increases personal communication, and reduces the chance of topics going off-topic.


I hope that gives you some idea of what you can look forward to with regards to the front-end appearance of IPB3. We'll be previewing the actual design of the skin in the coming weeks as we ramp up testing, so if you have any questions, comments or suggestions on the things I've covered here, now is a good time to get them out!

[EXPERTO]

IP.Board 3: Topic Marking Overhaul

Topic markers have evolved quite a bit over the past few years. What started out as being an almost secondary concern has become quite an important part of the user experience.

A Very Brief History
Early versions of IP.Board relied on cookies to track read topics. This worked fairly well but it wasn't without problems. Anything to do with cookies is always a little flaky. There is a very finite amount of information you can store and browsers have a habit of eating them or not setting them correctly. The biggest complaint, however, is that topics that you have read on one computer do not stay read on another computer.

IP.Board 2 introduced topic markers that are stored in a database table. This greatly increased stability and allowed the read topics to remain read regardless of computer used.

However, this did lead to some performance issues on busier boards as the topic marker table is often in demand whcih can result in locking issues and processes queueing. Also, the code wasn't centralized and sprawled through different files making maintenance very difficult.

Learning From Experience
It was obvious we needed to centralize all the code and create a common, simple public interface as a matter of course. We also wanted to allow our other applications (such as blog and gallery) to use this system without having to copy code. Making it truly extensible also allows modification authors to use this centralized system without having to maintain their own code.

Next up was the performance issue. How could we increase performance without losing functionality? The most obvious answer was to store the read topics in the user's session. This was fine in principle but there were obstacles to overcome. First of all, session handling in IP.Board 2 is not entirely centralized. There is a class but it is not used exclusively. Other files such as register.php and login.php are allowed to modify the session table without telling other classes what it did. When you're trying to preserve data, this cannot be allowed. Also, session handling in general isn't an exact science. IP addresses change meaning new sessions can be created several times during a single visit.

The solution to these problems must be robust, centralized and extensible.

So, what's new?
First up was tightening up session handling. All session management is now performed through a single class (publicSessions). Other files that need to manage sessions are done so via publicSessions. This allows this one class to keep tight control over the session data.

The biggest challenge was to allow sessions to handle the marker data and only allowing the markers to be written back to the database table when the session is deleted. The theory is sound and simple but the execution a little trickier. The gory details of which are explained a littler further down for the technically minded.

In brief, the system loads the markers from the database table when a new member session is created. The markers are saved in with the rest of the session data when the session is updated at the end of a page view (to update the running time and location, etc). This continues until the session is due to be removed, for example, when the member is no longer active and the session is older than the allowed time. The sessions to be removed are captured and allowed to be examined by other classes. The item marking class examines these sessions and writes back the marker information to the marker database. The system also makes use of cookies to give some permanence for guests and those that are not logged in. The cookies are limited to the last 100 items read to prevent cookies being sent that are too large.

The end result is a much leaner system which should be much more efficient and presents a very simple public interface. Here's some sample code to give you a taste:

CODE
# To mark an item read (an item is a topic for the forums 'application')
$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 ) );


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.

[EXPERTO]

Kolejna dobra informacja z IPS

IP.Board 3: Friendly URLs at last!
Posted by Matt, Yesterday, 03:00 PM in IP.Board

Possibly the most often requested feature we've had since the very first version of IP.Board is 'friendly URLs'.

Although this sounds like you'd expect your URLs to greet you with a self-empowerment phrase first thing in the morning, it really relates to making the board generated URLs a little more attractive to both humans and search engines.

I am being very careful to avoid the phrase "Search Engine Optimization" in this opening few paragraphs despite it being used often in the request for friendly URLs. What we've added will definitely help with SEO but it's not a complete solution and neither is it intended to be.

So, what do you have?
In a nutshell: friendly URLs! The process to create and manage them is far more interesting than the end result, but more on that in a moment. Lets first look at some examples of the new URLs.

Here's a few sample URLs from IPB 2.3.x:

To show a forum (My Test Forum):
www.board.com/forums/index.php?showforum=10

To show a topic (My Test Topic):
www.board.com/forums/index.php?showtopic=99

To show a user (Matt Mecham):
www.board.com/forums/index.php?showuser=30

There's nothing wrong with those URLs. They are short and concise and they spider very well, but we can do a little better to make them more attractive.

If you are on a Windows webserver, you can use the 'query' string method which presents URLs like this:

www.board.com/forums/index.php?/forum/10/my-test-forum
www.board.com/forums/index.php?/topic/99/my-test-topic
www.board.com/forums/index.php?/user/30/matt-mecham

If you are on an apache based web server you can make use of the 'path_info' method:

www.board.com/forums/index.php/forum/10/my-test-forum
www.board.com/forums/index.php/topic/99/my-test-topic
www.board.com/forums/index.php/user/30/matt-mecham

Even better, if you can manage your own .htaccess files, you can make use of the mod_rewrite functionality. For convenience, the mod_rewrite code is generated for you. The end result looks like this:

www.board.com/forums/forum/10/my-test-forum
www.board.com/forums/topic/99/my-test-topic
www.board.com/forums/user/30/matt-mecham

What would happen if you used accented characters like this: Mått Méçhåm? The are simply converted into their nearest non-accented 'versions'. In this example, "matt-mecham".

How do I use it?
The easiest way to generate a 'friendly URL' is by making use of the {parse} tag:

CODE
{parse url="showtopic=99" base="public" seotitle="my-test-topic" template="showtopic"}


The "seotitle" parameter (and one of few concessions to the phrase Search Engine Optimization for brevity) is the ready-formatted string to use within the URL. If you want to parse the title on the fly into something a little more friendly, then you can wrap it like so:

CODE
{parse url="showtopic=99" base="public" seotitle="%%My Test Topic%%" template="showtopic"}


The optional "template" parameter refers to which template is used to build the URL. These templates are managed in a single file in "admin/extensions/seoUrlTemplates.php". Here's an example:

CODE
$templates = array(

# APP: MEMBERS
'showuser' array( 'out' array( 'showuser=(.+?)(&|$)', 'user/$1/#{__title__}$2' ),
'in' array( "/user/(\d+?)/", array( 'showuser', 1 ) ) ),

# APP: FORUMS
'showforum' array( 'out' array( 'showforum=(.+?)(&|$)', 'forum/$1/#{__title__}$2' ),
'in' array( "/forum/(\d+?)/" , array( 'showforum', 1 ) ) ),

'showtopic' array( 'out' array( 'showtopic=(.+?)(&|$)', 'topic/$1/#{__title__}$2' ),
'in' array( "/topic/(\d+?)/", array( 'showtopic', 1 ) ) ),

);


This example shows the default template code for showing users, forums and topics. The 'out' method deals with how the link is formatted while 'in' tells IP.Board how to handle the incoming links.

This means that if you don't like the format of the links currently, you can change them to suit your own tastes. Modification authors can also add to this file (via an interface in the ACP) to add in friendly URLs for their own applications and modules.

I did mention that "seotemplate" is optional - and it is. If you don't specify a template name then IP.Board will test all available templates to the URL its examining to see if there's a match. Actually specifying which template to use simply speeds up the process a little.

Any variables not catered for in the templates is added at the end of the URL, separated by an underscore like so:

www.board.com/forums/topic/99/my-test-topic/_/view/getNewPost

This makes for a convenient way to transport data without having to add all the possible permutations in the template file.

We hope that the inclusion of this popular request will go some way into helping your overall SEO approach as well as making common links look altogether more pleasant!

[EXPERTO]

IP.Board 3 Testing Procedures

As we get further along in the development cycle for IP.Board 3 an obvious step that we will be taking on soon is general testing of the new codebase. While this happens with every release, both internally and publicly, it is even more important for a release as immense as IP.Board 3. The entire underlying codebase has changed and vigorous testing will be needed to iron out all of the issues us developers have missed.

With every test phase of a product release, we frequently get barraged with requests from customers asking to be a part of the testing process. We wanted to let everyone know that we have come up with a process for IP.Board 3 that we think will please everyone - everyone will be able to test the new release if they wish to. original.gif

Progress is happening at an astounding rate, and right now we're working through bugs that we have identified and putting finishing touches on much of the software. The skin is still heavily being developed and worked on, both on the front end and in the admin control panel. Trust me when I say we're just as eager to get people in and show off what we've been working on as you guys are to see it. Please bear with us as we continue working on these rather unexciting yet necessary steps. We know you're anxious to see it and we want to ensure that what we deliver is what you are expecting. To that end, please also understand that future blog entries may be a little less exciting than they have been for the last several weeks.

All of us have begun testing IP.Board 3 internally. As we discover unfinished areas or bugs, we are working hard to rectify these things to get IP.Board 3 as stable as possible. We are still working through bug reports from previous versions of IP.Board, as well, to get IP.Board 3 off to a fresh start with as few bugs as possible.

Once we feel that IP.Board 3 is relatively stable, and that we have worked through all of the issues we have found internally, we will be inviting our customers (you!) to take a look and to give us your feedback. This first stage of testing we expect to remain tightly controlled, with us hosting a copy of IP.Board 3 and providing you access to this copy. You will be able to use the features and we would love for you to report back your comments on the functionality, the skin, and any issues you find. More information about what we will be looking for exactly will be available once we reach this point.

After we have ironed out all the bugs and addressed all of the feedback we can, we (as per our usual procedures) will be updating our company forum. This helps give us a chance to really test out the new release in a live environment. You'd be surprised at some of the issues that never come up during development and basic testing that come up when you move to a live environment. This also helps give us a chance to test the software under a real-world usage scenario, giving us information about resource usage and areas of the software that we feel need improvement to be able to handle today's large forums. We are dedicated to ensuring that IP.Board 3 runs efficiently so that you can don't have to worry about how your site runs, but rather how you run your site.

Finally, once we've gotten to this point and feel we've nailed down all of the bugs we can (or at least most of them) and we feel the software is stable and resource-friendly, we will open up IP.Board 3 for public beta testing. This is the point where you will be able to download IP.Board 3 and install it on your own servers (but not upgrade your live website) so that you can test it to ensure that our next generation release will meet your needs. There are, quite literally, thousands of different configuration scenarios and hundreds of different server environments out there, and this stage of testing gives us a chance to help make sure IP.Board will run properly and bug-free in as many setups as possible.

Throughout this process, we will be contacting modification authors, community project teams, and skinners to help get them started as well. We would love for IP.Board 3 to launch and have resources available right from the start, or as shortly there-after as possible. While we have no control over third parties integrating with our software, we will do what we can to assist these developers so that our customers will have as short a wait as possible for the software they need to run their sites.

From there, we plan to follow the normal routines we follow for release. We will correct reported bugs, test them internally, and release public betas for further testing. When we feel we are ready for release, we will put out a "Release Candidate" version of the software. This release is one that, to our knowledge, should be ready for prime time, but we are providing another chance for customers to test it and report back any issues that they have found so that they may be addressed before we release the software as "final" for general public usage.

We know everyone is excited about IP.Board 3, and eager to get a look at what we've been working on for the last several months. We are eager to show it off, and are looking forward to the testing phases described above. These phases give us invaluable feedback from the most important users - you!

[Major]

O co chodzi ?

[EXPERTO]

Ja to tak zrozumiałem że IPB jest już w fazie testów

[EXPERTO]

IP.Board 3: Personal Conversations

Around ten years ago, I was hard at work on one of the first 'Private Message' modifications for a board that has long ceased to exist. At the time it was an exciting novelty to be able to message another board member. These days it's an expected feature for any seriously considered forum software.

Not much has really changed with messaging's core features. Sure, the interface has become a little smarter and there have been a few little bells and whistles added such as message tracking but ultimately it's still sort-of email based in functionality.

This was a limitation I noted when developing IP.Dynamic. In fact, almost two years ago, I blogged about Personal Topics, the next logical step in private messaging.

Enter Personal Conversations
As, with most of IP.Board 3.0.0's new features, personal conversations - as we like to call them - have been a popular request. A request that we have now fulfilled! Why bother CC-ing and forwarding messages to other members when you can invite them right into the conversation?

How it Works
Where you would normally 'compose' a new message, you now 'start a new conversation'. The form looks largely the same. However, instead of there being a space to "CC" other members, there are boxes for you to invite other members. How many members you can invite is up to the administrator as it's limited to your group settings. In fact, the admin could remove your ability to invite other members completely if they desired to return to a more traditional messaging system.

The recipient and each invited member will be notified they have a new message (in terms of notification, a message is either a new conversation or a reply to any existing conversation). The new conversation will appear in both their "Inbox" and their "New" folders. It will remain in their "new" folder until its read and then it will only be available in the inbox. Why? Well, because of the magic folders. But more of that in a moment.

The conversation looks largely the same as a normal topic does; linearly sorted with the newest replies last. There is even a "fast reply" form much like you use when replying to topics. This instantly makes it easier to view previous replies and keep the 'thread' of conversation without having to delving into your 'sent' folder to see what you replied with.

The topic starter (and any participating super moderator) can choose to 'block' any participant that is blockable. Immunity from being blocked is granted by the "Not Ignorable" setting. This means you can ensure that you (the admin) can never be blocked from a conversation you are participating in. When a participant is blocked, the topic vanishes from their folders until they are unblocked.

Each participant apart from the topic starter can choose to leave a conversation at any time. Once the participant has left the conversation, it is only available in the magic "Finished" folder and the replies no longer count towards your space allowance. The topic starter cannot re-invite you but you can choose to rejoin the conversation at any time.

The topic starter can choose to invite more members (up to their invite allowance) at any time from the conversation display screen. Each participant can also view all participants and see the last time they read the conversation.

Magic Folders
This is the term we give to certain folders that are not editable or removable. They are: "New", "Finished", "All" and "My Conversations". Topics in "New" and "My Conversations" can also be in other folders. "My Conversations" is the default location for any conversation you start. You can then move into another folder -- but it will always be accessible from "My Conversations".
"New" simply lists any new personal conversations or any personal conversations with new replies. So, you could have a conversation in "My Folder". When it receives a new reply, it will also be listed in "New" until you read it.
"Finished" simply lists all the conversations you've left, allowing you to rejoin if desired.
"All", as the name implies, lists all the conversations you are participating in as either a starter, recipient or invitee.

We think this is a very exciting step forward for personal communication and opens up new ways to communicate via the forum. Ten years is a long time to wait for change. We hope you find it worth the wait!

[Mr.chudy135]

Jest już znana jakaś przybliżona data premiery?

[EXPERTO]

jeszcze nic mi nie wiadomo na ten temat jak testy wypadną poprawnie to myślę że ukaże się lada moment

[EXPERTO]

IP.Board 3: Networking And Integration

Brandon blogged a while back about IP.Board's integration points.

I wanted to spend a moment discussing the features within IP.Board 3 that all you integrate the board with your website and to create your own network.

Member Management
Since IP.Board 2, we've had, what we call, "Log In Modules". This is basically a mini-framework to allow custom code to be used easily when authenticating and registering members. For example, if you had a database full of members and you wanted for them to be able to use their existing usernames and passwords, you could add a log in module to query your database or other system (via SOAP, XML-RPC, etc) for authentication.

This system has been enhanced based on user feedback and IP.Board now ships with modules for LDAP and OpenID which will make it much easier to use existing authentication.

Networking
The log in modules also tie into our 'IP.Converge' product which allows you to share authentication details across multiple IP.Board installations. The IP.Boards don't even need to be on the same server! In fact, we use Converge and the log in modules ourselves so that our customers can use the same log in details on the forum as they do in our ticket center.
You could use this functionality to share members across many forums, creating a true network of members.

Using the IP.Board Engine
We've made no secret that IP.Board 3 is a complete rewrite. The new framework makes full use of PHP 5 and incorporates many timesaving features that you can instantly make use of.

It's common for our customers to ask how they can use certain parts of IP.Board within their own website. For example, they'd like to show a list of recent topics or posts. That's no problem as we've had an API class interface since IP.Board 2.

However, if you wanted to send data to IP.Board, such as a new post or new personal message; things got tricky. Even using a template bit required a lot of code copying.

For example, if you wanted to make use of our database engine or templating engine, you would need to copy a lot of 'index.php' so that it set up ipsclass correctly. With IP.Board 3, that is no longer required. You can use our engine in your own scripts as simply as this:

CODE
require_once( './initdata.php' );
require_once( IPS_ROOT_PATH . 'sources/base/ipsRegistry.php' );

$registry = ipsRegistry::instance();
$registry->init();


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:

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

$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();
}


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!

CODE
require_once( IPSLib::getAppDir( 'members' ) . '/sources/classes/messaging/messengerFunctions.php' );
$messengerFunctions = new messengerFunctions( $registry );
$messengerFunctions->sendNewPersonalTopic( $toMemberID, $fromMemberID, $invitedUserIDArray, $msgTitle, $msgContent );


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

CODE
require_once( IPSLib::getAppDir( 'members' ) . '/sources/classes/messaging/messengerFunctions.php' );
$messengerFunctions = new messengerFunctions( $registry );
$messengerFunctions->getPersonalTopicsList( $memberID, 'in' );


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

CODE
require_once( './initdata.php' );
require_once( IPS_ROOT_PATH . 'sources/base/ipsRegistry.php' );

$registry = ipsRegistry::instance();
$registry->init();

print $registry->output->getTemplate( $templateGroup )->templateName( $templateArguments);


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!

[EXPERTO]

IP.Board 3.0 Search Engine Optimization

We receive requests quite frequently to "add SEO to IPB". This is a very difficult request to quantify and to fulfill. What is SEO? What is wrong with IPB's positioning to search engines presently? What can be done better?

We've seen some suggestions over time that make sense, and some we feel would be better left to modifications. While we are not jumping full force into the "SEO" arena with IPB 3, we have made changes throughout the software that we believe will help you position yourself better for search engine indexing. This blog post will touch on a few of these changes.

Semantically correct HTML
The word "semantic" means the study of meaning in communication. Basically, when used in the context of an HTML document, to state that the source code is semantic means that the HTML tags used are appropriate for their representations. It wasn't too long ago that tables were used to position elements in your browser window, and 1x1px gif images were used to pad areas so things looked nice. Those days are (almost) long gone, and today's modern web pages are focusing on producing HTML source code that makes sense, while separating styling to CSS documents and javascript to external javascript files.

When IPB 3 ships it will validate as xHTML valid, and the source code will be semantically correct. Deprecated HTML tags and excessive and unnecessary tags (such as 3-layer nested divs) are not used, and the javascript is not obtrusive (*see comments). Screen readers and search engine spiders should find it much easier to read a topic generated by IPB 3 than IPB 2. Furthermore, all functions should work (although in some cases to a lesser degree) when javascript is not available. Heading tags are used properly and feature keywords related to the content on the page. They also cascade in a defined format so that they represent the content in a meaningful way.

*Note: HTML will be semantic and javascript unobtrusive to the extent possible. There are thousands of configurations, literally, and with so many browsers, options and features it is hard to make a blanket guarantee of this sort. Rikki has explained more about our goals for the skin in another blog entry if you are interested in the new skin.

Microformat support
Microformats are common ways to represent similar data. For instance, it is not uncommon for a random website to have some sort of news or articles data and some sort of user profile page for each user. Microformats were developed so that these common things could be represented in a common way to help further the web. By utilizing microformats, other webpages and scripts can parse your page and extract valuable data that they can then share. Even Internet Explorer 8 will be making use of Microformats for some of it's cooler new features, while other browsers already do or are also planning to.

IP.Board 3 makes use of several microformats to help your document make sense to tools that can read and understand these formats. Specifically, we are making use of the hCard, hCalendar, rel-nofollow, rel-tag, and rel-home microformats. We also make use of some other common relationship attributes where appropriate (such as "rel='help'" for the link to the help documentation), even though they are not necessary full-fledged microformats at this time. Furthermore, we will continue exploring and watching microformats, and applying them as they develop and relate to IPB.

rel='nofollow' Support
This is another common request we receive: making all posted links in topics utilize the "rel='nofollow'" attribute appropriately. Many users, on the other hand, have asked that we do not implement this. The idea is that search engines should understand "rel='nofollow'" to mean that the webmaster is not endorsing the link, so when the search engine follows it, the search engine shouldn't penalize the website the link is hosted on should they determine it was a bad link, or irrelevant to the linking site.

We have added a setting to allow users to enable this without having to make source code modifications. The rel='nofollow' attribute will be automatically appended to all urls posted and parsed through the normal bbcode routines when the setting is enabled.

Removal of "(Powered by Invision Power Board)" from board index
For years, since the beginning of IPB, the page title of the board index page has had "(Powered by Invision Power Board)" added to it if you did not purchase copyright removal. We did not disallow users from removing this text, however, and many users did.

We've gone ahead and bit the bullet, and removed this text from the base release.

Removal of "lo-fi" version
The lofi version in IP.Board was meant to provide a toned-down basic representation of the current topic or forum. It was useful for both search engines and mobile browsers. It was so useful, in fact, that many times when you reach an IPB in a search engine listing you will actually end up at the lo-fi page instead of the full-version page.

In IP.Board 3 we have removed the lofi version entirely in favor of the new output engine capabilities. A mobile skin can be set directly through the admin control panel, negating the necessity for an entirely different script to serve the content. This is the great thing about the MVC pattern for all you developers - leave the model and controller alone, and just change the view itself.

The relationship to search engine optimization comes into play when you consider that the lo-fi version and the full version are essentially duplicating the content from one another, and a commonly held belief exists that search engines penalize you for duplicate content. While we can't speak for what any given search engine actually does, we did feel this feature was deprecated and no longer needed given advances in the skin system in IPB, and have removed it entirely.

Changing of modes moved to user control panel
It's not uncommon for a search engine to index a link to a topic on a site running IP.Board, and for some unknown reason decide the topic is best represented when "&mode=outline" is added to the URL. While this doesn't stop you from visiting the page, it DOES change the layout of the page, and for newcomers some of the alternate layouts may not be as easy to follow when they first visit your site.

Many users do utilize the different layout options (which are handled on a per user-account basis) so we did not feel it wise to remove these options. Instead, we have moved the ability to change the layout of topics to the user control panel. This should stop search engines from indexing topics with "mode" parameters in them, reducing confusion for visitors actually clicking the link to visit your site.


Additional features
Additionally, we've already gone over a few other changes that are related to better search engine positioning which we need not repeat here. Just as a brief recap, you may also be interested in reading these blog entries

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



There are many more minor but important improvements buried deep within IP.Board 3 that should help you keep your site listed in search engines appropriately. While we won't jump on the SEO bandwagon and advocate certain styles of running your site or formatting your urls, we are doing our part to bring basic functionality our users have requested with regards to their site's optimization into reality with IPB 3.

[LukaS]

popsules znow cos nie ma SB i cos po angielsku mi wyskakuje

[EXPERTO]

Robię upgrade to trochę potrwa...

[EXPERTO]

IP.Board 3: Kernel Improvements

Since IP.Board 2, we've had a "kernel" of classes which IP.Board uses but do not depend on IP.Board to use. A selection of these kernel classes includes DB management, file uploads, emailing, RSS parsing and reading, XML parsing and reading and our proprietry archive format XMLArchive.

For example, you could use "classUpload.php" and "classImage.php" in your own modifications or extensions to handle uploads and GD thumbnail generation. You would not have to initialize the registry or do anything else other than just include the file and use it.

As we took the plunge and went ahead with making PHP 5 a requirement, we were able to make some long-awaited improvements. Here are the high-lights.

Custom Fields
Josh has completely re-written custom field handling within IP.Board and this class ties it altogether. Josh uses just about every PHP 5 trick in the book including abstract classes, interfaces and ArrayAccess to provide a simple clean interface that can be used in almost any project. It doesn't have to be limited to just IP.Board's custom profile fields.

Graphing
Remco has extended this class to include many new graph types including "funnel", "bubble" and "radar" graphs so that presenting data is more relevant. As IP.Board 3.0.0 develops, we'll be making good use of these new methods for statistic reporting within the ACP.

GD and ImageMagick
Brandon virtually started from scratch with our GD image creation. He also wrote a class for imagemagick offering more choice for those who have it installed. It's now very simple to resize an image or add a watermark.

CODE
$image = new classImageGd();
$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();


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:

CODE
$xml = new classXML( 'utf-8' );
$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();


This will produce this document:

CODE
<productlist name="myname" version="1.0">
<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>


This is how you'd parse that document:

CODE
$xml->loadXML( $xmlData );

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

/* Prints: */
Baked Beans
Green Beans


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:
CODE
$archive = new classXMLArchive();
$archive->read( "/path/to/archive.xml" );
print $archive['someDir/file.html'];


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:
CODE
$archive = new classXMLArchive();

$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();


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.

[EXPERTO]

IP.Board 3: Administration Improvements

Introduction
Administration is an important part of running your site. You need to be able to control your site the way you want to, and you need to be able to do it as quickly as possible. Not everyone has an hour or two to hunt down a setting, after all. Once you start to factor in the fact that other applications (such as IP.Blog, IP.Gallery and IP.Downloads) can integrate into this same administration control panel there are new challenges to take into account as well.

With IP.Board 3 we've made improvements to the ACP in an attempt to help streamline common administrator actions and make the overall work flow clearer and easier.

Navigation
Navigation is a tricky thing to manage once a project becomes as large as IP.Board has. We've broken navigation down into multiple areas to help you drill down and find what you are looking for. Firstly, each application is listed at the top of the page - that way you can jump to whatever application you need to edit right away (no more navigating to the "Components" tab to edit IP.Gallery categories, for example). Then, along the left hand column you will find an expandable menu which provides access to the main pages of the application, similar to IP.Board 2. For applications requiring it, context links and tabbing are then utilized within the main area of the page to facilitate your work flow. We realize without screenshots it may be hard to visualize the new ACP, but a primary goal throughout the whole process was to retain a level of familiarity so that existing admins will find navigating very natural, while improving the process where-ever possible.

Searching
One complaint we've heard over the years is that new administrators frequently have trouble finding where they need to go in the ACP. Searching is a natural inclusion to help people find what they need, and can even be helpful for seasoned administrators as a shortcut to get where you need to go quicker. We have added a live-search facility to the admin control panel to help you find what you need much much easier (and before anyone asks - yes, "live search" is like the search on apple.com rolleyes.gif ). The settings page already had search functionality in IP.Board 2, but we felt that wasn't good enough. Many times the "setting" you are looking for is found when editing a group, not actually in the main site settings area.

To that end, the live search searches "settings", "pages" and "acp help" files. We have also included a method of adding keywords to these sections so that if we find many users are looking for an area through a specific keyword, we can easily add that keyword into the system so that searching for it will return the results people are looking for.

We will need your help once IP.Board 3 goes into beta testing with identifying areas that need keywords added for new administrators. What a wonderful way for all of you who are so eager to help out to give back to the community! And you don't even need to know PHP or HTML for this. biggrin.gif

Better Integration
While we have mostly already gone into detail on this front in other blog entries, just to recap on the subject within the context of this blog entry, improvements have been made to areas of the ACP that people frequently need to plugin to in order to help improve usability overall. For instance, an application can now show per-group settings on the actual group edit form, instead of having to provide a separate disconnected page in the application itself (for instance, the "Group Settings" page of IP.Gallery - these settings are now directly include on the edit group form instead). Similarly, applications can plugin to the edit member pages of the ACP, all with no file editing required. Settings for an application can, as they could in IP.Board 2, still be included within the settings area of the ACP. This means you can edit a group and control all of it's settings, without having to go to each application separately to update settings for the group.

Permission Editing
Many applications have a permission matrix - a grid of checkboxes that control what each permission mask can do within that application. This system works so well that we centralized the functionality in IP.Board 3 to make it easier to reuse and control. In doing so, we've also created an easy method of updating settings for every application on a per-permission set level. That is to say, if you want to update the permissions for users in the "Validating" group, you can do so globally from one page - for all applications at once. Remove calendar permissions, forum permissions, and gallery access all at once, without having to visit each application individually.

Going along with this, many users have been confused with how permission sets and groups relate to each other. We hear often from administrators that they created a new group - now how do they set the permissions for that group? To make this easier to understand and manage, when adding a new group there is a field that will allow you to fill in a new permission mask name (if you want to set permissions for the new group differently from other groups). After you save the new group, you will be redirected to the page that allows you to edit that group's permissions globally. You no longer have to create the mask first, set all the permissions (in each application separately, as well) and then add the group afterwards, selecting the new mask. Now it can all be done in one simple, easy to understand work flow.

Template Editing
I can't give out too many details on the template editor interface *just* yet I'm afraid, but let's just say that template editing has been entirely overhauled. We have put a lot of thought into ways of making it easier to edit templates, CSS and macros to hopefully help administrators work through their skins in a much much easier fashion. Some improvements that you may find interesting:

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


Reordering content
Remember all those lovely reordering dropdown menus (e.g. in the forum management screen)? Or those wonderful up/down arrow combinations (e.g. in the component management screen)? While they certainly served their purpose, they were identified for IP.Board 3 as being both inconsistent and, well, old.

All areas utilizing reordering functionality for all of our applications will use drag-n-drop + AJAX javascript functionality in IP.Board 3. Want to move a forum up one spot, just drag it up there and you're done.

In Closing
We think you will find that all in all the ACP area will be much easier to navigate and utilize in IP.Board 3. Once we get into the public beta testing stages and you get a chance to review our changes we'll be eager to hear your opinions and suggestions on the new and improved administration area.