Matt

It's an unfortunate fact that when you run a successful site, you attract unwanted users posting spam on your site. IP.Board has always been incredibly pro-active in preventing spam users from signing up by making use of built in tools such as the question and answer challenge, spam monitoring service and CAPTCHA systems. I'd like to take a moment to talk about some enhancements we've made in IP.Board 3.4.0 to help prevent unwanted posts and spam. Spam Monitoring Improvements We've further enhanced the spam monitoring service in IP.Board 3.4.0 by adding a new option: "Do not permit the user to register an account". This reduces the amount of clean up you need to do after a new wave of attempted spam user sign-ups. Furthermore, the "flag a member as a spammer" tool optionally deletes posted content rather than simply hiding them further reducing the amount of work needed to maintain your community. We have also totally reworked our spammer-detection logic behind the scenes to make the spam monitoring service detect spammers more quickly. In addition to internal changes, we are also looking at direct integration with services like Project Honey Pot and others. The great thing about the spam monitoring service is that we can make improvements on our side that are instantly beneficial to your community. keyCAPTCHA Integration IP.Board has made good use of the popular reCAPTCHA service to limit the number of "bots" that sign up to your forum with the intent of posting spam. The idea being that a slightly jumbled selection of letters is easy enough for a human to read but more difficult for a computer program. However, some do find that the CAPTCHA images are becoming increasingly complex to keep up with more intelligently written programs to defeat them. KeyCAPTCHA takes a novel approach to this problem by using images instead of letters and numbers. You simply arrange a few large pieces of a very simple puzzle to complete an image. You don't need to be completely accurate when building the image, either. This is now an option in the IP.Board Admin CP. Should you wish to enable it, you'll need to register an account with keyCAPTCHA. The link for this is contained in the setting form and is very straight forward. As always, we look for new ways to help make running your community a little easier and we look forward to helping you keep those spammers at bay!

The Admin Control Panel (ACP) is a very comprehensive section of your IP.Board. The ACP is used for everything from managing members, creating forums to dealing with support tickets from within our IP.Nexus application. Indeed, the ACP has grown so large that it can be a little bewildering remembering where pages are and you may find that there are areas of the ACP you rarely use and would like to tuck out of the way. Happily, we've made significant improvements in these areas for IP.Board 3.4. Bookmarks You probably use a handful of ACP pages numerous times a day and navigating to those pages may be a little cumbersome or you may find a really useful settings page but struggle a few days later to remember where it was. The brand new bookmarks feature solves these problems. The new bookmark system is available by the bookmark icon to the left of the tab bar. Clicking this will allow you to add a new bookmark for the page you're on while hovering over the icon opens the menu. You can make the current bookmark your 'home' page. This means that after you log in, it'll take you to this page directly instead of showing the dashboard. You can also drag and drop items to move them if you prefer more useful links at the top of the list. Tab Preferences Another common feature request has been the ability to re-order the tabs within the Admin CP. This functionality is now available. You may wish to give greater priority to a specific application or just clean up your tab bar by removing some of the pre-set tabs such as "Look & Feel". Clicking the "Edit Tabs" link at the far right of the tab bar opens the preferences page. You simply drag and drop the tabs from the Main Tab Bar onto the 'Other Apps' menu or vice-versa. Here you can see that I've moved everything except the Nexus tab to the 'Other Apps' menu. This is ideal if you spend most of your time within IP.Nexus and want quick access to it. We hope you enjoy these additional features to the Admin CP and we really believe they'll speed up your day to day tasks!

We're always amazed at how diverse our customer base is and how many different uses customers find for their IP.Board. Many customers, ourselves included often have a forum that invites questions such as pre-sales or support forums. These forums often generate a lot of topics with many replies and it can often be confusing for other readers to know which reply definitively answered the original question. The Best Answer Feature IP.Board comes with a brand new 'best answer' feature. This enables the topic starter (when allowed), moderators (where allowed) and super moderators/admins to mark a post as the best answer. This screen shot shows a typical question topic and the best answer has been flagged. You'll also notice that at the top, a small excerpt of the post is shown with a button to go and read the full post. This is useful for when the best answer may be on a different page to the one you're viewing. Looking at the forum view, you'll see that the answered topic has a badge that when clicked takes you to the flagged post. You can also quickly filter the forum list to remove answered or unanswered topics. This will be handy for forums that have staff answering questions! As you'd expect, this can be enabled on a per-forum basis and you can choose whether the topic starter can flag a topic or not on a per-forum basis. There is also a moderator toggle to empower moderators to flag a topic as the best answer. This enables you to retain as much control over this feature as you need. We hope you enjoy this feature new to IP.Board 3.4. We know that it's been requested many times and we're very pleased at being able to include it!

As part of our regular SEO round-up when developing a major new release, I'm happy to run through the latest SEO changes we've made for IP.Board 3.4. Friendly URL Changes After much research and discussion with other SEO focused forum owners, I decided to revamp the FURL structure when handling additional page parameters. The existing format uses the following structure: board.com/topic/123-title/page__foo__bar This is then parsed as foo=bar when converted to a normal query string. The problem with this is that it confuses search engines because it looks like another page rather than just a variant of a single page. We have a canonical tag which helps to reduce confusion but it's still not perfect from an SEO perspective. With that in mind, the new format is: board.com/topic/123-title/?foo=bar Now humans and search engines can quickly see that these are additional parameters of a single page. The canonical tag now backs this up and there is absolutely no confusion! New page parameters Another item that often came up when discussing URL structures and best practises was the current pagination method which is: board.com/topic/123-title/page__st__30 This is then parsed as st=30 when converted to a normal query string. This tells IP.Board to start from the 30th post in that topic, which is page two if we have 30 posts per page. This was less than optimal because some search engines had trouble understanding this was an additional page of the same topic. I've made this more explicit by making use of a special page parameter: board.com/topic/123-title/page-2 board.com/topic/123-title/page-2?foo=bar The eagle eyed will notice that there no additional slash after page-2. This means that search engines (and humans!) will identify the root page, a page with parameters and a page of a topic: board.com/topic/123-title/ board.com/topic/123-title/?foo=bar board.com/topic/123-title/page-2 board.com/topic/123-title/page-2?foo=bar In this case 'board.com/topic/123-title/' is the root page. Of course, IP.Board will happily 301 redirect visitors using the old st=x method or the old page__x method. Unread Topics In IP.Board 3.3, there was a special 'unread' folder added to topic links on the board index. This was often confusing as it seemed like yet another page from the root topic. In 3.4 we're using: board.com/topic/123-title/?view=getnewpost This explicitly states that it is simply another way of viewing that single topic. Statuses In IP.Board 3.3, each status update from a member was given a new page, like so: board.com/statuses/id/12345 During Google's Panda update, websites with 'thin' content could be penalised. It could be determined that these status update pages are very thin and a moderately busy board could generated thousands of them. In IP.Board 3.4, we use the new FURL format: board.com/status/user/1-matt/?status_id=12345 As you'd expect: board.com/status/user/1-matt/ This URL shows all of the user's status updates. Multiple SEO Titles I've improved the SEO URL builder to allow for multiple 'seoTitles'. Right now, IP.Board 3.3 is limited to just one, so you can only create FURLs like so: board.com/topic/123-#{title}/ Multiple titles will allow you to create complex titles like so: board.com/#{title-1}/123-#{title-2}/ In addition to the bundled inclusion of the old IP.SEO, this wraps up most of the big SEO changes coming in 3.4. I'm confident that the new pagination and new FURL structures will clarify your site's structure to search engines making it easier to spider and associate content without being penalised for thin content. Of course we're always open to well-constructed feedback on SEO improvements. Everything you see in this blog entry was implemented from feedback. Please start a topic in our feedback forums if you have SEO suggestions not directly related to the content of this blog entry.

With a product history of over ten years, it's quite often a challenge keeping the product right on trend. Old technologies go and we make provisions to remove them and likewise, we make provisions to incorporate new technologies. For example, IP.Board was the first bulletin board to incorporate Ajax functionality all the way back in IP.Board 2.1 back in 2005. We were also one of the first boards to add in 'WYSIWYG' editing to make constructing styled posts much easier. Of course, this was long before jQuery and Prototype frameworks make writing javascript easier so we hand-rolled our own editor. This was eventually replaced in February 2011 with the arrival of IP.Board 3.2 in which we used CKEditor. However, the underpinnings of the editor remained unchanged which lead to some challenges. For example, the actual post was saved as BBCode in the database. This meant that the post had to be converted into BBCode before saving and then converted back into HTML before editing or showing the post. This lead to some frustrating due to inconsistencies with this process. Happily, the underpinnings to our editor have now been completely rewritten to increase stability and to remove these inconsistencies. Now, the post is actually saved as cleaned HTML (via the excellent HTMLPurify) which means it does not have to be converted between states. You can still edit the BBCode manually if you wish, but this is handled by a single BBCode plug-in for CKEditor. This is very exciting because it frees up IP.Board from having to deal with BBCode manually saving hundreds of lines of code. Of course, your custom BBCode will work normally and because of built-in legacy functionality you won't need to convert your posts to the new format as this is handled 'on-the-fly'. We've also taken the time to improve several other elements within the editor: Code Boxes The code box has been improved to allow you to select the code format (HTML, Javascript, PHP, etc) and a starting line number. Tabs and spaces are also preserved correctly. Live Previews When adding quote and code boxes, the editor will preview them live, like so: The code box when rendered fully contains striping and line numbers which makes it easier to read the code: We're confident that by rewriting the editor and parsing engines, the editor in IP.Board 3.4 will be much more stable and reduce those annoyances which can sometimes crop up when writing complex posts.

We released IP.Board 3.3.0 as beta yesterday to our clients and I wanted to just round-up some of the very latest SEO changes we've made this week. We've invested a lot of effort into making sensible non-invasive changes to IP.Board to encourage search engines to spider pages we want them to spider and to remove extraneous links, potential crawler errors and non-desirable keywords. We routinely check progress on this forum in Google Analytics and Google Webmaster tools to identify any areas that need further work. I spotted a few things which I've fixed which include the following. Tags We added tags back in 3.2 and we've continued to make improvements including adding 'other items tagged' which is now an option when viewing a topic. However, guest and search engine access to tags was largely blocked and the URL to fetch a list of matching items wasn't very friendly. This has now been changed. The old format URL was 'index.php?app=core&module=search&do=search&search_app=forums&search_tag=tagName'. It's now a much snappier '/tags/forums/tagName/'. Search engine bots now have access to the tag results page within the search engine so they can spider the results of specific tags. This should increase good keyword density. Guests and 'unread' links The default setting in 3.3.0 is to disallow topic tracking for guests. This means this setting applies to search engines too. However, the 'last topic' link when viewing a list of forums still retained the '/unread/' parameter. This is fine as it sends a soft redirect header which Google correctly picks up. That said, it is an unnecessary hoop for Google to jump through and as topic marking is disabled, there is no benefit to this parameter. This has now been removed in 3.3.0. Title tags We've also gone through and removed some more unnecessary title attributes from links such as the 'Go to latest unread' which preceded almost every 'last topic' link when viewing a forum, search results and sub-forums. This further reduces undesirable keywords. Soft 404s On reviewing the crawler errors listed within Google Webmaster Tools, I noticed a lot of largely irrelevant pages were listed as being 'soft 404s'. Google declares a page a soft 404 if it sends a standard OK header (200) but it seems to contain no valuable data such as a generic 'No data to show' message within a table. This occurred with regularity with the 'Who Posted' feature as well as the 'Display Name History' button on user's profiles. I've now removed both links to Guests as arguably they serve little purpose to a non-member. Ratings I've added schema data to the IP.Board topic rating system so Google will detect and show the relevant rating with the search result. These are all fairly little changes but they'll further improve your forum's SEO which can only be a good thing! We're looking forward to seeing these new changes and features in action on your forums.

IP.Board has made use of micro formats and schema data since IP.Board 3.0. We added to this in 3.2 to include breadcrumb data in our navigation. This enabled Google to display our navigation links within search results. The schema data has been read from our page which enables the green navigation links and post/author data. We've further extended the schema data for 3.3 which is great news for SEO: Topics and posts At the head of each topic, we've added schema information to the title and author details. This will help search engines locate the title of the topic. We've also tagged up the posts to help search engines extract relevant information. As we can see, Google can read this schema data very easily and quickly locates the data we want it to focus on. Forum View We've added schema data to the forum view also. This will help search engines locate relevant data. The screen shot below shows the data Google extracted from the forum view page. As you can see, there is a row for each topic in the forum. Events We've added schema data to calendar events and even the sidebar 'Forthcoming Calendar Events' block so they display correctly when your site is searched. Here's the result of Google's rich snippets tool preview. Note the 'Meeting!' event underneath. These unobtrusive changes should greatly assist search engines in locating relevant content which is good news for everyone!

IP.Board was one of the first commercial products to make use of Facebook integration to allow logged in Facebook users instant membership. We extended this in subsequent releases to include the ability to share status updates and links from the board such as topics. During this time, we also added Twitter as an authentication system and the ability to tweet out links and status updates. You don't have to be an active Facebook or Twitter user yourself to appreciate the advantages of tapping into the millions of users these sites receive daily. It's a great way of driving more traffic to your site and to encourage activity. Auto Sharing In the current version of IP.Board, you can quickly share and 'like' content such as topics, gallery images and blog entries when you read them. In IP.Board 3.3.0, we've taken this a step further and added the ability to auto-share content during creation. You simply check the boxes for the services you want to share with and it'll share the content as soon as its been saved. You can even make the current preferences default so you don't have to remember to check them each time. Of course, these buttons don't show if you've disabled sharing for that forum and you can optionally disable the entire feature from the Admin CP. Authentication Flow In the current version of IP.Board, you have to be connected to Facebook before you can share status updates and links. This means you'd have either registered with a Facebook account of you'd have linked them via your UserCP. Not everyone will be aware of this functionality so there's a chance that some of your members will never make use of those features. In IP.Board 3.3, we've utilised the Facebook Javascript SDK into our own code so you can connect to your Facebook account without leaving the page. The Facebook auto-share button is visible even if you're not currently connected (assuming of course that the feature is enabled and you've set up Facebook via the Admin CP). When you click the checkbox, if you're not connected, the request for permission dialogue loads automatically. Once allowed, the connection is finished in the background and you're all set up ready to share without leaving the page. This drastically reduces the barrier for connecting your Facebook accounts with IP.Board and further encourages sharing. Changes to meta data When you share a link, Facebook checks the page for specific Open Graph meta tags. Once of these determines the image that is shown next to the link. By default this is the IP.Board logo. In IP.Board 3.3 when you attach images to a post, these are used as the shared image bringing context to the link. These changes will no doubt increase the number of topics shared with Facebook which in return will increase visitors to your forum for those that embrace social media as a way to drive traffic.

Our core goals for IP.Board 3.3 where to clear up the moderator tools, make IP.Board more efficient for larger communities and improve SEO. We've already blogged twice on our SEO improvements outlining tweaks to improve good keyword density, reduce crawl errors and improve good keyword placement. Our own company forums are very busy and get a lot of traffic and we monitor the data via Google's Webmaster Tools and Google Analytics. As we upgraded to IP.Board 3.3.0 last week, I was curious to see how the data looked even though it's too early to really spot any differences, a few things did become obvious. Duplicate TITLE tags I noticed that Google had recorded thousands of 'duplicate title tags'. This is where separate content shares the same <title> tag in the HTML document. This can weaken the impact of the page within its algorithms so it made sense to clean that up. There were three very common areas that accounted for nearly 99% of all these errors: Profile Tabs When viewing a user's profile in IP.Board, you can click the side-bar tabs to view recent topics, posts, gallery images and more. This is handled by javascript where available with a linked back-up. Google naturally selects the linked back-up which has the correct content, but the actual document title still says "Viewing Profile {name}" hence the duplicate title tags warning. The simple fix is to add the tab name in the title 'Viewing Profile: Topics {name}'. Skin Selector and Language Selector At the footer of each page is a skin and language drop down selector. When you have more than one visible skin, the drop down is visible allowing you to move between them. This is completely lost on search engines and they crawl the links leading to more duplicate content. As of IP.Board 3.3.0, they are no longer shown for search engines. Direct post links Each post in a topic has its own post number and this is a link to that particular post. Currently, this is a unique link (page__findpost__12345) which flags up as a warning because it is not unique content. The easy solution is to simply use a standard HTML anchor tag. This doesn't flag up as a warning as it is using basic HTML as intended. As an addition, I removed the generic "Link to post" title attribute to something more suitable. An interesting topic was started a few days ago about a possible SEO pagination issue. The author feels that our pagination method could do with a few more links in to encourage Google to crawl deeper into your forum. While I feel the user/search engine trade off wasn't worth it, I make it simple enough to change. As of IP.Board 3.3, simply add: $INFO['show_x_page_link'] = 9; into your conf_global.php file to tailor how many pagination links are shown so you can find the best balance for your needs. These changes will help reduce crawl errors and strengthen your ranking. It's the little additions like these that really add up over time.

During each release cycle we often take some time out to assess performance and look at ways to improve in this area. We're also in a unique position to have first hand experience at hosting tens of thousands of IP.Board installations via our own hosting network. We also work closely with our clients who constantly give us feedback on how IP.Board is performing and let us know about any areas that need further examination. All of this data is very useful when it comes to profiling and testing IP.Board and making performance improvements for the next major version. In this this blog entry, I'd like to discuss some of the improvements we've made for IP.Board 3.3. Topic Markers IP.Board has had a centralised database drive topic marking system since 3.0. As IP.Board is only part of the suite, we wrote the system to be extensible and flexible so that our own apps and apps written by others can use the system without maintaining their own tracking databases. We wrote the system to use two tables. One of which can be considered a 'deep storage' table. This contains permanent tracking data in the format of one row per member per parent. So this means that if you had 200 forums, each member would take up 200 rows. The second table can be considered the 'active' table. When a member is loaded from the database and no 'active' row is found, the markers are pulled from deep storage and written in a serialised form to the 'active' table. When the member is no longer active, the data is removed from the 'active' table and written back to the 'deep storage' table ready for the next time they visit. In theory, this is the perfect solution. You only have to read and write to a smaller table which should make the system more efficient. However, we discovered that trying to keep the tables synchronised when you have a very busy site negated the benefit. The sheer number of SQL inserts and deletes often caused bottlenecks affecting the whole board. Another downside was that all the marking data had to be loaded when the member was loaded. This could be up to 200k of marking data - most of which wouldn't be needed. If the member was viewing a topic, they wouldn't need marking data for Blog, for example. We've tweaked the system to remove this SQL bottleneck. We've removed the 'active' table and simply write to the main tracker table. Now we don't have tables to synchronise, we can simply write back to the 1 row that needs updating and not have to periodically update all 200 rows. Furthermore, we've removed the need to load all markers at once. A new function in 'coreExtensions.php' dictates which markers to load. You can still load all as this may be more efficient (as is in the case of the board index when you have a lot of sidebar hooks) If you choose not to load the marker data on member initiation, you can use the new built in JOIN methods to fetch the marking data along with your dataset. In testing, this has dramatically reduced write overhead and the memory footprint required per page view by up to 150k. We're testing this out right now on our company forums and many people have already commented that 3.3 is seriously faster. Post Table Access The largest table in your database is almost certainly the post table. We have clients with millions of rows in this one table alone. It makes good sense to keep reads to a minimum where possible. In older versions of IP.Board, we had different views such as 'threaded'. These were removed in 3.2 as these older legacy views were rarely used and not really applicable in a modern context. However, some of the older code remained which meant that the post table was being queried twice per topic view. Once to fetch a list of post IDs and again to fetch the data. We've rewritten this bit of code to use a new API and now we only query the table once. This alone will drop read access to your post table by almost 50% in normal daily use. This is a significant change. Today's Top Posters This fairly innocuous feature is accessible via a link in the board footer and on most boards doesn't get a deal of traffic. However, we've found that clients with larger boards notice a significant slow down when this feature is used which can cause another SQL bottleneck. This is because the query is fairly complex due to the flexible permission IP.Board offers. The query causes the creation of a temporary table to sort the data which isn't desirable for larger boards. We've added a new caching table which caches recent post IDs. This makes this feature much quicker (over a second in SQL terms in testing) and as an added plus, it doesn't have to query the post table to generate the list which again saves read access on that large table. Conclusion There are many other, smaller changes in additions to those listed here. Some of these changes may seem trivial but they quickly stack up. It only takes one or two slow queries to bring a site to a crawl while SQL catches up with queued queries. These changes will make a significant different to everyone but especially those working with large databases. Your IP.Board will be faster, consume less memory and be more SQL efficient. Those are changes we can all appreciate!

Anyone that runs a lively and thriving community knows that now and again you have to make the hard decision to ban a member. IP.Board has a powerful set of tools built in to manage this for you and you can ban a member for a set number of days or permanently with a few clicks via the warning system or the ACP member management system. Currently, there are two ways to ban a member. One is to flag them as banned and the other is to move them into the pre-defined banned group. They both act very similarly and there's a lot of overlap which leads to some confusion as to what the differences are. Flagging a member as banned will prevent them from viewing the board and contributing to the community. Moving a member to the banned group does the same but at a group level and also removes the member from the member list. This isn't immediately apparent and we do find some administrators get confused. "Do we have to flag as banned and move to the banned group?". We've simplified this in 3.3 by removing the pre-set banned group for new installations. Now when you flag a member as banned, they are removed from the member list and any friends lists they may be on. Additionally, only super moderators and admins can then view their profile. I've also ensured that spammers are treated in the same way. When you flag a member as a spammer, they are removed from the member list and any friends lists they may be on. It's worth noting that existing installations do not get their banned group removed, but any members in the banned group are automatically flagged as banned. You can, if you choose, remove the banned group yourself. I've taken this a step further to consider the impact on SEO when you flag a member as a spammer or ban a member. You don't really want your members and search engines following profile links that lead to an error, so I've removed the hyperlink for banned members and spammers for anyone that is not a super moderator or admin. This means fewer crawler errors and more importantly less keyword pollution. We all know that most spammers choose keyword rich user names that you don't want associated with your community! The new warning tools have been updated to allow you to move banned members into a group of your own choosing if you'd like to keep group-level organisation. I'd like to wrap up this entry with a quick mention on some other SEO tweaks. I read a great little entry by Enkidu yesterday on his blog. He suggested some quick tweaks to remove unimportant keywords like 'category' and 'forum'. I've gone ahead and implemented his suggestions. This will help reduce keyword noise and increase keyword density for keywords you want to focus on. The screenshot below shows the changes in action. Note how many times the category name is now repeated: These changes and updates further our goals to increase SEO, improve moderator tools and clean up interface elements in IP.Board 3.3.0!

Over the past few years, we've invested a good amount of time into ensuring that your forum content is spidered well by various search engines. We've created a crisp clean skin with good semantic mark-up, introduced a friendly URL system and made numerous enhancements to ensure that search engines read your content and spider it effectively. Search engine optimisation is an organic process and it is always evolving. I feel that even though IP.Board 3.2 maintains good practise, more can be done to better tailor content. Of course, we'll always steer well clear from the murky waters of HTML cloaking and other dubious techniques but with the help of a small focus group, we have identified areas that can be improved and I'd like to take you through those today. Problem: Dead End Links One thing that was identified very early on was the number of 'dead ends' that IP.Board gives to search engines. Let me elaborate a little. Lets say that you don't allow profile viewing for guests. Search engines are shown the same content as guests so this is very relevant. Now, imagine you're a search engine and you now see the board index. It's content rich with hundreds of links of which a good proportion are for user profiles. Google happily follows these links to end up on an error page served with a "permission denied" error. This clearly does not have a good affect to how Google treats your forum. What's worse is that the default error code is 500 which is designed for a generic "Internal Server Error"; now Google is getting a high number of permission denied errors and some internal server errors. The solution Now, if you don't have permission to view a profile, then the username is not hyperlinked and neither is the photo thumb on the board and forum indexes. This dramatically cuts down on the number of dead end links and even reduces bandwidth for large busy forums. We have also changed the default error code to 401 which is less severe than ISE 500 and we've ensured that we use 403 and 404 appropriately. We've also added a per-group setting to disable the display of online lists reducing further bandwidth through mark-up and reducing 'noise' in your content. We snuck in another per-group setting to remove completely the "last post" information for those that want a really focused clean look with only keyword rich text on display for guests and search engines. Problem: Scary Error Pages We admit it. Our existing error pages are a bit scary. The red/pink background below the screaming proclamation that "AN ERROR OCCURRED" not only intimidates people but can also confuse search engines who are relatively blindly sucking up words to attribute to your site. The solution Our error pages have had a complete makeover to reduce the technical jargon and make the messages friendlier. Even better, the title is header code context sensitive so if it's a 404, then the title reflects that to reduce confusion. Problem: Poor use of 'bread and butter' mark-up. IP.Board has had meta description tags for a long time now but they've not been especially optimised. Likewise the <title> tag that is possibly the most coveted piece of mark-up for search engines. The meta description just contained 155 characters of the first post with no real context. Worse still, at no point was the forum name and topic title written in the same tag. For example, if you had a forum called "Halo 3" and someone started a topic called "Cheats!", IP.Board would not often return "Halo 3 Cheats" unless it was explicitly written in the post. The solution Meta descriptions now contain a proper brief description that contains both the topic title, the forum name and some of the post. The <title> tag now also takes the format of NAME - FORUM - BOARD NAME. Putting together important keywords in richly spidered areas. We've noticed that a lot of forums rank highly for benign keywords such as "photo", "topic", etc. We've made several improvements to reduce the frequency of these keywords. For example, the little photo thumb on the board index used to have an alt tag of "Photo" - so no surprise that "photo" was spidered a lot! This has now been changed to something better suited contextually: TOPIC TITLE - last post by NAME. Problem: Poor Bounce Rates Very briefly, the bounce rate for your site is the percentage of visitors who 'bounce' right out of your site. This could be because they found a link to your site via a Google search but the actual page itself doesn't have relevant information for the visitor so they back right out. The solution We've already reduced content to code noise and we've reduced nonsensical keywords such as 'photo' and we've increased visibility of vital keywords so already Google should do a better job of attributing keywords to your pages which will help in 'false' matches via a Google search. We've also taken this a step further by being a little more polite: The slightly huffy "You cannot reply" buttons have been replaced with "Please log in to reply". Better still, we've introduced a killer new feature "Also tagged with". This pairs up perfectly with IP.Board 3.2's new tagging system to show a list of topics that share tags from the current topic. The matches are forum wide, so it doesn't just return matched topics from the forum you're in. Consider the possibilities for this feature! If you tag a lot of topics up, they'll now show cross referenced below the topic. This should further entice visitors into your site if the topic they found via Google doesn't have the information they need. Better still, it adds more rich keywords onto the page which further strengthens the existing keywords. Let's recap The takeaway message from this blog is that we're committed to improving search engine optimisation within IP.Board. It's a constantly evolving process and we'll continue to monitor and improve. We feel these changes will drastically improve how search engines view your site and also benefit those with large and busy sites by removing excess mark-up. Of course there is always more to do so use our feedback forum as appropriate if you have specific suggestions. We're very excited about these changes and we hope you are too!

One of the many pleasures of running your own forum is watching it grow as the years roll by. Sometimes it's fun to go back and look at old topics but they just get pushed further and further away from the first page until you end up with a large database full of posts that rarely get seen. Perhaps you run a massive forum with 10 million posts or more and you're starting to reach MySQL database limits and considering pruning back posts from 10 years ago just to free up some space. Maybe you just want to keep your number of active posts as low as possible for ultimate efficiency. IP.Board 3.3 has a new an innovative way of handing these problems! Introducing the archive system Brand new to IP.Board 3.3 is the archive system. This is a very easy to use system of archiving off old posts. You get complete control over what is archived too but more on that a little later. The archived posts are moved to a different table but it doesn't have to be in your current database or indeed your current server (though of course it can be too)! You can set up a new server just for older posts and move them all there thus freeing up your forum post table again. This means less overhead for MySQL to manage when people are browsing your community. Searches are faster, look-ups are faster and everything zips along. Archived topics still show in the forum view as normal. You can still view them as normal. They still get all the skinning as normal so everything works just like a regular topic. Their URLs do not change so SEO is not impacted. However, as they are archived, you cannot reply or follow the topic, so all that is removed from the display which actually saves your server a lot of work! It doesn't have to load up the editor javascript or load up any follow data from the database. In testing, it actually saves 30% database access showing an archived topic. The topic title isn't changed and the URL isn't changed so there's no need for complex 301 code redirects for search engines. If you change your mind or archive a topic without meaning to, you can unarchive a topic. The Admin CP Interface The Admin interface consists of just two screens. The overview deals with a snap-shot of stats and data and the manage rule screen is where you set up which topics to archive off. Let's start with the overview screen. Here you can see how many topics have been archived already via the big progress bar at the top. Underneath is the number of topics to unarchive. In this screen shot, I've decided to unarchive all topics that have had a post within the last 600 days. Here's where you can set the unarchive preferences: Now let's take a look at the rules screen. It's simple enough. There are two tabs "Archive Where" and "Don't Archive Where". This allows you to either set up an inclusive or exclusive list of rules. The green strip at the top shows you how many topics the current settings will archive. This is automatically updated each time you change a setting so you get an on-the-fly update of how many topics to archive when configuring this form. A quick look at the forum filter: And the topic starter filter: The public interface So how do you know when a topic is archived? Simple! When viewing the topic as an administrator, you get the option to selectively unarchive a topic - and this will exclude it from being archived again. A regular member or guest will just see: Summary We really feel that this feature will benefit everyone. You can effectively lock older topics to prevent confusing 'bumps' or replies after a few years Free up your forum post table so it runs speedy again by giving MySQL less old data to have to work with all the time Use a remote server to house the archives so it can freely grow over the years Get a 30% reduction in SQL usage when viewing archived topics which is great news if you get a lot of good search engine placement. Quick and easy to configure Archives are done via a task that runs at regular intervals. It does a small number of posts each execution to prevent timeouts. It doesn't confuse search engines as the title and URL don't change (and even the H1 tag doesn't change). We hope you enjoy using the new archive system!

IP.Board 3.2 was a major new version boasting a new sleek skin with a major overhaul to the user interface. We also added in long requested features such as tagging, the shared media panel, and a brand new moderators control panel along with many more improvements. We have been thrilled with the overwhelmingly good feedback since 3.2's release and we are ready to take IP.Board to the next step by targeting specific needs with laser-like precision. The next version of IP.Board will be 3.3.0. But what is in a number really? Do not worry, we are revising our version numbering so that a major increment reflects any added functionality. The development cycle between 3.1 and 3.2 was lengthy because of the massive changes we made. This cycle will be much quicker. We want you to think of IP.Board 3.3 as improving and refining what we already do - not as a huge update that will require extensive changes. In fact, unlike the 3.2 update, the 3.3 update will not have a new default skin or sweeping code-base changes that impact existing hooks/apps. So lets look at the areas we are targeting. Search Engine Optimization We have had lots of feedback about this area of the software. We have made huge strides in the past by ensuring the correct headers are sent and the HTML is as clean as possible. We even have our free-to-customers product IP.SEO. We are taking this a step further in IP.Board 3.3. We set up a small focus group earlier this year and asked them directly where we can improve and we received some great responses which we will work on. Moderation Key to running your community efficiently is good moderation tools. IP.Board has tons of functionality but sometimes there is a little overlap or areas that are not crystal clear. We will be working on some of the moderation tools to improve that and we are also introducing a major overhaul to a popular moderation feature! Admin CP Our admin control panel is incredibly comprehensive but we are looking to make it a little smoother and easier to use in common areas. We have some specific ideas on how to speed up common tasks which we will implement in 3.3. Large Boards Many of our customers have grown with us and taken their small community into new territory with millions of posts. Other customers have converted to us from a large established community. Either way, there are some specific needs that larger community owners have that we are working on for 3.3. We have an innovative cool new feature currently being written that we know large community admins will love! Refinement As always we continue to refine existing areas of the software. Our development staff continually works through our bug tracker and support tickets to fix reported bugs. Beyond bugs we often make little changes that make a big difference. Simply rewording the text of a button or moving a link to a more logical location can make things work more smoothly. All those little changes add up to the overall polish of the software. We are happy to say that IP.Board 3.3 will not mean a complete new skin and neither should your custom skin need reworking from scratch. Existing modifications and hooks should operate just fine too. Everyone at IPS is very excited about this release and cannot wait to start blogging about the new features and improvements we have implemented. We are shooting for an late first/early second quarter 2012 release date (a release date from IPS!). Keep an eye on our blog for more news soon!

IP.Gallery is our popular photo and movie sharing platform for IP.Board. We've been working on updates and I wanted to take you through several today. You've already read about the bigger features for IP.Gallery 4.2.0 such as tagging, quick navigation, moderators' control panel, album selector and the Admin CP updates. This entry covers a few of the smaller updates - most of which have been requested via our feedback forums. Image View Updates We've made a few cosmetic changes to the view image page to bring it inline with IP.Board 3.2's look and feel. The image title /follow image button is now in the same format as a topic title for consistency. Image Only Global Album We've now made it possible to have a global album that only accepts images and not albums. Sort by title You can now sort an album by image title. This can be set when adding or editing an album as well as being available dynamically. Like and Reputation We've added in the like / reputation button. The screen shot shows the system in the 'like' mode. If you chose reputation mode, it would display the plus and minus buttons as normal. Member's Album We've added in an enforced global album named 'Member's Album'. This is the default parent for any new member albums. This helps to separate the global albums a little and allows you to better set permissions. If you only want your members to create albums in your existing global albums, then you can deny permission via the edit album feature. This wraps up our series of IP.Gallery updates. I hope you've enjoyed them!

IP.Gallery is our popular photo and movie sharing platform for IP.Board. We've been working on updates and I wanted to take you through one today. The IP.Gallery 4 Admin CP Album Manager streamlined down the various Admin CP functionality for managing albums but it was hard to locate specific albums and to drill down through the global album structure. I've completely rewritten the Album Manager and put the focus on finding the albums you need as quickly as possible. I've broken the Album Manager down into two tabs: Global Albums and Member Albums. Each has a context sensitive search bar so you can quickly search through your albums. The global albums display. It now shows sub-albums under the parent album and also shows if the global album has any member albums attached to it. As you'd expect, clicking "Contains X member albums" takes you to the member tab with those albums displayed. The member albums display. Clicking on the owner name will bring up all their albums. It also shows the full parent tree so you don't end up confused if two albums have a similar name but in different areas. You can quickly search for a member's albums via the member tab. The album selector we wrote about previously is also in the Admin CP and works in the exact same way when you need to select an album. I hope you've enjoyed this blog entry. I'm sure you'll all love this feature and it'll make your album management much more enjoyable!

IP.Gallery is our popular photo and movie sharing platform for IP.Board. Today, I wanted to take you through an important part of the IP.Gallery 4.2 update; the album selector. At various places within IP.Gallery, there is a need to select an album. This may be because you're creating a new album; choosing an album to upload into; moving images or moving albums. In the current version, this is achieved with a simple drop down list to allow an album selection. This isn't ideal because it's unclear which albums are yours and which are global albums and when you have a lot of albums, it produces a very long and confusing list of album names. IP.Gallery 4.2 introduces a dynamic album selector that is used everywhere you need to select an album. It offers a much better view of available albums: The selector separates out global albums from member albums. You can also search for albums which is great if you're performing moderation tasks. You can quickly select from recently selected albums easily. It is context sensitive and displays only albums available for the task you're performing. I've recorded a short video so you can see this in action. I hope you've enjoyed this update. It'll certainly make your day to day Gallery tasks much easier! It's also available from the Admin CP too.

IP.Gallery is our popular photo and movie sharing platform for IP.Board. We've been working on updates and I wanted to take you through a few of them today. IP.Board 3.2 introduced many new core features such as tagging and a Moderators' Control Panel. These features were written to allow other applications to take advantage of them easily to unify the various apps. We've introduced these new features into Gallery 4.2. Tagging Tagging allows you to 'tag' an image with data. You can then search these tags to return all matches. This allows you to add secondary categorical data to your images and movies. You can allow your members to add new tags freely or limit them to presets you set up. You can override the presets on a per album basis. You can add tags when adding or editing images. The tags appear under the image name when viewing an image. You can search a tag and find all matching images. Quick Navigation IP.Gallery now supports the quick navigation panel which is launched when you click the icon just below the search box. It contains a list of all Global albums and also a list of your own albums so you can go to an album quickly. Moderators' Control Panel IP.Board added a central control panel for moderators. This makes finding and approving unapproved content much easier than navigating through the forums and apps to locate them. Both comments and images are supported. These additions tie IP.Gallery into the IP.Board framework for a cohesive integrated feel across the products. I hope you've enjoyed this update, we've got more to follow!

Since the release of IP.Board 3.2 a few months ago, our immediate focus has been on fixing the bugs that have been reported and making fairly frequent releases to our customers. We're thrilled that IP.Board 3.2 has been a huge success and we've received a lot of feedback which we've enjoyed reading. Now that the initial wave of bug fixes have been made, we've found the time to add in some functionality based on feedback from our customers. Here are some of the IP.Board enhancements that have gone in for 3.2.3. HTML Emails This has been a very popular request for a long time now and we've included this into 3.2.3. By default it is off, but you can enable it from the Email settings page in the admin control panel. This will also resolve issues with non Latin characters, right to left languages and more. The HTML email wrapper is fully editable via the Look & Feel templates as normal and it automagically converts the current plain text templates into HTML so you don't need to change anything! Import a URL Photo We've had a fair number of requests for a simpler way to import a photo so we've included the ability to import a photo from a URL when in the photo editor. This copies the image to the forums server so it can be checked (to make sure it's actually an image!) and to create the thumbnail copy. Editor Improvements IP.Board 3.2.0 introduced a brand new editor and it really is one of the most complex areas of the software (no, really!). We've put a lot of focus into squashing those annoying BBCode bugs. We've also gone ahead and added the auto-save and 'toggle mode' functionality for editors in the admin control panel. Of course, there are also numerous other bug fixes and improvements including more efficient Sphinx index building, iPad compatibility and more!

Since the very first release of IP.Board, those with a working knowledge of HTML and CSS have been able to alter the look and feel of the board to better match their site. Over the years, we've made many improvements to the skinning system. For 3.2 alone we've added remote skin editing and more modular CSS to make editing much quicker. Last year, we introduced the skin generator for customers with an active license. This has been a very popular service and quickly allows customers to produce a new skin that better matches their site colors. However, we felt that we could do better than this tool and do better than our competitors who allow you to 'blindly' change colors from the Admin CP without seeing the immediate effect it has on the board. Wouldn't it be so much easier to just change the colors while browsing the board? We thought so. Introducing the Visual Skin Editor This brand new innovative new feature allows you to edit the board's colors right from the board itself! You don't need to know CSS, you don't even need to remember hex codes and you don't have to blindly edit oddly named CSS classes from the Admin CP. Live Demonstration As this feature is best demonstrated, I've recorded a short video in which I make a brand new red themed skin in about five minutes using this new feature. The usual disclaimer applies: this is work in progress and contains some rough edges that will be smoothed out before release. As you can see from this video, it's a cinch to create a brand new skin in IP.Board 3.2! If you can point and click and use a basic paint editor on your computer then you're able to use this tool. We're thrilled to announce this feature and look forward to your feedback and questions.

IP.Board was one of the first boards to recognise the importance of attracting visitors via popular social networking websites such as Twitter and Facebook. We have matured this integration over the past few years and IP.Board 3.2.0 offers several new enhancements. Firstly, the pop-up dialogs have undergone a facelift to make them easier to use and easier to recognise which social networking account you are posting from. We've used the modal functionality to display these pop-ups to give some more room to display the data. The Facebook pop-up also has the 'Like' button included inside the box. Many customers were uncomfortable with strong Facebook branding appearing prominently on their site. Although in many ways the 'Like' functionality is similar to 'Share', there are some keen differences on how the 'Like' data is displayed in one's Facebook feed so we felt it pertinent to keep both methods. IP.Board was also ahead of the curve in providing a dedicated mobile theme for your users on smart phones. We recently blogged about this but we've gone ahead and added full Facebook and Twitter functionality to the mobile theme. You can now log in using Facebook or Twitter and share topics to Facebook and Twitter. Below are some screen shots of this new functionality in action.

Long before we threw the doors open to our IP.Board 3.2.0 preview board, we blogged about our new text editor. We reasoned that maintaining our own in-house post editor was becoming more time intensive due to the speed at which new versions of all the popular browsers are released. We chose CKEditor in the end because it's a very popular and capable editor that allows one to extend the core code. We had a lot of compliments on the new functionality of our editor but most were put off by its look. We agreed that the default skin is a little ugly and not really suitable for a professional application like IP.Board so we took an afternoon to skin it to fit in better. We're pleased with the end result. In a very short space of time, we were able to match it to the current editor which will give you and your members that familiar IP.Board feel. Not only were we able to easily match the current IP.Board editor look and feel, but we made it easily skinnable via the normal Admin CP interface so skinners won't have to settle for the default look in their skins. After all, if you have a dark or strongly colored skin, you're not going to want to settle for the mundane grey default CKEditor skin. Here's a few screen shots of our CKEditor implementation: It's also worth noting that the CKEditor is 'hidden' in the fast reply area so that it when you're ready to make your post, a simple click into the area expands the textarea into a fully operational editor without it grabbing focus on the initial load. We hope you've enjoyed this blog entry and we're thrilled to be able to make improvements based on your feedback so far. Keep an eye on this blog for some further entries about other tweaks and improvements!

One of our main goals for IP.Board 3.2.0 was to revamp certain areas of the interface to make it easier to interact with the board. We also wanted to put controls at your fingertips rather than make you root through pages of settings. This blog outlines some of these changes. User Control Panel In many ways the user control panel follows the old computing convention of a special area for configuration and settings. The idea being that you keep all configurable elements in a single location. This works well for the most part but there are many times when you have to go looking for a setting to control how the board works often meaning you have to leave the page you're on, change the setting and then return to what you were doing. We wanted to move specific controls to their contextual location. We've also merged a few areas together such as "Settings" and "Profile Information", "Email" and "Password". This reduces the number of links and allowed us to merge the "Profile" and "Settings" panes into one. We've revamped the User Control Panel and stripped down many of the settings and put them in their relevant areas. For example, we've already moved the View New Content settings into the View New Content interface. The attachment system now 'sniffs' out whether the user can use the better Flash based uploader and uses that if no other settings have been set. If the user decides to switch to the basic uploader, then this preference is stored and used on the next page load. You can now disable your personal messenger from within the personal messenger itself. You can elect to do this if you do not want to receive PMs from other members. Once it has been disabled, you can re-enable it by visiting the personal messenger again at any time. There was a single option to remove signatures from the topic view. We've enhanced this to allow you to remove a single user's signature if desired. When you mouseover a post, a little "X" appears in the signature. clicking this brings up a menu. Ignoring a user's signature will add them to the 'Ignore Preferences' page so you can remove them. Other Enhancements The current "Mark As Read" found in the board's footer marks all applications as read which may not be the desired result. In IP.Board 3.2, clicking this link brings up a menu so you can mark a single applications or all applications as read. We've removed the old style forum jump form drop down interface in favour of a much enhanced "Quick Navigation" link that is in the footer of every single page. This Navigation panel is extensible via the application's extensions folder so third parties can update their applications to take advantage of it. The tabs down the side are loaded by Ajax, so you can quickly tab between all your applications to locate the page you want. We've also gone ahead and updated all the areas where the mini profile card was activated with the green icon next to a user's name. Currently you have to click this icon to load the mini profile card. Now, simply hovering over a user's name will make the mini profile card appear. The main user drop down menu has also been enhanced. You can now update your status via the menu which means you can do this from any page on the board. We feel that these small enhancements make a huge difference in your workflow and in the general feeling of the board. Feel free to comment on this blog entry below or, if you have feedback unrelated to this blog entry, start a new topic in our feedback forum. If you have feedback related to changes beyond what this entry is referring to, please start a feedback topic. Be sure to check the What's New in IP.Board 3.2 topic for a running list of announced changes!

IP.Board's Admin CP comes with many useful and powerful tools to edit your board's skin. You can edit virtually all of the HTML as well as the CSS from within the "Look & Feel" interface. This suits most people but sometimes you just want to use your own desktop editing tools so you can take full advantage of your text editor's syntax coloring, search and replace, merge and other tools. We added a tool back in IP.Board 3.1 to enable this in a limited way. If you put the board into 'developer mode', you could export the templates into a PHP file per skin group. This worked reasonably well but many found it tricky to put the board into developer mode as it requires different folders and files to be created and exporting the templates into a single PHP file meant that an external merge tool wasn't effective. We're pleased to say that we've overcome these issues in IP.Board 3.2 by using the popular WebDAV protocol. This protocol is already used by many popular applications like Dropbox to synchronise files between your desktop and their servers. We've used this existing technology to allow you to edit your board HTML and CSS in a totally native format right on your desktop. Indeed as far as your computer is concerned, these are local files! I've taken a short video (sorry, no sound!) that takes you through a template and CSS edit. I've used the mobile skin for this demonstration as we're not ready to reveal the new skin just yet. Here's a quick walk through of what you see on screen. - I log into 'Transmit' which is an OS X FTP/WebDav app. You can use the 'Connect to server...' option in Finder for this task but I find Transmit faster as it caches requests whereas Finder does not. - I use my forum ACP username and password to log in. - I browse the template groups, select 'global' and then globalTemplate.html. - I make a simple edit and save. - I browse the CSS folder and open ipb_styles.css - I make a simple edit and save. - I then refresh the board and you can see the changes have taken instantly. I hope you enjoy this great addition! You can use this with OS X, Linux and Windows and we'll prepare some guides nearer to IP.Board's release on how to make best use of this feature for your OS. I'm sure you'll agree that this offers an excellent way of editing templates outside of the Admin CP that doesn't need a special 'developer mode'. Feel free to comment on this blog entry below or, if you have feedback unrelated to this blog entry, start a new topic in our feedback forum. Be sure to check the What's New in IP.Board 3.2 topic for a running list of announced changes!

We recently blogged about the notification interface enhancements. I'd like to take a moment to go through some further enhancements we've made in this area. We want the notification system to be something you and your members use regularly to keep updated on new events and new content. We've really re-designed the alert system from scratch to make it simpler to use and indeed more useful. First up, lets take a look at a little interface update from the last blog entry: You'll note right away that we're using icons instead of text links and that the 'tab' of the menu is correctly colored to give a full application feel to this system. We've also added a link to the notification 'options' so you can fine-tune your preferences quickly. The more eagle eyed among you will notice a few entries for "New topics" and "new replies" but we'll get to that shortly. Here's what the notification system looks like with new alerts ready to view. We've spent some time looking at the various uses of the system and made some improvements to the preferences form: We've moved 'notification list' as the first column. This is the first stop for many people as they may only want to have a 'red alert' box show when something happens. We've removed the option to send a notification via personal message. We found that virtually no one uses this option and it creates a chain-effect when you have certain notification combinations. Now that the notification 'red alert' box works correctly by only showing an un-acknowledged count which disappears when you click to view the drop down, we felt that having a separate personal message alert just duplicated this. We've also moved the "show an inline pop-up" option directly inside the "Private Messages" section. Now, you will only get an inline pop-up for a personal message and not for other alerts. This was a very popular request! Also, when you receive a new personal message, you no longer get a notification about this. The new inbox alert system works exactly like the notification alert system in that the list retains the most recent items but the 'red alert' box disappears when you click the list. Now that we've moved the 'watched topics and watched forums' over to the 'follow' system, we can tie this neatly in with the notifications system. You can elect to receive an alert when someone replies to a topic you're following just as long as you've selected an 'immediate' notification. This will be great when you want to continue browsing the board but need immediate notification when someone replies to a topic or starts a new topic. I hope you enjoy these further updates to the system and find it a very useful way to be kept up to date with new events! Feel free to comment on this blog entry below or, if you have feedback unrelated to this blog entry, start a new topic in our feedback forum. Be sure to check the What's New in IP.Board 3.2 topic for a running list of announced changes!