Invision Community Blog: Invision Community

IP.Board 3.2.0: New Text Editor, Part II

Thu, 10 Feb 2011 14:08:55 +0000

I recently introduced the new text editor in 3.2.0. This new text editor brings a robust rich text editor coupled with custom BBCode and an auto-save feature.

Today, I wanted show some user interface and usability improvements we've made in this area.

Firstly, where space is tight or where you don't want to be overwhelmed with the text editor, it is shown 'minimised'. The screenshot below shows this minimised state and the editor looks just like a regular HTML text area that everyone is familiar with.

Upon clicking the text area to begin making your post, it'll expand into the full editor ready for use:

We've also gone ahead and added 'Ajax reply' and 'Ajax quoting'. This improves the responsiveness of IP.Board by removing the page reloads and gives it more of an 'app' feel by posting and updating the page instantly.

I've taken a short video of this in action. Please note that you are viewing an in-development feature so the final design is not set for both the board and the editor and also that I'm currently working in "development" mode with CKEditor which means that there is a slight pause as it loads. This will not be the case when we package it up for release.

We hope that you enjoy these enhancements to commonly used areas and that it makes a common task more enjoyable. Please do keep in mind that cosmetic style issues and such will be addressed in future blog entries.

Spam Service Update

Wed, 09 Feb 2011 15:50:00 +0000

On 13 January 2011 we posted some information on our Spam Monitoring Service that was helping to block the huge amount of spam accounts hitting communities all over the web.

There's not much new to report - spam will always exist unfortunately - but we thought everyone would be interested to know that we were recently able to block huge ranges of attacking IP addresses.

IPS has a hosting division that provides managed community hosting for many thousands of communities. We host everyone from small, hobby sites to large enterprise clients with thousands of online users. We manage our own network and hardware to have the best possible control over the experience we can offer our clients.

We have been able to leverage our hosted network of thousands of communities to detect the signatures that the spammers were using to get past the various defenses in IP.Board. The spammers were using automated software to, for lack of a better term, brute-force their way past the reCAPTCHA service and this program left clear marks in our server logs because of the unique way it accessed the servers. Our network staff were able to, across our dozens of servers, gather up all the IP addresses used to register spam accounts and add those to the block-list on the Spam Monitoring Service.

While this is not a complete solution we were very happy to be able to detect these trends and block those spammers at the service level so the knowledge we gained from our own network could be applied to help all those with an active IP.Board license.

Fighting spam is an ongoing battle of course but we will continue to do our best to help blocking those who would try to disrupt your community. The better your community runs the better IPS grows and we take our responsibility to your community seriously.

IP.Nexus 1.2 Dev Update: Custom Packages Improvements

Wed, 09 Feb 2011 09:09:13 +0000

IP.Nexus has always had the ability create "custom packages" - you can specify a price and renewal terms and IP.Nexus will keep a log of the purchase and generate renewal invoices.
However, some options like member group promotion, custom modules, etc. are not available in this setup - and with the addition of advertisements and hosting packages, it is necessary to be able to generate custom packages of these types also.

In IP.Nexus 1.2 we've completely rewritten how custom packages are handled to allow this flexibility.
When generating an invoice, the normal "Custom Package" option appears in the dropdown - choosing this will show you a menu of available package types just like when creating a normal package.

The next screen shows all of the options that would normally be available to normal packages (except settings which don't make sense for custom packages, such as if the product should display in the store or only be available to certain member groups):

After creating the custom package and the invoice has been paid for, it displays just like a normal purchase, both in the Admin CP and the client area:

Administrators can of course edit any of the custom package settings from this page.

IP.Board 3.2.0: New Text Editor

Tue, 08 Feb 2011 16:20:00 +0000

Nearly ten years ago, IP.Board shipped with a pretty advanced functional editor that allowed you to quickly format your text in a rough "WYSIWYG" format. This was an exciting technology. As the main browsers started adding better support for this functionality we updated our own code to keep up.

The internet is a constantly evolving space and web browsers and technology rise and fall and keeping up with these changes gets harder and harder. This is why we've added a new editor to 3.2.0 that is developed by a dedicated team outside of Invision Power Services.

IP.Board 3.2.0 will come with the excellent CKEditor as standard. It's a well developed and well tested editor that is very extensible. It's constantly updated which means that we simply have to update the version that comes with IP.Board to get all the latest fixes.

In general use, the new editor is much better at "WYSIWYG" (rich text editing) than our own current implementation and we've extended it further.

Please keep in mind that the screenshots and videos below are using a very early development copy of IP.Board 3.2.0 and the editor will likely be skinned in a little more to match IP.Board before we release.

All the usual IP.Board tools are present
We've written a lot of plug-ins so that no functionality is lost. You can still create custom BBcodes and add buttons to the editor easily via the Admin CP and you can still use your own smilies.

Switching between modes
We love the new editor and as it supports nearly all major browsers, it's the first choice for replying and adding new topics. However, there are times when you want to edit the BBCode directly and with that in mind, you can switch between rich text editing mode and simple text mode without a page reload.

Auto Saving Text
A new and really handy feature we've added is auto save. As you type, the editor checks to see if there's any new content and if there is, it'll ping off via Ajax to save what you've written. If anything happens to your page, upon reloading you'll see it's stored your content and you can quickly restore it. You won't lose another post to a browser crash or server time out.

IP.Board saves as you go.

A refresh without posting allows you to view and optionally restore any content that has been auto saved.

We hope that you enjoy the new editor in IP.Board 3.2.0 and the extra functionality we've added. We're excited to use it ourselves!

IP.Board 3.2.0 Dev Update: Calendar Improvements, Part II: Consistency

Mon, 07 Feb 2011 14:09:06 +0000

We are continuing to make improvements to Calendar to both bring it more in line with the rest of the suite of IPS products and to modernize the application and make it more functional and useful for our customers. If you haven't read our first blog entry describing improvements you can expect to see with Calendar in IP.Board 3.2.0, Part I: SEO Improvements, feel free to take a moment to read our last blog entry to catch up. In this entry we'll discuss some of the changes you can expect to see in the Calendar with the release of IP.Board 3.2.0 that provide for a more consistent use of the application when stacked up to our other products.

Ratings

With the next update of Calendar, you will now be able to rate events very much like you can rate topics now. Ratings are saved through AJAX, just like with topics, falling back to a normal page load and redirect if javascript is disabled on the user's browser. You can control on a per-calendar basis which permission masks have permission to rate events within the calendar. If the user has permission to change their rating via their user group configuration, they will be able to change their previously rating for any event in Calendar as well.

Reputation

As with posts within the forums, you will now be able to give the member who submits an event reputation when viewing the event in Calendar. The reputation box displays just like it would for a forum post, allowing your users to quickly and easily understand the interface and functionality. By allowing reputation to be issued for event submissions in Calendar, you provide incentive to your users to submit events in your Calendar, making it all the more useful for your entire community!

Attachments

In our continued effort to increase consistency and functionality in Calendar, we have also implemented attachments for Calendar in the next update. When submitting or editing an event, the standard attachment uploader will be shown on the event posting form. You will be able to submit attachments based on the ACP configuration, just like you would be able to for posts in the forum. You can embed the attachments anywhere within the event content, or let Calendar just append the attachments to the end of the event information, again just like a post within the forum. Attachments may be useful for Calendar to share an event poster or flyer, to share coupons for an event, or to attach documentation users may need to be informed of prior to the event, just to name a few uses.

Notifications

Users can now optionally elect to be notified of new or updated events in Calendar, allowing your site to notify users of changes to the Calendar that they may elect to be informed about. Previous versions of Calendar provided no way to push information to the user to notify them of changes in Calendar. Any user interested in an event saved to your Calendar would need to manually check on it periodically to verify any changes made to the event, which we can agree is certainly not an optimal experience or expectation. As of the next version of Calendar, users can follow both individual calendars and individual events, allowing them to be notified of additions to calendars they are following, and updates to events they follow. By letting Calendar notify your users of changes, the software becomes more functional and useful in it's prime goal, sharing event-based data with the community.

Comments

Your members will now be able to comment on events submitted to Calendar. You can control on a per-calendar basis which permission masks can comment on events in each calendar, and you can also specify whether comments must be moderated prior to becoming visible (again, on a per-calendar basis). Comments in Calendar use the central commenting class of IP.Board, meaning it works identically to all other applications (e.g., identical to the blog commenting system at the bottom of this page), allowing for a consistent interface users can understand and utilize without having to learn how to use yet another posting screen. If a user opts to follow an event to be notified of updates to the event, they will also be notified of comments made on the event, allowing your site to better communicate updates to users about content they are interested in, and driving more activity within the Calendar in the process.

"Like"

Alongside commenting, users can now "like" calendars and events (the aforementioned "follow" capability), giving them the opportunity to either show their support for the calendar/event, to be notified of updates to the calendar/event, or both. As with IP.Blog, IP.Downloads, etc., the like system is a central class within IP.Board that is reused within Calendar, again to provide a consistent interface to users that they can learn and understand once, and expect to use throughout your entire site.

Sharing

The general use share strip that you see below each topic (and elsewhere throughout our suite of applications) has been added to Calendar. This allows users to share events through social networking sites, through email, or even to print an event's details out with their printer. If Facebook support is enabled in your ACP, the Facebook "like" button will also show up for the user, allowing them to share the event on Facebook. This is likely to drive activity to your site as the user's friends see this content shared on Facebook and follow it through to your site, where they may be interested and join your site...a win-win!

I realize this blog entry is pretty concise and the above-mentioned changes are not thoroughly detailed here, however because these are consistency-based changes to bring Calendar in-line with the rest of our products, the majority of our customers will already be familiar with everything mentioned above. By bringing these changes to Calendar, we allow for more useful functionality and more consistency with the rest of our suite of applications for IP.Board. Our next blog entry for Calendar will start detailing some of the changes unique to Calendar that we believe will make it much more useful for you and for your community. Stay tuned, and if you would like to be notified when we post future blog entries, be sure to "like" our company blog.

IP.Nexus 1.2 Dev Update: Editing Existing Packages

Fri, 04 Feb 2011 12:35:00 +0000

Currently in IP.Nexus when a package is edited, certain factors, like the group a user is moved into when purchasing the package, only apply to new purchases.
While less of an issue for traditional products there are times, particularly with advertisement and hosting packages, where you will want to apply these changes to existing purchases.

Let's say for example, a user has purchased a product called "Premium Membership" - note how the customer is in the group "Members":

I now decide that I'm going to create a new group for people who have purchased this group called "Premium Members" and change the product settings to move members into this group when they purchase the package - note that I'm editing the package that the member bought, not creating a new package:

When I save this, I will now see a new screen which indicates the change I've made can be applied to existing purchases:

If I choose the bottom option, no further action will be performed - the package will save and the changes will apply to new purchases only.
If I choose the top option, IP.Nexus will go through all existing purchases and make the change:

And all of the appropriate changes will be applied:

You can change almost any field for similar behaviour - removing the usergroup for example would move everyone back into their original groups, enabling the license key settings would cause license keys to be generated, for hosting accounts changing the allowances will update the account on the server, etc.

The system will also notice if you have customised a purchase and keep your changes in such a situation.
For example, let's say you've manually edit a customer's bandwidth allowance on their hosting account - when IP.Nexus goes to update the purchase it will notice the value has been customised and leave that particular setting alone (and update other settings as usual).

Of course, changes made in this way are logged on the customer page as normal, as if done manually.

Gallery 4: Mobile Skin

Wed, 02 Feb 2011 16:45:00 +0000

As the beta process for Gallery continues, I've found the time to implement the mobile theme that can be used by any mobile handset's browser or by the iPhone app we have available for free in the App Store.

The mobile theme is lightweight as expected and makes good use of the small cropped thumbs as well as the new 'small' image that is created. This saves a lot of bandwidth which will be a huge relief to those that don't have a good 3G signal.

I'll be updating Gallery here later today so you can see this live. The mobile theme will be available with Gallery 4.0 Beta 3.

The Gallery homepage:

If you scroll down you can access the global and member albums:

Album view:

Viewing an image:

I hope that you enjoy this new functionality when it's available!

IP.Nexus 1.2 Dev Update: Custom Customer Fields

Wed, 02 Feb 2011 10:34:00 +0000

IP.Nexus can ask the customer for various information (like their full name, postal address and phone number) when registering purchasing an item. This information is required for shipping, some payment gateways and the anti-fraud system.
Up until now, these fields were static - only the hard-coded fields were available and you could only specify all or no fields were required at registration or checkout.

In IP.Nexus 1.2, we've made these fields customisable - you can choose which should show where, which should be required and add and reorder fields as you see fit.

This means, that you could, for example, add a "Company" field, which would show alongside the others:

Of course, users can also edit custom fields in the client area, and administrators can edit them from the customer page.
Whenever the details is changed, it is logged to the customer history page as one would expect:

Administrators can also search by custom fields both from the quick-search in the menu, and the main customer search form:

This also means that since existing fields can be edited, you can now reorder or remove options from the "Country" field. You can also specify if "State" should be required or not.

IP.Board 3.2.0 Dev Update: Calendar Improvements, Part I: SEO Improvements

Mon, 31 Jan 2011 15:06:01 +0000

Work is underway on IP.Board 3.2 so we wanted to start divulging some of the great changes you can expect to see in our next upcoming major release. One area of IP.Board that we wanted to spend some time improving was the calendar, and this blog entry is the first of several outlining changes and improvements you can expect to see in the calendar with IP.Board 3.2.

We intend to post several blog entries detailing changes you can expect to see in calendar, so if there's something you're looking forward to and you don't see it mentioned in this blog entry that doesn't mean it won't be coming. Keep an eye out for future blog entries outlining calendar-related changes by "liking" this blog entry.

Meta Tags

Beginning with IP.Board 3.2, Calendar will start issuing appropriate meta tags based on the page you are viewing. When I say meta tags here, I'm not only talking about "keywords" and "description", although these are certainly included. I'm also talking about context-sensitive link tags that relate to SEO, such as the canonical URL tag.

Previously, Calendar set no meta tags at all. Now, calendar will set the following meta tags as appropriate, based on the page you are viewing:

Keywords: Calendar will begin setting the generic "keywords" meta tag
Description: Calendar will begin setting the generic "description" meta tag
Canonical URL: Calendar will set the appropriate "canonical" link tag to consolidate backlink weighting to the appropriate page in Calendar
Up: Calendar will set the appropriate "up" link tag which helps navigational tools and other software designed that reads and understands this link tag
Author: Calendar will set the appropriate "author" link tag, again supported by some navigational tools

Friendly URLs

While Calendar supported FURLs in previous versions of IP.Board, that support was limited and often times various versions of a URL would cause the FURL not to be generated correctly. We have re-evaluated all of the friendly URLs in Calendar for IP.Board 3.2, solidifying the format and enhancing support where appropriate.

First, of note, the event title is now added to the friendly URL when you view an event. A sample event URL might look like this: /calendar/1/event/47-first-test-event

Additionally, the calendar title itself is now added to all other friendly URLs in calendar. When viewing a single calendar you may see a URL like this: /calendar/1-community-calendar ; when viewing a month, you will see a URL like such: /calendar/1-community-calendar/02-2011 ; and when viewing a day the URL looks like so: /calendar/1-community-calendar/day-2011-01-18 .

Some areas of calendar previously generated URLs with URL components in different positions within the string. The end result of this was that URLs that should have been FURL often weren't, simply because our FURL engine couldn't match them up. We have gone through all such URLs and ensured the consistency of the URL format to make sure that all URLs that support friendly URL formatting now do so correctly.

hCalendar Microformat

We have also taken this opportunity to implement the hCalendar microformat into Calendar. Microformats are basically universally-accepted HTML structuring that, when used correctly, allow software to read the page and parse it like an XML document. In particular, the hCalendar microformat very closely resembles the iCalendar format, allowing some software to read Calendar just as if it were an iCal feed.

While this may seem like a small change on the surface, the more scripts that support universal formats, the higher the likelihood that other tools will be created to interact with these formats. As you can see at the previous link, there are already tools available to convert hCalendar into iCalendar, and vice-versa.

Layout Enhancements

While we are not ready to go into detail about some of these other changes just yet (but we will in a future blog entry!), we are making other changes that closely relate to SEO in the general structure and layout of Calendar. For instance, we have consolidated all event posting pages into one, so there is just one "Add Event" button now, and we are changing the current daily view to less-closely resemble the event view. We feel these two views being essentially duplicates of each other is not only confusing to the user, but may be seen as duplicate pages by some search engines while crawling your site (if you view a day that has one event, and the event directly, the output is nearly identical, even though they are two separate views within Calendar). These changes, while we are not targetting SEO specifically with them, do impact your search engine optimization directly and indirectly. Expect future blog entries to be posted that detail these changes further.

We hope you are excited about IP.Board 3.2, and want you to know we are excited to begin discussing things you can see coming in the next version. As mentioned previously, keep an eye out for our next blog entry on 3.2!

IP.Nexus 1.2 Dev Update: Payment Improvements & Anti-Fraud Protection

Thu, 27 Jan 2011 15:14:00 +0000

IP.Nexus aims to give you the tools you need to monetize your community, and the core of that is the actual transaction process.

We've made a number of changes in IP.Nexus 1.2 not only to make managing payments and gateways easier but to protect you against fraud, encourage renewals and generally make it easier for you to make more money.

Authorize.Net Recurring Payments

IP.Nexus has since version 1.0 supported the Authorize.Net payment gateway. In IP.Nexus 1.2, we're adding support for two systems which will automatically bill customers renewal charges:

The first is their "Automated Recurring Billing" system. This works very similar to PayPal Subscriptions - a profile is created on Authorize.Net with the payment information. Then when the renewal is due the card is automatically charged, and Nexus is notified.
For more information about Automated Recurring Billing, please see Authorize.Net's website.

The second is their "Customer Information Manager" system. This works by having Authorize.Net store the credit card information. IP.Nexus then calls Authorize.Net to make payments, when renewals are due or manually in the Admin CP.
This system gives greater flexibility as Nexus chooses when to charge, and you don't need to manually cancel recurring payments with Authorize.Net when a purchase is cancelled.
For more information about Customer Information Manager, please see Authorize.Net's website.

For both systems the user sees an option on the checkout asking if they want to be charged automatically:

PayPal Website Payments Pro

PayPal Website Payments Pro is a service provided by PayPal that allows merchants in the US, Canada and the UK to accept credit card payments directly on their website.
We're pleased to say that IP.Nexus will support PayPal Website Payments Pro, including recurring billing support.

For more information about PayPal Website Payments Pro, please see PayPal's website.

Improved Gateways Page

Different payment gateways have different requirements such as HTTPS, supported currencies and maximum transaction amounts. In IP.Nexus 1.2, we've added more information to the gateways page, including a warning box that will notify you of any misconfigurations:

Anti-Fraud Protection

MaxMind offers a Credit Card Fraud Protection, which here at IPS we've been using for years to help audit transactions for fraud.
In IP.Nexus 1.2, we will be adding integration for this service.

MaxMind returns a score between 0 and 100 indicating how likely a transaction is likely to be fraud. All the service needs is the user's address (which you can require on checkout), however it works best with gateways that use credit cards, i.e. Authorize.Net and PayPal Website Payments Pro.
Depending on the score returned, you can choose to manually approve or decline the transaction:

The purchase screen will also contain detailed information indicating the reasoning behind the score:

For more information about this service, please see MaxMind's website.

As always - if there's anything you'd like to see not mentioned here (including other payment gateways), please post in our feedback forum.

IP.Nexus 1.2 Dev Update: cPanel Integration

Mon, 24 Jan 2011 16:30:00 +0000

As was hinted in the blog entry last week, IP.Nexus 1.2 shall bring support for selling hosting packages.
Right away I'd like to mention that this at the moment will work with any server using cPanel and WHM - we will of course gauge interest for other control panels for future versions.

Hosting Packages

You set up hosting packages just like regular products and advertisement packages. There is a contextual settings tab which displays hosting-specific settings, and these packages then show up in the store:

Each package is assigned what we call a "Server Queue" - this is a collection of servers which the account may be created on.
So for example, you could have your "advanced" packages only use higher-powered servers. Servers can be part of multiple queues.

When the account is created, the server in the queue which has the least accounts is chosen to create the account on.

Purchasing a Hosting Package

When purchasing, users will be asked if they want to choose their own domain or use a subdomain of one of your domains. You can of course make only one of these options available.
If the customer chooses their own domain, they'll be shown your nameservers, and if they choose a subdomain, they'll be shown a list of options - both of these you can set up in the Admin CP.

Client Area Management

Customers can view their account information in the client area along with all other purchases:

From here they can also launch the control panel, FTP and change their password.
You can also configure options to allow users to purchase additional bandwidth for that billing cycle, if their bandwidth limit is reached.

Admin CP Management

The purchase page in the Admin CP shows the same information that is available in the client area, along with the control panel and FTP buttons:

Clicking the edit button will allow the administrator to edit specific allowances on the account, without the need to log into WHM:

The administrator of course, does not need to manually suspend and terminate accounts. If the customer does not renew their account, it will be suspended, and, after a certain number of days (configureable in the Admin CP), terminated.
Of course, using the normal package cancel function allows administrators to manually suspend accounts.

Server Management

In the Admin CP, you can view all of your servers along with the current load. From this page you can also reboot a server.

Clicking on a server will show you a list of accounts on that server. You will also see an overview of how much diskspace is in use and how much is allocated (so you can see if you're overselling). Nexus will also check all the accounts in it's local database against the server to check for any discrepancies:

Discrepancies can include an account not on the server but in the database (and vice versa), domain names not matching and account is suspended on the server but active in the database (and vice versa):

In addition to auditing each server, there is an "Audit All Servers" button which will check all servers for discrepancies.

We're sure that there will be many questions and comments about this new functionality - if there's anything you'd like to see not mentioned here, please post in our feedback forum.

IP.Nexus 1.2 Dev Update: Advertisements In Store

Thu, 20 Jan 2011 13:52:00 +0000

IP.Nexus features an advertisement system which allows administrators not only to set up circulating advertisements on their community, but sell advertising space too.
Currently in IP.Nexus, advertisements are purchased through a special location in the client area. In IP.Nexus 1.2 we will be removing this area and moving advertisements into the store.

When adding a package to the store, you will be shown a screen which asks you what type of package to add:

Then, when filling in the settings, there will be a contextual tab which shows settings for that package type. For products you'll see options about shipping and license keys, and for advertisements you'll see the usual advertisement package settings:

Users can then purchase advertisements through the store just like a normal product. They will be asked to provide their advertisement link and image on the same screen that custom package fields appear:

And view information about the advertisement on the normal purchase screen:

Not only does this make the process of purchasing advertisements easier, but all of the options available to packages are now also available to advertisements, including:

Only make certain advertisement packages appear to certain groups.
Give discounts on advertisements to certain members, for example, members who have purchased advertisements in the past.
For time-base advertisements, use renewal price settings to allow members to continuously pay for advertisement space.
Move users who purchase an advertisement into a different usergroup.
Allow users to upgrade to a higher package (for example, with more clicks) from within the client area.

Finally, this change opens the door for us to add more types of packages all of which display in the store. Like, for example, hosting packages...

Spam Monitoring Service Statistics

Thu, 13 Jan 2011 19:52:00 +0000

We thought everyone might find a few statistics from our Spam Monitoring Service interesting. Since the rate of spam registrations has greatly increased since the first of the year we are of course seeing greater activity on the service.

All stats are since 1 January 2011 to 13 January 2011.

The spam service has processed 300,000 requests and the rate is accelerating as more people are activating the service since spamming has increased over the last couple weeks.
About 30% were marked as spam accounts and therefore prevented from registering on IP.Board's that use the service. This is of course a much higher percentage then even a few weeks prior to the influx of spam registrations.
The service has "learned" from the activity and permanently black listed about 5000 emails and IP addresses.
Of those the service blocked, about 10% were due to IP.Board administrators and moderator using the "flag as spam" feature which tells the service that an account is from a spammer. So keep reporting!

It's our hope that Google's reCAPTCHA service will soon be improved. In the mean time be sure to follow the tips in our announcement to prevent spam registrations.

We can never 100% stop spam but our Spam Monitoring Service is another tool to help prevent registrations from impacting your community. The service is a free IPS Extra for anyone with an active IP.Board license or IPS Community Hosting client.

IPS Staff Opening

Thu, 01 Jan 1970 00:00:00 +0000

IPS is currently seeking a self-motivated individual to join our general support team. Requirements:

Excellent communication skills
Advanced knowledge of IP.Board and related applications
Ability to work in a fast-paced, team-oriented environment and be self-starter
Linux, cPanel/WHM experience strongly preferred, but not required

You must be 18 years or older to apply for this position. US residency required.

For more information about this position, please e-mail jobs@invisionpower.com. Be sure to include your background with IPS products and how you feel you could benefit the team.

Thank you for your interest!

IP.Nexus 1.2 Dev Update: License Keys

Wed, 12 Jan 2011 15:44:00 +0000

IP.Nexus 1.1 was released at the beginning of this month bringing a number of new features such as product options, reporting tools, advertisement system improvements and more.
Already we have started work on IP.Nexus 1.2 - while release is still a while away, we'll be posting blog entries during development to show you the upcoming new features.

The first new feature in IP.Nexus 1.2 that we wanted to talk about is a license key system.
Many users are using IP.Nexus to sell digital products, and currently there is no way to keep track of where your products are being used. In IP.Nexus 1.2, you will have the ability to generate license keys and use an API to call back to Nexus to activate and check license keys.

Generating License Keys

When creating a product, there are now a number of options regarding how to handle license keys:

License keys are by default generated either as a random md5 hash or several blocks of random letters and numbers - developers can also upload a simple PHP file to a certain folder to add more methods if you have your own way of generating license keys.

You can also choose an "identifier" for the license keys. Identifiers are provided to the API when activating the license key (for example, your program could ask users for their license key and their name or Email address) - as an additional security measure. Identifiers can be the customer's name, Email address or any custom field with the purchase. This is of course optional.

Managing License Keys

In the Admin CP, there is a new box on the purchase screen which displays information about the license key:

The grey box shows you the license key, when it was generated and it's current status and the table below shows where it's being used (you can set how many times a license key can be used).

The dropdown menu at the top with the other buttons contains options to reset (which will clear uses and generate a new key) or cancel (which will make API calls to check the license key fail) the key.

Of course, all actions related to license keys is also logged in the customer history page.

Users can see their license keys in the client area:

Using the API

The API uses XML-RPC to send and retrieve data. Full developer documentation will be available when Nexus 1.2 is released, but to give you an overview, there are four methods:

activate
This is what you call when the user enters their license key, for example, on an installation screen. You send Nexus the license key, the identifier (if necessary) and any additional information you want to save (for example, the version number). If the license key is invalid, or the key has already been used the maximum number of times, Nexus will return an error - otherwise, Nexus will log the IP address used to activate and the additional information you sent and return a success message along with the "usage id" which is an ID number given to that installation for that license key.

check
This is used to check that a license key is still valid, for example, you may call this periodically from your application. You send Nexus the license key, the identifier and the usage ID (returned from the activate method) and Nexus will return the status of the license key (if it's active or cancelled).

info
This is used to fetch information about a license key. You send Nexus the license key and the identifier and Nexus returns data about the key (when it was generated, how many times it's been used, etc.) the purchase associated with it (it's ID number, when it expires, all custom fields, etc.) and information about any child purchases (that is, purchases associated with the purchase the license key is associated with.

updateExtra
This is used to update the additional information send in the activate method. You send Nexus the license key, the identifier, usage ID and new information and Nexus will update the information locally and return a success message.

IP.Board 3.2 Development Expectations

Thu, 01 Jan 1970 00:00:00 +0000

We are into the development process for IP.Board 3.2 and wanted to share some general expectations for this release. First of all it won't be out for several months so don't start asking about release dates now :)

In addition to the obvious enhancements to make the software work better, faster, and smarter we are focusing our development toward three key goals:

Community Promotion
Front-end Usability
Modernization

Let's quickly talk about each of these three goals and what you can expect from IP.Board 3.2. We are dealing with a successful and widely used platform so we do not intend on making sweeping changes but instead picking individual features and areas of our software platform and working to improve them with an eye toward the three goals. For the purpose of this blog entry we are not going to get into specific features planned as you will start seeing blog entries on specific entries starting in early February.

Community Promotion

One could argue that this is the most important goal of IP.Board 3.2 in that our key focus is to help you promote your community and help it grow. Small things like a more streamlined registration process, more attractive emails sent to your users, and core features like view new content or SEO improved. These changes all add up to a community that is more inviting to new users and quicker and easier for new users to register and start participating.

Front-end Usability

As the web evolves so must software like IP.Board that is designed to be a showcase software for the ever-growing presence of online communities. To that end, we will be working on modernizing the default skin that comes with IP.Board. The goals of this redesign are to create a default skin that is clearly updated and modernized without completely scrapping all the great elements we have today. This means that, although skins on 3.1 and below will not work on 3.2, the update process for those older skins will not require a 100% rewrite as many elements will be shared between the old and new versions. To put it another way: version 3.2 will be cleaner, more modern, and slicker but it will still clearly be IP.Board.

In addition to purely cosmetic updates we will also be putting great effort into general usability. Small changes like rewording the name of a button or moving a control to a new area make a world of difference for your member's usability and will encourage them to stick around and participate in your community.

Modernization

There are many features and settings in our software that made sense years ago but today are antiquated, redundant, or simply pointless. We will be evaluating all the various settings in IP.Board to streamline the management of your community. One example is the Question and Answers settings for the registration page. There is a setting to enable this and then a whole separate page to configure the actual questions and answers. Why have both? We can remove the redundant setting without getting rid of any functionality. This is just one example of dozens of settings areas we can streamline without sacrificing functionality.

We are also going to be removing some select features that are a bit antiquated. Specifically the linear+ and outline views will be removed in IP.Board 3.2 as these two functions are relics of the beginning of the Internet and have really outlived their use. We realize a handful of clients may use these features but the vast majority do not.

And speaking of antiquated we will also be putting great effort into areas like the calendar and user profiles to make every part of our software modern and updated.

Of course this is a high-level summary of what to expect from IP.Board 3.2 but everyone at IPS is very excited about our plans for IP.Board 3.2 and cannot wait to show you specifics! Look for frequent blog entries starting in early February to present new features and enhancements. As is always our policy, IPS does not release specific roadmaps but instead posts blog entries about new features once they are completely finished and will definitely be in the next version.

IP.SEO Update

Thu, 23 Dec 2010 15:32:00 +0000

When we released IP.SEO 1.0, we said that we were going to start small and regularly update with new features based on user feedback and SEO trends. We've been staggered by the response to the first release, and have read all of the feedback topics posted so far. So in the spirit of those regular updates, we're now releasing IP.SEO 1.1 to cover some of the most requested features.

Here's what's new in today's release:

Sitemap pings added for Ask and Moreover, to add to the existing pings to Google, Yahoo and Bing.
XML-RPC ping support for services such as pingomatic.com, weblogs.com, blo.gs, etc. when new topics are posted. This will help you build up a few quick backlinks, and speed up the time-to-indexing of new topics.
Select a default skin specifically for guests and thus also for search engines, allowing you to cut out features that you don't feel are appropriate for guest/spider visitors.
Beta support for Microsoft SQL server.
For developers, a new base class for sitemap plugins. Example code for this and other features has been posted in the contributors forum.

This is just the first of many regular updates to IP.SEO, so please keep your feedback coming. We encourage you all to post your thoughts and ideas in the IP.SEO forum.

IP.Nexus 1.1 Dev Update: Miscellaneous Enhancements - Part 2

Tue, 21 Dec 2010 16:11:00 +0000

For our final entry on IP.Nexus 1.1, I'd like to sum up some of the additional general tweaks and enhancements since our last blog entry.

Marking an invoice unpaid

In IP.Nexus 1.0, once an invoice has been paid, there is no way to mark it "unpaid". While for most circumstances this makes sense, in the event a check bounces or something similar, you may want to undo everything done when the invoice was marked paid.

In IP.Nexus 1.1, when you attempt to mark a paid invoice unpaid, you'll see a screen like this:

This explains clearly what will happen, including:

Which purchases will be deleted.
Which purchases will have their renewal dates changed (if the invoice was a renewal invoice).
If anyone will have any commission revoked.
Which shipping orders will be deleted.

It will also warn you of any unexpected circumstances, such as if a purchase has been transferred to a different member, commission earned from the purchase has already been spent, or if any shipping orders have already been shipped:

Purchase Page

In IP.Nexus 1.0 there are specific pages in the Admin CP for viewing invoices, transactions and shipping orders. In 1.1, we've also added a page for viewing all the information about to a purchased item.

This allows you to view all information about a purchase which could sometimes be difficult to find previously, such as the invoice which created it, any renewal invoices, if the member will be returned to a different group when the purchase expires, and more.

Cancelling a Purchase

It could sometimes be confusing what "cancel" means when referring to a purchase. Sometimes you just want to disable renewals, sometimes you want to revoke any privileges gained by owning a purchase, and sometimes you want to delete it entirely.

In IP.Nexus 1.1, when you select cancel, it will present all of these options to you, explaining which does which, so that you can decide what action to take:

Share Links

We have added share links to the Store's product pages.

Print Invoice

While customers could always print invoices from their client area, we've also added a print button to the invoice page in the Admin CP.

Usability tweaks

We've made a few small tweaks to the interface to make things easier to use, including:

We've added a "duplicate" button for packages, to save you having to select the same settings for similar packages.
We've added a link to the customer page when viewing a shipping order.
We've added a "Save and Reload" button when editing packages.
We've added a button when viewing your purchases in the client area to submit a support request associated with a purchase right from the list.

Welcome to IP.Gallery 4.0

Thu, 01 Jan 1970 00:00:00 +0000

IP.Gallery 4.0 is now available to use on our forums!

Please keep in mind that this is beta software and still very much work in progress so expect to come across bugs and such. As there is bound to be a lot of feedback, I'll close this blog for comments and kindly ask that you post any feedback in the Gallery forum

Please report all bugs in the tracker as usual

Please let us know your thoughts!

IP.Nexus 1.1 Dev Update: Miscellaneous Enhancements

Fri, 17 Dec 2010 11:21:00 +0000

Email on new order

You can now set packages to send an email when a member purchases that package.

Usergroup Discounts

You can now provide discounts to users in a particular group.

Auto-resolve Support Requests

You can now set support requests to automatically be set to resolved after a given time of inactivity.

Group Name Limit

We've increased the length package group names can be to 255 characters.

https

In IP.Nexus 1.0, there was a setting which when enabled would make the payment screen server over https. The scope of this setting has been extended to the entire checkout process, the client area when providing information and support requests.

Delete Transactions

Transactions can now be deleted.

Support Request API

We have introduced two central models for handling support requests, one for support requests and one for support replies.

This allows you to create support requests and replies using a simple API. For example, to create a support request:

supportRequest::create( "Title", 1, 1, NULL, 1, NULL, NULL, supportReply::create( supportReply::REPLY_MEMBER, 1, "Message" ) );

Complete developer documentation can be seen here.

IP.Nexus 1.1 Dev Update: Advertisement Enhancements

Thu, 16 Dec 2010 10:38:00 +0000

IP.Nexus has an advertisements feature, allowing administrators to display advertisements on their community and sell advertising space to third parties.

We've spent some time going over some of the suggestions we've received for the advertisements system and have made the following enhancements for IP.Nexus 1.1.

Start/End Time

Advertisements can now be specified with start and end times for time-specific campaigns.

Advertisement Packages: Expire by length

In hand with the option to set a start/end time, you can now specify that purchased advertisements last a certain length of time, opposed to a number of clicks or impressions.

Advertisement Package Descriptions

You can now specify a description for advertisement packages which will display on the purchase screen.

Admin Image Upload

Currently, when an administrator adds an advertisement they must specify a URL to an image (or HTML code).
As of Nexus 1.1, administrators will see an option to upload an image too.

Circulation Mode

In IP.Nexus 1.0, if there is more than one advertisement per location, a random advertisement is selected from the pool.
In IP.Nexus 1.1, we've added a setting which allows you to continue using this behaviour, or to always use the most recently added advertisement. This is useful if you want to have a generic advertisement set up by the administrator but allow purchased advertisements to override that for their duration.

Maximum Number of Advertisements

You may only want one advertisement in each location at a time, so that advertisements don't circulate at all. In IP.Nexus 1.1, we've added a setting allowing you to specify the maximum number of advertisements per location.
Administrators of course can oevrride this, but if there is the specified number of advertisements in a given location, users will not be able to purchase advertisement packages which add advertisements to that location.

Alignment

We've added a new setting which allows you to choose how to align your advertisements.

Size Restrictions

You can now specify in an advertisement package the maximum size for advertisements created by that package.

External Access

Currently, IP.Nexus displays advertisements in pre-set locations on your community. As of IP.Nexus 1.1, you can include advertisements in other areas of your skin, in IP.Content blocks and even in external pages and applications outside of IP.Board.

To place an advertisement in a template or IP.Content block, you can simply use the tag:

{parse advertisement="1"}

The tag can take either the ID number for the advertisement to display, or the key for the location, which will use IP.Nexus' normal logic for fetching the advertisement. For example, using this tag:

{parse advertisement="ad_code_board_index_header"}

Would display whatever advertisement is configured to show in the board index header - if more than one is configured, Nexus will either pick a random one, or the most recent one (as per the circulation setting described above).

To place an advertisement on an external site, you can call a new REST API which will out put the contents - the file is located at:

http://www.yoursite.com/interface/advertisements.php

You simply need to pass a single variable in the query string which is the same as the parse tag above (ID number or location key).

For example, you might use something like this to add your advertisement to a website outside of IP.Board:

If you have more in-depth feedback or ideas please use our feedback forum so your suggestions can be given proper attention. Otherwise, feel free to comment on this entry below.

IP.Nexus 1.1 Dev Update: Guest Support Requests

Wed, 15 Dec 2010 12:43:00 +0000

IP.Nexus 1.0 has the ability for users to send in support requests via Email. Nexus handles these internally as "Guest" support requests and the users can reply by responding to the Email notifications Nexus sends when a staff member replies.

In IP.Nexus 1.1, we've added a web-based interface for guests to create support requests too. This makes it easier for users to submit pre-sales questions without having to create an account, and is particularly useful if you are unable or unwilling to use incoming Emails.

Guests can now access the new support request screen like regular members, where they'll be prompted for, in addition to normal support request information, their Email address. They'll also need to fill in a Captcha verification if you have that setting enabled.

IP.Nexus will then send them a confirmation Email which will contain a link where they can retrieve their support request to reply later. This then displays as a normal support request:

They can also of course reply to this notification if you have that incoming Emails enabled.

If a user has created support requests as a guest then registers, support requests with their Email address will become associated with their account.

Introducing IP.SEO

Tue, 14 Dec 2010 18:07:00 +0000

As anyone with an interest in it will know, search engine optimisation is a difficult and contentious field, not least because of the amount of different opinions and the lack of any definite answers. There are a few things we all know to be good, and a few things that we all know are definitely bad, but the rest is a bit of a gray area. We've done a lot of work to make sure that all of the definite things are covered in IP.Board, and feel we've done a great job at this. Until now however, there's been a selection of features and additions we simply couldn't add to IP.Board core (due to being too resource intensive for many, or too niche), and thus were missing from the product. IP.SEO fills that gap.

IP.SEO is the combination of two applications we've already built: IPS Sitemap Generator and Search Activity - with the addition of some new features. It's designed to be an application we can add all those missing SEO features to, for those that want them, without overloading those users who do not. Here's some of what it does:

Sitemap Generation

Just like in the IPS Sitemap Generator, IP.SEO will build a sitemap for each of your applications that support it, including the forums, IP.Blog, IP.Downloads, IP.Content and more. It will then ping your sitemap to all of the major search engines to let them know what's new.

Search Activity Statistics

This area of IP.SEO is designed for those who love to track what's going on with their forum. It'll tell you just how many times you've had search spiders visit your site, how many users have come to your site from search, their keywords and what pages they landed on.

Meta Tags - Anywhere

This feature is new to IP.SEO - You can now add meta tags (and, as an added bonus, change title tags) on any page of your site. It works as follows:

Once you've configured all of your various meta tags on the above page, you can see them in action straight away:

You can even include the "original" page title (without the board name on the end) in your custom titles by doing entering something like: "My Great Content: {oldTitle}", or simply "{oldTitle}". As you can see above, you can also use * as a wildcard anywhere in your URL to apply meta tags a whole section, or your whole site.

SEO Guidance

Also new in IP.SEO, we've added an "Items Requiring Attention" area that will give you guidance on potential problems with your IP.Board configuration. This serves as our guidance to improving your site for search, you can choose to ignore individual notices.

We intend to update this application regularly, both to add new features and to update our checks for "items requiring attention", to make sure we're always delivering the best SEO performance we can for you. We've already got some great changes planned, including the much-requested HTML sitemaps functionality. If you've got any questions or requests, please drop them in our IP.SEO forum.

The great news is, this new application is already built! We're just doing our final testing, and will be releasing the application for free in the next day or two, so be sure to keep an eye on the IPS Marketplace for it!

IP.Nexus 1.1 Dev Update: Guest Checkout

Mon, 13 Dec 2010 15:57:00 +0000

In IP.Nexus 1.0, when a user visits the store and tries to make a purchase, they are redirected to the login screen where they can register or log in. Once logged in, they are redirected back to the checkout screen.

While this works well, it can be confusing to some users to be removed from the checkout process. In IP.Nexus 1.1, we've made this process a little smoother.

First of all, if a guest attempts to make a donation, they will not be prompted to log in - guests will be able to make donations without registering an account first.
You can disable this in the Admin CP so users must be logged in to make a donation if you prefer.

For normal purchases, when a user attempts to make a purchase when not logged in, rather than being redirected to the login screen they will simply see a few extra fields on the personal information screen:

By simply filling in those details, IP.Nexus will create an account, log them in, and the checkout process will continue as normal.
They can also click the login link, which will take them to the login screen, and will be immediately returned to checkout after logging in.

Some notes on this:

You will notice the screenshot is not prompting for a username. IP.Nexus will automatically set their username based on their real name. You can choose to prompt the user for a username if you prefer.
The setting specifying whether or not a user should enter personal information when registering is still honoured. If that is not enabled, and they are not purchasing a physical item, Nexus won't ask them for their address.
You can enable Captcha on this screen.
Validation settings are still honoured. If you have Email or Admin validation enabled, Nexus will put the user in the "Validating" group and send out the validation Email and/or admin notification Email.
If you have disabled registrations, users can still register through this method - this allows you to only allow users who are purchasing items to create accounts. You can of course disable guest access to the store if you do not want this.
The Spam Monitoring Service settings are honoured.
If COPPA is enabled, they must use the normal registration process since they will need to fill in the COPPA form before the account can be created. Nexus will continue to function as it does in 1.0 if COPPA is enabled.