Mark

When adding a package to an invoice being manually generated, the custom fields bit sometimes displays "Array"

As we wrap up principle development of new features for IP.Board 3.4, I wanted to go through some of the other changes we've implemented for the new release. Share a single post A common feature request has been the ability to share a single post. You might want to share a great reply to a topic on Facebook or perhaps email a link to an interesting post to a friend. You can now do this by clicking either the post number or the little share icon to the right of the post number. This brings up a new modal window System Templates Some "system templates" such as the wrapper used for HTML emails were previously only editable by manually changing the files which contained those templates. This is inconvenient, especially as it means one has to remember not to upload those files when upgrading IP.Board. In IP.Board 3.4, these templates will be editable from the Admin CP making it much easier to maintain edited versions of these templates. Mobile Moderation Our mobile theme is suitable for all mobile devices. Even though we have our mobile application available for the iPhone and iPad, we want to ensure that other devices are able to interact with IP.Board. A very common request has been to enable basic moderation actions from within the mobile theme. To that end, we've added buttons for common topic moderation into the mobile skin. Editor Pasting A lot of the time you find that you just want to paste plain text into the editor so you don't have to then remove formatting such as background and font colors. We've made this an option from within the IP.Board 3.4 editor via the new Options icon (far right on the screen shot). You can still paste as rich text by clicking on the relevant paste button on the top right section of the toolbar. We hoped that you've enjoyed reading this series of blogs on IP.Board 3.4. We're currently putting the finishing touches to this major new release and can't wait make it available for release!

IP.Board has for a long time allowed administrators to send bulk mails to members, including the ability to filter recipients and use variables to customise the message sent to each member. This is an important tool for communicating with the members of your community and in 3.4 we've made it even better. The problem with bulk mail Sending vast amounts of email through your own server is troublesome. Firstly, it takes a long time (you can't just send out thousands of emails in one go) and due to the way PHP works, you need to have activity on your community to initiate the sending of each batch of emails (you could set up a cron, but you'd probably only want it running when you actually have a bulk mail sending, and they're fiddly to set up). Secondly, if you're on shared hosting, other sites on the same server may have given your server a bad reputation and caused it to be placed on blacklists, this causes the emails you send to be more likely to be marked as junk. Thirdly, sending vast amounts of email through your own server is an expensive task - most communities we see use the same server for sending emails as hosting the community itself, meaning resources are being used for the sending of those emails and not serving your users. Fortunately, these problems are well-known throughout the internet and a number of companies offer services to send mail for you, through their servers to alleviate these problems. In addition, these services provide web applications where you can view statistics, and track how many of your emails have been opened, rejected, etc. We're really pleased to announce that in IP.Board 3.4 we've built in integration with Mandrill, a service of well-known and respected MailChimp. How it works Setting up integration with Mandrill is really easy. In the new "Community Enhancements" section of the Admin CP (which we've mentioned in earlier blog entries), there will be an option for Mandrill: After creating an account on their site, all you do is enter your account details: IP.Board will from then on send all bulk mails through the Mandrill service. And it's not just bulk mails. You can even configure IP.Board's normal email settings to send all outgoing emails via Mandrill's SMTP server. Sending bulk mails As part of our improvements, we've also: Tidied up the interface for sending bulk mails Improved the unsubscribe link sent in emails to be a one-click link (rather than requiring users sign in and uncheck the box) Built extension capabilities the filter options available when composing a bulk mail, meaning 3rd party applications can add their own filter options (we'll use this for example, in a future version of IP.Nexus to allow you to send bulk mails to anyone who's purchased a particular item). Added a tab on the confirmation screen to allow you to view the list of recipients before actually sending the bulk mail. All these improvements are present even if you choose not to use the new Mandrill integration. Statistics and Tracking You can view statistics via the Mandrill web application. Emails sent from IP.Board's bulk mail system automatically enable tracking for opens and clicks. They even have iPhone and Android apps available. Pricing Full pricing details are available from Mandrill - for up to 12,000 emails per month though, the service is completely free.

A Content Delivery Network, or CDN is a distributed system of servers to provide high-availablity and high-performance. For example, rather than serving your CSS, images and Javascript from the same webserver that PHP and the rest of your community runs on, these are loaded from a network of servers, improving performance and reducing load on your server. Having a CDN can improve your community's quality, reliability and scalability, as well as reduce your hosting costs. By offloading the serving of images, CSS, Javascript, etc. you free up your system resources to serve the real content which makes for a better experience. Some say that there are also SEO advantages o CDN use. The IPS Community Suite has supported Content Delivery Networks for some time. However, they can be expensive and difficult to set up. Many clients want a CDN but do not know where to go and we hope to help them out. We are pleased to announce a new service, IPS CDN, which will allow you to quickly, easily and inexpensively start using this important technology on your community. How does it work? The IPS CDN service will be supported in IP.Board 3.4. After upgrading, you'll notice a new section of the Admin Control Panel called "Community Enhancements" - one of the options available here is "IPS CDN". On this page you'll be able to enable the CDN, which will take you to a new page in the client area where you can purchase credits: Note that the packages shown in this screenshot are examples only. As you will notice from that screenshot, you can purchase credits for your CDN account as and when you want, and optionally set up your account to automatically top-up as you run low on credit. Once this is done, your community will automatically start using the CDN service. If you do not set up automatic top-up, we'll send you an email when your account is running low on credit (when you go below 10GB, 5GB and 1GB). If your credit runs out without you topping up, your community will automatically stop using the CDN service - there will be no interruption to the running of your community, it will automatically notice there's no credit remaining and go back to serving resources locally. If you top up again, it will automatically enable itself again. One problem of using the IPS Community Suite (or indeed any application) with a CDN is that when a resource is changed locally, the CDN needs to be recached to notice the new changes. Unless the CDN is notified of a change it will keep serving the old copy of the file - sometimes for up to 24 hours. This can cause much confusion to you and your visitors. To remedy that problem: since editing skins and the CSS is done from the Admin CP, the system will automatically call the CDN service to recache resources as and when you change them, so you don't need to worry about this. You can keep track of your usage in the Admin CP, where you'll be able to see a graph with your usage over the last 7 days. You'll also be able to buy more credits, disable the system, and manually recache. How much does it cost? The service will be based on "Pay As You Go" pricing. Meaning there's no minimum sign up fee - you simply purchase credit on your account and that credit is good for an amount of data transferred through the service. As you use the CDN, your credit will decrease and you can top up with more. The base price for the CDN will be at or around $0.18 per GB of bandwidth served through the CDN and may drop as you reach higher levels. We realize this is rather unspecific right now but we are negotiating with CDN providers to get the best bulk pricing. It will be our goal to pass any volume savings we receive on to our clients as we look at this service is a great way to enhance our client's experience and want to encourage its use. Everyone will however be offered their first Gigabyte for free to try out the service before purchase. Of course if you do not want to use the IPS CDN service and want to use another provider you can certainly do that. We believe the click and go setup for the IPS CDN service will encourage usage and benefit all IPS Community Suite users. Future CDN Integration Right now the CDN is a basic "pull" implementation whereby it simply pulls data from your live server then serves it via its cache. In the future we hope to implement storage services. This would mean that uploaded files would be stored on the CDN rather than your local computer. This is great to reduce storage costs on your hosting and also means that, other than the actual processing of data, your community's files are geographically distributed. For our power users this would also mean even easier cluster/cloud hosting. Storage and other CDN integrations will come in future versions of the IPS Community Suite so for now enjoy the current features while we work on even more great additions!

VigLink is a service which works with a number of affiliates to provide you commission when a user visits the affiliate from your website. So, as an example, let's say someone posts a link to an Amazon item on your community, with VigLink integration, you'll be provided with compensation every time a user purchases that item if they bought it after following the link from your site. VigLink, and services like it, have been a popular addition for many of our clients and we have received requests for built in integration. Monetizing your community is something IPS has been working to enhance support for over the recent years. From ad code integration spots to our full commerce system IP.Nexus our clients who are interested in monetizing their community have benefited greatly. The addition of VigLink enhances those offerings. This video provides more information on how VigLink works: We've been working closely with VigLink to provide direct integration with this service in IP.Board 3.4. Setting it up couldn't be easier - we've built a new page in the Admin CP called "Community Enhancements" which lists all of the services we integrate with. You simply click on "VigLink" in this page and you'll be taken to the VigLink site where you can either sign up, or log in with your existing VigLink account, if you have one: Once that's done - you're all setup. You don't need to copy and paste any code - the integration will be enabled for you, and you can now track your usage through your VigLink account. There's a number of settings you can configure for finer control over how the system works. You can set which users VigLink applies to (both in terms of who gets redirected through them and whose posts get VigLink enabled) and you can disable the system on a per-forum basis: We'll also be releasing an update to our iOS app around the 3.4 release to support this integration too. IPS benefits financially through a reciprocal marketing agreement when someone uses VigLink through our software however we do not take any cut of the commission offered from VigLink to you. Anyone familiar with IPS knows that taking a cut is not how we would operate :smile: Community Enhancements Section Mentioned earlier in this entry, the AdminCP has a new section called Community Enhancements. This area contains all the various external services that your IPS Community Suite can use to enhance your community. It's not all new though: we have moved services like our Spam Monitoring Service to this section as that too is an external enhancement to your community. We are also introducing some new services that will integrate with your community in this section! Certain services are from external partners, like VigLink, that clients may opt to use and some are new IPS-created services. Some services are free and some carry a small cost depending on the nature of what's being offered. They are all of course optional and if you do not enable them they do not execute or engage any resources in the Suite. Keep an eye out for future blog entries introducing these new Community Enhancements!

The IPS Community Suite provides a fantastic community solution for all kinds of websites. For many of our customers, the community is just one component of their site. Many of these customers utilise single sign-on systems for integrating the community with the other areas. At IPS, we get requests for this on a regular basis, and over the years, I've worked on many of these solutions as part of my day-to-day workload. Companies like Evernote and Roxio have created a single sign-on solution with the IPS Community Suite and their existing user databases. Other companies which manage large numbers of communities like the NFL and the NHL have created a single sign-on solution allowing all their communities to share the same user database. Creating these systems can be quite arduous though. Every setup has different ways of handling data and systems must be created bespoke to each situation. 6 years ago, we had an idea to simplify this. What if we could create a solution that would allow a network of web applications to share user information? We created a solution and called it IP.Converge. Over these 6 years though, the internet has changed. IP.Converge was designed to be a "master" in a network of "Converge compatible" applications. This approach had two main shortcomings: firstly, it is often the case that our software needs to be the "slave" in a single sign-on network, secondly, the approach was too general which made both facilitating full single sign-on (where users are automatically logged into all applications after logging into one) was difficult, and making non-IPS software compatible with Converge was extremely difficult. Fortunately, we think we've come up with a better solution. As of IP.Board 3.4, we are completely removing support for IP.Converge, and have developed a new system, which we're calling IPS Connect. IPS Connect has no central application. In an IPS Connect network, one of the applications will serve as the master, and there will be any number of slaves working off it. When writing IPS Connect, we had three main objectives: So what does this mean? As of IP.Board 3.4, it will be easy, and completely seamless to create a single sign-on network between 2 or more IP.Boards, and 3rd party developers will also be able to write support for any other web application to join in in the network. How does it work? For the simplicity of this example, let's say you're networking 2 IP.Board installations. The "master" installation has a secret key which will be given the "slave" installation. When a user visits the "slave" installation, IP.Board will check if they are logged into the "master" installation - if they are it will log them in automatically, creating the account if necessary. If they're not logged in, but then choose to log in on the "slave" installation - they will automatically be logged into the "master" installation. This happens transparently, without the user leaving the "slave" installation. When a user registers or updates their account, the "master" application will be pinged and updated. Again, this happens transparently. How simple is it to write support for my custom web application? Really simple! If you want your application to be the "master", all you need to do is create a single php file which "slave" applications will send requests to. This needs to do things like facilitate log ins, account registrations, etc. If you want your application to be the "slave", you simply ping that file on the "master" application when stuff happens. We've created 2 completely functional example websites which demonstrate exactly how to do this, which will be available to download when 3.4 is released. [*]Single Sign-On must be completely automatic and effortless. After logging into any application in the network, the user should be automatically logged into all others. And similarly, after logging out, the same. [*]The process should be completely transparent to the user. The user should be able to register an account, or update account information on any application in the network, and these changes should be pushed transparently to the other applications. [*]It should be easy for developers to make their web applications compatible with IPS Connect - and they should be able to make their web applications serve as either the master or the slave.

IP.SEO is a popular free add-on for IP.Board which provides many additional SEO features for your community. IP.SEO has proved so popular since it's introduction that as of IP.Board 3.4, we're going to be moving it's features into the core of IP.Board meaning that a separate application will no longer be necessary. If you're not already familiar with IP.SEO, here's an overview the features it provides, all of which will be included in IP.Board 3.4: Sitemap XML site maps provide a great way to show search engines the content on your community. All IPS applications are supported, and third party applications can also add their own support. You can even specify a "priority" for each forum and other areas of your community to tell search engines which content is more important. IP.Board will automatically update your site map as new content is generated and will automatically ping search engines to let them know your site map has been updated. SEO Advice A new screen in the Admin CP will provide advice on areas of configuration which can be adjusted to provide the best SEO. Search Activity You will now be able to view graphs showing the visits your community has received from search engine spiders, and visits received from users who found your community via a search engine. You can even see the term that users searched for which led them to your community. Meta Tags You can now edit the page title and meta tags for any page on your community. You can also use a "Live Meta Tag Editor" which will allow you to browse your community, adding tags to the pages as you visit them. Miscellaneous FeaturesIP.Board will now be able to automatically ping XML-RPC ping services whenever a new topic is created. You will now be able to select a particular skin which will be used by guests. You can add Google Analytics tracking code through a setting in the Admin CP to integrate with the Google Analytics service. More to come on SEO... this is not the only SEO change being made in 3.4 so keep watching our company blog!

Hopefully most of you don't have the need to visit our bug tracker enough to have noticed, but we recently switched from a third party application for managing our bugs to IP.Content. The history of the software we used to use for our bug tracker goes back quite a bit. It was originally written by Matt, many years ago - before that we used regular forum topics as bug reports! A couple of years ago, around the time IP.Board 3.0 was released, we handed over the codebase to a group of volunteers who wanted to develop the bug tracker application further - and they did. The developers have done a fantastic job with Tracker, however since then we've released IP.Content, our own application which lets you create (amongst other things) custom databases. We decided that since moving forward it's definitely easier for us to be using our own applications (otherwise we have issues whenever we upgrade this site to beta software) especially as soon we'll be developing them all under one release cycle, and IP.Content is more than capable of handling the task, to switch from Tracker to IP.Content. So what did we do to turn IP.Content into a fully featured bug tracker? Actually, nothing special! IP.Content's databases already have support for categories (we created one for each product) and custom fields (we created fields for "status", "version" and "fixed in version"). We didn't need to do any skinning either - the default database templates work fantastic for a bug tracker. We also took this opportunity to have one of our non-technical members of staff create the database. This gave us some great ideas on improving the system for ease of use. In fact, there was only 3 hurdles we had to overcome: 1. Filter Bars When you're working through bug reports you only really want to see open bug reports - we needed a way to filter the records being shown created on the custom "status" field we'd created. After thinking about the best approach for this, we realised that there's probably other uses for IP.Content which also might benefit from fields being "filterable". So we went ahead and added the feature to IP.Content. When the next version of IP.Content is released, any enumerable field type (dropdowns, radio boxes, checkboxes) will be able to be selected as "filterable". When viewing records you'll then see a sidebar allowing you to select one or more of those values to filter the records by. This is what it looks like in our new bug tracker: 2. Quick Changing Fields Unlike most database uses, in a bug tracker, you need to be able to change the record's data (status, fixed in version) quickly - and often at the same time as making a comment on the report. We decided for this we'd need to write some code specifically for our needs. Fortunately, IP.Board's hook system makes this really easy. In case anyone out there is feeling particularly geeky and wants to know how this works, the hook has 3 parts: A skin overloader which adds dropdown boxes above the comment form A data hook which intercepts the comment being added and updates the records data based on the dropdown box values. It also edits the comment that was posted and adds in "Updating Status to: X", or whatever was changed. An action overloader which stops an error being thrown if the comment is empty. In total, the hook is just 81 lines of code and took about 30 minutes to write. 3. Moving the data Our final hurdle was converting the data (for which I whipped up a CLI script). Naturally, we also had to make sure that old bug report links gave HTTP 301 redirects to the new reports - wouldn't want our SEO to suffer! To do this, I just dropped a few lines of code in one of the old Tracker source files. So here it is, our brand new bug tracker, completely powered by IP.Content. Read more about IP.Content or try it for free. If you have any questions about what IP.Content can do, shoot us an email - we'd love to hear from you.

To wrap up our blog entries on IP.Nexus, there's a few more additional features and enhancements that we haven't previously covered: Custom Advertisement Zones IP.Nexus allows you to create advertisements and even sell advertisement space on your community. There are several different areas where the IPS Community Suite has built-in advertisement spots where Nexus can place advertisements. In IP.Nexus 1.5, you can create your own custom "zones" and then add tags into your skin templates, IP.Content pages or even external websites outside of your community to display the advertisements in the zones you have created. Expected Output Monitoring IP.Nexus can monitor your servers and report to you if any of them are not responding. Sometimes though, a site can be having issues, but not actually be reporting as down - for example, if a database table had collapsed, the server would be reporting as online, even though the site isn't actually usable. In IP.Nexus 1.5, you'll be able to create custom "Expected Output Monitoring" rules. IP.Nexus will then call the URLs you provide at regular intervals, and if the page output is not what is expected, will notify you that there's an issue. Transaction Review Details on the items being purchased is now available in the transaction review screen without having to click into the invoice. Voiding Customers IP.Nexus has a tool to quickly ban a customer, refund their transactions, close their support requests, etc. Sometimes however, you might want to only perform a select few of these actions. In IP.Nexus 1.5, each "action" now appears as an individual toggle when you go to void a customer. Resource Improvements When we work on a new release of any application, we look at the resource usage to see if any improvements can be made. We've made several changes to improve the resource usage of IP.Nexus. The most significant of these changes is a change to how package data is cached. Some communities use IP.Nexus with lots of packages in many categories. Up until now, IP.Nexus stored all packages in a cache so that they didn't need to be fetched from the database on every load. However, for communities with lots of categories and packages, this can result in a large cache which ends up using more resources to process than is necessary. In IP.Nexus 1.5 we've reworked some of the logic to make this method of caching data no longer necessary, and as a result, Nexus is able to scale much more efficiently when there is a large number of packages. This wraps up all of the changes we're making in IP.Nexus 1.5. Keep an eye on our pre-release testing forum over the next couple of weeks for public betas :smile:

Our last few blog entries on Nexus have talked about some of the larger changes we've been making to the storefront and how billing is handled. In this blog entry, I wanted to go over some of the smaller changes we've made in these areas :smile: Gift Vouchers Starting with Nexus 1.5, customers can purchase gift vouchers, which can then be redeemed in your store. If you have enabled this, when in the store, they'll see two new options underneath the package categories: Customers will then be able to select a gift voucher amount from the options you have set in the Admin CP, or, if you have enabled it, enter their own amount: \ Vouchers can either be emailed straight to the recipient or printed off. The voucher is given in the form of a code, which can then be entered into the store to redeem. Nexus will keep track of who used vouchers purchased by whom and will show all this information in the normal customer history screen. And of course, all this can be done from the mobile skin too: Multiple Billing Cycles IP.Nexus allows you to create recurring packages with whatever renewal terms you specify. Sometimes though, you might want to give several different options - for example, let's say you wanted a package which costs $10 per month or $100 a year (or whatever). In IP.Nexus 1.5, this is now possible. You can create as many different renewal options as you like: When a customer goes to purchase a package which has more than one renewal option, a drop down will be displayed for them to select their desired renewal option: Self Purchase Management You're probably very familiar with getting support requests from customers who want to renew their purchase for a period of time in advance (we, for example, often get people asking to pay for a year's hosting) or cancel their purchase. In IP.Nexus (provided you have enabled it), customers will be able to renew purchases for any length of time up to what you have allowed, and cancel their own purchases. Bulk Discounts Nexus currently has several options for providing discounts to certain customers: Usergroup discounts can be used to give customers in certain groups a discount. Loyalty discounts can be used to give customers who already own (or are purchasing) some of your products a discount. Bundle discounts can be used to give customers a discount on their entire purchase if certain items are purchased in combination. In Nexus 1.5, we're adding a new discount type which we call Bulk discounts. Bulk discounts can be used to give customers a discount on an individual product if they are purchasing it with certain other products. In this manner, it can be used for "Buy one get one free" type deals: In this example, the first of this item the customer adds to their cart will be full price, the second will be free, the third will be full price, the fourth will be free, and so on. You could also do "Buy one get second half price" or "3 for the price of 2" style deals, and so on. Grouped Renewals Let's say you have a setup where you want to adjust the renewal fees for a product based on additional products that a customer has purchased. Currently, there are two ways to do this. You can set up add-ons as product options which adjust the renewal price of the package - however this isn't feasible if the add-ons also need access to support, downloads, etc. Alternatively you could set the add-ons up as packages which must be associated with a parent and have their own renewal costs - however, this means that if a customer purchases an add-on at a later date, their renewals won't be at he same time, which can be inconvenient and confusing. In IP.Nexus 1.5 we're adding the option for packages which can be associated with a parent package to have grouped renewals. This means that rather than having their own renewal dates, the renewal fees for add-on packages will be added on to the parent package. Latest Products The storefront in Nexus allows you to view featured products, popular products or browse by category. In IP.Nexus 1.5, we've added an option to view the latest products. Thumbnail Sizes The thumbnails used in the IP.Nexus store are hardcoded to 100x100px. In IP.Nexus 1.5 you'll be able to set whatever thumbnail size you'd like to use. When you adjust the setting, Nexus will set a flag on your products that the thumbnails need to be rebuilt, and this will be done on the fly as they're requested, so you don't need to sit around waiting for the images to rebuild.

IP.Nexus allows you to sell hosting packages with using integration with CPanel/WHM. In IP.Nexus 1.5 we're adding support to sell domain names too using integration with eNom. Once set up, customers purchasing hosting accounts will see a new option to purchase a domain name: The TLDs available and their prices can be set in the Admin CP. When selecting this option, the domain will be added to the cart like a normal item: When the customer then pays, the domain will be registered through eNom. The domain then shows as a normal purchase associated with the hosting account: A renewal invoice will be generated as normal when the domain is due to expire, and when renewals are paid, the expiry date will be updated with eNom. This feature requires an eNom reseller account. In future versions of IP.Nexus we will add additional registrars based on interest.

IP.Nexus currently provides support for a number of gateways: Authorize.Net (with ARB and CIM support), PayPal (Website Payments Standard and Pro), 2CheckOut and manual payments (check, bank wire, etc.) In IP.Nexus 1.5 we're adding more gateways and extending the functionality of some existing gateways. Gateways Stripe Stripe is a relatively young payment gateway. They support all major cards and have no monthly or setup fees which makes them great for smaller companies wanting to accept card payments. One of the more interesting aspects of Stripe is that they have a clever solution where although the customer can enter their card details right in Nexus, these details never actually hit your server - which is great for security. Those interested in the technicalities of this - the card form elements are displayed without having a 'name' attribute, meaning that their values are not sent in the POST data to your server. Instead, Javascript on Stripe's server extracts these details and provides Nexus with a token which is what is then sent. In addition, Stripe supports "storing" card details (again, technically, Nexus only actually stores a token) meaning when paying your customers will be able to tick a box to save card details, and these details can automatically be used for renewals, future purchases, etc. Authorize.Net DPM Nexus already provides support for Authorize.Net's AIM (that's "Advanced Integration Method") service. This allows customers to enter card details directly into Nexus. The way this works is that the card details have to be sent to Nexus - this is a concern for some as it means that, even though it's very briefly, your server has the customer's card information, which means that certain security precautions need to be considered. Authorize.Net now have a new service called DPM ("Direct Post Method") - to the customer, this seems to work exactly the same, however, rather than posting the card data to your server, and then Nexus sending that data to Authorize.Net, the form submits directly to Authorize.Net's server - meaning your server never deals with the sensitive card information. Unfortunately, due to the way this works, Authorize.Net's ARB and CIM services (both of which are a form of recurring billing) are not compatible with DPM. Those who need recurring payments can keep using the AIM method. Sagepay Nexus 1.5 also adds support for Sagepay. Refunds Currently, Nexus allows you to refund transactions right from the Admin CP for Authorize.Net and PayPal transactions. In IP.Nexus 1.5, PayPal Pro and 2CheckOut can now handle this too. Authorize.Net DPM and Stripe, which are added in 1.5, also support it. 2CheckOut Improvements 2CheckOut payments are now handled with their INS service. Not only is this more secure and reliable, using it has also allowed us to add support for recurring payments. So where does that leave us? IP.Nexus now supports 7 different payment gateways (8 if you include manual payments like check and bank wire), each of which have their own features and merits over one another. We've created a little table to show the key differences between each gateway: As always, we'll continue to gauge interest and add additional gateways to Nexus over time. But wait.... there's more! Split Payments Sometimes, people might want to pay for an invoice using two different cards (or other payment methods). In IP.Nexus 1.5, this is now possible: You can set a minimum invoice amount before this feature is available, or disable it completely if you don't want to use it. Package Methods In IP.Nexus 1.5, you'll now be able to set which payment methods can be used to purchase a particular package:

IP.Nexus allows you to set up shipping prices with customisable rates, destinations and tax. Once an item has been shipped, you can then provide a tracking number which will provide the customer with a link where they can view tracking information. While this solution allows complete control over shipping prices, it can be tedious to set up methods, and arrange shipments with couriers - particularly if you receive lots of orders. In IP.Nexus 1.5, we're introducing direct integration with FedEx. In future versions of IP.Nexus we plan to integrate with other providers like UPS and USPS in a similar way. The setup To get started, you simply need to enter your FedEx account details in the Admin CP. You can also specify which services to use (if you don't want to use them all), add a surcharge to FedEx prices and more: Once that's done - you're all setup. FedEx options will automatically become available when a customer selects a shipping method - you just need to make sure you have provided an accurate weight for shippable products. You can of course disable FedEx services for any individual product. Purchase When a customer goes to purchase a product they'll now see FedEx services in the shipping methods select box: You'll notice that each option shows the price as well as an estimated delivery date. This data is coming straight from FedEx based on the customer's shipping address and the items being purchased. The customer can also edit their shipping address on this screen which will adjust the prices accordingly - the shipping address can be different from the billing address provided in step 1 (but will be automatically filled out with that data). The address entered is also validated with FedEx to check for any mistakes in filling it out. Shipping In the Admin CP, you'll now see a button on the shipping order to arrange the shipment: Clicking this will show you a screen like this: As you can see, there are several options for how you want to provide the package to FedEx. The nearest FedEx drop boxes and service stations are listed and clicking on any will provide the opening hours: You can also have Nexus schedule a courier to come to you to pick up a package which will present you with this screen: Once shipment has been arranged you'll be able to print a shipping label. When the package has been delivered, you'll be able to see a proof-of-delivery with the signature that signed for the package. Both of these are provided by FedEx: Tracking The shipping order page in the Admin CP provides tracking information from FedEx: The customer also has a page in the client area where they can view the same information:

Our last two blog entries have focussed on large new features to the support system in IP.Nexus. But we're not stopping there! In this blog entry I wanted to talk about some of the smaller new features and enhancements we've made to the support system for IP.Nexus 1.5. Pay-Per-Incident IP.Nexus 1.5 adds the ability for you to define a support department as "Pay-Per-Incident". Each department allows you to enter a Pay-Per-Incident amount. When a customers tries to create a support request in this department, they'll see a message like this: Clicking the "Submit Request" button will take them straight to the payment screen to provide payment for the support request. After submitting payment, they'll be redirected straight back to the support request submission form - the title and department will even be remembered and filled in: Contact Us Nexus allows guests to create support requests which can be used for sales enquires, etc. Currently, this is usually done through the incoming email support, however in 1.5, we've added an optional "Contact Us" link to the footer which will allow anyone, including guests, to submit a support request: Tracking notifications IP.Nexus allows staff members to "track" support requests, tracked requests can be accessed quickly from the main support request list and are highlighted in that list. In IP.Nexus 1.5 we've also added the option to receive email notifications when a customer replies to support requests you are tracking: Staff members can reply to these notifications directly via email and their reply will be added to the support request. Reply to notifications IP.Nexus allows you to send a notification to any email address(es) for new support requests or emails within a particular department. Previously, the notification just said that a support request had been created or replied to, and gave you the title and ID number. In IP.Nexus 1.5, the notification email will contain the full body of the message and can be replied to directly by email. Improved Incoming Email Handling IP.Nexus supports the ability to receive incoming emails as support requests and replies. In IP.Nexus 1.5 we've rewritten a lot of this code to make it more reliable and secure. We've also added a setting to allow you to control whether you prefer Nexus to parse emails as HTML or in plaintext. Each message now also has a toggle which allows you to quickly toggle (it uses AJAX) between HTML or plaintext on any message: Merge Staff members have been able to split a support request into two requests in Nexus for a long time. In 1.5, we've added the option you can merge two together into one. Reminder Emails IP.Nexus allows you to assign support requests to staff members. Staff members can quickly see all support requests assigned to them from the support request list, however, if you don't regularly check the list, you may not know a request has been assigned to you. In IP.Nexus 1.5, if a staff member has any support requests assigned to them, they'll receive an email each morning with a list of the support requests that are assigned to them. Edit Title In IP.Nexus 1.5, staff members will be able to edit the title of a support request: Stock Actions When Logging a Support Request Stock Actions allow you to quickly set a department, status, assigned staff member and reply on a support request. In IP.Nexus 1.5, when logging a support request in the Admin CP on behalf of a customer, you'll be able to use these Stock Actions in addition to when replying.

Those familiar with IP.Nexus will be familiar with the ability to create custom fields both for packages (so when a user purchases a package they can provide custom information such as the size, colour, etc. of the item being purchased) and for customer accounts (so you could add additional fields for customers to provide when making a purchase, etc.). In IP.Nexus we're adding the ability to use custom fields with support requests. You can choose from several different types of field, select the departments it applies to, and choose whether or not it is required. Here I've created a field to ask users what "software version" they're using: Now when a user goes to create a support request in the "Support" department, they'll be prompted to provide this information: This works on the mobile skin too, of course: The values of these fields can then be viewed both by the customer, and admins:

IP.Nexus provides a great support system, allowing customers to submit support requests through your community or directly through email. The support system also includes robust reporting tools allowing you to see the volume of support requests over time and audit individual members of staff to view how many replies they're making and the quality of those replies. Ensuring customer satisfaction is important to anyone running a support system, and in IP.Nexus 1.5 we're adding a feature that will allow your customers to rate, and provide feedback on, the support they receive. When the system is enabled, customers will see a star rating system below each staff member's reply: They can then click on their desired rating, which will bring up a popup where they can enter additional feedback. This is completely optional, and customers can just leave a star rating if desired. In the Admin CP, you can control using ACP Restrictions if administrators can view the ratings given and optionally also view the feedback given. If a rating is given and the administrator can see it, it will appear user the message, just like in the front-end: If the customer left a note, and the administrator has permission to view it, they can do so by clicking on the rating: IP.Nexus has a "Staff Audit" tool allowing you to view how many support requests each staff member has answered over time. The audit now has an additional column providing the average rating for their replies in that time period: And of course, when you click on the number to view the staff member's responses, the rating and the note if available will display here too: Finally, we've added an additional report page in the Admin CP which allows you to view the average rating for different staff members over time: In this screenshot, I'm comparing two staff members average ratings throughout 2012 on a bar chart. But just like the other reporting tools in Nexus, you can select any date range, chart type (options are bar, line, pie or a plain data table) and can customise the series too (you could compare any particular staff members, group staff members by their department to compare departments, view everyone on one series, etc.) As always, if you have any feedback or suggestions unrelated to this blog entry, please post them in the IP.Nexus forum

IP.Nexus has for a long time included a referrals system, allowing your customers to refer their friends to your community and subsequently earn commission on any purchases they make in IP.Nexus. The problem with this set up though is that you might not want referrers to continue earning commission forever, or you might want to specify different commission amounts depending on what the referring user is purchasing. In IP.Nexus 1.5 we're adding much better control over the system - you can now create custom rules which control the commission amount which will be paid out to referrers. Nexus will loop through the rules you set up and give the highest commission amount out of the rules that match. You can base your rules on: The number of purchases that the referring user has made (as a number, or as a money amount) The group that the referring user is in The number of purchases that the user making the purchase has made (as a number, or as a money amount) The group that the referring user making the purchase is in The packages being purchased The amount of the transaction You can then specify a commission amount to give as a percentage, and optionally a hard limit on the maximum amount of commission that can be given. Here you can see I've set up a rule which will give the referrer 50% commission on the first purchase that members they refer make, provided the purchase is at least $10: We've also made some improvements on the front-end. Firstly, users can specify any URL to use as the URL the people they refer are directed to. In addition, users will be able to see the commission rules that apply to them: If however, you don't want users to be able to see details of the commission rules, you can replace the content of that popup with your own custom message, or remove it all together. Just like before, you can also create banners and upload them in the Admin CP, which will provide users code for using your banners on that page: And you can of course keep track of who referred whom on the customer pages and customer history page:

As mentioned in our last blog entry, we're hard at work on our next version of IP.Nexus. One of the more visual features we're adding in this version is an updated mobile skin - here are some screenshots! Main store page: Category listing: Product screen: Cart view: Checkout screen: Client area - menu: Client area - invoice view: New support request form:

IP.Nexus is our hugely popular eCommerce and business management application for the IPS Community Suite. Over the past few weeks we've been working on lots of new features and enhancements for the next version of IP.Nexus (version 1.5). The first change we wanted to share with you is called Fraud Rules. For a long time, IP.Nexus has provided integration with MaxMind for anti-fraud measures. However, this is limited only to holding or refusing transactions based on the MaxMind score. You might want to, for example, manually review all transactions where, for example, the user's billing address doesn't match their physical location (which MaxMind can detect) - or perhaps you don't want to use MaxMind and want to manually review all orders over a certain amount, or all orders from particular countries - this is where Fraud Rules comes in. IP.Nexus 1.5 allows you to create as many Fraud Rules as you like based on a wide range of criteria - each Fraud Rule is checked in the order you specify and the last that matches is what is used. This is what the management screen looks like: Here you can see I've set up a number of rules (the names are assigned by you as a reference for what the rule does) - I've created rules so that if the amount is over $100 or the the customer is paying by PayPal and has not made any previous purchases, the payment will be held for manual approval, unless the customer is in the "Administrators" group. This is just an example of what you might do - there is a wide range of criteria that you can base rules on. Here is what the add/edit page for a rule looks like: If MaxMind is enabled, even more options are available: The full list of what you can base rules on is:The transaction amount (greater than, less than or equal to X) Payment method used was (multi-select) Customer is in usergroup (multi-select) Customer's email address (is/contains X) Customer's billing address country (multi-select) Customer has made X approved transactions (greater than, less than or equal to X) Customer has made X approved transactions which have been blocked by Fraud Rules or manually refused by an administrator (greater than, less than or equal to X) Coupon was used (yes/no) MaxMind: Score (greater than, less than or equal to X) MaxMind: Customer's billing address is valid (yes/no) MaxMind: Customer's billing address matches their IP address location (yes/no) MaxMind: Customer's phone number matches their billing address (yes/no) MaxMind: Likeliness that customer is using an IP address proxy (greater than, less than or equal to X) MaxMind: Customer is using a free email provider (yes/no) MaxMind: Customer's email address is considered "High Risk" (yes/no) MaxMind: Customer's username is considered "High Risk" (yes/no) You can then choose whether the transaction should be approved, held for approval or refused based on the conditions specified. You can also set the rule to ban the customer if it used (which you might use, for example, to ban someone if they make X transactions which are blocked by Fraud Rules). For each rule, you can specify any number of the conditions available - the conditions you don't specify will be ignored and the rule will only be used if all conditions specified match. As mentioned earlier, the rules are checked in order and the last that matches is used, with this in mind and the ability for a rule to approve a transaction, you can add additional rules to specify circumstances where a customer can bypass a rule (in my example above, I've set it up so Administrators are exempt from all rules). The new Fraud Rules feature gives complete control over your transactions and will hopefully ease some of the headache of manually approving transactions. This is of course just the first of many features and enhancements we have planned for IP.Nexus 1.5 - stay tuned for more updates over the coming weeks! As always, if you have any feedback or suggestions unrelated to this blog entry, please post them in the IP.Nexus forum :smile:

IP.Board has featured a reputation system since 3.0, allowing users to give positive or negative reputation to posts, as well as content in other apps in the IPS Community Suite (blog entries, gallery images, etc.) as well as content in third party applications. In IP.Board 3.2, we enhanced this by adding a new way of viewing the reputation system, in terms of "liking" content as opposed to giving reputation, which is a more common social feature on websites today. In IP.Board 3.3, we're adding two features to utilise the reputation system in content discovery. Reputation in user's profile We've added a new tab to the profile which allows you to see both the content that the user has most recently liked, as well as content the user has made which has been most recently liked. This of course supports both reputation modes (the "Like" system and the traditional reputation system). The tabs at the top allow you to choose which application you want to view content from (in the screenshot only Forums and Calendar are viewable, but of course, support will be added for other apps and 3rd party developers can also add support), and also toggle whether you want to see reputation given or reputation received. Content with the highest reputation In addition to the profile tab, we've also created a new page (the link to which appears in the footer next to the top posters, etc.) which shows the content which has the highest rating, or has been liked the most. Just like on the profile tab, you can toggle between which application you want to view the content for. Both systems of course also work exactly the same with the traditional reputation system: Feel free to comment on this blog entry below or, if you have feedback unrelated to this blog entry, start a new topic in our feedback forum.

With every release of our products, we like to spend some time identifying areas which can be improved slightly, and small feature suggestions we can use. 3.3 is no exception, and I wanted to write a quick blog entry to highlight just some of the smaller enhancements we've made to 3.3 to make the product more powerful and easy to use. Login autosave In 3.2, we introduced a login popup box when you click "Sign In" to make logging in faster. Previously, the content for this popup was loaded by AJAX which meant some browsers would not automatically fill in your username and password like they normally would. In 3.3, we've changed the way this is loaded so that this is no longer the case. It still works exactly as it did before, except browsers will now be able to autofill your login details. Emoticons in sigatures Emoticons (smilies) are now supported in signatures. Log in as member Sometimes it is useful to log into your community as a member if they're experiencing issues, or to check you have set permissions up correctly. Previously, you would have to change the user's password and then log in as them normally in order to do this. In 3.3, we've added a button to the "edit member" page in the Admin CP which will log you straight into the community as that user, without you needing to know their password. This is of course protected by Admin CP Restrictions, so you can choose which of your administrators have access to this function. Duplicate forum Sometimes you want to set up several similar forums. This can be a real hassle having to create every forum, and set the settings and permissions for that forum manually. In 3.3, we've added an option in the drop-down menu in the forums management screen which allows you to "duplicate" a forum, so that you can easily create multiple forums with similar settings and permissions. Remove ability to create status updates Sometimes, you might want to remove a user's ability to post status updates. Previously, this could only be done in the Admin CP, however, in 3.3, we've added this option to the "edit member" screen on the front-end, so moderators can toggle this setting without having to log into the Admin CP. Tasks as cron IP.Board features a powerful task manager which is used to run certain tasks throughout the day to perform cleanup, send emails, etc. The task manager has always supported running tasks using cron for sites which would prefer to do so or perhaps do not receive enough activity for tasks to be triggered by users. Previously, each task had to have its own cron job set up. In 3.3 however, you can create a single cron which will execute any tasks that need to be ran. Delete guest posts IP.Board has always had the ability to delete all posts by a certain member. However, if you allow guests to posts, there was no tool to delete all posts made by a particular guest. In 3.3, we've added this feature. Rebuild reputation When you delete a post, the user's post count does not go down as this is representative of how many posts the user has made. IP.Board however, does have a tool to rebuild post counts based on what's currently in the database to set the post count for each user to be the current number of posts on the community. Reputation has a similar problem - when a user receives reputation, if the post which received reputation is deleted, their reputation does not go down - this is by design. Up until now however, there was no way to "rebuild" this like you can do with post counts. In 3.3, we've added a tool to rebuild reputation based on what's currently in the database, just like the tool to rebuild post counts. Upgrader custom script This is a change which only applies to application developers. In 3.3, we've added support for two scripts which are executed before and after an upgrade, respectively. Developers can use this to verify the application is compatible with the IP.Board version, and to run any post-upgrade rebuilds that may be necessary. Email tester We've also added a tool in the "Support" section of the Admin CP which will send a test email so that you can verify your community is sending emails correctly. Feel free to comment on this blog entry below or, if you have feedback unrelated to this blog entry, start a new topic in our feedback forum.