bfarber

You should change the call to send the data directly to IPSMember::save (which is all $this->createLocalMember() is doing), however this isn't really a help forum - it's a feedback/feature request forum. If you need help coding for the software or modifying the code, you should post in our peer to peer forum here: http://community.invisionpower.com/forum/310-product-modifications/

Yes, it's fixed for 3.1.2.

Actually, all you should need to do is clear the content cache under System tab -> Cache Management in the ACP. BBCode is parsed at runtime, not during save, however we do cache parsed posts - so you will likely need to clear that cache for your changes to take effect.

If you need an answer you should submit a support ticket. This is a feedback/feature suggestion forum and we don't "answer" most topics in this forum. We use it to gather ideas for new features.

It is entirely possible, for what it's worth, to modify your skin template so that if the user has ignored the poster the post doesn't show up at all. Granted, it could make for some confusion (i.e. post #1, post #2, post #4) but that would only be a minor thing.

Just like in real life, if you ignore a person, that doesn't mean the person disappears off the face of the earth. They're still there, and it is still up to YOU to ignore them, if you don't want to pay attention to what they say. IPB will hide their content. If you still go and view it, that's your own prerogative.

Under Manage Hooks, you edit that hook and change the template location where the hook file adds itself. Use the peer to peer forums if you need assistance with this.

There was a bug report opened last week about the checkboxes.

Personally, I've never seen the problem with bumping a really old thread. Old does not necessarily mean irrelevant.

1) If you click your username at the top and choose My Settings, it takes you to this page: http://community.invisionpower.com/index.php?app=core&module=usercp 2) Yes, Gallery can support unlimited subcategory depth. Gallery also supports displaying images larger than the medium configured size in lightbox. Random example: http://community.invisionpower.com/gallery/image/2963-pc-image-6/ Click the icon 3) Through a template/javascript modification, yes. There are no settings to change it without altering the skin, however. 4) This is not a feature at this time.

No - recaptcha generates all that as I recall. We simply call to their javascript API and they generate the UI for the whole block.

Our IP.Board 3.1 beta testing stage is well underway, and so far things are looking pretty good. We want to take a moment to thank everyone for their time and effort helping us to test IP.Board 3.1. Your contributions are appreciated and only help to ensure the quality of the software is nothing less than you would expect from us upon final release. While IP.Board 3.1 is feature locked, we recently took some time to work on the URL parsing routines to deal with a couple of issues, and thought you might like to hear about these updates. Auto parsing of media tags IP.Board 3.0 introduced the new [ media ] tag, which is used to embed multimedia, like YouTube videos and more, into posts and other areas. This tag works just great, but we've heard from many of you that you think it would be better if media that works within the special tag was parsed and displayed automatically, even if the media tag was omitted. As of IP.Board 3.1, this is now the case. If you copy and paste a link that would correctly parse inside the media tag into your post without media tags, IP.Board's bbcode parsing routine will recognize this and automatically embed your YouTube video or other media right in the post without any other user intervention! Parsing of URLs with commas We've had some passionate discussions spring up across the forums over the past couple of months discussing whether a comma character that would seemingly be part of a URL should be parsed as part of the URL. IP.Board 3.0 originally did so, however this was changed during an early 3.0 release due to a posted bug report. Regardless of the history, many of our customers felt that if a URL has a comma contained within it, that comma should be treated as part of the URL. If it contains a comma at the end of the URL, it should not. You'll be happy to know that IP.Board 3.1 will now present commas as part of the URL appropriately. Here are some example scenarios (the URL bbcode tag was not used to post these) so you can see how it will work: http://community.invisionpower.com/index.php?test=1 http://community.invisionpower.com/index.php?test=1,2 http://community.invisionpower.com/index.php?test=1,2&something=3 I like http://community.invisionpower.com/index.php?test=1, and that's all! This is a relatively minor change, but one which we feel many of our customers will be happy to hear will be included in 3.1. Just a note: if you don't know, don't care, or don't know why commas in a URL should matter to you then you can ignore this small change :) International Domain Names ICANN (the body that regulates domain names) has recently begun approving (and examples are popping up in the wild) domain names that contain non-latin characters in them (known as IDNs). While this won't affect many of our customers, we decided to take this opportunity, before 3.1 is released, to ensure that IP.Board will correctly parse such URLs. Some examples: http://παράδειγμα.δοκιμή/ http://وزارة-الأتصالات.مصر If you expect such domain names to be used on your board, you should expect that IP.Board 3.1 will be able to correctly parse such URLs. We always want to try to stay "ahead of the curve", and this is just one example where we'd rather implement expected functionality now, before our members are affected by any legacy limitations. These changes have been applied to our board here as of the time of this posting, so feel free to try out the new changes in the test posting forum. As always, we look forward to your feedback, and if you happen to find any bugs, please report them to our bug tracker. View full blog entry

To add on to what Luke said, I find a forum for reports/dealing with users to be problematic. Case in point - we've had one in the past (at least at IPS Beyond) and then at some point it gets pruned, hidden, or removed. Suddenly, all of the information on the user's warn history is gone. It's better to keep this data in a self-contained system for it's own specific purpose, in my opinion.

Ok, sitting back and thinking about this, if we contract ANYONE to do a security audit - why would we require them to buy a license first? :blink: I can't imagine how that would make sense. If I was a security auditor and faced with that situation, surely I'd simply raise my price to compensate for the cost of the IPB license (or tell the company they're nuts and ignore them). Cryptovirus has been looking for and reporting issues he finds on his own without compensation. The fixes, once rolled into IPB, benefit all of our customers (especially since he seems to be focusing on security-related things). Personally, I'm happy for him to look through the code and report any problems he finds so we can continue to deliver a secure, stable software for all of our customers.

We introduced IP.Chat 1.0 in January of 2010 and our servers have already processed over 6 million chat messages in just a few short months and the rate of adoption of IP.Chat continues to accelerate. Many communities are making good use of the chat software and we hope you are enjoying the IP.Chat product so far. Logs of your chat room are an important tool for moderation of your community. Presently, you can download your chat logs from your client area, and while this is fine, it limits access to the account owner only. Wouldn't it be nice if you could access your chat logs right from your IP.Board ACP? Beginning with IP.Chat 1.1.0 you will be able to review chat logs right from the ACP. The Interface Chat logs will be styled similar to how you see the chats appear right from the chat room. Background coloring helps to identify /me messages, moderator actions, user has entered/left room messages, and private chats. Here, you can get an idea of how the log messages appear. There's not a lot to explain here. BBcodes and smilies will be parsed similarly to the front end, and the rows will be styled similar to the front end. Searching and Filtering By default, private chats will NOT be displayed. We debated how to handle private chats early on. We knew that some users would want them to appear in the chat logs, and some users would feel it's a breach of privacy. The way the chat logs work is that private chats are hidden by default. There is a search/filter bar at the bottom of the chat logs table allowing you to control which chats you wish to see, as well as search your logs. By default "Public" is checked, so you will only see private chats if you choose "Private" or "Both". Your selection will be remembered when browsing from page to page, but you can reset it at any time using the form at the bottom of the page. If you don't wish to review private chats made on your community that is absolutely fine - just don't check the radio button to do so and they will be kept private. In addition to controlling which types of chat messages are displayed, you can search for keywords (and/or usernames), and restrict the logs to a specified date range. You can also fill in only the "from" or "to" field (to get all chats after a specified date, or all chats up until a specified date). The javascript date picker is used to help you supply a from and to date. Pruning A new setting has been added to allow you to specify how far back to keep chat logs. By default, chat logs will be kept for 30 days, and then a task will prune any logs older than 30 days. You can increase or decrease this retention period, or disable pruning altogether. The Backend Chats are still processed through our central servers, so in order to provide this functionality, we have introduced a method for allowing you to retrieve the chat logs for your chat room from our servers. A task is added with IP.Chat 1.1.0 that will download chat logs from our servers every 30 minutes. The task will only retrieve logs saved after your most recent log entry to reduce bandwidth consumption and processing time (and to prevent pruned logs from returning at some future point). Further to this task, you can manually refresh the logs by clicking the "Refresh Logs" button you'll see in the chat logs window. This effectively executes the task immediately, downloading any logs available on the server but not yet stored in your local database. Conclusion As IP.Chat's popularity continues to grow and our customers continue to make use of the software, we felt that this small addition would aid administrators and moderators in managing their communities. Having the logs available locally to your site means anyone with ACP permissions on your board can access the logs, and review anything they need to. You also have control over how long your logs are retained this way, and don't need to visit your client center to review them. We hope you find this new feature useful in the upcoming IP.Chat 1.1.0 release. View full blog entry

Since first unveiling the notification changes coming in IP.Board 3.1 we've received a ton of feedback from our customers to further improve the system and make the notifications more useful. We've been listening to your feedback (and often agreeing with your points) and have decided to implement many great ideas to the make the notifications system cleaner, easier to use, and less intrusive. Better defaults upon upgrading With our first beta release, nearly everything that can issue a notification did. While inline notifications were set for various less important notifications (such as "Your friend has updated their status"), this quickly proved to be intrusive for users who were regularly active on the board. We have not removed any of the notification options available, however we've defaulted many of the less important notification options to not issue notifications initially upon upgrade. Users who wish to receive notifications for these actions may still visit their user control panel and enable them. This should lead to a less intrusive (and thus, more useful) inline notification setup when you first upgrade, while still allowing users to stay informed of everything happening on the board should they wish to. Shut the popup off Another option that has been introduced is the ability to disable the popup, should you not wish to see it whenever you receive a new notification. There is a per-user setting added to the notifications configuration section of the user control panel to allow you to enable and disable the popup. If you disable the popup, your notifications are still available in your user control panel. This is a small addition that we felt would give each user more control over their browsing experience. Review all of your unread notifications in the popup Another change requested frequently since we first introduced the new system is the ability to review all of your unread notifications from the popup. Presently, only your latest notification is shown, and a link is provided to allow you to visit your notifications log area. Now, there are buttons to allow you to jump through your unread notifications directly from the popup so that you can view all of your unread notifications at once. We've made a short video to demonstrate how this works: This is another small, but useful, change that has been oft-requested, and that we're happy to provide in the next 3.1 beta release. Better accessibility And now we've saved the best for last. Many of our customers have requested that in-lieu of an intrusive popup window to alert you when you've received a new notification, that we implement a menu inline in the page, and show a count on this menu. The menu would provide for quick access to your latest notifications, providing an easy way to review new notifications, while not issuing a popup on every other page load. We're happy to report that you will see such a menu introduced in the next IP.Board 3.1 beta release, with a few extra touches to further enhance your browsing experience. A new menu has been added next to your username dropdown in the top right corner of the page. The number of unread notifications is listed on this menu so that you can quickly see how many unread notifications you have. When you click on the menu, a dropdown is loaded via AJAX displaying your last 10 notifications. Unread notifications are bolded to help you quickly identify them in the list. You'll notice that we've additionally added icons to represent each notification type. These icons can be changed per-skin, and third party developers can add and specify their own icons for their own notifications that they issue. (Please note that the icons you see in this screenshot may not be the icons used in IP.Board 3.1 final) There's a "View All" link at the bottom of the menu, allowing you to quickly go to your notifications list should you need to review further back than the last 10 notifications you received. An important note to make here - when you open your menu, all of your unread notifications will be marked as read. This is a small change that we feel helps make the notifications system more useful. It's natural to assume that when you open the menu and review the list of notifications, you've acknowledged them and no longer need them to reflect an "unread" status. You can still, of course, review them even after they've been marked as read. And finally, once you have no unread notifications, the styling of the menu will change so as to prevent it from drawing your attention as readily as when there are unread notifications for you to view. Coming in the next refresh All of these changes will be present in the next refresh of the IP.Board 3.1 beta which will be applied to our community forum later next week. We look forward to your feedback on the enhancements we've made to the notifications system. We expect these changes will prove useful and help to further polish an already powerful and exciting new feature. (Note that a beta of IP.Board 3.1 is not yet available for download while we finish polishing off these features based on your feedback. Once we have a stable product we will be releasing public betas. Keep an eye on this blog for an announcement.) View full blog entry

Development is under way (and wrapping up, in fact!) on IP.Chat 1.1.0, so we wanted to take a few moments to illustrate what new functionality you can expect to see with the next update of IP.Chat. If you are not already familiar with IP.Chat, we offer a javascript-based chatroom solution that any customer with an active IP.Board license (or support and services contract) can add to their site. The first level of service for the IP.Chat product allows for you to host up to 5 simultaneous chatters, and is available at no cost to you while your license is active. Other packages are also available for sites that expect more traffic to their chatroom. For more information on IP.Chat, please see our IP.Chat product information page. How many people are in the chatroom? While IP.Chat does include a hook that shows the number of users in the chatroom on the board index, many users felt that the display of this hook was too hidden (it is at the bottom of the screen, along with the other board stats), and only shows on the board index. As a result, users are frequently unaware when someone enters the chatroom, limiting the amount of activity the chatroom gets. We've implemented the most popular suggestion to counter this problem: we've added a count to the 'Chat' tab at the top of the screen that displays how many users are currently in the chatroom. This has been implemented as a hook, and as such can be disabled in the Manage Hooks page of the ACP if you have no use for the feature. You will also have the option to disable the count if no one is in the chatroom, and to hide the count on the tab when you are actually viewing the chatroom page itself. If you allow the count to display while viewing the chatroom itself, the count will dynamically update as users enter and leave the chatroom, allowing you to easily and quickly tell how many people are still in the room just by looking at the tab at the top of the page. We feel this is a small, but useful, addition to the chat software which should help spur activity in your chat room. Private Chatting Another highly requested feature has been implemented for IP.Chat 1.1: private chats. You will now be able to chat within the chat software privately with other users who are logged into chat. A new ACP setting has been added, allowing you to control which groups are allowed to initiate private chats (note: anyone can receive private chats). When your group is allowed to initiate private chats, the username menu that exists presently for moderator actions will have an option to "Start Private Chat". When clicked, a small popup box appears to allow you to fill in the private chat text you wish to send to the user. When a new private chat is started, a new tab is created within the interface. And if new messages are received for inactive tabs, a count is displayed to let you know. As the name of the feature implies, private chats are a one-to-one relationship between two users only. What if I don't want to talk to you? It's natural that you may not wish to converse privately with certain members of a community you are a part of. A "block user" feature has been added to allow you to prevent specific users from sending you private chats within the chat room. There is a new user control panel page where you can block and unblock users. You can also block and unblock users directly within the chat interface. AJAX is used to save the option, and your preferences are updated dynamically (users will be blocked immediately). The user is not made aware that you have blocked them. Instead, any private chats will simply be ignored on your part, as if it was never initiated. Wrap-up IP.Chat has proved to be a stable, useful, and popular addition to our community software line-up. Many of you are making good use of the chat software on your site, and we hope these new additions improve and expand the functionality available in the software in useful ways for you and your users. We have some good ideas for future features, however we wanted to keep a focused approach for 1.1.0 first. Stability and security is of the utmost importance to us. The new functionality introduced for IP.Chat 1.1.0 lays the foundation for many new useful features in the future. View full blog entry

IP.Content has many features, and indeed it's quite possible to create a rather useful articles system using the custom databases feature introduced in IP.Content 1.1, however many of our users have been requesting a true "articles" feature since the first release of IP.Content. In typical IPS fashion, we've listened, and you will be happy to hear that IP.Content 2.0 introduces a new "Articles" module. Building on existing functionality As I mentioned, you can create a very useful and workable articles section using the existing databases features in IP.Content. The database feature accomplishes so much of what needs to be implemented for articles, in fact, that articles actually "build on" databases behind the scenes. Much of the interfaces will feel familiar, because indeed much of the code is shared between the two modules. This helps ensure consistency is met between the various sections of the site, and helps to ensure that bug fixes for one area are automatically and immediately carried over to the other. Many of the ACP pages will feel nearly identical to the databases section, and the majority of the features are available in your own custom created databases as well. We feel that the similarities with the existing functionality will help you to get started with articles quickly and efficiently, while the new features and functionality will help to set it apart from the rest of your databases. Navigational flow and frontpages In a generic custom database within IP.Content you will have a "categories" template (which displays a list of your categories, akin to the forum index page), a "listing" template (which shows the listing of records, similar to viewing a forum), and a "display" template (which facilitates displaying the actual record itself, similar to viewing a topic). The articles module separates here from the databases functionality a little, giving you some more options and flexibility. The homepage uses a new template type we refer to as a "frontpage" template. When you first visit the articles section, this frontpage template is used to show you the landing page content. By default, articles that are flagged to show on the homepage will display on the frontpage, however you can naturally change the template to manipulate the data however you like. We will ship with 3 default frontpage templates: 1x2x2 This template displays a large article summary block at the top. The next 2 rows have 2 article summary blocks side by side. Finally, two more rows can display showing article summary blocks side by side. Blog The blog-style template displays one article per row, showing the entire article text (or the first page of the article text, if it is a multi-page article). This is similar to what you might expect to see when you visit a blog. Single Column This template displays one article per row as well, however instead of displaying the full article (or first page of the article), it only displays a small summary. This is similar to what you might expect to see on a typical news site. You can of course also create your own frontpage templates, or modify our defaults to suit your own needs. It is entirely up to you, however we have included a few to help get you started. Now, a user is likely to enter an article directly from the front page, since we bring articles to the forefront with the frontpage template. If so, they will reach a "display" template, just like they would with a standard custom database. However, if a user instead clicks through to a category, they will see a layout similar to the homepage, since you now will also assign a frontpage template to each category. The category will display articles in a fashion similar to the homepage (although you can use different frontpage templates per-category), instead of just providing a listing of articles as would happen in a standard custom database. We do still have a "categories" template within the articles module, which is linked in our default site from the category block. You can make use of this if you want, however we believe you will find it secondary to the main navigation structure, instead of a primary focus as it is in other custom databases. There is also an "archives" template, which is similar to the "listing" template in any other custom database. It will list all articles within your articles section, and features sorting, filtering and pagination as appropriate. Managing articles The ACP interface for managing articles has similarly been overhauled, allowing for an easier and more efficient process of managing your articles. You can dynamically sort the listing of articles both in a lowest to highest and highest to lowest order, you can change the status of an article to published or draft using AJAX, and you can filter articles via multiple characteristics to allow you to easily and quickly find the content you need to edit. The form to add and edit articles has been cleaned up and condensed, making it a much quicker process to add or update an article. When adding or editing an article, you will be able to set certain characteristics about the article. You can control whether the article shows on the frontpage or not. You can control whether the article will allow users to comment on it or not. You can also specify a comment cutoff date, after which comments will no longer be allowed. You can control when the article itself "expires", after which it will only be available when viewing the archive listing. You can change the article author to another member (using AJAX). You can even control, per-article, which article view template to use. This means that you can create a set of pre-defined article view templates (for instance, maybe one which displays the screenshot image on the left, and one which displays it centered at the top of the article), and then when adding your article you just select which template to use from a dropdown menu. Overall, you have a lot of control to ensure that your article is presented exactly how you intend. It is important to note that, just like with your other custom databases, you can create additional custom fields for your articles if you find that you need a field which is not presented by default. There is also a frontpage manager page in the ACP, where you can quickly see all articles set to display on the front page, with the ability to remove any articles that should no longer be available on the front page. It is important to note that you can also control how many articles are displayed on the front page, and that your template can further control how many articles are displayed, based on certain conditions of the template. Thus, while you may have 20 articles set to display on the front page, only 10 may actually display. Your front page manager can help you control which articles, exactly, should display. Promoting forum content Along with the new articles section of IP.Content in version 2.0, we have added a "Promote to article" hook to the forums. Users allowed to use this new button will be able to promote any post on the forums to the new articles section of IP.Content 2.0. The promotion feature has several options to ensure that it is flexible enough to meet your needs. Firstly, as the administrator, you can control which user groups are allowed to use the feature. You can allow both copying and moving of posts to the articles section. When you allow copying of posts and a user clicks on the promote button, a new article will be posted as a copy of the post. When you allow moving of posts and a user uses the feature, instead of copying the post to the articles section, it will be moved (with the original post in the forum being deleted). You can optionally have a link left behind in the forums pointing to the new article. When a post is copied, this link is added to the end of the post. When a post is moved and a link is left behind, the post isn't actually removed, but rather replaced with the link to the new article. As the administrator, you can allow your users to specify whether to leave a link behind each time a post is promoted, or require that the link always be left behind. This new feature should help facilitate promotion of valuable content on your site, and help enable easier content discovery by your vistors, registered or otherwise. As the search engine industry often says, "content is king". The content on your site is its most valuable asset, and this feature helps you better manage that content, to ensure it is benefiting your site as best as possible. Before we move on, I would like to take a moment to mention that the articles section can also allow comments to be stored in the forums, just like your other databases. This new feature in IP.Content 2.0, discussed in a past blog entry, supports databases and articles alike. New default site By itself, we believe the new article section will help you better manage your site, and get you started using IP.Content quicker than ever. No longer will you need to manually create a database, create database templates, tweak them to suit your needs, add the database to a page, and so on. Instead, the articles section takes care of the majority of the legwork for you. So now that we've made everything easier to use from the outset, where can we go from there? Well, not content to sit back even for a moment, we have redesigned the default site that ships with IP.Content to better highlight some of the features of IP.Content 2.0. By default, you will have two "pages". One hosts the new articles section, while the other is a demo of another custom database: a media section, linking to various youtube videos. We feel that the new demo site better shows off many of the capabilities of IP.Content, so that you can better understand how to use the system. Some of the things the new default site shows off: Some default pages Some CSS "pages" Custom blocks holding variables An article category feed A "latest articles" feed A "latest article comments" feed A separate custom database The default site will also populate some basic content for the above areas so that it is not empty upon installation. We will not be inserting this default site for upgrading users (the expectation is that if you are upgrading, you're already familiar with the software and would only be deleting the default site content anyways), so we've decided to host a demo of the new default site so you can click around and see how it works. We will post some articles describing how we created some of these areas for you to benefit from near the release of IP.Content 2.0, in case you are curious how we accomplished certain functionality (such as the media database). Take a look for yourself! And with that said, head on over to our demo installation so you can take a look! This is an early look at the actual default site that will be presented with IP.Content 2.0 upon installation. We look forward to hearing your feedback, and we hope you are as excited as we are about the latest feature announcement for IP.Content 2.0. Overwhelmingly, the one thing our customers have requested for IP.Content 2.0 is a "true article system". We've listened, and a true article section is on its way. View full blog entry

IP.Content is an extremely flexible system. While considering the possibilities with IP.Content and feeding content to your external pages, we knew that there were multiple options. Using a database You can create a database to store content such as articles, and then allow commenting on these articles directly. In doing so, you keep your articles and your topics separated. Using a blog You could create a blog, and then create a feed block that pulls entries from this specific blog to your homepage. In doing so, you could create a dynamically updated homepage which is fed from a specified blog. You would not easily be able to allow commenting on the entries on the homepage, but the blog itself would still allow commenting. Using a forum You could create a forum and then post your "news" topics in this forum. Then you can create a forum feed block to pull these topics to your homepage. This allows for easy syndication of topics you wish to show elsewhere, although you will again face limitations when it comes to allowing comments. Raw pages You could certainly create new pages manually, and update them on your homepage. You could even create a topic manually associated with each page, and then feed replies from that topic to the page using a forum reply feed block, if you wanted. Many users have expressed interest in a hybrid method not listed above. Specifically, many users have requested a way to use the forums to facilitate commenting on database records. As of IP.Content 2.0, this will now be possible. Overview Databases are segregated from your forums on purpose. They are their own "section", and are designed to run independently of the forums. Still, there's no reason that the two can't play nicely together, right? With IP.Content 2.0, you will now be able to turn on and off the forum integration at a per-database (and per-category) level. When you do, submitting a record to the database will post a topic in a forum of your choosing. You can also optionally choose to use that topic as the comment storage container. If you choose to do so, comments made in the database will actually be posted as replies to the topic, and the comments displayed on the page will be the replies pulled directly from the topic. Specifics For each database, you can enable and disable the forum integration. You will be able to turn the forum integration on, specify which forum the topics should be posted in, specify a topic title "prefix" and "suffix", specify if the topic should be deleted if the record gets deleted, and enable the feature to use the topic to host the comments for the record. Further to this, you can override these settings at the category level as well. By default, the categories will inherit the forum settings, but you can edit each category and override any of the above settings. This allows you to create some interesting combinations. You could use the built in database functionality for all categories except for your news category, for instance. Or you can have IP.Content post the topics in an appropriately mirrored category structure in the forums. It's up to you! You can also allow IP.Content to remove the automatically generated topic (and any replies to the topic) when you delete the record, as well. Additionally, any standard moderator actions (delete comment, approve comment, unapprove comment, etc.) will work seamlessly from IP.Content, both from the front end and from the ACP, regardless of whether you use the forum integration or not. While you can manage comments from the forum as well (for instance, if you delete a reply to the topic, that "comment" will no longer show up when viewing the IP.Content record), we recommend you use IP.Content to manage the comments. In some instances, IP.Content may need to take additional actions which will only be triggered when the moderator action is initiated from IP.Content. Comments When you enable the forum integration for comments, any comments made on the record are not stored in the IP.Content database tables, but instead are posted as replies to the automatically created topic. When displaying the comments in IP.Content, instead of checking it's local tables it will instead pull the replies to the topic and display them on the record page. Users will be able to comment on the record directly, OR post a reply to the topic (provided you give them appropriate permissions in the forums). Either way, the comment will be displayed appropriately when viewing the record in IP.Content. Note that IP.Content will be able to post to the topic even if you do not allow any permission masks to access the forums you have told IP.Content to use. This means you can create hidden forums to host the topics if you want, or you can create forums that are open to everyone. Some users may prefer to navigate your main website (powered by IP.Content), while some users may find navigating your forums more familiar. Using this new integration option, you can cater to both demographics on your site easily, all the while without increasing your workload or duplicating the content inappropriately across your site. The comments as displayed in IP.Content when using the forum integration appear the same way they would if you stored the comments locally. Your users won't know the difference. Note that if you leave reputation on a comment that comes from the forum, the reputation is associated with the forum post (so the user will not be able to visit the topic and rep a post again). Just for completeness, here's an example of comments being fed from the automatically generated topic anyways. Upgrading When you upgrade to IP.Content 2, naturally your existing articles won't have topics stored in the forums, thus comments won't be stored in the forums either. Any record that does not have a topic associated will automatically fallback to using it's local built-in commenting system, while new records submitted will use the forums as configured. This means that when you upgrade, you don't have to worry about any of your comments disappearing if you decide to make use of the new functionality. Everything should work seamlessly so you don't have to worry about rebuilding records or missing comments. When you upgrade, you can optionally make use of this new feature, but it won't affect your previously saved records. Wrap Up We feel that this new capability in IP.Content solidifies the forum integration capabilities available with IP.Content, allowing you to create unique and creative site configurations. You can allow visitors to view the content from both IP.Content and the forums, or only from IP.Content, or only from the forums. You can opt not to embed the database into any pages, and instead just allow members to read the records and comment on them from the forums only. You can let IP.Content post a topic and all comments to a hidden forum to make moderation easier for your old-time moderators who aren't familiar with IP.Content. You have many options; this is the goal with IP.Content. To allow you to decide how your site should function. We look forward to hearing your feedback regarding this new feature! View full blog entry