bfarber

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

Templates in IP.Content are a useful tool that can save administrators a lot of work managing their site. They are utilized to facilitate displaying database content, and can be utilized to normalize the display of multiple pages through a shared template. We have made a few small tweaks to templates to make them easier to manage and easier to use in IP.Content 2.0. Separation of templates In IP.Content 1.x database templates and page templates were displayed on the same page. While they technically use the same backend system to render the templated HTML, it can be confusing for users to associate page templates and database templates on the same page. Utilizing containers can help separate the two types of templates, but we felt we should go a step further. In IP.Content 2.0, database templates and page templates are not displayed on the same page. Database templates now have their own page under the generic Templates header. Container grouping Within the template areas you can create containers to "contain" your templates. This is primarily used as a form of categorization and grouping, allowing you to group similar templates together. This is useful when viewing the templates on the template manager page, however templates are not similarly grouped when viewing them in dropdowns elsewhere throughout IP.Content. We have enhanced the template dropdowns in IP.Content to display the appropriate template containers you have created in the dropdown menus, allowing you to more easily identify the templates you wish to use. The template containers are rendered as "optgroup" tags, so they will be unselectable (you won't be able to accidentally set a template container as your page template, for instance). Developers may be interested to know that in implementing this change, we have enhanced the IP.Board admin CP output library formDropdown() method to accept an optional array of opt groups. You will be able to make use of this new optgroup functionality in your third party applications starting with IP.Board 3.1. Identifier storage Previously in IP.Content, we recorded whether a template was a database template or page template, however we never recorded what kind of database template you were saving (i.e. a "category" template, a "listing" template, or a "record display" template). Starting with 2.x, we now store what kind of database template you are creating, and in doing so we can better streamline IP.Content's options elsewhere. When you create a database, only listing templates will be displayed in the listing template dropdown menu, for instance. This will help prevent users from accidentally setting a category display template as their listing template (in which case, no records are ever listed). Additionally, when clicking the link to display database variable help, we can now show you the variables directly related to the template you are editing, without having to ask you to select what kind of template it is first. While this isn't an exciting change, for sure, we believe you'll find it streamlines management of your IP.Content installation, and makes your available options much clearer. Template comparisons We are introducing a template comparison tool for your database templates starting with IP.Content 2.0. When you upgrade to IP.Content 2.0, you will need to make template changes to take advantage of some of the newer features. For instance, to show the button to "watch" a record or category, the HTML for this button needs to be added to the template. It can be tedious and time consuming for you to have to manually create a new template and then copy over the customizations you have made to your previous template. We have added a template comparison tool that will compare your database template to the default database template for that template type (i.e. to compare your database listing template to the default database listing template) so that you can quickly see what is different in your custom template compared to the default. We believe this tool will help ease upgrades moving forward, especially upgrades where new features are introduced to the databases functionality in IP.Content. Until next time... We realize this isn't the most exciting blog entry about IP.Content 2, but we wanted to finish telling you about some of the smaller changes you should expect to see in IP.Content 2 before we get into the bigger things. Stay tuned for the next few blog entries. We think you'll like what we have in store! View full blog entry

Add and edit hookpoints Based on requests from users integrating IP.Content into their website, we have added two new hook points to the database handler: postSave() and postSaveEdit(). These are called immediately upon saving the record to the database (for add and edit requests, respectively), and can be utilized to take action on a record after it has been saved. This could be used, for instance, if a file is uploaded or linked, and you need to take action on this file, but don't want to until the record itself has been accepted. Format numerically We have added a new field formatting option that will allow you to automatically format fields numerically, based on your selected locale. This option will automatically apply thousands and decimal separators to the value supplied in the field. "Bump" records with comments There is a new per-database configuration option that will allow you to tell IP.Content that when a new comment is made on a record, that record should be "bumped" to the beginning of the list. For this to work, you must be sorting your database by "last update". When this option is enabled and a new comment is made on the record, the last update timestamp for the record will also be updated, moving that record to the top of the list. Other contributors If you have a database configured that allows wiki-style editing, and you have revisions enabled for this database, a new line will be displayed below the "Submitted by:" field showing all members who have contributed to the record. This is useful in a true collaborative environment to allow you to see all users that have modified the record. You can still utilize the revision manager in the ACP for details of each revision, as well. Random database feeds You will now be able to order database record and comment feeds randomly, making these feeds more consistent with the other feeds you can create using the block manager. You can use this ability to show a block with 10 random records, for instance, helping your users to discover the content in your databases easier. Database category feeds You will now be able to create feeds of the categories within a database. The feed template has some slight modifications made to it in order to display the categories in a more natural display than you would use for records. Hierarchy is preserved with the feed. More consistent linking In IP.Content 1.2 and below, many of the links to the databases require using a "redirecter" link to get there. By that, I mean that instead of linking directly to a category or record on the page it is actually located on, we link to "app=ccs&module=pages&do=redirect&database=1&record=1" (for example). This is effective and efficient, however it is not the most desirable setup naturally. In IP.Content 2, the actual link to the resource is correctly used instead. Primarily, you will notice the changes in feeds. Canonical tags And while we're on the subject of SEO and consistent linking, the next feature we'd like to announce for IP.Content 2.0 is that of canonical tags. Canonical tags will be automatically determined and added to pages and databases (including category and record display pages in databases). This will help to ensure that any additional links that may load a page or database record will pass it's link value through to the correct canonical URL. New field type: uploads The attachments field shipped with IP.Content 1 works well, and is very consistent with IP.Board posting. Your users will find it familiar, and indeed in most cases this may be the best field to use for your specific needs. However, many users have requested the ability to upload single files, often because they would like to be able to manipulate these files from the listing template (for example), or because they want more control over how the files are embedded into the actual record. IP.Content 2.0 introduces a new single file upload field which you can use to upload single files. You can add more than one of this field type to a database (there is no hardcoded limit), and the value that will be seen by IP.Content is simply the URL to the file you've uploaded. There is no image resizing or other functions executed with this particular field type - it is a simple field to allow you to upload a file easily. You can use this field type for any file type as well (you can define which file types are allowed with the field when configuring the field in the ACP). When editing records, a note will be displayed below the upload field to let you know if a file is already present and will be overwritten by uploading a new file. A checkbox will also be available to allow you to easily remove the file without uploading a new one. Resize image template plugin When implementing the single file upload field, we begin experimenting with ways to embed the content within the record, and found that it would be useful to be able to dynamically resize images that were uploaded, even if we didn't resize the file itself. Even just specifying width and height parameters to the image would allow us to manipulate the display for our specific purposes. To this end, we've added a new template plugin that accomplishes just that. Note that template plugins can be used all over IPB and are not restricted to IP.Content specifically. You use the template plugin by embedding the following: While we work to wrap up some of the IP.Content 2.0 changes we'll be discussing in upcoming blog entries, I wanted to take a moment to give everyone a quick update on some of the smaller changes and tweaks we've already implemented in IP.Content 2.0. These small, but useful, tweaks and feature enhancements are sure to allow you to take IP.Content databases in new directions. {parse resize_image="url or path to image" maxwidth="100" maxheight="100"} The plugin will determine the proportionately resized width and height values that fit within your constraints, and return the string "width='x' and height='x'" to suit your request. Note that maxwidth and maxheight are both optional parameters (you could restrict based on width only, for instance), however at least one must be supplied. Multipage records We have added a new custom bbcode that can be used within IP.Content to create multi-page records. The bbcode is very easy to use. Below you will find an example: [/page][page] This is the text for page 2 [/page][page] This is the text for page 3 This is the text for page 1 Effectively, you just insert " Moderator "add record" permission While IP.Content does allow for some separation of authoring and editorial duties, many of the lines are blurred and a true editorial process is not always clear within this environment. We made some small enhancements to the moderator duty capabilities in IP.Content 2 to overcome this. There is a new permission option for moderators: "Add Records". Utilizing this permission, you can easily create a true editorial review process for all articles posted on your site. You can now create "moderators" who have only "add record" permissions. These moderators can post new records into the database, but cannot edit or approve those records. Then, you setup your editors as moderators with enhanced permissions in the database. These are the users that can edit, delete and approve records. Your authors will then add the records, and your editors will edit, review and approve the records the authors add. By utilizing a multi-step process, you cut down on grammatical, spelling, and factual errors in the content posted on your site. Share links A week or two ago, we can expect to see in IP.Board 3.1. This new sharing link functionality will be integrated with IP.Content 2, as well, allowing you to easily share (or email/print/download) any record in your IP.Content databases. Comment reputation Going along with the last feature, in keeping consistent with IP.Board we have integrated reputation into IP.Content database comments. You can now leave reputation for database comments, just like comments in other areas such as IP.Blog, and these comments will automatically be hidden or displayed based on your configured reputation preferences. You will be able to quickly view comments hidden through negative reputation filtering by clicking a link presented with the comment. Subscribe to records and categories And last, but not least, for today: the ability to watch categories and records in IP.Content 2.0. You will be able to click a watch icon (which will change to "Stop watching" if you are already subscribed) in categories and when viewing records starting with IP.Content 2.0. Upon clicking the button, you will begin receiving notifications of new records in categories you subscribe to, and new comments made to records you have subscribed to. These notifications honor your configured notification preferences in IP.Board 3.1. AND THAT'S NOT ALL! As you can see, there are a lot of exciting changes coming to IP.Content 2.0. We feel that many of these changes round out the database features significantly, bringing its functionality in line with that of IP.Board, both for consistency, and to allow you to offer your users more functionality that they are already familiar with. We still have some more great features we can't wait to tell you about, but we hope these tidbits will tide you over while we work to finish up those other enhancements. We're working hard to make IP.Content 2.0 a great release. We hope you're as excited about the upcoming changes as we are! " where you want a page break inserted. The custom bbcode takes care of the rest, inserting page links (which you can style independently of the main IP.Board pagination links) below the article content for the specified page. Here's a screenshot that will make this a little clearer (in this screenshot, we are on page 2). Matt blogged about the new sharing links functionality [contentpagination=4] View full blog entry

IP.Content is a complex framework that allows you to create and manage website content in many different ways. You can embed blocks and databases into pages, and pages can be wrapped by templates. You can define page names and use friendly URLs through the IP.Board built-in FURL system, you can use friendly URL's through the included index.php file with IP.Content (for instance, if you want your website in the root of your domain, and the forums in a subfolder), or you can optionally not use friendly URLs at all. Because of the many configuration options, and the fact that you are already embedding a database within another friendly URL system of sorts (given that you define the filename of your page already), friendly URLs were not supported in IP.Content 1. They will be in 2.x, however. We have added support for databases in IP.Content 2.x to utilize friendly URLs. To make use of this support, you will need to be using an existing friendly URL method (accessing IP.Content through the included index.php file, or using IP.Board friendly URLs). The index page of a database lists the categories contained within the database, and is accessed by accessing the page the database is embedded on. For example, if you embed your database on a page called "database.html", then you may access your category index page at http://domain.com/database.html In IP.Content 1.x, if you clicked on a category from this page, you would see a URL similar to the following http://domain.com/database.html?category=1 Arguably, the URL is still "friendly", but "?category=1" doesn't really tell you much about the link you are clicking on. In IP.Content 2.x, you will now define the friendly URL name for the category by editing the category in the ACP. The upgrade process will automatically set a friendly URL name for your categories based on the category title, but you have free-reign to go back through and set the categories to be accessed as a different name if you wish. If I set the category 1 friendly URL title to be "ipb-rocks" for instance, the URL to the category is now http://domain.com/database.html/_/ipb-rocks Because categories are defined by administrators and we are able to do error checking while saving your category configurations, categories do not require any additional information in the URL (such as the category ID). This page will list the records stored in the category. In IP.Content 1 those records would be accessed as follows: http://domain.com/database.html?record=1 Again, this isn't unfriendly, but we can do a little better. Similar to topics in the forums, records will automatically inherit their title based on the specified title for the record. For instance, if the record title is "IP.Content is cool!", it will be automatically rewritten to the following URL http://domain.com/database.html/_/ipb-rocks/ipcontent-is-cool-r1 In this instance, because titles can be duplicated and we wouldn't want to restrict record titles purely to prevent URL conflicts, we must add a marker with the ID to the end of the URL. IP.Content in turn uses this information to load up the proper record when this URL is requested. This is pretty useful in and of itself, however we went a step further. IP.Content is used by many different customers in many different fashions. On some sites, anyone can submit to the database. On some sites, only administrators submit to the database. Because of the different configuration options, and because some databases are small and very controlled by nature, we knew that some administrators would like to remove the record ID from the end of the URL. So we built in support to do just that. If you would like to remove the "-r1" from the end of the URL in the last example, you need only login to the ACP, load up the record to edit it, and within the ACP you will have the option to specify the friendly URL for this specific record. If you manually specify a friendly URL for the record, it overrides the dynamic friendly URL and is used instead. You will not be able to set this same friendly URL for any other record, naturally, but you can edit the URLs at any time should you need to. Thus, you can turn the above record into the following URL http://domain.com/database.html/_/ipb-rocks/ipcontent-is-cool You may have already noticed, but it's important to note that IP.Content utilizes the category hierarchy within the URL for records, including for any sub-categories you may have configured. If you do not utilize categories for your database, that's fine as well - IP.Content will already know this and omit the category from the URL without issue. While not related to the friendly URLs, there's something else I'd like to point out while we're discussing friendly URLs in IP.Content. You are not required to specify an extension for the pages you create in IP.Content, if you don't want to. If you didn't realize this, you can rename "database.html", in our example, to just "database" and the page will continue to function just fine. If you did so, your URL would become http://domain.com/database/_/ipb-rocks/ipcontent-is-cool I know some of you are going to ask about the "/_/" marker in the URLs posted above. It is not a typo. Because of the complexity and many configuration possiblities (pages can be in folders, which can be subfolders, with or without an extension, and so on), IP.Content requires some sort of "marker" in the URL so that it knows when the rest of the parameters are database information. We thought about setting some sort of word for this marker (i.e. "news") but quickly realized this isn't feasible, because everyone uses their databases for different purposes, and many of our customers do not speak English natively. Additionally, you may run one more than one database, however the marker itself is global to IP.Content. While the marker will ship as "/_/" in IP.Content 2.0, you can change it if you desire by editing a constant in an IP.Content file. We felt that having this constant was the the best way to ensure you had control over the marker, should you wish to change it, given that we cannot store this information as an ACP setting for technical reasons. Your requests for friendly URLs in IP.Content 2.x have been heard. They will be available, and will work right out of the box based upon your existing configuration. We have much more in store, so stay tuned! View full blog entry

The page manager, introduced with IP.Content 1.0, is a core feature to IP.Content. It allows you to create pages and folders, and manage those pages and folders, core functionality that IP.Content relies on for everything else. Page management has been pretty reliable and functional, but we decided we wanted to improve the interface for IP.Content 2.0 to make it sleeker, faster and even more functional. Several interface tweaks have been (and are still being) implemented in IP.Content, and the page manager was one of the primary focuses of these interface enhancements. We'll quickly describe the major changes below. Redesigned "buttons" The IP.Board ACP interface utilizes a small "button" icon that is located to the far right of a row in the ACP that you can take action against. In most cases, you will click this button and then choose an option from a resulting dropdown menu. Here's a quick screenshot of one such button to give you an idea of what I'm referring to While functional, Rikki has redesigned this area to allow for the more important buttons/options to be pulled out of the menu, while still allowing for the menu to contain further options you may need to take on a row, but likely won't be executing very often. This means that for your typical options (i.e. edit) you now have one click, instead of two. And it's a lot prettier to boot! The folder rows allow you to quickly add a new folder or page under the selected folder, while the page rows allow you you to quickly edit the page. Additional options remain tucked neatly away in the dropdown menu, just a click away. Quicker access to folders In IP.Content 1.x, when you click on a folder you are taken to a new page that lists that folder's contents. If there is a subfolder, you can click on it to enter into that folder. While effective, if you have a deep folder structure, this can require some time to fully drill down to where you want to end go. There's an easier way than this, surely! With IP.Content 2.0, when you click a folder, its contents will be returned via AJAX and displayed inline. Any subfolders will be listed, along with any files in the folder, right below the folder row that you clicked in (indented, to show "depth"). You can click on subfolders to return those results as well. here's a quick screenshot to show you what I'm talking about. In this screenshot, I've clicked on "another-test" and then proceeded to click on "sub-another" to show its contents as well. With this method, you can quickly drill down into any directory without having to wait for several page loads to occur, improving resource usage and efficiency, while simultaneously reducing the time it takes to accomplish the same task as before. Page filtering When you just have 4 or 5 pages, it's not much of a task to find the one you need to edit. You can quickly browse the list of pages from the page manager and click on it to edit it. Once you start designing an entire site, however, and utilize folders to create sub-sections of the site, it can become increasingly difficult to find the exact page you are looking to edit. Setting aside any "difficulty" in navigating to where you need to get, if you have a 10-level directory structure, it obviously takes a little bit of time to drill that deep. IP.Content 2.x features a new filtering field at the top of the page manager page. This filtering field utilizes live-search functionality to show you search results as you type into the field. You start off by typing in the name of the page you wish to edit. The display will switch to show you all search results for that page, and the folder the search result is contained within. From here you just click on the page and start editing. You can click the "x" icon to clear the search results and switch back to the normal page manager listing, all without any page refreshes. If you know the name of the page you want to edit, but don't remember what folder it is contained within, this new filter capability can make it easier to find where you need to go without hassle. More AJAX We've utilized AJAX elsewhere on the page manager to make common actions quicker and smoother. For instance, if you click on a button to add a folder, and submit the new folder name, it is submitted to the server via AJAX and then displays inline where it should (i.e. as a subfolder of an existing folder, or in the main page manager root, depending on what folder you are adding your new folder to). Deleting and emptying folders also utilize AJAX to accomplish these actions without the need for a full page refresh. Inline confirm prompts (newly restyled) ensure that you don't accidentally click the link without confirming that you truly want to empty or delete the folder. Additionally, deleting pages also utilize AJAX to accomplish the task, again with the restyled confirm prompt to prevent you from accidentally removing something you didn't mean to. Conclusion Many of these new interface changes you will see introduced elsewhere in IP.Content, such as the new action buttons to trigger actions against a specific row of data. Other minor tweaks are being implemented elsewhere in the ACP as well, but we'll leave that for another blog entry. ;) As always, if you have any questions or feedback, we'd love to hear it! View full blog entry

Database "Tweaks" The database functionality in IP.Content is quite powerful at its core. You can do a lot of things with the database feature that would normally be laborious coding yourself. A lot of addon applications add common features: rating, comments, sorting options, etc. IP.Content takes all of this legwork out of the picture by providing it for you with just a few clicks in your admin control panel. But there's always room to improve! We have focused on some small but useful tweaks and improvements to the core database features that we think will benefit everyone. Specify The Text IP.Content databases refer to stored entries as "records". This is a generic term that can be used for just about any database, which is why we chose to use this originally. It is understandable, however, that some of you want to personalize the interface a bit more. "Records" isn't exactly the clearest term in all cases to all users, so it makes sense that you might want to refer to the entries as "articles," "pets," or "recipes", for instance. With IP.Content 2.0 you will be able to define the text bit to use to represent "records" in a database right from the database configuration form in the ACP. Four fields will be presented to allow you to define the singular and plural versions of the words in both lower-cased, and first-letter-capitalized versions. I know this probably reads a little confusing, but basically it allows you to define "record", "records", "Record" and "Records" independently. While PHP has many useful functions that can handle this just fine for the English language, in an effort to better-support our international customers we felt it prudent to allow you to define all of these versions of the word yourself. Specify The Content In IP.Content 1.x we provided an option on the database configuration page to allow you to indicate which field represents the "title" of a record. Because databases are so configurable, we needed to give you a way to specify this field so it can be re-used properly throughout IP.Content. In IP.Content 2.0, you will now also specify which field represents the "body" or "content" of a record. Some databases may have no use for this, but if you are setting up a database of articles, you will surely want to specify which field represents the "content". This designation is then used to determine which field to show as the "body" in a database feed, and in our next new feature we'll talk about... RSS Feeds Yes, you can now allow automatically generated RSS feeds in your IP.Content databases. Even better, RSS feeds are supported at both the database and the category level, automatically. You can also disable RSS feeds individually on a per-category level, should you wish to. This is useful if you have a private staff-only category of articles, for instance, which you do not want to publish via RSS with the rest of the articles in the database. Settings have been added to both the database and the category configuration forms to enable/disable RSS feeds, specify how long (if at all) you wish to cache the feeds, and to specify how many records to include in the feed. The category configuration form also has a setting to exclude it from the global RSS feed, as mentioned previously. Feeds are cached, if configured to do so, for performance reasons. Duplicated Sort Form In the ACP record management screen, we have duplicated the sort/filter form to the top of the page. If you have a lot of record management duties to perform in the ACP, this can help you to more quickly drill down to find the records you need to work on by eliminating the need to scroll to the bottom of the screen each time you wish to change the returned records. We have also added a "Save and Reload" button to the record add/edit form. You can stop with the PMs now Ditchmonkey! :lol: Save and Reload We've added a button to the add/edit record form in the ACP that will allow you to "Save and Reload" the record. If you are making may small changes to a record (for instance, you want to refresh the record on the front end to verify how it's displaying), this is useful as it will save your changes, and then immediately reload the form so you can continue editing the record, instead of forcing you to save, find the record, and click edit on it again to bring the form back up. Meta Tags Configuration fields have been added to the database and category forms in the ACP to allow you to define your meta keyword and description tags for your databases and categories. For records, meta tags by default will be automatically determined, just the same as happens in topics in the forum. You can, however, also manually override the meta tags on a per-record basis from the ACP by editing the record, should you need to. Display Subcategories Similar to how the board index will list subcategories underneath their parent forums, IP.Content 2.0 will now (by default) display subcategories of a category underneath the category title when viewing categories. And more to come! These are just a few of the changes we've made to the databases system in IP.Content 2.0 that we believe will make your databases more useful, more configurable, and more "your own". The changes better integrate IP.Content with the forums, providing a more seamless feel to the site, while at the same time enhancing IP.Content-specific functionality to let you better control your content. Be sure to stay tuned for our future updates on IP.Content 2.0! We have a lot of other useful changes in store you'll surely want to take advantage of. View full blog entry

IP.Content 1.x has turned out to be a very solid, stable, and extensible application, allowing for a vastly diverse number of implementations that showcase many of it's capabilities. We're thrilled to see so many of our customers using IP.Content in different and creative ways. We've been gathering feedback from all of you to help shape the future of IP.Content, and to that end we want to share with you some changes you can expect to see in IP.Content 2.0. Feed Blocks Feed blocks are a very powerful tool in IP.Content. You can create blocks that feed data from any application in IP.Board (that supports IP.Content), as well as from any RSS feed. In fact, much of the data you will want to show on IP.Content pages is easily returned through a feed block (latest gallery images, recent topics, top posters, etc.) of one kind or another. With each release we put some effort into improving the feed blocks further to make them as useful as possible. Database Comments Some of you have requested a new feed block type that will allow you to pull database comments from IP.Content databases, and IP.Content 2.0 will now feature this capability. Some practical uses for such a feed type include a "Latest Article Comments" block, or a "Comments Awaiting Approval" block for moderators. Use your imagination, and let IP.Content do the rest. Forum Feed: Honor Permissions Presently in IP.Content, if you create a feed block and restrict the forums that content can be pulled from, the topics and/or posts are pulled, regardless of whether the user has permission to view the content. This was done by design, to allow you to have a hidden forum for news entries (for example) and still feed this to your home page. Some users have requested that we allow them to honor a user's view permissions when filtering content by forum, however, and this will now be supported in IP.Content 2.0. When creating a feed from the forums, there will be a checkbox to allow you to honor the forum permissions, and only content a user is able to see will be returned. This only impacts forum feeds where you have explicitly restricted which forums to pull content from (if you do not restrict the forums that content can be pulled from, the user's view permissions are already honored). Filtering Database Feeds Database feeds were implemented in IP.Content 1.x, however the filtering options are relatively restrictive. It is logical that some of you may want to restrict records returned in a database feed based on custom fields, providing you with more opportunities to define the parameters used to determine what content to display. With IP.Content 2.0, you will now be able to restrict database feeds to filter content based on most of your custom fields (the same ones you can use to sort/search within a database presently). You will be able to define up to 5 custom filters based on your custom fields. This opens up many opportunities for you to introduce creative new database feed blocks on your site. Gallery Feed Improvements Virtually everyone creating Gallery feed blocks will ultimately want to display the image thumbnail. While this is entirely possible in the current version of IP.Content, it requires you to add some code to your template manually; code that everyone ends up adding. To make Gallery feeds easier to use for everyone, the code to generate the image thumbnail is now automatically executed in the feed, and the thumbnail is available to the template as $r['thumbnail']. Additionally, we've added a new filter setting under the category multi-select box. Enabling this new checkbox will tell the feed to also check in any albums (that the user has permission to view) under the selected categories. This means you could, for example, select the Member's Gallery and check this checkbox, and not have to manually select every album contained within the Member's Gallery (and it also means you won't have to continuously edit the block configuration to continue selecting new albums as they are created). And a few other tweaks In addition to the changes above, we've been going through some of the feed blocks to try better respect the returned data you expect to see. For instance, in a topic feed, the last_poster_id can sometimes be the last poster id in the forum, rather than the topic. We're taking some time to try to normalize the data returned from feed blocks so that you have better access to the data you want to use. And a lot more to come... We have a lot more in the pipelines for IP.Content 2.0 as well, and we can't wait to reveal what else we've got up our sleeves. We're hard at work improving the interface, performance, and usability of the system, and we are taking all received feedback into account while we work to make IP.Content the best tool of it's kind! We're very proud of IP.Content and hope that you are enjoying it so far. If you have any features you're just dying to see included, please be sure to post them in the feature suggestions forum. Similarly, if you have any questions or feedback about the changes discussed in this blog, please feel free to leave your comments. What we've discussed here is just the tip of the iceburg. We think you'll be even more excited to hear what else we've got in store when we roll out our next blog entry. Stay tuned! View full blog entry

We'll keep this blog entry short and sweet, since there's not a whole lot to say. Developers have asked for further documentation of IP.Board (and addon applications), specifically source code-level documentation of the various classes and methods that can be reused. Those of you familiar with phpdoc will know that it's the perfect tool for the job, and thankfully we wrote IP.Board 3 using phpdoc-style comments to facilitate this job. After a lot of cleanup and tweaking, we have made the phpdoc developer documentation available for all. Please be aware that this is the first "release" of these documents, and there are likely going to be some oddities and under-documented functions. Please let us know where we can expand on the documents. We intend to add more code examples and to clean up the class-level documentation a little over time, but if you have any specific requests we'll focus on those first. http://community.invisionpower.com/resources/phpdocs/index.html View full blog entry

It's a well-known fact that one method of ensuring continued visitation of your site is to email members frequently to send reminders and notifications. For instance, if a user posts in a topic, they may forget that they posted after a day or two. If an email is sent to that user after someone else replies, however, it can remind the original user to return to your site to check on the updates. IP.Board has a strong system of notifications, however we found that much of the code to handle this is scattered and duplicated throughout many files in IP.Board 3.0. The methods of managing your notification preferences are also inconsistent, making it confusing and difficult for new users to determine how to control notification preferences. If you are a moderator, you manage your report center notification preferences in the report center. You are only able to get email notifications of tracked topics. You can select to get email or PM notification of new comments and friend requests in your user control panel. Through these few examples, you can see that managing notification preferences can be made easier. IP.Board 3.1 introduces many improvements to notifications, both on the backend and within the user interface of the board itself. Inline Notifications In overhauling the notification management options in IP.Board 3.1, we decided to add inline notifications. Essentially, this is a notification within the board itself, without actually issuing a private message or an email. There are many instances where a visitor might want to be notified of an action, but might not want an email to be sent to their email address, or they might not want a private message for such notifications (especially if your board has limits on the number of private messages an individual can store). Visually, when an inline notification is first triggered, it will look identical to the existing private message popup. In fact, private messages no longer directly initiate the popup you have become familiar with - instead, they issue an inline notification (which initiates this popup). This was done on purpose for consistency, and for code reduction and reuse purposes. A "Mark Read" button has been added to the popup so that, in addition to closing or viewing the notification, you can mark it as being acknowledged without having to leave the page. A new option has been added to the profile dropdown to allow users to quickly access their inline notifications, as well. Administrators can control how many inline notifications a single user can store on a per-group basis. If a user is allowed to store 50 inline notifications, and notification number 51 is issued, the user's oldest notification is automatically pruned. The user will see a notification popup on the board the next time they click a link. There is also an area in the user control panel where each user can list, view and prune their notifications. Additionally, a new board index hook will show up when a user has unread notifications (and automatically disappear once all of their notifications have been acknowledged). Stronger control of notifications A new area of the ACP has been added to allow administrators to better control notifications as well. Any registered notification events will be listed, and the administrator can control which methods to use by default for each notification event, which methods cannot be used at all, and will also have the ability to disallow users from overriding the admin-defined selection. For example, an administrator might want the default notification method for new private messages to be inline notifications (show a popup on the board). Administrators may also want to disallow users from electing to get an email notification when comments are made on their profile to reduce the number of email messages sent from the server. An administrator may also want to enforce that all users (with appropriate permissions) get an email notification when content on the board is reported. All of these things, previously not possible, can be configured from one page within the ACP of IP.Board 3.1. Easier user configuration options In addition to the new UserCP page to view your inline notifications, there is a new notifications page where all notification settings and options have been consolidated. New configuration options are available to control your notification preferences, as well. Each user will be able to select whether they want to receive email, PM, or inline notifications (or a combination of the above, or none of the above) for each notification event from one page. Methods that are not available per the ACP-defined preferences are removed from the user's options, while notification events that an administrator does not allow users to override are disabled but still displayed (so that a user can know how they will be notified when one of those events occur). A couple of screenshots should help clarify this. If an administrator makes the following configuration in the ACP A user can expect to see the following in their notification preferences You'll also note from these last 2 screenshots that we've added the ability to get notified when someone quotes a post that you made. Easier for developers IP.Board 3.0 has well-abstracted code to make sending private messages and emails easy for developers. While this is true, code is duplicated throughout IP.Board 3.0 that is meant to handle sending either PM or email notifications. As a general rule, duplicated code is not a good thing to have. We also had to find a way to easily implement inline notifications (without adding yet more if/else style statements everywhere that sends notifications). We have created a new notifications class which developers can easily use to allow third-party applications to plugin to the new notifications system. This reduces the workload needed to set up notification capabilities (and management) for new applications significantly. A developer will first need to create a plugin file for their application to define notification events. A sample plugin file might look like this /** * Notification types */ $_NOTIFY = array( array( 'key' => 'report_center', 'default' => array( 'email' ), 'disabled' => array() ), ); <?php (Yes, this is the actual code for the "core" application of IPB to handle report center notifications). You define the default selections, and the options to disable by default. For example, you would not want a private message to issue a new notification by private message. This allows the developers to define the default handling of notifications for their applications. Then, to send a notification, the following code can be used // Notifications library //----------------------------------------- $classToLoad = IPSLib::loadLibrary( IPS_ROOT_PATH . '/sources/classes/member/notifications.php', 'notifications' ); $notifyLibrary = new $classToLoad( $this->registry ); $notifyLibrary->setMember( $user ); $notifyLibrary->setFrom( $this->memberData ); $notifyLibrary->setNotificationKey( 'report_center' ); $notifyLibrary->setNotificationText( 'This is the text to show to the user' ); $notifyLibrary->setNotificationTitle( 'This is the title of the notification' ); try { $notifyLibrary->sendNotification(); } catch( Exception $e ){} //----------------------------------------- The most common implementation will be to use the email library to first "build" an email, and then to assign the subject as the title, and the message as the text. As you can see, however, it is quite easy to use the notifications class. The class itself will determine what the administrator has defined as being allowed and disallowed, and what the user has selected for their notification preferences, and issue all appropriate notifications automatically based on the ACP and user preference selections. You don't have to worry about ACP settings or user cp settings either, using this method. All of it is taken care for you! Closing Through implementing the new notification capabilities, we hope to be able to expand the notification capabilities in IP.Board easier in future versions. As you can see, we've already added one more area where a user can get notified of changes in activity, and have some ideas of other areas where we would like to have the ability to issue notifications as well. With the refactored code and easier configuration management, implementing these changes will be easy. Also, please keep in mind that the screenshots you are seeing are very early screenshots taken of a development build. Rikki hasn't had a chance to put his magic touch on these pages, so most likely the final look and feel will be touched up a bit. We just wanted to share the new capabilities, complete with some screenshots to help you visualize them, as soon as we possibly could. Please let us know if you have any suggestions or feedback about the new feature. View full blog entry

As we near the release of IP.Downloads 2.1.0, we wanted to take a moment just to summarize the changes in this release and to point out the new features you can expect to see upon updating. Friendly URLs Friendly URLs have been implemented into IP.Downloads starting with version 2.1. Ability to shut off "Resume breakpoints" Most download accelerator clients support downloading multiple pieces of a file simultaneously. While this means that the file can download faster for the user, it also means that you can have multiple connections open from one user downloading a single file. Beginning with IP.Downloads 2.1 you can disallow requests for individual file parts to help control the number of open connections to your server. Download sessions Beginning with IP.Downloads 2.1, you can enable functionality that will cause IP.Downloads to create a unique URL for each file download request. The URL will expire once used (or after 24 hours, whichever comes first), helping to prevent users from sharing direct download links to the files. Global settings IP.Downloads 2.1 will allow you to configure maximum file size and screenshot dimension settings globally, while still allowing you to override those settings on a per-category level should you need to. This can help simplify updates to your download manager configuration for these particular settings which are commonly configured the same across all categories. Support for link "types" When submitting screenshot and file links, you will now be able to select what type of link you are submitting. The link types are configurable in the ACP so administrators can add and alter link types to better suit their site. Upload progress meter Through integration with the flash uploader used for uploading attachments to IP.Board posts, the download manager now supports a true progress bar for all uploads (if the user is using the Flash uploader as specified in their user control panel). One record, many files To date, IP.Downloads was designed to allow you to submit one file at a time (and one screenshot, depending on the configuration). IP.Downloads 2.1 takes the next step and allows you to submit multiple files and multiple screenshots per record. Interface updates The interface for the download manager has been tweaked and updated to provide a more polished feel, while distinguishing the user interface from the rest of the board. Wrap Up The primary focus of IP.Downloads 2.1 was expansion of the file storage methods to include support for important new functionality: multiple files per record and support for the flash uploader tool used by IP.Board. To that end, we decided to focus development on this core functionality in order to provide a solid foundation for future functionality changes in IP.Downloads. We hope you find the updates useful, and we look forward to your feedback to continue improving the product. View full blog entry

Earlier this week we discussed some of the changes you can expect to see with regards to search engine optimization in IP.Board 3.1. Mostly, the changes are basic tweaks that will have great impact. These are the best kinds of changes. Based on the feedback received, we've implemented a few other changes related to optimization of your site for visiting search engines. As before, most of these changes are pretty basic. In the end, the goal is to help streamline your site for purposes of search engine indexing. We want to promote the content that is valuable and worth indexing, de-emphasize the content that isn't, and overall adhere to common industry standards and protocols for purposes of ensuring IP.Board does everything it should to help your site position appropriately. Removal of a setting We have removed the "Use 301 for friendly URL redirects" setting from the ACP. After reviewing the functionality and purpose of this setting, we have decided it is unnecessary. If you enable friendly URLs and decide to redirect the wrong urls to the correct friendly URL version, you will always want to use a 301 header. By removing the setting, we have effectively hard-coded this to "Yes". The purpose of this is to remove unnecessary options, in favor of presenting you with the options that truly are important for optimizing your site. Centralize SEO-related settings We have created a new "Search Engine Optimization" setting group in the ACP to better pull out and separate settings meant for this purpose. We have moved the existing friendly URL settings to this new setting group, and have added some other new settings we will discuss later on in this blog entry. Addition of "canonical" meta tag for board index This is an addition we feel is very important and beneficial. A "canonical" meta tag identifies the proper URL for a webpage to a search engine spider. For instance, all of the following urls will load the IP.Board forum index http://yoursitehere.com/forums http://yoursitehere.com/forums/index http://yoursitehere.com/forums/index.php http://yoursitehere.com/forums/index.php? http://yoursitehere.com/forums/index.php?act=idx http://yoursitehere.com/forums/ There are many other variations that will do the same. But which one is correct? How can a spider know which version to index, or should it index them all? At the end of the day, they are all different urls, and can potentially be treated differently by a search engine spider. With dynamic software, such as IP.Board, it is often difficult to ensure that the URL used to reach a page is the "correct" version and to redirect appropriately. It is not difficult, however, to tell a search engine which version of the URL SHOULD be used. When a search engine reaches the board index page in IP.Board 3.1, through any URL listed above, or any other variation not listed, the canonical tag will instruct the spider to use one specific version of the URL for that given page. This will help consolidate inbound link weight to the single/correct version of the page, and consolidate duplicate results in search engine listings to the single/correct version of the page. More improvements for the board index Many users have requested that we provide a way for them to specify the page title to be used on the board index page. The board index page is going to be the most important page of your forums (in the eyes of a search engine spider), and having complete control over the page title is important. Prior to IP.Board 3.1, the "Board Name" setting was used for the board index page title. This works well for many users, however it is also appended to the end of the page title for many other pages, so depending upon your specific needs, you may want to use different text for the two locations. IP.Board 3.1 has a setting to allow you to change the page title for the board index page specifically. If left blank, the board name will be be used, just as with previous versions. Additionally, we have added settings to allow you to specify the meta keywords and meta description tag values in the new Search Engine Optimization setting group mentioned earlier. The end result is that you now have much more control over SEO aspects of your board index, arguably the most important page of the forums for search engine spiders. De-emphasize unimportant pages IP.Board 3.1 will now issue a meta robots tag with the value "noindex" for some common non-content pages. Examples include the login page, the register page, and the lost password request page. The purpose of the tag is to suggest to the search engine not to index the page at all. Every IP.Board installation on the internet will have effectively the same login, registration and lost password pages, and these pages have no valuable content that search engine spiders want to index anyways. By de-emphasizing unimportant pages, more emphasis is placed on the content-heavy pages we want search engine spiders to spend their time on. Wrap up We've got some more feedback and suggestions we would like to take into account and implement in a future version of IP.Board, however we feel that for 3.1 we've taken the most important changes that do not require many invasive core changes to the software and implemented them in a manner that will benefit customers the most. We are working hard to ensure we've done our part to help your forum stand out from the crowd, and are confident that the changes made to IP.Board will have actual, useful benefits to your forum with regards to search engine indexing. View full blog entry

Many of our customers have expressed interest in optimizing their forums for search engines, and to that end IPB 3.0 introduced many great features to facilitate this. You may recall from our blog entries leading up to 3.0 that we introduced friendly urls, canonical tag, dynamic meta tag support, and many other useful changes to make indexing your website easier for search engine spiders. Here are a few blog entries detailing the new features in IP.Board 3.0. IP.Board 3: Friendly URL Enhancements IP.Board 3.0 Search Engine Optimization IP.Board 3: Friendly URLs at last! For IP.Board 3.1 we have consulted with an industry specialist to determine some areas of IP.Board where we can optimize the software to better adhere to standards and facilitate easier discovery of content. By making some minor changes to how the software behaves, we can help search engine spiders more easily index your forums, and more easily filter out content that should not be indexed. Appropriate header codes for errors Error pages do not need to be indexed by search engine spiders, as they provide no real content that one would expect to search for using a traditional search engine. We have changed IP.Board 3.1 to issue a 500 header code ("Internal Server Error") for most generic error messages. Errors that are indicating the user does not have appropriate permissions will now be delivered with a "403 Forbidden" header code, while error messages that indicate the content could not be found (i.e. an invalid topic id) will issue a "404 Not Found" header code. By using more appropriate header codes, search engines will more easily be able to identify that certain pages should not be indexed, as they are true errors. The infamous "icon" alt attribute XHTML Strict standards dictate that an alt attribute must be supplied with every image. The idea is that the alt attribute can be read by screen readers and other assistive technology (as well as by search engine spiders) to better identify what an image represents. Many images in IP.Board are used merely for visual "eye candy" purposes and don't have specific meaning. The title attribute used for anchor tags wrapping the images is more than sufficient to dictate what the link itself is used for, while the image is routinely nothing more than an icon used in place of text to look nicer. As such, IP.Board 3.0 frequently used "icon" as an alt attribute for many images, because that is what the image was. However, search engine spiders are seeing this as an increasingly relevant term on many IP.Board forums as a result, when clearly many (if not most) forums are not really about "icons". To that end, we have removed "icon" as an alt attribute (in some places, specifying no text as the alt attribute) to de-emphasize the unimportant term. We will be making similar tweaks to other textual and meta data on the page to better help search engines identify what is truly important within any given page. Cash in on social networking Social networking is all the craze these days. Love it or hate it, it is hard to deny that social networking is changing the landscape of the internet. Sites like Facebook and Twitter are serving millions and millions of users on a daily basis, making them excellent places to promote your own website to garner interest and put out word of mouth advertising for free. While IP.Board 3.0 already supports Facebook Connect out of the box, making it easy for users with a Facebook account to simply login to your site using their Facebook credentials, we decided we wanted to do something more for IP.Board 3.1. Pulling IN content is great, but pushing OUT content is even better. IP.Board 3.1 will feature buttons when viewing a topic that will allow you to quickly push out any given post to Twitter and/or Facebook, making it easier for you and your members to share specific content on your website with large audiences. What's great about this is that this sort of content sharing is much more targetted than generic advertising. If a member shares a specific post on his Facebook "wall", it's much more likely that his friends and colleagues will be interested in the content, and more prone to following the link to your website, than an advertisement block on a random website, or within search engine result listings. Friends and colleagues often share similar interests, after all. Even more to come While we feel the above changes are simple but useful tweaks to the existing software, there are some more similarly simple changes we intend to implement to IP.Board 3.1 in order to better position your site to stand out from the crowd. We hope that you feel, as we do, that these improvements will only improve your site, both for search engines, and for your actual users. View full blog entry