bfarber

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

Please use the peer to peer forums for help with such things.

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

Please use the peer to peer forums, or submit a ticket, if you need help with features in the software. This forum is for feature suggestions.

We don't generally respond to most feedback with status updates I'm afraid. We just don't have enough time to respond to everything unfortunately.

I don't know why you were negative repped, wasn't me. :)

The reason is due to a technicality in a feature on the profile, specifically the posts per day statistic and percent of total forum posts. What if your board has one forum that increments posts, and one that doesn't. The total count doesn't care which forums increment user post counts and which don't (this is by design), so say you have 10 total posts on the forum. One user posted 5 topics in the forum that increments post counts, and one posted 5 in the forum that doesn't. For the user that posted in the forum that doesn't increment post counts, he'd have (if we only showed the post count on the profile that increments) 0 posts ( 5 posts per day / 50% of forum total) How could have 0 posts, but 50% of the total posts on the forum)? OR, he could have 0 posts ( 0 posts per day / 0% of forum total) However, then when you look at the forums itself, this user actually does have 50% of the total of course. No matter what route we go here, it's going to be confusing.

Not sure what you mean. This is a feature suggestions forum, and we don't respond to every single post made in the forum. Even still, one of the developers DID respond once already. You should not expect "answers" to topics in this forum. We read the suggestions, then gauge demand for new functionality.

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

To be fair, every vbulletin user switching to IPB has their own expectations and requirements (I've seen some say they won't switch without a "topic preview on hover" capability, for instance, without ever mentioning this sort of functionality). You're making a pretty blanket statement there. :P This suggestion *has* come up before, but in the 5 or so years I've been here, it's only been a relatively few number of times, and has never really gained a lot of backing or traction amongst our customer base. I don't see any harm in having it as an option, but this particular setting isn't really like the magic thing IPB needs or anything like that. :P

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

Exactly. Though I'd argue that a poll isn't necessary. I tend to look at reputation points quite a bit when looking at suggestions, as it's perfect for that sort of thing. Thumbs up or thumbs down, do you want suggested feature x or not.

This may seem counter-productive, but honestly - going through a 20 page topic with 1000 different features suggested is actually *harder* for us than going through individual topics about single features. As a whole, "post all different feature suggestions in one topic" topics aren't as useful as posting separate feature suggestions. I see no need to "copy" suggestions over from other topics into some master topic such as this one. Just a heads up. I can tell you, if there's some feature suggestion on page 13 in a 20 page topic, it's VERY easy to get overlooked, compared to it having it's own separate topic...

The skin system itself has some limitations at present, as I explained previously, providing multiple "default" skins. The system needs some tweaks to better handle this, which Matt said he was planning to implement in 3.1. This is why the mobile skin is waiting. The mobile skin has already been put into the 3.1 package and will be available with 3.1.

That is one opinion, and we've gone down the "x skin is better than y skin" in another topic already. :)

We can't speculate on the release date I'm afraid. It will be released when we feel it is ready.

I apologize for any misinformation you were given. Most likely the representative you asked about the skin confused it with the community skins (Classic Blue, Pro, etc.). I would love to answer your questions, but I simply don't have any answers. I don't know what the status is. I do know that I updated the skin in the client area the same day Ehren posted it in the customer lounge, so the "official" copy you can get from the client area is the latest copy released. As I recall, it's under IP.Board Development Releases category. We're not ignoring the skin, forgetting it completely, etc. I suspect it's just being left on the backburner until Matt makes some needed changes to the skin system for 3.1 to properly protected "root" skins. I'll see if anyone has any more information today they can share.