bfarber

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

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. :) 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!

It is necessary in any application to handle error situations. The most common method of handling such a situation is to issue an alert to the user so that they know an error has occurred. While this is sufficient in most cases to resolve the problem, we wanted to address IP.Board's error handling routines a little bit with the upcoming release to try to make them a little more useful. Firstly, we've gone through all of the errors that are issued, and clarified and separated them. No more obscure "Sorry, some required files are missing" error messages when doing something as simple as visiting a topic that has been deleted. The error messages should be much easier for the end user to understand with the upcoming release. In addition to updating the error messages themselves, we've added unique error codes to each and every message. The error codes follow a defined format so that in the event you need to submit a ticket and reference an error message you received, by providing the error code our technicians can look up more information on the error and easily find where and how it was triggered. This should help make technical support more efficient for all of us. At some point following the release of IP.Board 3.0, we intend to make public this error codes database so that users can easily look up more information on errors when they need to by themselves. Further to this, we've added error logging. By default, certain errors will trigger a log to be generated. Generally, these logs are only generated when an error has occurred that could indicate a user is attempting to bypass security restrictions. Some administrators may want to trap more errors, however (perhaps even all generated errors), and as such we've added a setting that allows you to force IP.Board to log all errors above a given level (levels range from 1 through 5). Additionally, you can opt to be notified of all errors triggered above a certain level. For instance, if you want to know about all level 5 (serious) errors encountered right away, you can have the board email you when such an error is generated. This can help you administrate your board more effectively and securely by identifying issues you didn't know existed (for instance, in a custom modification), and can help our technical support drill down on issues that are unique to your site. The log pruning task has been updated to support the new error log tables so you can prevent it from growing too large. We have some more ideas for improvements to the error system in general to provide more value and assistance for you and your users. Errors are a necessary part of application development, but we are doing our part to make them as friendly and manageable as possible. If you have more ideas for improvements to the error management system in IP.Board 3 please share them with us below!

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 overloadersSkin overloadersTemplate 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.

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.

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!

BBCode is a core part of your forum system. We understand that. To that end, we've been working hard to completely rewrite and overhaul the entire bbcode handler in IP.Board 3.0. We think you'll like what is in store. Changes since IP.Board 2.x There are some core differences in the BBCode system we are introducing in IP.Board 3 that you may notice right away. For starters - *every* BBCode is configurable via the Admin CP. That means if you want to add "rel='nofollow'" to your urls, you can do so without editing files. If you want to change the resulting HTML for a code tag, you can do so, right there in the admin CP. Similarly, the backend treats every bbcode as "custom" as a result, and every bbcode is treated equally. Additionally, we are changing the HTML that the bbcode parsing generates to be more XHTML compliant. Alt attributes are added to image tags. We've changed emoticons to place the emoticon code in the alt attribute, and have removed the (non-standard) emoid attribute entirely. Quotes will properly use the blockquote HTML tag (and, further, will use the "cite" HTML tag when you provide the name and link with the quoted text). Bold will now use the HTML "strong" tag and i will use the HTML "em" tag. Almost all of the bbcode HTML is being rewritten to be both more semantic, and to bring IP.Board's HTML output up to today's standards. Additionally, the code-syntax boxes (e.g. HTML and SQL bbcode tags) are undergoing an overhaul that will make them much more flexible and allow us (and you!) to add new code languages very easily. We will be providing more information on how to do this in the future. New features in the BBCode system I'm sure this is what you've all been wanting to find out about. Well, here we go (in no particular order)... Aliases: BBcodes can now have aliases, so that more than one tag can execute the same custom bbcode. Uses? For instance, "code" and "codebox" both execute the same bbcode. Similarly, "media", "blogmedia", "flash", and "youtube" are all one bbcode that behaves the same way. (Hold your horses, we'll get to the media in a minute ;) )Single-tags now supported: You wanted to add "". You now can.Option content is optional: Bet that sounded confusing. It really isn't - basically, taking the "URL" tag as an example, you can either provide the URL as the "option" to the URL tag, and display text as the "content", or you can omit the option entirely, and the content becomes the display text. This setting allows you to do the same thing with your own bbcode.Prevent other codes from parsing: You can prevent other bbcodes from parsing inside your own bbcode. The classic example is our "code" bbcode - you don't want smilies and other bbcodes parsing within the code bbcode when you're trying to show someone how to use them.PHP Plugin execution: Do you require a bit more logic to be carried out to replace the bbcode? You can utilize plugin files to do this. Plugin files have a defined interface and more information will be provided for developers near launch. Several of our default bbcodes utilize plugin files, so this should help developers more easily understand how they can be used. You will no longer need to modify built in bbcode processing files to add new bbcodes.Control which groups can use a bbcode: The bbcode manager now has a multiselect which allows you to specify which groups can utilize the bbcode (secondary groups also supported). So if you want admins to be able to create tables using a [table] bbcode tag, but not members, go for it.Control where each bbcode can be used: Want to allow images in posts, but not in signatures? Now you can configure this right from the bbcode management screens in the admin cp. This feature runs on a plugin system so modification developers can also allow you to configure which bbcodes are allowed in your custom applications. New "default" BBCodes in IP.Board 3 I use the term "default" loosely, since everything is configurable via the ACP. In addition to all of the bbcodes you will find in IP.Board 2.x, the following default bbcodes will be available in IP.Board 3: "member". Usage: bfarber. This tag is a "single" tag bbcode that accepts one option, the member's display name. When parsing out the tag, the bbcode will generate the correct link to the member's profile and display "<a href='correct link'>member name</a>"."hr". Usage: . Very simple bbcode which generates a horizontal rule."xml" and "php". Usage: XML content or $phpCode = 1;. Generates syntax-highlighted code boxes, similar to the existing SQL and HTML boxes. "media". Usage: http://youtube.com/videolink. Ah, the one most of you have been waiting for. The introduction of the media tag in blog was so well received, we've gone ahead and added it to the IP.Board core. You can configure the media tag matches and replacements (for those of you who own Blog 1.4, you'll know what I mean), which allows you to add new media services at will. Generic flash (the old "" bbcode in IP.Board) works through this new media tag as well. Optionally accepts "width,height" as it's option. Sharing and formatting content couldn't get much easier that configuring what you want in the ACP! Dull boring techie stuff For those of you actually interested in the code aspects of the new system, we've completely rewritten the bbcode parser from the ground up. Firstly, sections should go back to the proper way of calling pre_db_parse before storing content in the database, and pre_display_parse before actually displaying it. This will ensure that bbcode can be correctly unparsed when a user edits their content. A major change to how the formatted text is handled: it isn't! We don't do any bbcode parsing on save, storing (nearly) exactly what you submitted into the database. Instead we format the bbcode at the time of displaying the content. This means we don't have to "unparse" previously parsed bbcode, nearly eliminating any bugs in attempting to do so. Another nice thing about this method...while you will need to rebuild your posts when you upgrade to IP.Board 3, you should never need to again. Ever. Yes, you read that right - you will need to rebuild your posts once upon upgrading to IP.Board 3....but after that, no more rebuilding posts headaches. Additionally, we intend to fully update our command-line rebuild posts routine, and we intend to introduce a task which will do this for you automatically should you wish. More information on this will be available as we get closer to launch. Some of you may be wondering about the resource impacts of parsing a post on every display. In rewriting the bbcode engine, we've nearly completely eliminated regular expressions in our bbcode engine. Regular expressions allow you to take a "pattern" and find matches to that pattern in a block of text. This is how bbcode was found and replaced in IP.Board 2.x (and in most other bbcode engines out there). For IP.Board 3, we are talking what's called a "tokenized" approach. We use some very fast built in php functions (such as strpos and substr_replace) instead of performing massive regular expressions, making the entire bbcode parsing process much quicker. We will be profiling this in greater detail as IP.Board 3 starts wrapping up. We'll try to share the results of this profiling with you at that time. We've also entirely rewritten the word wrap function in IP.Board. It should now be fully HTML-safe, HTML-entity-safe, and multibyte-safe...three huge problems we've repeatedly run into with the word wrap function in IP.Board 2.x. Additionally, there will now be one word-wrap function, and it properly lives in the bbcode library (though for legacy purposes, we will maintain a "redirect" function in our text handler class similar to the function in ipsclass in IP.Board 2.x). All in all, once we get the various inevitable kinks all ironed out with using the new system, it should not only be much easier to utilize our bbcode library, but it should be much more reliable and much faster to boot! Conclusion We hope you like the changes in store, and we hope that the updates which many of you have waited a long time for will serve your post-formatting needs for the forseeable future. Please share your thoughts or ask any questions you may have, and we'd be happy to try to answer them for you.

IP.Board has grown a lot over the years. We've added new functionality through the components framework, allowing us to deliver first-party supported addons such as IP.Gallery, IP.Blog and IP.Downloads. Our Community Projects leverage this infrastructure to provide even more value for your board, and third party developers have produced wonderful components utilizing the same infrastructure on their own. As IP.Board has progressed, we've seen challenges with the integration and continued separation of these components. We don't want our addons modifying core IP.Board files - this makes upgrading IP.Board a much more challenging task than it should be. At the same time, the components should seamlessly integrate into the core of the site so that everything can be managed together, and common code libraries can be shared. IP.Board 3.0 introduces our new application framework which will replace traditional "components". The software "out of the box" comes with 5 applications. There are 3 default applications: System (which includes things like template editing and settings, things that are not specific to any section, but are part of the core of the site as a whole), Members (member management, group management, and similar functionality), and IP.Board itself (forum and moderator management, for example). Further to this, the core of IP.Board 3.0 supports IPS-provided addons, and third party addons, which will function the same as our integrated built in applications. We provide 2 IPS addons out of the box: Calendar and Portal. Applications can be disabled globally (i.e., you can easily shut off or turn on the Calendar, for example). The IPS and third party addons operate identically, and utilize the same fully-featured application framework our built in applications use. You can easily add settings, adjust the secondary menus, build in permission routines and determine cache loading/updating routines, and much much more simply by utilizing this framework in specific ways (for instance, providing a specific file in a specific location within your application). We hope that the new framework will help third party developers (and ourselves!) to be able to segregate code so that it does not interfer with the core IP.Board code, while at the same time being able to fully integrate into both the front end of the site, and the admin control panel. We will be providing some guides and developer information with the launch of IP.Board 3.0. For instance, we plan to provide an overview of exactly how we convert one of our first-party components over to the new framework to show developers exactly how they can convert their own code base. This new framework should be utilized for fully-featured sections or addons. More information will be forthcoming in future blog entries on how to utilize new plugin and hook functionality provided with IP.Board 3.0 for addons that don't require separate "sections", and thus don't require use of the full application architecture.

The term 'ban' in IP.Board has a relatively loose definition and can often mean many different things. IP.Board supports an array of useful features to control access to the board, or in this case to restrict access to the board. Some examples of what 'ban' may refer to are IP address ban filtersEmail address ban filtersUsername ban filtersPlacing a user in the 'Banned' groupSuspending the user so that they cannot access the board temporarilyAdditionally an administrator can prevent a user from posting for a set amount of time, or require preview of all of their posts for a set amount of time. Many users have asked us to make it easier to ban users - frequently an administrator finds that they want to do more than just one of the above actions, and usually against a specific user account who has been causing problems. IP.Board 3 will help administrators control who can (and cannot) access their board. While all of the above features are still in place and can be accessed individually just as in IP.Board 2.x, there is now a centralized "Ban User" panel that an administrator can use when they are taking action against a specific user account. When viewing the user account, there is a button you can click labeled "Ban User" (if the user is already banned, the button will read "Unban User"). Upon clicking this button, an AJAX popup window will present you with many options. Firstly, IP.Board now supports a true "banned member" status, separate from their actual user group. This means you can ban a member without moving them into another group (for instance, if you do not want to upset the user's friends on your board). The ban management panel will also allow you to move the user to another group (e.g. the "Banned" group included by default with the IP.Board installation routine). You can also ban the user's email address and username right from the popup window. Additionally, every IP address that IP.Board can find that the user has used will be listed, and you will be able to ban each IP address just by checking the box next to each one. Lastly, there is a textarea box provided on the popup that will allow you to enter in a note (which saves to the typical user notes area) for future reference. As a convenience, links to suspend the member temporarily, remove the user's posting rights, and require moderator preview of the user's posts appear in the window, in case you determine you would rather take one of those actions instead. The unban panel provides exactly the same options, but in reverse, allowing you to move the user back to their normal member group, remove their email address, usernames and IP address from the ban filters, and to remove the banned flag on their account, reversing the changes you just made. Account management is important to administrators, and IP.Board 3 is taking steps to make such management that much simpler.

IP.Board 2 included a login manager utility in the admin control panel. Using this tool, you could tell IP.Board to authenticate login requests against third party databases, LDAP installations, or against IP.Converge, for example. You could even write up your own login methods and authenticate against any external data source of your choosing (i.e. the IP.Board 2.3 OpenID module). We used the login manager for conversions too - if you converted from another forum software, our login manager can understand the old password hashing schemes so that you do not need to reset all of your users' passwords (in most cases). IP.Board 3 takes the login manager even further. The login forms on the front end are all being consolidated into one template. This will make it easier to ensure that every time a login form is displayed, the same login form is displayed. You won't have to add options to multiple templates, as you did in IP.Board 2, if you want to customize the login form in any way. The login form has also been made "smart". Because you could potentially have a login method that requires a username and a login method that requires an email address, we decided to dumb down the form a little bit. You will be asked for your "sign in name" now (just one field) and IP.Board will figure out if you submitted an email address or a username. We've removed the option of "passthrough" or "onfail" from the login manager. It is no longer needed, as you can now chain login methods together. For instance, you may want to try to authenticate a user against the local database first (if the account exists), but if that fails, load the member from a remote database. Or you may want to allow a user to login using one of a number of data sources you maintain. This functionality is now possible. The login methods in the admin control panel are reordered using drag-n-drop to make it easy to control which order they are checked in. Some login methods need extra information from you. For instance, if you use LDAP, IP.Board would need to know the LDAP server host name, your username and password to login to LDAP to check the user, and so on. In IP.Board 2, this information is entered into a configuration PHP file. IP.Board 3 presents this information in the admin control panel to make it easier for you to check and update whenever you may need to. In IP.Board 2 when a member is added to the local database after authenticating through a remote data source, the member would be required to fill in a display name, and potentially their email address, even if that information already existed in the remote source. In IP.Board 3, there is much more control over this at the login method level - you can pull ANY data you want from a remote source and use it in IP.Board. At the very least, this means if there is an email address and a username available in your remote data source, the user most likely will not be required to visit an intermediary screen before being allowed access to your forums. The name and email will be stored automatically, making for a very seamless login experience. IP.Converge has received a slight update too - if you have IP.Converge enabled on your board, your users (who have already logged into the forum and configured their account) will now be able to use their username to login (if you enable username logins in the ACP). Behind the scenes IP.Board will find their email address and authenticate through IP.Converge using their email address, but your users won't have to know that. Additionally, OpenID has being added to IP.Board 3 as a supported login method. If you are not familiar with OpenID, it is basically an emerging protocol allowing you to control your own login authentication. You submit a url to sites that support OpenID (such as Yahoo, Wordpress, Flickr, and AOL) and then you are taken to that URL to verify the request really is from you. You may be required to login to your OpenID provider to confirm what information you are allowing to be sent back to the requester (in this case, your forums). After you confirm this information, you will be automatically logged into your forum. Additionally, as long as the user allows their name and email address to be sent back to the forums, their account will be fully created and functional. IP.Board will support OpenID 1 and OpenID 2 with the Simple Registration, Attribute Exchange, and PAPE extension modules (meaning email, username, date of birth and gender will all be supported and remembered by IP.Board, and that you can supply a policy url to the OpenID provider). Please note that we will be using the PHP OpenID libraries from JanRain for the OpenID backend support. If you don't need any of this functionality, it won't impact you at all! For those of you who have been requesting it, however, IP.Board 3 should cover all your bases.