bfarber's Content - Page 60 - Invision Community

4.0 - Handling email

bfarber posted a blog entry in Invision Community

Sending email is an important part of almost any web software available today. Social Suite applications have varying needs for sending email. Examples include allowing users to confirm their email address during registration, advising users when there are updates regarding content they are following, and bulk mailing your member base to alert them to something important regarding your site. While functionally the email handler has not significantly changed in 4.0, the process has been vastly simplified, allowing you to send more consistent emails with far less code than in the past. Building and sending emails When sending email in the Social Suite, there are two primary types of email you might need to send: an email based on a pre-existing template that you swap out variables in, and a completely custom email where you define the body specifically for the current email being sent. Both of these scenarios are accounted for. First, let's take a look at the simpler and more common scenario where you send an email based on a template. IPSEmail::buildFromTemplate( 'core', 'admin_spammer', array( $this ) )->send( IPSSettings::i()->email_in ); Here, we are building an email from a template ("admin_spammer" in the "core" application, more on that in a moment), passing the current object in for purposes of replacing out variables in the template, and then calling the send method to actually send the email, passing the recipient to it. The buildFromTemplate() method is a factory method that will create a new object of type IPSEmail. When calling the send() method, you can optionally pass a single email address to send the email too, an array of email addresses to send the email to, or a single instance of IPSMember or an array of IPSMember instances to send the email to. The library takes care of the rest. The other type of email you may need to send is a completely custom email where you define the entire body without using a template. Bulk mails are a good example of this type of email. You can easily send these types of emails as well. $email = IPSEmail::buildFromContent( $subject, $htmlBody, $plaintextBody ); $email->from = "john@doe.com"; $email->send( "jane@doe.com" ); Here we call the factory method buildFromContent(), passing in the email subject, the HTML email body, and the plain text email body. You can optionally omit the plain text email body and it will be generated for you automatically. We then specify the from address (which defaults to the suite's outgoing email address), and finally we call the send() method, passing in an email address. While it is not recommended, you can create an email object without specifying either email body parameter, and specify these later if you have a need. Further control and options Beyond what is outlined above, you have fine-grain control over the details of the email being sent. The following example outlines more of the possible values you can specify when necessary $email = IPSEmail::buildFromContent( "Hello world" ); $email->from = "john@doe.com"; $email->fromName = "John Doe"; $email->subject = "Changed my mind to hello planet"; $email->useWrapper = FALSE; $email->headers['X-Mailer'] = "My cool app"; $email->headers['Priority'] = 3; $email->setBody( array( 'html' => "<html><body><b>My email</b></body></html>", 'plain' => "My email" ) ); $email->send( array( "jane@doe.com", "janet@doe.com" ), array( "abc@abc.com" ), array( "test@test.com" ) ); Most of the above should be self-explanatory. Just a few quick notes: You can set the $useWrapper property to FALSE if you do not wish for the email to be wrapped in the standard default HTML and plaintext email wrappers. The wrappers primarily define the HTML structure (doctype, html tag, etc.) and also allow for automatic definition of the unsubscribe link. You can call the $unsubscribe property to manually define an unsubscribe link and the text to display. Alternatively, you can call the "buildUnsubscribe()" method (see below) to do this automatically and consistently. There is no point in doing this if you do not use the wrapper, however, which is why it is omitted in the example above (in this case you should manually include an unsubscribe link if appropriate). The first parameter passed to the send() method is the to addresses. The second is the CC addresses, and the third is the BCC addresses, if necessary. Automatically handling an unsubscribe link Links to handle unsubscribing from emails can be accommodated automatically with emails sent through the email handler. For bulk emails, the following method is called $email->buildUnsubscribe( 'bulk', IPSMember::loggedIn() ); The first parameter is the 'type', which is 'bulk' in this case. The second parameter when specifying an unsubscribe link for a bulk email should be the member who is being emailed, as their personal details are used to generate a unique key allowing one-click unsubscribing. When sending notification emails, you still call buildUnsubscribe() with the following parameters $email->buildUnsubscribe( 'notification', 'my_notification_key' ); Instead of a one-click unsubscribe link being included, a link pointing to the user's notification preferences area will be included instead, highlighting the notification preference that caused the email to be sent. Unsubscribe links are only automatically included in the outgoing email if you (1) call this method, and (2) use the default wrappers. Email templates While we will touch on this further in a future blog entry, email templates are now defined in a similar manner to HTML templates, and there is one template for the HTML version of the email and one template for the plaintext version of the email. This allows us to better tailor the email being sent dependent upon the content-type in order to provide the nicest experience for the user. The email subject is a language string based upon the email template name and is determined automatically by the email library when buildFromTemplate() is called. Wrapping Up While the email library still provides plenty of control to accomodate almost any scenario encountered within the Social Suite, for day to day needs the interface to send emails has been vastly simplified in order to provide a more consistent experience for both the user and the developers integrating applications within the Suite. We hope you find these small changes will make your jobs easier, without losing the control you have presently.

Spam Service Updates

bfarber posted a blog entry in Invision Community

Our proprietary Spam Service which was launched in 2009 has been a very popular feature for IP.Board license holders. This service (which is included at no additional cost for all active license holders) is queried during account registration on your IP.Board installation and will respond to the query with a flag to indicate the likelihood that the registration might be a spammer. You can control how your site should react to the various responses the service may return in the admin control panel, and combined with other anti-spam tools in IP.Board you can help prevent spam registrations from occurring on your site. While the system is constantly "learning" and blocking new spam signups, we have performed some updates to the service recently that we feel will help the system respond even quicker and more reliably to spam account registrations. First, Some Stats For those interested, we have some interesting statistics to share with you. To date, the spam service has responded to over 58 million requests! The service has responded to almost 163,000 requests in the last 24 hours alone, and the service continues to respond to between 5,000 and 10,000 more requests day over day. A total of over 23 million user registrations have been blocked (i.e. a status code of 3 or 4 was returned by the spam service) to date. That's 23 million spammers we've helped you prevent from disrupting your community. Quicker Responses With the recent updates we performed, the system will more quickly respond to new spammer accounts than it did previously. It is important that the system do not treat a single report of a spammer as a permanent block on that account of course, however we identified several areas where the algorithms used could be tweaked to more quickly identify potential spammers and have performed these changes. Additionally, by use of decaying flags (treating newer reports with a higher priority than older accounts), the system can more quickly respond to new spammer threats. Project Honeypot Integration We have integrated our spam service with the popular Project Honeypot service. This means that all account registrations are checked through Project Honeypot, and the threat score that is returned from this service is used to help determine the likelihood of the IP address being associated with a spammer. Stop Forum Spam Integration In addition to integration with Project Honeypot, we have integrated the IPS Spam Service with Stop Forum Spam. Our spam service will check the Stop Forum Spam email address and IP address databases and use any information found here to help weight and score the likelihood that the registration is coming from a spammer. It is important to note that we do not rely directly on the Stop Forum Spam data to determine a spammer status, but are instead using the data from this service to help weight the overall score based on all of the flags we have available. Enterprise Spam Mitigation If you are in a load balanced or cloud environment, you may wish to take advantage of this new offering which allows calls to the spam service from multiple origins using the same license key. Additionally, this service allows greater control over your spam mitigation service including weighting algorithm preferences and customized blacklists and whitelists. This addon service is available for $100/6 months. For more information, please contact our sales department. Collectively we feel the changes we have made to the service will benefit all IPS customers who are making use of our IPS Spam Service. We hope these changes help your community fight the threat of spam more rigorously and more reliably than ever before.

IP.Board 3.4.5 + all applications available for beta testing

bfarber posted a blog entry in Invision Community

The following applications are available for beta testing: IP.Board 3.4.5 IP.Blog 2.6.3 IP.Content 2.3.6 IP.Chat 1.4.4 IP.Downloads 2.5.4 IP.Gallery 5.0.5 IP.Nexus 1.5.8 IP.Calendar 3.3.4 This round of maintenance updates represents updates to all of our applications. At this point in time, there are zero open bug reports in our tracker (that are not flagged to be resolved in a future major version). We would like to encourage all interested users to perform as much testing of these apps as possible. We will be upgrading our company forums early this coming week. Please report any bugs you find with the beta to our bug tracker. Please pay particular attention to the following areas:The editor, both within IP.Board (topics/posts) and in other areas (such as IP.Content articles, IP.Blog entries, etc.). Pay attention both to the editor itself (i.e. when typing out and formatting your post, and toggling the editor back and forth) and the final post that is submitted. Rebuilding posts, specifically upon upgrading from an older version of the software. Pay attention specifically to quotes to be sure they display correctly. Any IP.Nexus functionality that has to do with grouped renewals. Cancelling packages where renewals are grouped, reactivating those packages, changing those packages, etc. If you find a bug, please be certain to report it to the bug tracker. When doing so, be sure to include as much information as possible that will allow us to reproduce the issue, including what browser you are using, what version of PHP is running on your server, whether this was an upgrade or a fresh installation, and so on. Screenshots are often helpful. As with all beta releases from IPS, these releases are not supported by our technicians until the official final releases are publicly available in our client center. Please do not upgrade your live installation using these betas, as you may find no path between these builds and the final releases that we put out. We recommended, instead, to create a copy of your live board as a test installation, and upgrade your test installation instead. All customers with active licenses can download the betas at: http://community.inv...ower.com/qa.php Thanks in advance! We look forward to your feedback.

IP.Board 3.4.4 available for beta testing

bfarber posted a blog entry in Invision Community

IP.Board 3.4.4 is now available for beta testing! We have been hard at work on IP.Board 3.4.4, and following a good week of testing here on our company forums, we have built a downloadable IP.Board 3.4.4 package for you to test on your own servers. We appreciate any testing you can perform. Please report any bugs you find with the beta to our bug tracker. Please pay particular attention to using the editor with IP.Board 3.4.4. A very large focus was placed on resolving some of the outstanding bugs and complaints with the editor, and we would appreciate any testing you can perform in this area. Create new posts, edit existing posts, toggle between the editor modes - if you find any bugs, let us know. As with all beta releases from IPS, IP.Board 3.4.4 is not supported by our technicians until it has been officially publicly released. Please do not upgrade your live installation using this beta, as you may find no path between this build and the final release that we put out. We recommended, instead, to create a copy of your live board as a test installation, and upgrade your test installation instead. All customers with an active IP.Board license can download the beta at: http://community.invisionpower.com/qa.php Thanks in advance! We look forward to your feedback.

Use a third party library/framework, or build it in-house?

bfarber posted a blog entry in Invision Community

One question I have seen surface in the past (and present), revolves around how we decide when to use a third party library or framework, and how we decide when to develop something in-house entirely. For instance, in the 4.0 Suite we will utilize jQuery (a third party javascript framework), however we will build our underlying PHP framework in-house. How did we decide to go that route? There are several PHP frameworks on the web, many of which having licenses compatible with our commercial license, so why didn't we choose one of those to kickstart 4.0 development? This is, admittedly, often a difficult question to answer. The truth is, we evaluate each scenario on a case-by-case basis and make decisions based on what is best for us and our clients. Sometimes these decisions may not be obvious, however you should know that much thought has gone on behind the scenes here at IPS to ensure we are making the choices that we feel are best for our products. Javascript frameworks are almost an essential tool with today's fast-paced browser development and web advances. Browser updates from some vendors are almost weekly. We went from HTML 4 to XHTML 1 to HTML 5 within but a few years. And while everything a javascript framework does can be replicated in-house, it would consume a lot of development time that we would have to spend in order to keep pace with all of these changes, purely for compatibility reasons (e.g. no new functionality added, just to keep things working and up to date). We have long-ago determined that using a well-maintained javascript framework to facilitate javascript development is virtually a necessity, otherwise you quickly get bogged down trying to maintain javascript code just to retain compatibility with current browsers and newly available functionality. What about PHP frameworks though? There are many out there (CodeIgniter, Zend Framework, etc.) and many are relatively robust, well tested and quite extensible. Why have we chosen to write our own underlying framework given this information? In researching whether to maintain our own framework or use an existing one, we had to weigh many pros and cons. For instance, one pro using third party PHP frameworks would be that we can skip all of the development of underlying classes (controllers, autoloaders, database connector and so forth) and jump into the higher level development. This is surely an important consideration to take into account. On the other hand, using third party PHP frameworks ties us into that framework, and we expect the underlying codebase in the 4.0 series to last several years once it is released. What if the framework we choose to utilize is no longer maintained 2 years from now? What if a security issue arises in the third party framework, but it is not rectified quickly? We certainly can't leave our clients vulnerable to known security vulnerabilities while we wait for a third party to patch it. What if the framework developers release an important update, but it renders APIs incompatible with our implementation of the framework? We could find ourselves in a situation where we either can't update the framework easily, or we would need to recode many of the underlying usages of the framework in order to update. Additionally, frameworks often have many, many capabilities, many which we may not need or use. This can make our release larger than it needs to be, and/or cause our software to consume more resources than it would otherwise, if those features which we aren't using were not present. Of course, licensing concerns are also present - we have to be certain that any third party code we use is released under a license that is compatible with our commercial license. Finally, if we utilized a third party PHP framework, we would either have to (1) rewrite ALL of our code (just think of every database query that may be run - these would need to be passed through the framework rather than through our own database driver), or (2) write an abstraction layer on top of the framework to translate the requests we currently send to low-level classes so that they are compatible with the framework. No easy task, either way. By writing our own framework we ultimately have better control of our software. We can tailor every class to our needs, ensuring that it is as efficient as possible within the confines of what we wish to accomplish, while still making these classes robust enough to handle everything we want to throw at it. We can ensure we do not have unnecessary classes and code, or features which aren't (and never will be) used. If a security issue is found, we have full control over the underlying code base and can address the issue quickly without waiting on a third party to release an update, or rewriting underlying API calls in our software if the framework changes how a class must be called. If we wish to implement new functionality, we can implement these changes directly in low-level classes efficiently. We do not have to work within the third party framework's design, artificially requiring us to utilize more resources (e.g. by extending a class vs implementing our changes into the base class to start with). By writing our own framework, we face the "con" of spending the time up front to develop all of these low level classes we will need, however we feel the "pros" that this affords us in the long run are worth the time and trouble. It is a decision every developer or development company has to make as they approach a product, and everyone has different view points. The take away here, however, should be that we have indeed looked into available options, weighed the pros and cons against our goals and needs, and have determined after careful evaluation that sometimes it is best to use an existing framework, and sometimes we just need to roll our own.

Some development decisions made prior to 4.0

bfarber posted a blog entry in Invision Community

Development is much more than just opening a text editor and writing some code. This is how most developers start, of course, and may be what an individual developer's day to day duties entail at a large corporation, however when viewing the "big picture" there are many other decisions that must be made in the course of building a software package for release that clients often don't realize were even considered. We thought you might be interested in hearing about some of those decisions that were made regarding 4.0, prior to ever writing a single line of code. Minimum Supported Versions One decision that has to be made relatively early in the development process is what dependencies will the software require. For software developed in PHP, this typically means what version of PHP will be the minimum, and (often) what will be the minimum required version of MySQL. PHP 5.3.0 was released in June of 2009, and includes functionality that we intend to utilize within the 4.0 Suite. Subsequently, this was an easy decision to make. We were leaning towards requiring MySQL 5.5, which was also released in 2009. We feel that 3 years is long enough on the web to incorporate updated software within most hosting environments. Upon investigating the functionality we intend to utilize in MySQL, however, we have determined that MySQL 5.0.3 and above includes everything we need, so MySQL 5.0.3 will be our minimum required version. Profiling and Benchmarking If you are a PHP developer and have ever attempted to profile your code, you probably realize it can be challenging. Many IDEs support some level of profiling built in, however it is almost always manually invoked. xdebug is a powerful tool for profiling, but again it requires you to enable profiling, run a request, and then view the results. In a live environment this is nearly impossible as profiling adds a lot of overhead to page loads and creates hundreds of profiling files quickly. Our goal is to be able to profile changes as they are committed, right away. We have decided to install Zend Server to the server that will host our staging environment for 4.0, which supports automatic rule-based built in profiling. This will allow us to easily profile requests automatically, even those that we may not "know" how to trigger manually (e.g. a specific task in a specific circumstance takes a long time to execute). Improving automatic deployments While automatically building and deploying the software to our staging environment itself is not a challenge per-se, a lot of times changes occur that require some sort of manual intervention to enact. We may have exported updated skin templates, language files, or there may be SQL queries that need to be run. We are developing an automatic deployment routine that can handle all of this easily and programatically, ensuring our staging environment is truly always up to date with the latest changes. Website and forum organization Not directly related to 4.0, another area we had to consider was our organization on the website and on our community here. This extend to all areas of the community, from the organization of our feedback and support forums, to our marketplace categorization, to our bug tracker categorization. The approach with 4.0 will be that we have one suite with modular applications that can be enabled. We need to market the software this way, and we need to ensure that the logical work flow for our clients reflects how our suite is designed. You will be seeing changes to categorization throughout our sites based on 4.0 in due course as a result. Loose ends And beyond all of the stuff directly related to 4.0, we felt it prudent to tackle a lot of loose ends before we jumped into a major overhaul of our entire software line up. There were a lot of smaller tasks that have been pushed off for a while but which we've finally sorted through which we feel will afford us less distractions as we work on the next release. Most of these tasks were minor, but not unimportant. Examples include: Moving our documentation to the main website Improving minor areas of IP.Downloads and IP.Nexus to allow clients to better help themselves, or to allow a smoother work flow within the administration areas our employees utilize every day Scripts on our end that allow us to better manage certain services Cleaning up old content in our installation, such as removing unused IP.Content blocks and deleting left over files on our server None of this directly affects 4.0, however the less distracted we get with minor tasks during 4.0 development, the better we can focus and deliver the product in a timely manner and with less chance of distraction-related bugs. Of course hundreds of other decisions have gone into 4.0 as well, some of which we will talk about in future blog entries. We thought you might be interested in hearing about some of the smaller things us developers do here at IPS, however, besides developing great software products to power your communities!

Betas for ALL applications available

bfarber posted a blog entry in Invision Community

We have built public beta releases of our entire product line up for testing. Please be aware that beta releases are not supported by IPS technical support. We do not recommend running them on a live site, you may be unable to upgrade from a beta release to the final version, and our only course of support is to recommend you restore a backup of your site if you face any issues. We appreciate clients who wish to participate in beta testing programs. We would recommend cloning your live site, or installing these betas to a new test environment, in order to test the bug fixes and functionality improvements. Please report bugs in the bug tracker. As of the time of this post, our company forums are running all of these latest versions. IP.Board 3.4.3 Bug fixes IP.Blog 2.6.2Bug fixes IP.Calendar 3.3.2Bug fixes IP.Chat 1.4.3Bug fixes IP.Content 2.3.5Bug fixes IP.Downloads 2.5.3Bug fixes Multiple featured files now supported Ability for clients to manage renewals for purchased files now supported IP.Gallery 5.0.4Bug fixes Ability to create Gallery IP.Content feeds filtering on "featured" status now supported IP.Nexus 1.5.7Bug fixes Integration with the bulk mailer supported Ability to leave a customer note when voiding account added You can download beta releases for which your license gives you access to at our QA page. Thanks in advance to all who decide to test!

Minor enhancement to IP.Gallery feed blocks in IP.Content

bfarber posted a blog entry in Invision Community

This is just a quick update to let everyone know of a small enhancement you can expect to see in the next IP.Gallery release. We recently noticed that you could not create IP.Content feed blocks to pull featured images from IP.Gallery. We felt that this was a small and easily correctable oversight, so we added a filter option when creating IP.Gallery feed blocks in IP.Content to allow you to choose whether to pull only featured images or not. You can expect to see this new option beginning with the IP.Gallery 5.0.4 release. Adding filters to IP.Content feed blocks is a generally easy process, depending upon what you are trying to filter by. Naturally, some types of filters can make the block much more complex, but with the example above of filtering by retrieving featured images, we needed only 2 language strings and 10 distinct lines of code. What types of block filters have you always felt would be easy but useful additions?

IPS Social Suite (4.0)

bfarber posted a blog entry in Invision Community

While we introduced some of our basic plans for 4.0 many months ago, we wanted to touch base again on some of these plans and expand upon some of our motivations behind decisions we have or will make for our upcoming 4.0 software release. Before we get too far, let me just state now that there is no expected (or even estimated) release date for 4.0 yet. While we always have internal guidelines, timeframes and milestones, we do not communicate these publicly until we are absolutely sure they are as accurate as possible. The 4.0 Suite will be a major overhaul, effectively a rewrite of most areas from the ground up, and there are many factors that can affect delivering within expected due dates. You may also have noticed the title of this blog entry uses a term for the suite you may not have seen used previously. We have decided to name the 4.0 Suite (which we will often refer to as "4.0 Suite" or "Social Suite", informally), officially as the IPS Social Suite. We feel that as we expand our line up and remove community-related dependencies, it is important that our main product release reflect the fact that our software can power more than just traditional communities. Formalities out of the way now, here are a few of our driving motivations behind 4.0... Modernize the interface The skin delivered for 3.0 and again for 3.2 was great, but several years have since passed. It is time we modernize the user interface in our software lineup once again. Features have been added, trends on the web have shifted, and technologies have advanced. Some specific points you may be interested to know: All areas of the suite will support the mobile interface. We are heavily investigating using a "response design" for 4.0. We will be switching to jQuery We will be embracing HTML 5 fully Modernize the underlying codebase While 4.0 will not technically be a "complete rewrite", most of the underlying codebase will be rewritten in some manner, and all of the code will at least be updated to work within the new framework we are developing. There is a lot to go over for those of you who may be interested in the developer side of things, and I'll point you to the right place later in this entry, but as a general outline here are some things you can expect to see:PHP 5.3 will be the minimum supported version of PHP MySQL 5.0.3 will be the minimum supported version of MySQL IP.Board will fully utilize namespaces in PHP The entire directory structure, class naming structure and more will be completely overhauled Applications will truly be self-contained within their own folders (currently javascript, skin and language files, for instance, are scattered throughout miscellaneous directories) The entire code base will be modernized. More use of formal design patterns will be employed, where appropriate. Dumping ground classes (such as IPSLib) will be avoided at all costs. More consistency between how applications implement functionality will be seen. Naming conventions will be more consistent. The way hooks work will be completely rewritten, making things simpler for us and for developers, and making hook usage behind the scenes more reliable (no more loadLibrary calls - everything is handled automatically by the framework instead). Make things more consistent We are also working towards making all of our applications more consistent. The approach to this actually has much more to do with planning and how we approach new functionality than it does any specific technical aspect of software development. In a nutshell, we will have one "suite" release moving forward starting at 4.0. Every application will be on the same versioning system and share the same version number, and every release will include every application (although you will only have access to the applications you have purchased, of course). What we will do as we implement new features is implement new functionality suite-wide from the start. If we were to add a new feature to 4.0, we would not add the functionality to the forums and then roll this change out to other applications as they see updates. Instead, we will be implementing changes suite-wide from the start, which has several benefits:From a user standpoint, the software will be more consistent. You won't have situations where a feature is available in Application X but not in Application Y. From a technological standpoint, we will be forced to implement functionality in an optimal manner where it can be utilized by all areas of the suite. There will be less application-dependencies for features that are intended to be suite-wide. There will be much, much less duplicated code as features will be designed from the start to work in multiple areas. Point #2 above will also benefit modders - APIs will be much more robust, yet more generic and reusable, for features implemented suite-wide rather than features implemented for one application and then shared across others. Beyond changing our approach to functional changes in the software itself, we will also be focusing on consistency while redesigning the interface, and throughout every facet of development of 4.0. Want to hear more specifics? We have recently launched our new development blog where we will routinely be posting about the nitty-gritty of our day to day development duties here at IPS. While this blog is not at all intended to be specific to the development of 4.0, you will find us posting about upcoming changes and decisions made in 4.0 quite regularly. We welcome you to follow The Development Channel blog if you are interested in reading about these changes. If not, don't worry - any major announcements will be blogged about here in our company blog as well in due course. If you aren't sure, just to be clear....development of 4.0 is definitely underway. A lot of planning and discussion took place prior to ever writing a single line of code for 4.0, however we are definitely working on 4.0 now and you will likely see blog entries about upcoming changes before long. Stay tuned!

IP.Downloads Multiple Featured Files

bfarber posted a blog entry in Invision Community

Through use of our own marketplace, we often identify small but useful changes to IP.Downloads that benefit sites that both use IP.Downloads to allow distribution of free files as well as those that sell files through a marketplace. While working to improve the user interface of the home page in IP.Downloads, we decided that allowing multiple featured files would be a small change but would help improve the interaction and discoverability of useful content in the marketplace. After all, every other marketplace has more than one file featured, right? IP.Downloads 2.5.3 will now allow you to feature more than one file. Up to 20 of the most recent files that are marked as featured will display on the homepage in a carousel-style panel. The act of featuring a file has not changed (the only thing that has changed here is that other files which are featured are no longer automatically unfeatured). Only the homepage interface has really changed. Here is a short video to show you what it looks like with two featured files. Note that if you only have one featured file, it will display as it does now in IP.Downloads 2.5.2. http://screencast.com/t/A0KX6uWs You will note that you can manually cycle through featured files, or they will cycle automatically. If you mouse over the featured file panel, the automatic cycling pauses. We hope you find this small change useful, and more consistent with other applications that allow featuring (such as IP.Blog, where you can feature more than one entry, and IP.Gallery, where you can feature more than one image). Let us know what you think in the comments below!

IP.Nexus integration with the bulk mailer

bfarber posted a blog entry in Invision Community

We identified a use case recently where we wanted to send a bulk mail to all clients who had purchased a particular package in IP.Nexus. This is not uncommon. Perhaps the package is being discontinued. Perhaps you erroneously over charged for this package. Perhaps there will be a special on additional purchases of this package. Regardless of the reason, it is logical and ordinary that you want to email all clients who have purchased a given package. Because the bulk mailer was improved in 3.4 and now supports per-application extensions, we have written one for IP.Nexus 1.5.7 that allows you to control with the bulk mailer certain ways to filter members based on packages they have purchased. The way this works is very simple. When you go to send a new bulk mail, there is now an IP.Nexus tab in the filters area allowing you to filter by IP.Nexus purchases. You can also control whether you send to only active purchases, expired purchases, cancelled purchases, or any combination there-of. Here is a screenshot to show you what it looks like on our site: I'm sure you can see just how valuable this small but useful change will be. This enhancement will be available with the release of IP.Nexus 1.5.7. What other types of filters have you wanted to bulk mail members utilizing, but can't presently?

More client control over marketplace purchases

bfarber posted a blog entry in Invision Community

Our marketplace is an area where developers can submit free and paid resources for other clients to download and use on their website. IPS processes many, many transactions through the marketplace, both one-off purchases and renewals for applications clients have previously purchased. When an application has renewals, however, it was pointed out that the client had no way to cancel those renewals. Perhaps the client is no longer using the resource they purchased, for instance, and does not wish to renew the purchase any longer. With our product releases in the client area you can easily opt not to renew purchases if you want, however there has been no way to do this in the marketplace...until now. With the release of IP.Downloads 2.5.3 (and available in the marketplace now), instead of a button that reads "Buy another", the button has been relabeled to "Manage Purchases". When you click this button on a file you have purchased, you will still have the option to purchase more licenses, however you will also have the ability to manage your existing purchases, includingCanceling a purchase that is active Reactivating a previously canceled purchase Renewing a purchase that has expired Additionally, we enhanced IP.Downloads so that when an author changes a paid file with renewals to free that it clears out the renewal terms for any clients who have purchased the file. If the file is no longer paid and no longer has renewals, existing purchases should not still renew, after all. And finally, if the file name is changed, previous purchases that are displayed in a user's client area will now reflect the updated file name, for clarity. These small enhancements will make clients better able to manage their purchases, save our customer service representatives time by not requiring them to cancel purchases for clients, and provide an all around more robust and complete experience for users. (Please be aware that this is an early screenshot of a feature to be included in the next release of IP.Downloads, and subsequently the interface and display is subject to change)

Welcome to The Development Channel

bfarber posted a blog entry in Invision Community

Hello everyone! Us developers are a strange bunch. We have a lot of crazy thoughts that just don't make sense to anyone else. Our brains are wired different. We get from point A to point B by going around point Z and bouncing off point M first. And very few of us (*cough*me exempted*cough*) are able to type up posts that make sense to more than just other developers. So what are we to do? Keep all of our great thoughts to ourselves? Nonsense. Nevertheless, we cannot flood everyone with the semi-(in)sane ramblings that go on in our heads every day, nor can we bore everyone with discussions of how great our new class structure will be, or how useful the new methods we've just added to x class will turn out. Introducing The Development Channel This blog will be a place us developers can write up our thoughts and discuss developer-specific topics. Anyone can follow this blog if they want to. We're not out to have a private exclusive group that only the elite development community can join. Quite the contrary - if you are interested in the sorts of things us developers do on a regular basis or are interested in the future and development of the software, please feel free to follow this blog. We will be talking about new features, minor tweaks and other changes to existing features, code-level improvements (such as class structure, class inheritance, and so on) and even things not related to the software (think: how we do x on our website, or why we chose to approach a problem in a specific way). If any of this is your cup of tea, we hope you enjoy the blog entries to follow. If this is all Greek to you (and you don't speak Greek), then by all means - ignore us. You are certainly free to continue following our official News forum and our official Company Blog, where all the important stuff will get posted. If you're still here, we hope you enjoy what we have in store. :)

Minor IP.Nexus 1.5.7 enhancement

bfarber posted a blog entry in Invision Community

We have added a minor enhancement to IP.Nexus 1.5.7 that we thought you might be interested to hear about. Our customer service representatives found that when they "voided" an account in IP.Nexus (by clicking the "Void Account" button when viewing the customer screen in the ACP) that they often wanted to leave a customer note at the same time, explaining why the account was voided. For years they simply added the customer note manually after they voided the account. This isn't a big deal, but we identified a way to improve their workflow in this instance. With the release of IP.Nexus, a textarea box has been added to the "Void Account" page (as long as you have permission to leave customer notes), allowing you to leave a customer note at the same time you void the account. This small change will save our customer service representatives time and effort while they perform their daily routines, and took us less than half an hour to do! Have you found any small changes like the one identified above that would save you time and effort? Sometimes moving a button around or adding an extra form field can make all the difference!

IP.Gallery 5.0: Some Further Changes

bfarber posted a blog entry in Invision Community

Development of IP.Gallery 5 continues, and today we wanted to blog about some additional changes you can expect to see in the next release. These changes are unrelated to one another, however they collectively will improve the functionality and capabilities of IP.Gallery 5.0. Note that these changes were derived as a direct result of client feedback, so keep it coming! RSS Feed Enhancements As of IP.Gallery 5, RSS feeds for IP.Gallery have been updated to give users better options as to how they subscribe to feeds on your site. In IP.Gallery 5, you will have RSS feeds available for categories, albums, and a new global latest images feed has been added, allowing users to stay abreast of latest images throughout the entire Gallery. This global latest images feed is discoverable easily by browsers and other feed reader applications, and a link is available in the board footer amongst the other RSS feeds for the software. Notification Enhancements One common request we've seen for IP.Gallery centers around notifications. IP.Gallery allows you to follow any album or image to be notified of new images or comments already, however you must follow these areas manually. Often you will upload some images and forget to follow them afterwards, so when another user comes along and comments on your images you are not aware of this. We have added a checkbox on the review page (the secondary step after uploading your images where you specify the caption and other details) that allows you to follow the image(s) immediately upon submission. This checkbox is checked by default, so the default action is that users will be notified of comments on newly submitted media. A user can optionally deselect the checkbox if they don't wish to be notified of comments made against the submission. This small change will help your users remain aware of comments on their images, and help spur return visits to your site through enhanced notifications relevant to the user. Homepage Changes While we have a fair many customers looking for a traditional navigational approach to Gallery (Category -> Album -> Image), many of our clients left feedback following an earlier blog entry regarding the new homepage indicating that they prefer a more social approach to the Gallery. Rather than a category listing, you want to see recently updated albums and new images to keep the page fresh. Additionally, the use of two sliders on the homepage spurred some discussion about the best way to present the data being made available on the homepage. Firstly, we have changed the recent images block to a stream of images, as you would see within a listing. The featured images block remains as a large slider at the top of the screen, however the recent images near the bottom of the page will now list many small thumbnails instead. Clicking one will open the image in the new navigational lightbox to allow you to see the larger version and the image details. Additionally, we realize that the categorical approach is not the preferred solution for all of our customers, so we have added a setting that will allow you to switch the homepage to a more "social" version. This setting only affects the homepage, however the data will be presented in a manner that will better allow users to simply review the most updated content with less of a focus on the structure of the Gallery. Here are some screenshots The top of the page continues to show the featured images in a slider, and otherwise looks similar to the more traditional categorical layout. The main difference is that the categories are listed in a sidebar block here, de-emphasizing the structure but still allowing you to navigate into categories at will. The main difference comes after the featured image. When the social layout is enabled, a stream of the most recently updated albums (that you have permission to view) are presented in order of last update. Up to 20 albums will be displayed. Below that, up to 50 of the most recently uploaded images are displayed, and as with the other image listings, clicking an image will open it inside a lightbox showing you the full size image and other image details without leaving the page. Wrapping up We will continue to evaluate feedback, particularly after the new software has been shown to our focus group and other alpha testers, and we will make sensible changes based on the feedback we receive. Please feel free to leave us feedback in the appropriate feedback forum!

IP.Gallery 5.0: More Navigation Changes

bfarber posted a blog entry in Invision Community

While we discussed some of the basic core navigational changes in IP.Gallery 5.0 already (and yes, we've heard your feedback on those changes!), we have implemented some other changes to enhance consistency and bring IP.Gallery into the modern world wide web. Some of these changes are basic on the surface, but will help to ensure the interface remains consistent throughout the application, in third party applications, and in future features we may add, while some of the changes represent an entirely new way to use the software. Image Navigation When you enter into a category or album that has a listing of images, you see each image and can click into them one by one to view the full-sized image and some further details. This is simple and intuitive enough, but a little...boring. With today's web, we can enhance this a bit, so we've done so. When you are viewing a listing of images and click onto an image, it will now open in a lightbox and most of the image details will be presented to the user. You can navigate through the images in the listing with next and previous buttons, easily allowing you to view all of the images on the page without ever leaving the page itself. The functionality itself is handled by javascript (and AJAX requests), but the links are good old-fashioned links to the full image details page, so you don't have to worry about search engine spiders being able to navigate through the software. To them, the navigation will work as it always has. The AJAX responses are cached to save resources while the user is still viewing the page (if the user navigates to an image they've already loaded, it pops up instantly). Here is a quick video demonstrating this new change. Note that you can still access the full image details page by clicking the caption in the lightbox (or through any other normal browser means, such as opening the link in a new tab, or dragging the image itself to your address bar in your browser). http://screencast.com/t/5yMrkqTe Album Changes In IP.Gallery 5.0, you will no longer be able to create sub-albums. Sub-categories are still supported, however albums themselves can only be placed within a category, not within another album. The upgrader routine will move sub-albums to the nearest category that allows album creation (or to the special Member's Gallery if a suitable category cannot be found). Similarly, private and friend-only albums are only allowed within the special Member's Gallery. These changes represent necessary deviations from past versions to allow IP.Gallery to scale effectively as the site becomes larger. One of the primary issues faced in past versions was resource consumption as the number of albums on the site grows - this will no longer be an issue with specific rules in place that prevent complex hierarchy challenges. Member's Gallery The special Member's Gallery category is the only category that allows friend-only and private album creation. It is designed as a category that members can create any type of album they want within (subject to the per-group restrictions the administrator has defined), and includes a special option to allow you to determine how to present the contents of this category. The special Member's Gallery allows the administrator to determine if the category will display albums, images or individual members. When you display albums, the category works like any other category that allows album creation. This is the default setting. When you display images, all images within all albums in the category (that you have permission to view) are displayed, just as if the category allowed direct image submissions. To the end user, they will be looking at an image listing, and will be unaware that the images are coming from albums within the category (although this is noted in both the lightbox popup and on the full image details page in the right hand information block). When you choose to show members instead, however, all members who have submitted an album to the special Member's Gallery are displayed, and clicking on the member will show that user's detail page (which in turn will list their albums and image submissions). For sites who wish to group by member within the category, this option allows you to do that, similar to earlier versions of Gallery. The last 10 images the member has uploaded into an album within this category will also be displayed. You will note there is a "Show Me" dropdown button at the top right. Members can override the administrator-defined default if they prefer to view the listing differently (e.g. if they just wish to see a stream of images), and their preference is stored in a cookie so that it is remembered if they leave the page and come back. And still more We have yet more to announce for IP.Gallery 5.0 and hope you are enjoying the updates. We are taking all feedback in and are looking forward to being able to show you the new release as soon as possible.

IP.Gallery 5.0: Smaller Changes

bfarber posted a blog entry in Invision Community

We have taken the time with IP.Gallery 5.0 to implement some smaller changes that help to round off the functionality of the software and bring it more in-line with the rest of the suite. While these changes individually are all quite small, collectively they help to make Gallery easier to use and more intuitive for the average user. pInterest Integration For those of you not familiar with this new service, pInterest is a popular new image tagging website that allows users to "pin" images from across the web to a "pinboard". They can create multiple pinboards to classify their images. IP.Gallery will now show a pInterest sharing button with the rest of the social sharing options. Shared Media Currently when you share an IP.Gallery image via the shared media plugin, a small box with the image details is shown, linking the user to the full image page. Here is an example (note that this example will change once our site is updated to IP.Gallery 5): http://community.invisionpower.com/gallery/image/1854-test/ Many users have requested that we instead simply embed the thumbnail directly and open the full image in a lightbox. We've updated IP.Gallery 5 to do just that. Here is a quick video showing this in action. http://screencast.com/t/YOlreAnC6Bi Set as Profile Photo In recent past versions of Gallery, members were required to create an album that they designate as a "Profile Photos Album", and then they are able to set an image within this special album as their profile photo. While functional, we have determined that the restrictions here are largely unnecessary. We have removed the "profile photo album" functionality within the software, and now members will be able to set any image they can view as their profile photo. Hidden vs Unapproved Keeping in line with the distinction between hidden and unapproved implemented in other areas of the suite, IP.Gallery has been updated to recognize this distinction. When an image requires moderator approval upon initial submission, it will be in an "Unapproved" state, and you can either "Approve" or "Delete" the image. After it has been approved, you will be able to "Hide" or "Delete" the image. When it is hidden, you will be able to "Unhide" or "Delete" the image. You will no longer unapprove a previously approved image. While this does not affect the functionality of the software greatly, it does serve to separate the actions. A new moderator control panel plugin has been added to show "Hidden" images. IP.Content The Gallery feed blocks in IP.Content have been updated to reflect the changes in Gallery, namely the distinction between Albums and Categories. The feed blocks will be available immediately upon IP.Gallery's release, as IP.Content blocks are now part of the individual application's package instead of the IP.Content package (in other words, you won't need to wait for an IP.Content release to enable these new changes). SEO Tweaks We have reviewed the on-page optimization of many pages in IP.Gallery and have made small tweaks to enhance the software. We have implemented canonical tags where appropriate to point all URL variances (such as sorting changes) back to the parent page. We have made certain duplicate page titles unique and clearer as to what they represent for the page in question. We have forced the true "page title" (e.g. the name of the category, album or image you are viewing) to an <h1> tag, and have cascaded down other <h*> tags as appropriate. We have forced some of the on-page javascript and CSS code into the head of the HTML document. These small but useful changes will only serve to better clarify to search engines how pages relate to one another and what pages are the authority source for specific requests. We are listening to feedback and suggestions regarding SEO, and we encourage you to let us know if you spot something that doesn't seem right in the appropriate feedback forum. More to come These small changes will work towards better consistency between suite applications, and bring some minor but useful updates to existing features in IP.Gallery. We have more changes to announce yet, and hope you are looking forward to hearing about other updates to IP.Gallery 5.0. Stay tuned!

IP.Gallery 5.0: More Administrator Control

bfarber posted a blog entry in Invision Community

One of our big goals with Gallery 5 is to restore a level of administrative control that allows different sites to dictate how their users and moderators will interact with the software. Some sites wish to allow their users to have control over their submissions. Some sites wish to control the submissions their members contribute once the file is uploaded. In order to accommodate the myriad of needs our clients have, we have implemented many new controls to IP.Gallery, and reworked how some existing controls function. Moderators One change we have made is to remove moderator-style permissions from the group management area and implement a full "Moderators" area of the ACP. When managing your categories in the IP.Gallery ACP, you can now add moderators to one or more categories. These moderators can be groups or individual members. You can specify the following permissions for your moderators: Can approve images Can approve comments Can edit images and albums Can hide images Can delete images and albums Can move images and albums Can set cover images Can edit comments Can delete comments Members will be allowed to move their own images between their own albums, but will not be able to move images from their albums to another member's albums, or to categories. You can still specify on a per-group basis if members can edit their own images and comments, delete their own images and comments, and you will also now be able to specify whether they can delete their own albums or not. This will allow administrators to control what their members can and cannot do in IP.Gallery. Controlling Albums In addition to the aforementioned moderator permission updates, administrators will now have more control over how users manage albums. You can now specify whether members can create public, private and friend-only albums separately (so you can allow members to create all 3 kinds, only public albums, or disallow members to create albums entirely). As with previous versions, you can also limit the number of albums they can create, and the number of images they can upload into each album. Further to this, however, you can control the defaults for new albums and which of those default options members can override. Under the Album Manager area of the IP.Gallery ACP, there is a new page: Album Defaults. When you visit this page, you will be able to control the album default options and determine which of those options members can change. To lock or unlock a field from being editable, you simply click on the green or red icon to toggle it. Fields that are locked will still display to users on the front end, but will be disabled and uneditable. This allows users to know what preferences are being enforced. You will note in the screenshot that there is a message under the watermark field advising that the option is only honored when a category is set to "Allow members to choose per-album". When you create a category that allows album submissions, you can choose one of three options for the watermark preference:Do not watermark Force watermark on every image Allow members to choose per-album The first two options are self-explanatory. The last option allows members to specify whether they use watermarks or not when creating their own individual albums (and of course can also be restricted by the album default preferences discussed above). It is important to note as well - you can enable and disable ratings and comments at the category level. If you disable comments or ratings at the category level, this preference cascades down to the albums within the category. If comments are disabled in a category, they are disabled for all albums within that category. If a user does not have permission to comment in a category, they will not have permission to comment within albums contained in that category. Image Control Administrators have fairly good control over images in IP.Gallery already, however we are expanding this control in IP.Gallery 5.0. Some new options include:Ability to shut off "medium" and "small"-sized images. You cannot shut off the thumbnail or large-sized images, as both are used throughout Gallery in many different places. You will be able to shut off cropping of thumbnails. Instead of "unapproving" images, you will now "hide" images. These will show up in the Moderator CP when hidden. Members who can delete their own images will actually be "hiding" them, giving moderators a chance to review the deletion before it is carried out completely. You will of course retain all of the previous image control options available in Gallery 4, and many minor interface changes will make handling your images easier and more intuitive. Up Next We realize control of your Gallery installation is important and we are working towards giving administrators sensible options to enable them to configure IP.Gallery to their needs. We have a lot more changes in store and will be discussing some of the more interesting changes in our next blog entry. Stay tuned!

Gallery 5.0 Goals

bfarber posted a blog entry in Invision Community

Development of Gallery 5.0 is well underway, and while we are not quite ready to reveal the product just yet, we wanted to give our clients an outline of what they can expect to see when the new version becomes available. Gallery 5.0 will build upon changes in the 4.x series, while restoring some of the functionality of the 3.x series, delivering a product you can easily understand and navigate that is both modern and fun to use. The next version of Gallery will not see many new features - instead, we are focusing on the existing functionality to ensure the released product is flexible, intuitive and dependable. Goals While our goals for Gallery 5 are simple and focused, don't let this fool you. A lot of changes are being implemented to accomplish these goals, and you will notice many small changes that add up to big differences in how the product is used. We can outline our high level goals as follows: Redesign the navigation, structure and hierarchy Gallery makes use of. Terminology notwithstanding, many users find navigating the current release of Gallery to be confusing, and do not understand the relationship between "global" albums and "member" albums. Many changes in the previous iteration of Gallery were made to ensure the software could scale effectively. We have taken many of the concepts of Gallery 4 and merged them with concepts in Gallery 3 to present an interface we think is easy to understand and navigate, and allows the administrator to control the setup of their Gallery. Give administrators more control over their Gallery. We have implemented or reinstated many software options that allow administrators to better control what members can do and where. Administrators will now be able to define what types of albums members can create, whether they can delete those albums or not, which album options members can customize, and much more. SEO and efficiency improvements. In virtually every release, we review the search engine optimization and code-level optimization of the software, and this release is no different. Interface updates. Much of the interface has undergone a complete overhaul as a part of the navigational restructuring of the software. In addition, some new functionality has been added to make navigating through images quicker and easier, and minor feature improvements or additions will be noticed. By keeping our goals list short and focused, we can put more emphasis on the high-level things that matter most to our clients. More Information More information about each of the goals outlined above and changes made to the software to implement these goals will be forthcoming in future blog entries. The software is still very much under heavy development and we are not ready to show off everything just yet. Nevertheless, we wanted to highlight the higher level goals you can look to in the next release, and give everyone a small update on development. A Teaser For now, we will leave you with a teaser - the new index page. Here you can see the top of the index page. In the right hand sidebar we have a block identifying the latest comments and a block identifying the most popular tags used in Gallery. The top of the content area is filled with a featured images slider (if you have any featured images - if you do not feature any, this block disappears, as expected). You can feature as many images as you like, and up to 20 will be displayed in a javascript slider. The slider will display the image (with some details along the bottom of the image), and will automatically show the next image after a couple seconds, cycling through them (and restarting when the last featured image is displayed). You will also note that the upload button is available. In fact, it is available on every page throughout Gallery, if you have permission to upload images somewhere. Further down the index page, you will see the category listing. Global albums have become categories in Gallery 5.0. More information will be available on this in a future blog entry. For now, just know that categories are administrator-defined containers that can be set up to [*]Allow albums to be created in them [*]Allow neither (useful if you create subcategories and don't wish for images to be accepted within the category itself, but rather in a subcategory) Categories allow you to specify cover images, and allow you much of the same control you had with global albums in Gallery 4. You can think of categories in Gallery 5 as global albums, renamed, in part to help alleviate confusion and to clarify the relationship between the two different types of containers Gallery allows. You can see from this screenshot that the hierarchy and navigation of Gallery right from the index page has been restored to a more traditional container listing. Finally, at the bottom of the page you will see the 20 most recent images that you have permission to see, in the same slider that was used to display the featured images at the top of the screen. You can see the hint of arrows on either side of the image, allowing you to manually navigate to the next or previous image in the slider (although, as with the featured images, it automatically cycles through each image). [*]Allow direct image uploads

Developer Documentation

bfarber posted a blog entry in Invision Community

While working toward the release of IP.Board 3.3.0 and IP.Content 2.3.0, the development team took some time to refresh our developer documentation, aiming to provide useful information for our third party developers in order to help them update their work as necessary. We are still very much working on expanding and updating the developer documentation we have in place, but we wanted to go ahead and reveal the new documents that are ready to give you a head start. PHP Docs We have refreshed the phpdoc export using doxygen. View the phpdoc documentation Developer Documentation In addition to the generic phpdoc export, the development team has written several more specialized articles aimed at helping developers utilize our framework. While we have had developer documentation in place for some time, these articles are up to date and based on IP.Board 3.3.0. We have a list of several more articles we intend to publish over the coming weeks, and relevant developer documentation already available will be retained or updated as needed. For now, you can view the new articles in the Developer Docs (New) category. Over time, these documents will be merged back into the main Developer Resources category. We have some cleanup and reviewing of our documentation structure to tackle first, but we didn't want this to hold up our valued third party developers in the mean time. We are working hard at bringing all of our documentation up to date, and we hope that our community find these resources useful. More information to come!

IP.Content 2.3 Dev Update: Odds and Ends

bfarber posted a blog entry in Invision Community

While we have discussed many great things you can expect to see coming in IP.Content 2.3 already, we've got a few miscellaneous changes that we wanted to let you know about, but that weren't necessarily grouped into a single "theme". Still, we felt you would be interested to hear about these changes, so I've taken a moment to compile this blog entry, discussing some of these odds and ends for those interested. Default Install Content The content that is inserted and available during the installation process is important. It helps users understand how the product works, gives them some examples of the product in action, and lets the admin start using the product right out the door with minimal configuration necessary. We have taken a moment to review our default installation, and have made some minor changes. Firstly, we have updated the screenshots that are shown with the default articles to reflect the IP.Board 3.2 skin. The screenshots in IP.Content 2.2 were based on IP.Board 3.1, and the skin has since changed. Additionally, I've touched up the article content here and there to bring it up to date, and I have added one new article about the new navigational menu system. This is all simply default content to show you how the system works, but we felt it was important to make a good first impression, and it is useful using the articles system as a sort of "how to" for users installing the product for the first time. At the same time, we have moved the articles system to a different page (articles.html) and we have made the default page IP.Content display a portal. A portal page is simply a page that brings in content from various parts of your community, usually used as a homepage so users can get a quick and easy overview of what is going on or what is new. This is very easy to set up in IP.Content, since its goal is to allow you to pull data from various parts of your community with ease, and as we get a lot of requests for a simple portal-style page in IP.Content, we have decided to make this the new home page. Blocks are set up to pull content from Blog, Gallery, Downloads, Calendar, Articles and the Forums by default, but if you don't have one of those applications installed don't worry - the block will simply not display and the page will function as normal. At the same time, this allows us to show off how the new block templates system works, as most of the blocks on this new portal are feed blocks utilizing new block templates. Content Pending Approval / Moderator Changes It can be challenging finding the content that needs to be approved in IP.Content 2.2. While ACP-based tools help with this necessity, there are few tools available to your moderators on the front end to find this content that requires their attention. We have addressed this with IP.Content 2.3 in a tiered approach. First and foremost, IP.Content is now integrated into the ModeratorCP. You can easily view database entries (and articles) pending approval, comments pending approval, database entries that have been hidden and comments that have been hidden. You can edit, approve and delete as needed right from the moderator control panel with ease. You will note in this screenshot that when you select "Database Records" that you can then (and must) filter by database to view the entries pending approval within that database. The same goes for viewing hidden content in the Trash Can section of the ModeratorCP. In contrast, all comments pending approval or hidden can be displayed at once without the need to view them separately per-database. Going beyond this central tool, however, we have also added indicators throughout the IP.Content templates themselves when something is pending approval. Frontpage and archive templates will show you if there are comments pending approval (if you have permission to approve them) So do the category listing templates And if you follow one of these links, the listing will be filtered so that you ONLY see the content pending approval. To remain consistent with IP.Board, we use badges in the various listings to show you when something is hidden or unapproved. We believe these changes when used together should help your moderators better find and manage the content that requires their attention throughout the front end. Finally, we have gone through and made IP.Content moderator processes more consistent with IP.Board 3.3. If an article or comment is requiring approval, it is considered unapproved and you can approve or delete that comment or article. If the article or comment is approved, you can delete or hide that article or comment. Some time was spent with IP.Board to clarify these actions and make working with them more logical (what is soft delete? what is hard delete?), and we wanted to bring those same improvements over to IP.Content. And, if you haven't picked up on it throughout this paragraph, IP.Content now supports soft deleting articles and comments (which is called "hiding" in IP.Board 3.3). These are the items that will show in the trash can of the ModeratorCP. Administrative Logging While not an overly exciting change, we have gone through the entire ACP codebase and added administrative logging to IP.Content. Now, when "Admin Joe" deletes a page from the page manager, or alters your most important database template, you will quickly be able to see this through the Admin Logs page of the ACP. Article Teaser Paragraph We have added a new default field to the articles system (upgraded installations will also get this new field) called a "Teaser Paragraph". This field allows you to define the teaser paragraph to show to users in the various listings (e.g. the archive view or the frontpage templates). When this field is populated, its entire contents will be displayed as given (it is an editor field, so bbcode parsing will also occur). When the field is not populated, we will default back to the current functionality, which is to show a certain number of characters from the article body field (without any bbcode parsing occurring). It should be noted that when viewing the article itself, the teaser paragraph is shown, and then the article body is shown after it, so the two fields are "combined" visually, however you can always edit the article view template to remove the teaser paragraph field if you do not wish for it to display. You do not need to use this field if you don't want to, however many customers have requested a way to better control the content shown in the listing and this new field will allow you to do just that. Further Interface Polish We are also presently working through the default templates to further refine and polish the interface before release. We have made many minor changes already - often times using a different CSS class to add some padding, or adding an extra line break (or removing one!) can make really make the templates appear more professional. We've worked on some various areas that we felt we could improve through minor changes, and we have ensured that the default templates make use of the IP.Board default CSS to the extent possible, removing IP.Content-specific CSS definitions that are no longer necessary in the process. The end result is a more refined interface for your users, less for skinners to have to customize, and more consistency between IP.Content and IP.Board pages. In Closing... We are working hard to prepare the best IP.Content release we have ever made, and we are eager to get your feedback on the new and improved product. We are expecting a spring 2012 release, and we are working through many of the last few pieces of the puzzle to deliver a product we know you will be excited to use. If you have any feedback about changes you would like to see in the product that we haven't already announced, please feel free to share them in our feedback forum. If you have any comments about the changes discussed above, please leave your comments below!

IP.Content 2.3 Dev Update: Nexus Blocks

bfarber posted a blog entry in Invision Community

As part of our continued effort to strengthen existing functionality in IP.Content 2.3, and bring about a more consistent and reliable experience for novice and advanced users alike, we have implemented support for IP.Nexus blocks in IP.Content 2.3. IP.Nexus is our powerful e-commerce application, allowing you to monetize your site through the use of many great features such as a storefront, user subscriptions, hosting and support helpdesk functionality. Beginning with IP.Content 2.3, you will now be able to pull much of the great content IP.Nexus contains in unique and useful ways through feed and plugin blocks. Donations Plugin Block IP.Nexus ships with a "donations" sidebar block that can appear on the board index sidebar. If the hook is enabled, the block shows up automatically once you have configured a donation goal. We have duplicated this functionality as a plugin block in IP.Content 2.3, allowing you to show the same donation block anywhere you want, on or off site. Nexus Feed Block And, of course, we have included a Nexus feed block. While many of our applications have more than one data content type you can pull (for instance, you can pull files, categories or comments when you create an IP.Downloads feed block), our IP.Nexus feed block supports a whopping 6 content types. As we mentioned at the start of this entry, IP.Nexus is a very powerful application, and we wanted to allow you to pull the most commonly needed data through the new IP.Content feed block. While we will evaluate feedback and improve this block over time as needed, we feel we have captured the most useful data feeds in our initial implementation here. You will be able to pull the following data from IP.Nexus: Packages Filter by stock quantity Filter by "show on registration" setting Filter by "show in store" setting Filter by "is physical item" setting Filter by "is subscription" setting Filter by "allows upgrading" setting Filter by "allows downgrading" setting Filter by price (minimum and maximum) Filter by "is renewable" setting Sort by name, in stock, upgrade charge, downgrade refund, price, renewal price, ACP-specified position, featured status, or random Filter by product Filter by member (e.g. to show the viewing user purchases they have made, or purchases their friends have made) Filter by active status Filter by cancelled status Filter by purchase date Filter by expiration date Sort by name, active status, cancelled status, start date, expiration date, renewal price, package name or random Filter by department Filter by status Filter by severity Filter by member Filter by replies (minimum and maximum) Filter by open date Filter by last reply date Sort by title, start date, last reply date, last new reply date, last staff reply date, number of replies or random Filter by status Filter by creation date Filter by paid date Filter by total (minimum and maximum) Sort by title, amount, date, date paid or random Filter by status Filter by date Filter by method Filter by member Filter by amount total (minimum and maximum) Sort by amount, date or random Filter by status Filter by order date Filter by ship date Filter by ship method Sort by date, ship date or random [*]Purchases[*]Support Requests[*]Invoices[*]Transactions[*]Shipping As you can see, most of the bases are covered here. If you want to pull a block of "all transactions the viewing user has made, most recent to oldest" you can. If you want to pull a block "random product available in our storefront" you can. If you want to pull "all customer service tickets that are on hold", you can. And remember some special tips with IP.Content - date fields accept any regular date string (e.g. "today" or "last year"), and member fields support two special values: "myself" (restrict to viewing user) and "friends" (restrict to friends of the viewing user). These special options available in all IP.Content feed blocks can lead to some really creative and unique blocks. Time out for a techy moment If you are not a developer, feel free to skip this section. Beginning with IP.Content 2.3, support has been added for pulling blocks from the application folder. In IP.Content 2.2 and below, block files for third party applications must be uploaded to the IP.Content folder (admin/applications_addon/ips/ccs/sources/blocks/*). This works fine, however it is ideal to allow applications to keep their files self-contained to the extent possible. As such, you can now store feed blocks for your third party applications in (application_folder)/extensions/content/feed_blocks/ and plugin blocks in (application_folder)/extensions/content/plugin_blocks/. Behind the scenes, IP.Content will first check application folders, and then check its current block directories. A block in an application folder will override any included in the IP.Content directory. This will allow you to better self-contain your application files while still making use of all the features our application suite provides. What the future holds We are certain there will be other types of data in IP.Nexus you will want to be able to feed through IP.Content blocks over time, and look forward to your feedback and suggestions on ways to improve this new block type in future releases. We hope this initial release, however, covers most of your needs and that you find ways to make use of this powerful tool in IP.Content 2.3. We look forward to your suggestions and ideas for improving the software in our feedback forum. We heavily rely on feedback from all of our clients to shape the future of our software, and even if we don't reply to every topic, rest assured they are all read. If you have any comments on the new IP.Nexus feed or plugin blocks available with IP.Content 2.3, please share your thoughts below!

IP.Content 2.3 Dev Update: Improved Relational Fields

bfarber posted a blog entry in Invision Community

IP.Content 2.3 development is progressing nicely. We are sticking to the four core points we wanted to address with the release of 2.3, namely: usability, consistency, SEO, and strengthening the existing feature set. All of these points tie in together and compliment each other nicely, and addressing these points together will allow for an easier to use and understand yet even more powerful product in the end. One of the existing features we have taken some time to improve with the release of IP.Content 2.3 is the relational database field capability available in any database (and in the articles system). If you are not familiar with relational database fields, they allow you to easily "link" two databases together. A common example I like to give involves having a database of actors and a database of movies. Rather than typing out the actor names every time you add a movie, it makes more sense to add all of the actors to an actors database, and then simply select the actors when you add a new movie. Doing this allows us to link the database records behind the scenes, maintaining an association between the movie and the actors in the movie, in this example. While this association has not been capitalized upon to date, IP.Content 2.3 now provides some new functionality to make the relational fields much easier to use and much more useful. Linked field is not the displayed field One common complaint with relational fields is that no matter which field you select to link to, the title field is always what is displayed on the front end. Keeping with our actor database example, you might have the title field set to the actor name, but allow a separate field for stage name (which would often be the same as the actor's real name of course). When configuring your relational field, you choose to link to the stage name, as this is what users are going to know and look for, yet the dropdown/multiselect option on the submission forms and the displayed value when viewing the record after submission always show the actor name (because it is set as the title field in this database). This is not what our clients are expecting when they link to the specific field in the relational database, and we've heard you loud and clear. Beginning with IP.Content 2.3, the field you link to (in this example, the stage name) is what will be accepted on the submission form, and is what will be displayed when viewing the record upon submission. Dropdowns and multiselects not always ideal Naturally when you have specific allowed inputs, you have to implement a way to enforce the values sent are values that are allowed. If a user is adding a movie and you use a relational field to accept the actors for this movie, you want to ensure that they only supply names that are in your actors database. Dropdown fields are ideal for this purpose (or when accepting more than one value, multiselect fields), however what happens as the actor database grows? Eventually, you may have thousands of actors stored, at which point a dropdown or multiselect field will become virtually unusable. Enter the type-ahead field. Relational fields will now have a third option for "Type of field" called "Type-ahead". When choosing this option, instead of a dropdown field or a multiselect field, you will see a regular text field. As you begin typing in an actor name, suggestions that match the characters typed will be displayed and will be selectable for the user. The new type-ahead field accepts more than one value, so after you select your first value and it is inserted into the text field, you can start typing the next value you wish to insert and select it as well. Upon submission the values will be verified (to ensure that the names are valid for the relational field configuration), so you don't have to worry about random values that are not found in the remote database being stored. Linking Some users have expressed interest in linking the displayed relational field values to their associated records in the remote database. To continue with our actor and movie database examples, if you associate 3 actors with a movie, when viewing that movie it would be nice if the actor names linked back to the actor bio page automatically. Some users have attempted clever workarounds to generate the links themselves in the templates, only to find out that natural sorting is performed and thus ids and displayed values do not necessarily line up. We have added a new option on relational fields (when configuring the field in the ACP) to automatically link the selected values back to their records in the related database. You should only enable this option if your related database is actually accessible on a page via the front end (remember that you can create databases that are ACP-only), however in this configuration (which is most common), this new option will make it much easier to cross link the values, giving much more value to linking to related databases. As you can see in this screenshot, the values I submitted from my last screenshot are automatically resorted to be in alphabetical order, and they are linked to their related records in the actors database. And reverse linking So far the improvements described are all about fleshing out the relational fields to make them more useful and easier to understand. The last thing I want to talk about, however, will really enhance the usefulness of relational fields. You can now have records in the related database automatically reverse cross-link back to records pointing to them. As with the descriptions of the above changes, let's use a move and actor example to clarify what we mean by this. You have a movies database and an actors database. When adding movies, you use a related field to point back to the actors in the movie. When viewing the movie record, it can now even link to the actor pages. Reverse linking takes the next logical step - it will automatically show all movies that the actor is associated with when viewing the actor page. This is a per-relational-field setting, so you do not need to make use of this feature if you don't want to, however it now gives relational fields much stronger value beyond their current implementation. The future Relational fields are a very powerful yet under-utilized feature of databases in IP.Content. We have been evaluating much feedback related to this feature, and as you can see above we have implemented many of the most commonly requested changes for this specific field type. We hope you find value in these updates, and look forward to your feedback and further suggestions on how to make this field even more powerful and useful. Please feel free to share your suggestions for further improvements to relational fields or other areas of IP.Content in our feedback forum. Otherwise, if you have feedback about the changes described in this blog entry, we look forward to your comments below!

IP.Content 2.3 Dev Update: Navigation Bar

bfarber posted a blog entry in Invision Community

We hope that everyone is enjoying reading about the upcoming changes you will see in IP.Content 2.3. As we outlined originally, our focus is on four primary goals: usability, consistency, SEO and strengthening our existing feature set. One common usability issue our clients have pointed out is that after they create a page, there is not an easy way to link to the page in the primary navigation bar. While you can certainly edit the skin to accomplish this (and indeed, this is what most clients ultimately do), we have decided to build into IP.Content 2.3 a more robust and easier to use solution. Our new primary navigation menu manager Beginning with IP.Content 2.3, there will be a new link under the IP.Content 'Settings' module labeled "Navigation Menu". In order to use this new feature, a hook (provided in the IP.Content download and installed automatically for you) must be enabled - if it is not, the page will show you an error message indicating that the hook must first be enabled before you can utilize the navigation menu manager. Otherwise, you will be presented with a list of the applications installed in their current positioned order (which determines the tab order on the front end). You can edit these applications from here to perform the following functions: Change the tab 'title' (the text that shows when you mouse over the tab) Change the application's public title (be aware that third party language packs can override this) Toggle whether the tab is hidden or not Change the tab permissions (who has access to see the tab) Add custom attributes to the anchor tag that is drawn. This is a feature unique to IP.Content, allowing you to add custom onclick handlers, rel attributes, and other similar attributes to your tabs if you have a need. In addition to being able to manage your existing applications, you can add custom tabs to your navigation bar from this page. Your custom tabs can be normal tabs that link to a page, or a dropdown menu (and you can choose whether to activate the dropdown menu when clicked, or when moused over). If you choose to make the tab a dropdown menu, you will be presented with an area to provide the links to display in this dropdown menu. As with applications, you can define the text to display on the tab, the 'title' or mouseover text, which groups can see the tab, and custom attributes to append to the HTML anchor tag. Additionally, you will need to supply the URL as well. You can reorder your tabs in any order you like, putting them before, after, or intermingled with your regular application tabs. A handy preview window at the top of the screen allows you to quickly and easily see what the end result will look like, without having to visit the community front end and refresh the page. This preview is shown inside an iframe and is updated automatically whenever you reorder your tabs. Tabs will automatically highlight when you are viewing that page, and disable associated application tabs from highlighting, if appropriate. For instance, if you link to an IP.Content page, the 'Pages' tab will no longer highlight, since a more appropriate tab has been lit up. Database strings are ignored, so any category or record you view on that page will still cause the tab to light up. Additionally, if you view a page that is linked to within a submenu, the submenu tab will light up. Here are a few screenshots to give you an idea of the interface Here is the overview screen, showing the tab bar preview, list of applications, and list of custom tabs you may have added. Editing an application allows you to manage tab and link related details Adding a custom tab allows you to create a submenu if you wish to, with an unlimited number of links in it New tab bar on the front end, complete with custom tabs and a dropdown menu Wrapping up And no, that's not a pun based on the fact that Christmas just passed. :wink: It's a natural action for a new client to add a page and proceed to want to place a tab link to that new page on the front end, only to find that this requires navigating to the template manager and jumping into the HTML code to accomplish. This new module in IP.Content should make it much easier for new users and advanced users alike to quickly add navigational tabs to their custom pages (or any link they want!) in IP.Content. We will be monitoring feedback on this new module to look for ways to improve it in future releases, so please share your thoughts in the IP.Content feedback forum. And we look forward to your comments on this new feature below!

IP.Content 2.3 Dev Update: Tagging

bfarber posted a blog entry in Invision Community

Tagging is a powerful feature made available through the IP.Board framework that allows you to collect "tags" for submitted data, either through an ad-hoc system whereby the members provide tags at will, or through a closed system where the available tags are pre-defined. Tag support in IP.Content is, arguably, the number one requested feature, and since we try to listen to our customers and deliver software with the features you have asked for, we have chosen to include tag support for IP.Content in version 2.3.0. Read on to learn about how tag support will work in the next release of IP.Content. Configuration While your global configuration serves as the basis for IP.Content tags (just as it does elsewhere throughout our suite of addon applications), you can override the global options on both a per-database and per-category basis. When configuring your databases (or your articles section), you can choose to enable tags, disable prefixes, and specify the pre-defined tags to use if you wish to use a closed system. When configuring categories in your databases, you can optionally override the per-database configuration. That is to say, all of your categories by default inherit the configuration from the database, but you can disable tagging, prefixes, or specify different pre-defined tags (or none at all) on a per-category basis if you wish. You can do this for individual categories, or for all of your categories - the choice is yours. If you do not disable prefixes, they will be available to you and your members based on your global configuration in the System Settings. Similarly, if you do not define per-database or per-category pre-defined tags, the ones you configure globally in the System Settings will be utilized instead (or the system will be an open system where users can submit whatever tags they want). Global group options and per-member overrides (for instance, disabling tag abilities for a specific member) are all honored in IP.Content. These options will allow you to enable and disable tagging as you see fit throughout your article and database sections, giving you full control over how tags function. Tag Collection Tag collection on the front end works just the same as it does for topics. The input capabilities are dynamically set based on your configuration, so the "Use first tag as prefix" option is shown if allowed, and the tag input field will turn into a select box if you have a closed tagging system. The same input capabilities are available in the ACP when you add or edit articles or database records from there, instead. Additionally, the tag input field is available if you promote a post to an article, and taking the system one step further - we even default the tags associated with the topic on the new article form for you. You can of course remove them, add to them, or change them, but you won't have to try to remember what tags were used for the topic, and neither will your members. Display and Searching Just as with topics, the tags will display in the database record listings (including the article "Archive" view). If a prefix was set, it will show before the article or record title. When you mouse over a tag, a helpful tooltip is shown to let you know you can click the tag to search for it. The tags will also display in frontpage templates in a similar fashion. When viewing an article or database record, the tags are of course shown here as well And to round everything off, we show the prefix and tags when viewing records in the ACP as well Tags are also displayed in search results, if applicable. And, of course, you can search for tags within the IP.Content application in the global site search, allowing you to easily find the articles and other database records that you have tagged. New Plugin Block: Tag Cloud With the introduction of tagging in IP.Content, we decided to go ahead and include a new plugin block to allow you to display a tag cloud block anywhere throughout IP.Content or IP.Board that you like. This plugin block could, as well, be included externally on any webpage on the internet using our external widget code if you so wished. The block will display exactly as it does on the forum board index. More To Expect We are happy to be able to deliver one of the most requested features for IP.Content 2.3, and we hope you are looking forward to the release. We have a lot more in store, so stay tuned for future blog entries outlining other changes you can expect to see with IP.Content 2.3. If you have suggestions for other improvements to IP.Content, please don't hesitate to share them in our IP.Content feedback forum!

Downloads

Release Notes

IPS4 Guides

IPS4 Developer Documentation

Invision Community Blog

Development Blog

Deprecation Tracker

Providers Directory

Projects

Release Notes v5

Invision Community 5 Bug Tracker

Forums

Events

Store

Gallery

Everything posted by bfarber