bfarber

There is nothing immediately on the horizon with regards to such a feature.

I've been trying to tweak "recent posts" bit by bit over several IP.Content releases. On average it should run pretty good on an average sized site. I would still not recommend setting one up on a large site, however.

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

If there's an updated version of minify that works with IPB and fixes other issues elsewhere, I'm happy upgrading the version of minify we ship with.

Please use the peer to peer forums for support. The modification is no longer needed in 3.0.x. You just need to add a config parameter to your conf_global.php file.

Click the blog tab once in My Settings to see Blog and Entry tracker pages.

Click My Settings, then click the Forums tab. "Manage Watched Topics" and "Manage Watched Forums" http://community.invisionpower.com/index.php?app=core&module=usercp&tab=forums&area=topicsubs http://community.invisionpower.com/index.php?app=core&module=usercp&tab=forums&area=forumsubs Ah, I use FF usually. I'd submit that as a bug report in that case.

This can be done via IP.Content and via the built in Portal, depending on your specific needs. Can you clarify this one? What needs to be made easier exactly? You can already edit posts inline using AJAX. Or were you meaning something else? It already works this way. I use that functionality all the time in fact.

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

We did post details. We will post information in parts - not everything is done, so there's no realistic way we can post everything 3.1 will feature. The SEO changes posted are done, so we were able to blog about them. As we finish up functionality for IPB 3.1, we will relay the information to everyone.

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

I would recommend submitting a bug report in that case. Something must have broke at some point.

When a new action overloader is installed in the ACP, IPB loops through the existing hooks installed, and resets the "extends" part of the class definition appropriately. Say you have 1 hook installed that's like class myhook extends public_forums_forums_topics Then you install another hook that's class metoo extends public_forums_forums_topics When IPB goes to write the hook .php files to the hooks folder, it should actually change that second file to be class metoo extends myhook Then we instantiate metoo

We do use Nexus, and it does have weighting. Lindy was saying that when a reply is made to a ticket, it doesn't kick it to the end of the queue.

Not content just sitting back and letting our latest product IP.Content stagnate, I've been hard at work getting version 1.2.0 ready for everyone very soon. In the mean time, I wanted to put up a blog entry to discuss some of the changes you will see with this new release. Field default values There is now a per-field option to define the default value for the field. This default value will be used when the "add new record" form is displayed as the default value to place in the field. The user can still, of course, change this value while configuring their record. Disable fields in listing and display templates Many have requested a method of disabling specific fields from displaying in listing and display templates without having to modify the default templates (i.e. to exclude certain fields in the foreach loop, or to manually define the layout). As of 1.2.0 there are two new settings when configuring your fields to do just that. If you disable a field in the listing template, it simply won't show up there. You can even disable a field in the listing and display template and have a hidden field attached to the record, if you wish. Additional sorting for database feeds You will now be able to sort database feeds by meta-data fields (record id, last updated, submitted date, comment count, etc.). This will allow you to more easily create database feeds to show latest records, for instance. Text formatting options for text input fields There are now per-field settings on text-input fields (only) to allow you to define the following automatic formatting options: Capitalize all lettersLower-case all lettersCapitalize just the first letter of the stringCapitalize the first letter of each word in the stringRemove excess punctuation You can mix and match, using more than one option, but of course some options will have no effect when used together (i.e. capitalize all letters, and lower-case all letters). Attachment parsing for forum and blog feeds Attachment parsing has been added for forum and blog feeds (provided you do not use the default strip tags and truncate calls in the template for the content value). Attachment data available programatically Some users have expressed interest in having access to attachment data in a more robust manner than simply passing the field through the IP.Content attachment parser. For instance, you may want to display 1 image from an attachment field in the listing, without having to worry about whether there are more than 1 images associated with the field. Attachment data has now been added to a global cache during normal parsing routines, so that you may be able to programatically access the attachment data for the record and do more unique things with the data. A resource article on how to access this data will be forthcoming following the release. WYSIWYG and Code Highlighter Support We have added support into IP.Content to integrate with the following WYSIWYG and Code Editors: TinyMCECKEditorCodePressEditArea(None/default textarea) You can select which editor interface you would like to use (be careful using WYSIWYG editors when editing certain content, as they will strip special tags) and the editor will be available when editing templates and content throughout the ACP. Even better, the code highlighters will be "smart" and recognize what type of content you are editing (javascript, css, html or php, depending on the block, template or page details). If you have a favorite editor that you would like to see integrated let us know. We've designed the system to make it easy to drop in (and remove) editor types as needed, so if we can integrate with your favorite editor, we're happy to do so. The wrap up Undoubtedly you will notice that most of these features aren't big features, however we feel they will be extremely useful and relevant features as members continue to explore IP.Content and how to use the software to enhance their websites. Every feature listed above was requested by you (our customers), and were culled from tickets, feature request topics, and support topics in the peer to peer forums. Keep on suggesting things you would like to see in IP.Content, and we'll do our best to get those features in place appropriately! View full blog entry

this is why :) It may be confusing to you at first, but it actually gives you more control. We thought about removing the legacy banned group, but determined there would be sufficient interest in being able to manage members in more than one manner. Different strokes for different folks and all that. ;)

4 days without a response? That shouldn't happen - can you PM me the ticket ID please?