Invision Community Blog

4.0 - IP.Downloads Submission

The submissions process in IP.Downloads has a certain complexity that may not be apparent at first. As well as simple file uploads, we also support adding files from URLs and from the local file system, and screenshots can also be added in these ways. Which category you choose to submit to affects which of these options are available. In addition, via the AdminCP you can bulk-upload files - but not via the front-end.

For IP.Downloads 4, we wanted to improve this process with interface and functionality changes.

Submitting Files

Here's a video demonstration of how creating a single file record in IP.Downloads works in v4:

We've worked hard to improve the flow for users here - while they are uploading files (which may be large and take some time), they can continue adding the other file information such as screenshots and meta data. While that's happening, the upload progress is always shown at the top of the screen. In the video you'll also see how image uploading is handled, as well as prefixes in the tag system, which are now supported throughout the IPS Community Suite.

Bulk Uploading

Instead of going to the AdminCP to bulk-submit files, single- and bulk-uploads are now handled through exactly the same process on the front end. This means users can be granted bulk-upload permissions without requiring AdminCP access, a big improvement on the current implementation.

To bulk upload, a user clicks the "Submit a file" button as normal, and chooses "I want to submit multiple files at once". They see the same upload area, but this time, the file information step is handled separately after the page is submitted. Each uploaded file has a separate block for file information and its own set of screenshots.

We'll of course be showing more of the IP.Downloads homepage and file view later, but we hope that gives you a taste of what to expect in IP.Downloads in IPS4.

12,985 views

Rikki

February 18, 201412 yr

4.0 - Follow System

Following content is an important aspect of interacting with your community. It allows you to be notified when there are updates to the content or when other users comment on the content, and it allows you to find content you are interested in at a later date. We have taken the opportunity with 4.0 to enhance the system where-by users can follow content in the IPS Community Suite to simplify and clarify certain processes, make it easier to follow content you submit, and to be sure you are receiving the notifications you wish to receive.

Following your own content

One area of improvement that was identified during planning meetings for 4.0 was the process of following your own content. While the forums have a method in place already to follow new topics you create (or to automatically follow topics you reply to), the rest of the suite has no such similar capability in place. We wanted to make it easier for users to follow the content they are submitting to make it more likely they will be aware of comments posted to their submissions, in turn making it more likely they will return and continue to interact with the community.

In all applications in 4.0, when submitting new content you will have the ability to follow that content right away.

When replying, similarly there is an option to automatically follow the content you are replying to.

In your Notification preferences panel, you can choose to automatically follow new content submissions by default and you can choose to automatically follow content you reply to by default (in which case the appropriate checkboxes would be checked by default during submissions and commenting). These options affect your content submissions and comments across the entire suite in 4.0.

Following other content

You can follow other content submitted to the community by clicking on the "Follow" button available in the appropriate area. As with 3.x, you can follow containers (e.g. follow a forum or an IP.Downloads category), and you can follow content items (e.g. a topic or an IP.Downloads file).

You can follow content items and containers both publicly, which means others will be able to tell you are following that item, and anonymously, where you will receive notifications of updates to the item but others will not be able to see you are following it. You can choose to receive an email notification immediately when there is a reply to the content, or you can choose to receive a daily or weekly digest. Digest notifications have been expanded suite-wide and are now supported in all applications automatically. As with 3.x, you can choose to receive an email notification or an inline notification on the site (or you can choose to receive neither or both if you prefer).

One common issue encountered in IP.Board 3.x was that users would follow something, however their notification preferences were configured in a manner which meant they would never subsequently be notified of updates to the item they are following (because they have chosen not to receive neither email nor inline notifications for that follow method). The 4.0 suite recognizes this scenario and warns the user in this event.

Summary

We have worked to improve and clarify the follow system where possible in the 4.0 suite, while still retaining the same level of functionality and flexibility you have available in 3.x. The ability to automatically follow new submissions should help users remain engaged on your site when other users comment on their contributions, bringing them back and enticing them to continue contributing to your site. The improved clarification when users will not receive notifications due to their preference configuration will help reduce staff overhead in answering questions, as well as visitor confusion and frustration.

We will talk about notifications themselves in a future blog entry, however we hope these changes help improve usability and interaction with your site by your visitors.

13,455 views

bfarber

February 17, 201412 yr

IPS UTF-8 Database Converter

Please note that this entry may be a little technical, if you do have any questions, please post them in the comments below.

A little history
IP.Board was first released over ten years ago when the web landscape was very different. A lot of emerging technologies were still trying to define new standards. Very early versions of IP.Board allowed one to specify the document character set and had a default of "ISO-8559-1" which is useful for languages that use latin based characters. This meant, for example, that if you needed Chinese characters you would need to change the character set to something more suitable. This disparity between character sets creates many challenges when working with a single code base.

UTF-8
Over the past handful of years there has been a push towards a single document character set; UTF-8. UTF-8 is a variable-width encoding that is able to show every character in the Unicode character set. This makes it suitable for latin and Chinese characters (and many many more!). Popular Javascript libraries such as jQuery require that data is sent and received with UTF-8 and many native PHP string functions prefer UTF-8. The future is very much UTF-8 and trying to keep our codebase working with any other character set is going to be more and more challenging.

IPS 4.0
Even though IP.Board 3 introduced UTF-8 as the default character set for new installations, we're aware that we still have many clients that are not using UTF-8 currently. IPS 4.0 is going to be strictly UTF-8 only which means we need to convert the data before or as part of the upgrade process.

Converting to UTF-8 isn't as simple as changing the database encoding. Merely doing this will simply corrupt the data you have in your database. We need to be a little smarter and use a script to do this work for us.

The great news is that even if you choose to convert your data to UTF-8 today, your IP.Board 3.x will run just fine and you may even find it more efficient as it doesn't have to convert lots of data on the fly.

The IPS UTF-8 Database Converter
We've written a script that can safely convert your database to UTF-8. The script does not overwrite your data until you manually confirm that the conversion process has been successful. This means that there is no risk of corrupting your existing data.

Of course, it is good practice to perform a full MySQL back-up before making any changes to the database as a precaution and we recommend that you do this.

You can download the converter and its instructions here.

How can I tell if I need to convert my database?
When you first run the converter, it'll check your database and let you know if you need to convert or not. Even if you are running UTF-8, you may not be using the correct collation (utf8_unicode_ci) so you have the option of changing your collation which is a very fast procedure and does not need a full conversion to complete.

If you first used IP.Board with IP.Board 3.0 then you may only need to change your database table collation. This isn't a required step and the IPS 4 upgrade process will perform this task if you'd prefer to wait until IPS 4.0 is released.
Support
Please note that while we're happy to provide some pointers within the client forums, this release is not officially supported by our technical support department.

Beta Release
As this is a beta release, please be aware that there may be bugs. If you do spot one, please post it to the IPS Extras bug tracker.

25,217 views

Matt

January 23, 201412 yr

4.0 - Theming: Easy Mode Editor

A few years ago we revolutionised theme editing in IP.Board with the addition of the "Visual Skin Editor". This tool quickly became a popular way of making broad color changes to new themes to match in with an existing site or existing branding. For the first time, you could instantly view the changes you were making.

Goodbye Visual Skin Editor, hello Easy Mode Editor.
We have rewritten this tool from the ground up in IPS Suite 4.0 and renamed it the Easy Mode Editor now that it's a fully integrated part of the suite and not just a license add-on. It retains all the features you love and has a much better interface, more control and fully supports gradients. Let's take a look!

When you create a new theme, you have the option of creating an "Easy Mode" theme or a "Manual Mode" theme. As you would expect, the manual mode allows full editing of CSS and HTML. Easy mode allows you to edit the theme with an instant preview.

Once the new theme has been added you can launch it from the Theme list inside the administrator's control panel by clicking the wand button. You can still edit the HTML templates and custom CSS as normal should you need to.

The easy mode editor launches in a new browser tab or window (depending on your browser's settings). The floating palette overlay in IP.Board 3 was a little cumbersome as it took up a fair amount of room and you had to move it out of the way to view your changes. In IPS 4, we've made this a fixed sidebar which means that it doesn't have to reload when you navigate through the suite.

I've cropped out most of the public display as we're not quite ready to reveal that yet!

You can quickly colorise your new theme with the Colorize option. This chromatically changes the main colors of the suite quickly and easily.

A limitation of the Visual Skin Editor in IP.Board 3 was that it couldn't manage gradients so themes had those gradients removed and flat color applied. We now support gradients in IPS 4.0 from the Easy Mode Editor's color editing panel.

We previously blogged about the fantastic new theme settings feature in IPS 4.0. Some of these settings are now available to editing in the settings panel. This is a really quick and convenient way to change these settings.

Although the new Easy Mode Editor allows you to change most of the colors within the suite, there may be times when you want to write a few lines of custom CSS to tweak the theme a little more to your liking. We've got that covered too.

You can leave the theme as an Easy Mode theme for as long as you want. However, you may decide that you want a little more control and need to edit some of the framework CSS that underpins the suite. That's easy to do. Just choose the option to convert it to a Manual Mode theme and you are all set.

Never before has theming been so simple! This re-invented tool allows you to quickly edit your theme without fuss and you can instantly see the changes as you make them. We can't wait to see what you do with it!

19,100 views

Matt

January 8, 201412 yr

4.0 - Simplification of deletion and approval process

A little history

For many years, IP.Board functioned under a relatively normal model of managing a content's status. A topic, for example, was either unapproved or approved. If a moderator did not like the topic, that moderator could delete the topic. This worked well for many years, but improvements in technology and processes necessitated changes. As IPS software evolved we recognized the need to handle all content throughout the entire suite in a uniform manner, so old concepts like the "trash can" forum were no longer relevant when considering how you work with Gallery images or Download Manager files. Additionally, many sites today employ moderators that they do not wish to entrust with the complete ability to irrevocably delete content, yet they still need the moderator to be able to clean up a mess should it occur.

A few years ago, we introduced the concept of "soft delete". In practice what this meant was that when a user soft deleted a topic, the topic would be removed from general view for most users, but the topic would not actually be deleted. Administrators could choose who can view soft deleted topics, and who could "un-delete" the soft deleted topic.

Some time after this, the way topics were deleted changed as well (which was now referred to as "hard delete" in contrast to "soft delete"). If a topic was truly deleted, it would not actually be immediately removed from the database. Instead, a flag was set and the topic would be deleted from the database at some future point in time by a task. The idea was that you may need to restore something that was deleted by a moderator...but then, the software already supports a soft-delete concept to account for this, right?

When clients proved to be confused with all of the terminology (we can't blame you!), "hard delete" was renamed back to "delete", and "soft delete" was renamed to hidden. Nevertheless, behind the scenes we still had all of the various statuses to account for

Content is awaiting approval (unapproved) Content is approved and viewable (approved) Content has been hidden or soft deleted (hidden) Content has been deleted but not removed from the database yet by the task (pending deletion) Content has been deleted and is gone permanently (deleted)

And how about 4.0?

In reviewing the needs of most admins and how the process of managing the content and your moderator roles works in the real world, we decided to simplify and improve this experience.

The 4.0 Suite now has just 4 of the above statuses, and they behave in a manner you would expect.If you require moderator approval of new content, when something is submitted it will be in an unapproved status. If you do not require moderator approval of new content, that content will be approved automatically and immediately viewable. If a moderator has permission to hide content, the moderator will be able to hide any content that has been submitted. The moderator may or may not be able to see content that is hidden, and may or may not be able to restore hidden content to viewable status. (All that depends on Admin settings.) If a moderator has permission to delete content, the moderator will be able to delete content that has been submitted. Upon doing so, the content is immediately and permanently deleted.

You can configure your moderators such that they are able to hide content, delete content, or both.

As with 3.x, moderators who can see hidden content will be able to review all hidden content in the Moderator Control Panel, and those with permission to restore hidden content will be able to do so from here as well. You will not have to worry about the content you are viewing in the Moderator Control Panel is deleted or hidden, as there is only one status now.

This is an example of a very minor change that was made after careful consideration of how the software functions and should "flow" when being used in a real-world situation. It is often the case that the smallest changes can make the biggest impact in the eyes of the users.

15,942 views

bfarber

January 7, 201412 yr

4.0 - IPS Connect

IPS Connect is our in-house cross-site authentication framework utilized by IP.Board in order to facilitate sharing of login credentials on one or more of your websites. While IP.Board supports Connect out of the box (meaning administrators of two or more IP.Board installations can allow users to use the same login credentials on any site in the network with just a few clicks in the ACP), the design of the system allows for third party software to tie in to the network as well. Indeed, one of the more popular addons in our Marketplace is the Wordpress IPS Connect plugin.

We have made several changes to IPS Connect in 4.0 that we believe will help you better manage a network of sites designed to share login credentials amongst them. These changes stemmed both from our own internal use of IPS Connect and from direct user feedback in our feedback forums.

Fundamental Improvements

In IP.Board 3.4, a "master" installation has no knowledge of any "slave" installations that may call to it. Any IP.Board can be set up to call to the master installation and this mater installation will never remember that the slave has called to it in the future. While this is fine for basic login credential checking, the original design of IPS Connect introduces many limitations. For instance, updating your email address on any given site cannot cause the email address to be updated on all sites because there is no central installation that knows about any of the sites in the network. Similarly, logging in to one site cannot log you in to all sites because all of the sites on the network are not actually known at any one location (we do, however, work around this if all sites are on the same domain).

Beginning with 4.0, the master installation will "register" any site that connects to it using IPS Connect. This introduces many benefits:
If you make a change on any individual site (master or slave), that change can now be propagated to all other sites in the network. Logging in or out of any given site can log you in to all other sites (because all other sites are now "known") Requests can be queued if there are problems You can create a listing of all sites in the network from the master installation

Further, we have thought through potential issues and have implemented a queue system where-by if requests to an individual site in the network begin failing then those requests will be queued and reattempted at a later date in the order they were originally received. If failed requests start queuing on the master installation, an ACP dashboard block will show you this and let you attempt to process them manually. If the issue causing the requests to fail has been resolved, the queue can quickly clear out in this manner (vs waiting for the task to clear them out). If the issue is still occurring, however, you will be given some additional information which will be helpful in determining why the requests are failing. Finally, if the site in question has been taken offline and future requests should not be sent to it, you are given the opportunity to unregister the "slave" installation so that the master will no longer communicate with it.

More changes propagated

We found while using IPS Connect internally that we wanted certain actions to propagate across all sites on the network but IPS Connect did not handle this, and we subsequently had to develop custom hooks in-house to account for the missing functionality. As a result, with 4.0 IPS Connect will now manage a few additional capabilities.

Banning
As of 4.0, if you permanently ban a user from the admin control panel, the ban will be copied to the rest of the sites in the IPS Connect network. Bans are only propagated to other sites if initiated via the admin control panel as a security precaution. It is probable in many cases that you do not want moderator actions on one site affecting accounts on another site, so front-end bans will not be copied to other sites.

Deleting
As of 4.0, deleting users from one site in an IPS Connect network will now cause the user to be deleted on all sites in the network.

Merging
Similarly, as of 4.0 when you merge two users on a site in an IPS Connect network, the users will be merged on all sites in the network.

Password Changes
As of 4.0, password changes are fully propagated to all sites in an IPS Connect network. The net effect will be no different than IP.Board 3.4 in this regard, unless you later disable IPS Connect on a site in the network - in this case, the last used password will still be valid on that site, rather than some random password potentially stored on a "slave" installation 5 years ago that the user cannot remember.

Cross Domain Logins (and Logouts)

Beginning with 4.0, IPS Connect will now support logging in and out across different domains. Cookie restrictions (and the fact that the master installation did not register and/or remember any of the slave installations) prevented this capability with 3.4.x, so while the login credentials could be shared across domains, signing in to one installation did not sign you in to any other installation automatically (unless they were on the same domain). Similarly if you logged out of an installation you were not automatically logged out of any other installation in 3.4.x. As of 4.0, if you sign in to an installation (whether it is the master or an individual slave application), you will be redirected to the master installation, then redirected to each slave application in turn, and finally redirected back to your original destination. This is all very seamless to the end-user and largely unnoticeable. Logging out will, similarly, redirect you to each application to log you out of that application, bypassing security restrictions applied to cookies in a multi-domain environment.

Wrapping Up

Just as with IP.Board 3.4, other applications can tie in to the IPS Connect network, either as a master installation or as a slave installation. IPS Connect support has otherwise been greatly improved and now offers a much wider range of functionality, a more robust built-in SSO system, and more reliability when problems do occur via the new request queuing system. It should be noted that IPS Connect with 4.0 is NOT compatible with IP.Board 3.4.x, and sites will need to "re-register" with the master so that it can know about them. That minor limitation aside, we believe you will enjoy the great improvements coming in the next release!

16,837 views

bfarber

January 3, 201412 yr

Enterprise Spam Mitigation

Back in June, we announced several updates to our proprietary Spam Service, which includes influences from existing spam mitigation services (Project Honeypot and Stop Forum Spam). Today, we are announcing the release of more options to help you fine-tune the spam service for your site. These features are being released as a part of our new Enterprise Spam Service package, which is available now.

Weighting

The first feature added, as a part of this new package, is “Weighting.” With this feature, you will be able to adjust how influential the Spam Service is against registrations to your site.

As you can see, the slider here presents several options to help fine-tune the service for your site. The options presented are fairly straightforward. If you find your site to be a heavy target of spam, you can adjust the slider to Strict or Very Strict as a means of telling the spam service that registrations to your site should be evaluated more vigorously than normal, and treat all registrations with higher caution than normal.

Conversely, if you find the spam service to be too rough on registrations to your site, you can adjust the slider to Loose or Very Loose. Doing so will tell the spam service to take a step back on registrations, and treat them with less verbosity than normal.

And finally, the middle option (Normal) will simply tell the spam service to act as it does now, with no preferential influence one way or another.

Whitelisting / Blacklisting

Another feature added as the ability to define your own custom White and Black Lists for your site, providing even more granular control in addition to weighting.

First, you can define your own custom Whitelist entries.

Using this interface, you will be able to add any Email Address or IP Address to your own custom whitelist. If a member registers, and is using any IP Address or Email Address defined here, then they will automatically be flagged as Not a Spammer, and no action taken against the account by the spam service. This is useful for Administrators, Moderators, and Developers who frequently test registrations on their own sites, allowing them to do so without turning the service off.

Further, you can also define a custom Blacklist.

If you find that the spam service may not be catching a newly released spammer fast enough, and need to prevent them from accessing the site immediately, then you may add their email address or IP Address to the Blacklist. Once added, any registrations from either of those will be flagged as a spammer and will be denied registration (depending on your community settings for Code Level 4).

Calls from multiple origins

As mentioned in the previous entry, this service also allows administrators to use the spam service in Load Balanced and Cloud environments with ease, using the same license key.

The Enterprise Spam Mitigation is now available for $100/6 months as an additional add-on to your license. Please feel free to contact Sales for any additional information regarding this new service.

9,097 views

Ryan Ashbrook

December 30, 201312 yr

4.0 - Extending JS controllers using Mixins

Reminder: this blog covers the technical details of 4.0's programming. For details on 4.0's features, follow our main blog.

Reviewing controllers

Some time ago, I blogged about the javascript framework we've built for IPS4. In it, I covered the most important component: controllers. To recap, a controller is a special object within the framework, and is applied on specific elements. That element is the controller's scope, and the controller works on it to provide its functionality. For example, a simple controller might look like this:

ips.controller.register('core.global.core.example', { initialize: function () { this.on( 'click', this.showAlert ); }, showAlert: function (e) { alert( "This button's text is: " + this.scope.html() ); } });
It would be used on an element like so:

<button data-controller='core.global.core.example'>Click me</button>
Here we're registering core.global.core.example as a controller. This represents the controller path - it's in the format app.module.group.controllerName. Though it seems longwinded, this allows IPS4 to dynamically load controllers on-demand, rather than loading them all when the page is loaded. In the initialize method (called automatically), we set up an event handler for a click. When the element is clicked, you'd see an alert saying "This button's text is: Click me".

So, that's how controllers work. Almost all page behavior in IPS4 is handled through controllers. But how would you change a method in an existing controller, say if you were writing an addon, or if you had two controllers that were fairly similar, and wanted to provide a base controller they both shared?

Mixins

To enable that, we have mixins. Mixins allow you to specify functions which are inherited by objects - in this case, our controller objects. This means, using mixins we can add new functions to a controller without needing to edit the controller itself.

A mixin is defined like so:

ips.controller.mixin('addAnotherMethod', 'core.global.core.example', true, function () { this.anotherMethod = function () { alert('Inside anotherMethod'); }; });
The ips.controller.mixin method takes up to 4 parameters:

ips.controller.mixin( name, controller, automaticallyExtend, fnDefinition )
name: Name to identify this mixin
controller: The controller this mixin extends
automaticallyExtend: [optional, default false] Does this mixin automatically extend the controller (more on that below)
fnDetinition: The function definition applied to the controller

In this example, our mixin adds a method named anotherMethod to our core.global.core.example controller shown earlier.

Let's talk more about the automaticallyExtend parameter. Mixins can be applied to controllers in one of two ways - either automatically on a global basis, or manually on a case-by-case basis. Mixins are manually specified like so:

<button data-controller='core.global.core.example( addAnotherMethod )'>Click me</button>
This means the mixin is used on this element - but another element using core.global.core.example wouldn't get it. This is useful when you're building your own apps or addons; you can write simple controllers that implement base functionality, then extend them with functionality for specific cases by specifying the mixin name in your HTML. We use this ourselves - for example, we have a base table controller that handles sorting, filtering and so forth. We then have a mixin for AdminCP tables, and a mixin for front-end tables, which add functionality specific to those areas, reducing code duplication.

If you're extending an IPS controller in an IPS app, though, modifying the HTML isn't typically an option. Instead, you can specify the mixin as global, and it will be applied to all elements where that controller is used. This means you can write your own mixins that work with our default controllers without having to touch our controller code (and that's a good thing).

Advice

So that shows how to add new methods to a controller. But what if you want to work with the methods that already exist in the controller? In the above example you'd only be able to overwrite an existing method - certainly not ideal, because 1) you would break any other mixins using the default method, 2) if we made an update to a method in a later release, your mixin would break it.

To facilitate working with existing controller methods, we're using a model called advice. This adds three special methods to a mixin: before, after and around. These let you 'hook into' existing methods and provide additional code for them. Let's rewrite our example mixin from above to take advantage of it:

ips.controller.mixin('changeBackground', 'core.global.core.example', function () { this.before('showAlert', function () { this.scope.css({ background: 'red' }); }; });
Here, I'm using the before method. I'm hooking into showAlert method (from the controller), and changing the background color of the scope element. So what happens when the link is clicked? First the background changes to red, and then an alert box is shown. We've added the background changing functionality without needing to edit the controller at all. Here's two other ways of doing the same thing, using the other two special methods:

ips.controller.mixin('changeBackground', 'core.global.core.example', function () { this.after('showAlert', function () { this.scope.css({ background: 'red' }); }; this.around('showAlert', function (origFn) { this.scope.css({ background: 'red' }); origFn(); }; });
The after method is fairly self-evident. With the around method, the original function is passed in as an argument, allowing you to determine when it is executed by your mixin.

All three of these methods will stack, so multiple mixins can hook into the same method, and they'll be executed in order, each receiving the previous.

Conclusion

I hope this introduction to mixins proves useful to developers; it shows how our core app controllers can be extended in a non-destructive way, but also how your own apps can use the mixin functionality to create an inheritance model to make your life easier.

Javascript in IPS4 makes extensive use of custom events, so the preferred way of adding new functionality is to listen for appropriate events and act on them - but the mixin support described above provides a mechanism by which you can adapt existing event handlers.

7,838 views

Rikki

December 19, 201312 yr

4.0 - Nodes & Content Items

Reminder: this blog covers the technical details of 4.0's programming. For details on 4.0's features, follow our main blog.

Introduction

For almost all applications in the IPS Social Suite (IP.Chat being the notable exception), there are three components: Each of these different types of items share many common features. For example, in all applications you can "follow" nodes and Content Items, you can like (or give reputation on) Content Items and comments. There's also searching, tagging, moderator controls (pinning, locking, etc.), sharing, reports and so on. Up until now, applications were largely in charge of managing these different components and their relationships themselves, and utilised often complicated extensions to implement the common features. In 4.0, these components are handled differently. Each component follows an , extending a central class for the component, and implementing interfaces to enable additional features. Working with objects So, taking IP.Board as an example, the classes for each of the components (forums, topics and posts) will start off like this:
[*]Categories created by the administrator. For example, forums in IP.Board, categories in IP.Downloads, calendars in IP.Calendar). In 4.0, the terminology used throughout the code for these is "Nodes". [*]Content created by users, usually (though, not always) within categories. For example, topics in IP.Board, files in IP.Downloads, events in IP.Calendar, images in IP.Gallery, personal conversations). In 4.0, the terminology used throughout the code for these is "Content Items". [*]Comments posted on Content Items by other users. In most applications these are simply called "comments" though in IP.Board they are called "posts" and in IP.Nexus and IP.Downloads they take the form of reviews.

Active Record design pattern

namespace IPSforums; class Forum extends IPSNodeModel { ... } class Topic extends IPSContentItem { ... } class Post extends IPSContentComment { ... } In , I already talked about how Nodes work and showed how easy it is to start using them. Content Items and comments are the same, with very little additional programming (only specifying a few properties to specify what database table to use and the names of the other classes they relate to), we can start using them. For example, to get a topic from the database, I just do:

an earlier blog entry

$topic = IPSforumsTopic::load( 1 ); In this example, 1 is the ID number. If I was accepting user input, I could just wrap it in a try/catch statement. I could also, rather than using load() use an alternative factory method, loadAndCheckPerms(), which automatically checks if the currently logged in user has permission to view and throws an exception if not:

try { $topic = IPSforumsTopic::loadAndCheckPerms( IPSRequest::i()->id ); } catch ( IPSContentNoPermissionException $e ) { IPSOutput::i()->error( "You do not have permission to view that topic.", 1, 403 ); } catch ( OutOfRangeException $e ) { IPSOutput::i()->error( "Could not find topic. It may have been deleted.", 2, 404 ); } In the object, properties match the columns from the database table. For example, to set the page title to the topic title, I just do:

IPSOutput::i()->title = $topic->title; There's also lots of methods available. For example, to get the IPSforumsForum object of the forum the topic belongs to, I just do:

$forum = $topic->container(); Or to get the IPSMember object of the member that posted the topic, I just do:

$author = $topic->author(); An Example: Getting the latest 5 topics One thing which is particularly easier now is that now the central classes handle common functionality, you can easily obtain data without having to worry about if everything has been accommodated - the class handles it automatically. I already showed how loadAndCheckPerms() works - for a more complicated example, let's say you wanted to get the 5 most recent topics to display in the sidebar. Previously you'd have to do a query, joining on the permissions table, providing the permission mask IDs of the current user manually, remembering to check to exclude hidden topics (unless of course, the user had permission to view hidden topics). In 3.x, it would have looked something like this:

$member = ipsRegistry::instance()->member()->fetchMemberData(); $topics = ipsRegistry::DB()->buildAndFetchAll( array( 'select' => '*', 'from' => array( 'topics' => 't' ), 'where' => ipsRegistry::getClass('class_public_permissions')->buildPermQuery( 'p', 'perm_2' ) . ( !$member['g_is_supmod'] ? ' AND queued=0' : '' ), 'add_join' => array( array( 'select' => 'p.*', 'from' => array( 'permission_index' => 'p' ), 'where' => 'p.perm_app="forums" AND p.perm_type="forum" AND p.perm_type_id=t.forum_id', 'type' => 'left', ) ) ) ); In 4.0, the same thing can be done with just one line of code:

$topics = IPSforumsTopic::getItemsWithPermission( NULL, 'start_date DESC', 5 ); Naturally, one could have written a method to do this in 3.x, but in 4.0, because it is handled centrally, it is common to all applications. If a new feature is added which affects the functionality (such as when hiding content was added), each application does not have to be updated. Adding Features I already mentioned how there are certain features, like tagging, reputation, searching, etc. which are common to Nodes and Content Items throughout all applications. In 3.x, integrating these features involved writing a usually lengthy, extension. In 4.x, implementing most of these features is as simple as adding a few elements to your class. For example, let's take tagging. In 3.x, we have lengthy . It involves creating an extension, which in the IP.Board application totals 360 lines of code. In 4.x, you simply add an interface to your class - changing this:

developer documentation for implementing tagging

class Topic extends IPSContentItem { ... } Into this:

class Topic extends IPSContentItem implements IPSContentTags { ... } That's all there is to it. Having done that, the form where a user adds or edits a topic will immediately gain a tags input field (the elements included on the form is handled centrally) and I can now call an additional method to get the tags on any topic so that I can display them in the HTML:

$tags = $topic->tags(); Here is a screenshot of the full developer documentation for tagging in 4.x: The programming method employed here is actually more suited to traits, as implementing the interface does not involve adding any additional code to your class. The reason we've chosen to do it this way though is because traits are only a feature in PHP 5.4 and above, and we wanted to support PHP 5.3. It is likely that in a future version of IPS Social Suite we will switch to using traits. Other examples Reporting In 3.x: - 502 lines for IP.Board. In 4.0: Read Markers (shows if content has been read or not) In 3.x: - 146 lines for IP.Board, plus manually marking items as read. In 4.0: Liking / Reputation In 3.x: - 222 lines for IP.Board. In 4.0: Following In 3.x: - 357 lines for forums, plus 361 lines for topics in IP.Board. In 4.0: For content items: For comments:

http://www.invisionpower.com/support/guides/_/advanced-and-developers/application/application-extension-reportplugins-r100

http://www.invisionpower.com/support/guides/_/advanced-and-developers/application/item-marking-r211

http://www.invisionpower.com/support/guides/_/advanced-and-developers/application/application-extension-reputationphp-r101

http://www.invisionpower.com/support/guides/_/advanced-and-developers/application/application-extension-like-r69

12,856 views

Mark

December 17, 201312 yr

Convert to IPS Promotion

We have seen a huge increase in people switching to us over the last year or two and want to take advantage of this momentum and offer an exciting conversion promotion. But first some information...

Our Pre-Packaged Converters

Our conversion scripts make it very easy to convert your existing community to the IPS Community Suite. The process is very simple: just install IPS, upload the converters, and then tell the converters what software you're coming from. It will ask you a few questions and then copy over your data to our format. For many systems we even include scripts to 301 redirect your old links so internal references and search engines don't get lost!

Our converters are free to use and well-tested with thousands of successful conversions. Of course converting is not an exact science and things change all the time so we are always releasing updates to make them better and faster.

Need some help?

But some clients really do not have the desire to take on the process of converting data themselves. In this case we do offer professional services for a fee to have us do it for you. Normally these fees range from $500 - $1000 but for the month of December we are offering a flat-rate fee of $350 to convert your community to IPS if it is on the list of one of our pre-made converters. Just contact [email protected] to get started.

Even better news: if you're converting to IPS Community in the Cloud we will convert your existing database at no cost! Contact [email protected] for full information.

Converting from something else?

If your software is not listed on our pre-made converter list we can still assist in converting. Maybe you're using something that's old, niche, or even custom. We have a lot of experience converting people to our platform and would love to assist you. Contact [email protected] with questions.

What about 4.0?

If you follow our blog entries you know we are hard at work on the next version of our software: IPS Social Suite 4.0. When version 4.0 is released if you have an active license you will of course get access at no extra charge! Upgrading from 3.4 to 4.0 will be very easy and our staff can even do it for you if you like.

vBulletin Converter Update

Over the last several months we have seen a huge increase in interest from vBulletin users wanting to convert to IPS. As we are asked so often, we want to highlight some of the key reasons to switch to us.

We do not make you re-buy with each new major version release. So long as your IPS license is active you get access to new versions. We do not limit your support ticket access or charge extra fees. With an active license you get private access to our support staff. Our staff will install our software on your server at no extra charge. Our staff will even install major upgrades on your server at no extra charge. We have a whole community suite: forums, blog, gallery, CMS, chat, ecommerce, support, and with the flexibility of our platform the possibilities are endless. The IPS Marketplace is a great resource for our clients to get enhancements for their community. Think Apple's AppStore but for IPS products. IPS makes community software and services. That's all we do and our focus is helping you succeed not working against you.

Ready to convert? Have Questions?

You can download our free converters to give them a try. If you have questions about IPS before purchasing please email [email protected] and we would be happy to assist. And as a reward for reading through the end there's one more thing: use the coupon code SWITCH through the end of December for 10% off your order.

7,333 views

Charles

December 5, 201312 yr

Black Friday and Cyber Monday Promotion

IPS is happy to offer 15% off starting now through Monday on all new purchases for both new and existing clients! This includes all software licenses and Community in the Cloud hosting. This is a great time to add on those extra Suite applications you're missing or to go ahead and try out IPS if you have always been considering us.

Just use the coupon code HOLIDAY2013 at checkout.

Conversion Promotion Coming Soon...

Are you using another community software and thinking of switching to IPS? We will be posting a great conversion promotion on Tuesday for those wanting help in converting their community data to our format. So take advantage of the 15% coupon above to order your licenses or hosting services now and then stay tuned for our conversion promotion next week!

12,371 views

Charles

November 29, 201312 yr

4.0 - Advertisements

In IP.Board 3.x, we have a setting group where you can specify some global advertisement HTML. You can enable and disable advertisements, and you can specify code to insert into the header and footer of the page. For the forum index, forum listings and topic view pages, you can override these header and footer ad codes, and you can specify advertisement code to insert into a couple of other areas specific to those pages. If you install IP.Nexus, this setting group redirects you to the IP.Nexus advertisement control panel where you can effectively do the same thing, but with a few more options (including click and impression tracking, advertisement image uploading, automatic cutoffs for advertisements, and more).

We felt that the entire system and process was too basic when IP.Nexus was not installed, and too disorienting once you do install IP.Nexus. This setting group suddenly redirects you to another application and configuring the advertisements is an entirely different experience prior to installing this application.

Subsequently, we have done the only logical thing and consolidated the two systems and improved the functionality.

(Please be aware that, as with all early screenshots of the 4.0 Social Suite, the interface displayed in the following screenshots is very much subject to change before release)

Advertisement Configuration

First and foremost, we have consolidated the functionality provided by IP.Board and IP.Nexus in previous software releases into one control panel. Now, whether you install IP.Nexus or not, you can have powerful advertisement management at your fingertips. Installing IP.Nexus still provides additional enhanced functionality, such as the ability to sell advertisements to your members.

You can now have both HTML and image-based advertisements available, and you can create multiple advertisements for the same "location" (more on this in a minute). There is a setting available to tell the software how to pick which advertisement to show if more than one is configured for a single area (options include picking one at random, showing the newest advertisement, showing the oldest advertisement, and showing the advertisement with the least number of impressions).

You can configure start and end dates for advertisements, set them to cut off after a certain number of impressions (or clicks, in the case of image advertisements), and you can filter by status (and toggle the status from this page). If IP.Nexus is installed, an additional status of "pending" is present and supported for advertisements that have been purchased but not yet approved. Naturally once you reach any cut offs specified or the end date has passed, the advertisement will no longer be rotated.

As you can see in the screenshot, javascript is removed from the preview for security reasons.

If you have a caching engine enabled, advertisement data will be cached to improve performance.

Some new functionality

If you are already familiar with the feature set of the current release of IP.Nexus, the advertisement functionality you already know and love will be carried over to the 4.0 Suite. You can still specify which groups are exempt from seeing advertisements, for example, to help you upsell subscription packages to users on your site. In addition to the current functionality, however, we've made some great improvements.

Ability to specify SSL advertisement code
Google Ads does not have an SSL version of its advertisement code, and including their advertisements on secure pages can lead to browser warnings for your visitors. This is especially troublesome when you only use SSL for logins or for your store (IP.Nexus), as it gives an impression that the page is not secure.

Now, you can specify an alternative secure page advertisement code if you wish, or choose not to show a specific advertisement on secure pages at all.

Ability to specify multiple images
When uploading an image advertisement, you now have the option to also upload a small and/or medium version of the advertisement image. The small and medium versions, if present, will be used on the responsive layout on the alternate views for mobile devices and tablets. If not provided, the software will simply use the next best size available.

We have NOT included the ability to specify alternate HTML for the different resolutions. In our research, most advertisement partners either (1) already handle responsiveness with their own javascript code or (2) provide alternative instructions for responsive ads.

If you use a CDN such as Amazon S3 for your file storage in the 4.0 Suite, your advertisement images will be served from the CDN.

Extendable application support
As of 4.0, any and all applications that wish to support advertisements can do so via the extension system built into the software. All an application will need to do is provide an extension for the advertisement system, and then call the advertisement location in the template where they feel the advertisement should display. You can even add custom settings (so for example, the forum application can allow you to configure which forums an advertisement will be displayed in...).

Skinners can move the advertisements around however they like in their skin templates simply by moving the appropriate custom tag.

Custom locations
You can now define entirely custom locations for advertisements easily in the advertisement configuration page. Once you have defined a custom location for the advertisement, defining where to show that advertisement in your themes is as simple as inserting a tag where you want the advertisement to be displayed.

Closing

We hope these small changes will help you better manage your advertisements and provide you with the options you need to capitalize upon your community. If you have no use for advertisements, you can completely ignore this area of the software and no resources will be used by it, but if you do utilize advertisements on your community, the new tools should make it much easier to manage your site.

26,921 views

bfarber

October 31, 201312 yr

IP.Board 3.4.6 + IP.Nexus 1.5.9 available for beta testing

The following applications are available for beta testing:
IP.Board 3.4.6 IP.Nexus 1.5.9

This round of maintenance updates includes bug fixes for the listed applications. We would like to encourage all interested users to perform as much testing of these apps as possible.

As of the date of this post our company forums have been upgraded to these releases.

Please report any bugs you find with the beta to our bug tracker.

Please pay particular attention to the following areas:The editor, both within IP.Board (topics/posts) and in other areas (such as IP.Content articles, IP.Blog entries, etc.). Pay attention both to the editor itself (i.e. when typing out and formatting your post, and toggling the editor back and forth) and the final post that is submitted. URLs that are submitted with a post being automatically turned into a link correctly. Any IP.Nexus functionality that has to do with grouped renewals.

If you find a bug, please be certain to report it to the bug tracker. When doing so, be sure to include as much information as possible that will allow us to reproduce the issue, including what browser you are using, what version of PHP is running on your server, whether this was an upgrade or a fresh installation, and so on. Screenshots are often helpful.
As with all beta releases from IPS, these releases are not supported by our technicians until the official final releases are publicly available in our client center. Please do not upgrade your live installation using these betas, as you may find no path between these builds and the final releases that we put out. We recommended, instead, to create a copy of your live board as a test installation, and upgrade your test installation instead.

All customers with active licenses can download the betas at: http://community.inv...ower.com/qa.php

Thanks in advance! We look forward to your feedback.

171,836 views

bfarber

October 21, 201312 yr

ZendCon 2013

Last week I attended ZendCon 2013, a prominent PHP developer-oriented conference designed to give industry professionals information on tools, practices and trends which will help them deliver enterprise-class software to customers. During the conference, many sponsors set up booths in order to demonstrate new products and services, and many industry professionals hold tutorials and sessions that attendees can attend in order to learn more about our trade. The conference was held in Santa Clara, CA (about an hour south of San Francisco, just outside of San Jose) from October 7th through October 10th.

I spent a lot of time at the conference focusing on tutorials and sessions that I felt might provide the most value for our company, in order to deliver better, faster and more stable software for our clients. One tutorial that I attended, for instance, focused entirely on best practices for implementing caching into software (and at the server level), and tuning settings in PHP, MySQL and Apache/NginX to deliver the highest possible performance. Another session I attended focused on Object-Oriented Javascript Programming and the future of Javascript (or, more specifically, ECMAScript 6). By the very nature of the conference, all sessions were very technical in nature, so don't feel too bad if any of this sounds like Greek to you. The point I want readers to take away is that we take our profession seriously, and IPS feels that an investment into continuing education is important for our clients.

I had the pleasure of meeting many industry professionals in the PHP world, including Andi Gutmans (CEO and co-founder of Zend Technologies), Zeev Suraski (CTO and co-founder of Zend Technologies), Elizabeth Smith (very active contributor to the PHP project and various PHP extensions), Derick Rethans (creator of XDebug, MongoDB PHP extension, and other PHP project contributions), John Coggeshall (active lead for the PHP Tidy extension) and many other wonderful contributors to the PHP ecosystem. The passion that these people share for the products and services is just amazing, and serves as a great role model for developers everywhere.

I won't spend much time getting into the nitty gritty details of each session I attended. Some were very technical in nature, while some focused on more abstract necessities of running a team of developers and managing day-to-day development duties (for example, discussing things like time management, gathering project requirements effectively, and so on). All in all, every session I attended provided useful information that I feel we can make use of to better our processes and delivery of future software releases.

As I said, here at IPS we take our profession very seriously. We will always strive to deliver the best possible software, and are thankful for the contributions of our third party developer community as well as the rest of our clients, whom provide us with bug reports and feedback that help to improve our products. We have many exciting things in store in the coming months, so stay tuned by subscribing to our company blog to be notified of changes and updates.

8,989 views

bfarber

October 19, 201312 yr

4.0 Advanced Theming

In a recent blog entry, we talked about theming in IPS Social Suite 4. More often than not, you'll want to upload a new logo, tweak a few colours, add some custom HTML or work on the global template to incorporate your existing site wrapper.

For this blog entry, I want to talk about the tools we have for more in-depth theming that professional themers will want to use to create downloadable themes for others to use.

Custom Settings
In 3.x, we have a number of system settings throughout the suite that control design decisions, such as displaying sidebars, or controlling the layout of items on a page. This isn't ideal, because we're limiting what themes can do themselves (and of course enforcing what they must support too). Instead, it would be better if these design decisions could be controlled by each individual theme, giving theme designers the freedom to be creative and display content in entirely new ways.

In IPS Social Suite 4, we've added per-theme custom settings. This enables you to create settings that are configurable by administrators when editing a theme. Even if you're not creating a theme to sell, you may want to add settings to control areas of your theme that are managed without making template edits each time you wish to make a change. For example, the default theme will have an option to add a rounded border effect to user photos. This is something that would be unnecessary as a system setting, but makes sense as a custom theme setting. Or you might want to add a setting that allows admins to toggle between showing and hiding a sidebar. There are a lot of possibilities here that would have required extensive custom code in 3.x.

When creating settings, you can choose which tab that they'll show in when editing a theme. This means you can group your settings by specific criteria such as "Colors", "Layout", etc.

Once you have created a custom setting, you're then able to use it in a HTML template or CSS file simply by using the following syntax:

{{if theme.rounded_photos}} .ipsUserPhoto { border-radius: 100px } {{endif}}

Or, if you want to use it without an IF clause, then you can simple use this:

<div> {theme="rounded_photos"} </div>

You can manage the custom settings from the theme edit form. In this screen shot, the tabs "Custom" and "Colors" are theme setting tabs.

Version Check
We've added the ability for theme creators to include a URL that is checked multiple times a day. All you as the theme creator needs to do is return a simple JSON object like this example:

{ "version": "4.0.1", "longversion": 40001, "released": 1377688587, "updateurl": "http://www.exampleurl.com/announcement.php?theme=xeonblue" }
This is a great way to notify your customers about updates to your themes.

More information is displayed when you mouse over the "Update available" badge.

Designer's Mode
There are times when you want to change many template bits and CSS files using your own development tools. The new ACP template and CSS editor is great for making edits now that it supports full syntax highlighting but for more advanced work you'll want to work with your favourite IDE and make use of its tools such as file compare and searching.
In IP.Board 3 we have the WebDav interface which allows you to work with plain .html and .css files but because it's sent over HTTP and each item needs recompiling to show changes, it's often a little sluggish and can be frustrating to work with if connection speeds start to suffer.

In IPS Social Suite 4 you can work with plain .html and .css files locally; there's no need to fire up a WebDav client. You enable designer's mode by adding a constant into constants.php. This will automatically write out the HTML and CSS files into a directory called "themes" right in your suite's root folder. You can edit these files and the changes are instantly applied to the suite making working very fast indeed.

Once you're done working in designer's mode, simply sync back the changes using the menu item on the theme's row and remove the constant.

This will copy the changes back to the database and remove any stale compiled templates and CSS files.

Diff
It's often very useful after upgrading to see which template bits have changed. The new "diff" tool instantly provides a list of changed, deleted or added template bits and CSS files. You can even download a copy as a stand-alone HTML file to distribute with your theme sets.

These advanced tools will make creating themes for IPS Social Suite 4 easier than ever before. We look forward to seeing what you create with them!

19,405 views

Matt

October 15, 201312 yr

4.0 - File Storage

Introduction

The IPS Social Suite needs to store lots of different files - there's attachments and profile photos uploaded by members, CSS and JavaScript files, emoticons, etc.

In IP.Board 3.x, various images got stored in different places:
Files uploaded by users get put in the /uploads directory. If you have a complicated setup, it's difficult to handle these. If you have a load-balanced cluster you need to set up an environment whereby all files are stored on a single server, or all uploaded files are synched between servers, but serving these files over a high-performance CDN can be difficult. CSS, JavaScript files, images and emoticons get put in /style_* directories. If you want to serve these over a CDN, you can do so, but you need to copy the files over yourself. Other pieces of data are written to disk as a caching mechanism. This has the same issue with load-balanced environments as file uploads. Some applications had other methods - for example, IP.Downloads allows you to store files on a remote server using FTP.

In 4.0, we wanted to pull this all together and build a much better system for storing files and build the whole system with high-performance environments in mind.

File Storage

In 4.0, you have several different ways to store files:On a local server On a remote server using FTP (which you can use to upload files to many CDN services) As binary data in the database On Amazon S3

You can set up different configurations and choose which configuration to use for different types of files. For example, if you want to store user's profile photos on Amazon S3, but you want attachments to be on the local server, or even a different Amazon S3 bucket - 4.0 can handle that. And if at any point you change your mind about which storage method you want to use, the system will automatically handle moving all the files for you.

Everywhere that writes a file will use this central system - so IP.Downloads and IP.Gallery are included too.

Caching

There are lots of places throughout the suite where the same stuff needs to be retrieved or calculated over and over - for example, certain configuration settings, language data, information about the installed applications, etc. If this data can be cached, not only does it alleviate database load, it means the PHP code doesn't need to re-process the data.

In IP.Board 3.x, some of this was stored in a particular database table and could be cached using a proper caching system - but it was difficult to configure, and not everything used it - compiled HTML templates, language strings and more were saved as files in the /cache directory, which causes difficulties for load-balanced cluster environments.

In 4.0, we've overhauled all of this. For things that need cold storage (like compiled HTML templates) - you can choose either the file system or the database for storage. The data can then cached, along with anything else which might benefit from caching (like settings, application data, etc.) using one of 5 supported caching methods:APC eAccelerator Memcached Wincache XCache

26,305 views

Mark

October 7, 201312 yr

4.0 - Application Management and Distribution

Building off of our previous blog entry regarding the developer center, application management and distribution has been fleshed out to a point where we are ready to reveal the changes coming with the 4.0 Social Suite. Please keep in mind that while we are discussing some specific changes (and showing screenshots!) of changes you can expect to see in 4.0, everything in this blog entry is subject to change before final. With that said, let's take a look.

This screen represents the application overview screen. First, a list of all of the applications that are currently installed is presented to you in a table, with another table following this one listing the applications which are uploaded but not currently installed. You can easily install an application listed in this second table on the screen simply by clicking the install icon next to the application. A multi-redirect process is triggered which handles the application installation painlessly for the administrator.

Note that in the screenshot above, the "Create New" button is only presented because developer mode is enabled. Administrators will not normally see this button. Additionally, the gears icon next to the installed application allows you to access the developer center, and this button is only present when developer mode is enabled as well.

When clicking on an installed application, you will be presented with a list of front-end modules, allowing you to set permissions for those modules and to specify which module is the default for that application, and to enable or disable individual modules.

The lit up star icon indicates the default module - clicking the icon for any of the modules will specify that module as the default. Clicking the lock icon will allow you to specify the permissions for that module, and clicking on "Enabled" in the screenshot will toggle the module between enabled and disabled status.

Building and Distributing Applications

Beginning with the 4.0 Social Suite, building and distributing applications has been made as simple as possible. The concept of "building" an application refers to the process necessary to create all of the files distributed with the application in order to make it installable. Examples include the language strings and the skin templates associated with the application. While you work in developer mode, the software pulls these templates from files located on disk, however these skin templates and language strings need to be imported into the database for standard installations of the suite in order to be supported properly. In 3.x the way you do this is to visit each various area of the ACP and use the appropriate developer tools to first import the data, and then to export the data. This is no longer necessary with 4.0.

In 4.0 when you add most database-stored data, you do so through the developer center. This immediately puts the relevant data (such as a task or settings included with the application) into the database, as well as into the distributed files on the file system. You don't have to be concerned with building this type of data for application distribution.

Within the developer center there is a manual "Build for release" button which you can use at any time. However, most developers will likely find that they do not need to use this button, because you are given the option to build your application for release right when you go to download it. This brings us to application distribution.

In 3.x to distribute an application, after you have exported all of the various files you need to distribute to disk you would copy over the application folder, as well as any other files from other folders (e.g. javascript files in /public/js/) and then zip these folders up in order to create an application distribution you upload to the marketplace. 4.x does away with this entire process. Firstly, applications are now fully self-contained within their own directory, including javascript files, images, CSS files, skin templates, language files, and so forth. Applications no longer need to have files contained within half a dozen folders to be recognized by the suite.

Secondly, you can now directly download an application (with developer mode enabled) right from the ACP. Behind the scenes, the PharData class is utilized to build a .tar archive, and all of your application's files are pushed into this archive. You are given the opportunity when you elect to download your application to choose whether you wish to build the application or not, which is useful in case you have just made a minor bug fix and don't need to bother with importing skin templates or language files since the last time you distributed your application.

Installing Applications

We wouldn't be content with just making application distribution this simple when we can make application installation just as simple for the end user administrators. As of 4.x, while you can still extract the .tar archive you (as a developer) have distributed and manually upload the files, it is much easier to simply upload the entire application in the ACP and let the 4.0 Social Suite do it for you. When you click the "Install" button on the application overview page and select an application to install, the archive is uploaded and extracted, and then the same install process automatically executes that happens if you are installing files from disk.

Centralized "Offline" Mode

Most nodes within the software have a notion of enabled or disabled, and applications are no exception. Even in 3.x you can enable and disable applications without uninstalling them, which removes access to the application within the software. On top of this, however, almost all applications have a custom notion of "offline mode" where-by an administrator can put the application in offline mode, define a custom message to show users who attempt to visit the application, and in most cases also specify which groups can still access the application even while it is offline.

We have decided to consolidate and centralize this similar functionality, allowing for a more consistent and robust experience for the administrator. You can now put applications in offline mode (unless they are "locked", such as the system application) and specify a message to show to users and which groups can still access the application. This functionality replaces the basic enabled/disabled status, but still provides for the same end functionality.

Putting it all together

Here is a quick video showing the process of installing an application, specifying a default module and the permissions for that module, and putting the application into an offline mode.

You might notice a few quirks in the video, representative of pre-alpha software. Firstly, this is an early application export and the module title was not exported with it, so the key is displayed when you see the listing. Additionally, a full WYSIWYG editor will be presented in the popup to specify the offline message, however automatic javascript-dependency loading is something we are still working on. Nevertheless, you can see the full functionality in the video below.

http://screencast.com/t/2zK1L51Tp3I

Let us know your thoughts, and if there are any other application-management tasks that need some extra attention in 4.0, in the comments

9,316 views

bfarber

September 30, 201312 yr

4.0 - Introducing Themes

IPS Social Suite 4 is a modernization of our software line and rather than just refactor existing work, we are rewriting the code from scratch which gives us a chance to really evaluate the interface elements and labels. We felt that "themes" was a much more modern and better understood term than "skins". Of course, the name is just the start, here are some of the other improvements:

Managing Themes in IPS Social Suite 4
As you would expect, the interface has been completely overhauled in IP.Social Suite 4. All the familiar elements are there but we've simplified areas and made it easier to manage your themes.

As you can see from this screen shot, theme authors can now inform customers when they have an update available for them. The interface makes use of the new IPS Social Suite 4 Trees model which means you can quickly search for theme names and re-order themes.

In IP.Board 3, you could change the logo of the suite. We've made this even easier in IP.Social Suite 4. The upload fields are easily accessible on the edit theme form. You can even upload a Facebook sharer image and favicon!

Downloading and Uploading Themes
In IPS Social Suite 4, downloading and uploading a new version of a theme could not be easier. Just select the menu item and it's done. You no longer need to navigate to separate areas of the Admin CP to do this.

Conflict Management
What happens if you upload a new version of a theme but it contains changes to templates you have also changed? You'll get a chance to review these changes and select which version to use on the conflict management page.

Editing templates and CSS
The template and CSS editor should be familiar for any existing customers. The editor is now fully syntax highlighted which will make writing and editing code so much easier.

The template syntax is now much more compact as you can see from the above screen shot. We've also added a few things to reduce the amount of template logic required.

A common need is to load a template if a condition is matched:

{{if member.isAdmin()}} {template="admin_bar"} {{endif}}
You can now put the conditional inside the template tag like so:

{template="admin_bar" if="member.isAdmin()"}
This is much easier to read and reduces a lot of visual clutter. The combination of the better template syntax and HTML 5 mark-up results in a dramatic reduction in size and complexity of often edited templates such as the globalTemplate which is commonly used to add your own site chrome.

The screenshot below shows all of the IPS Social Suite 4 globalTemplate and for comparison, part of the IP.Board 3.4 globalTemplate which is over 340 lines long!

The CSS framework much like the javascript framework has been completely rewritten and is now modular. This means that most CSS files are very small which makes looking for specific selectors much easier. In addition, upgrades are less destructive to your themes. If you made edits to the button styles, then only that one style sheet is altered leaving the rest as default. Of course, IPS Social Suite combines and minifies these separate CSS into fewer files when saved.

This blog entry is just an overview of the theme section in the Admin CP. We'll go into more detail in a later entry on the new tools available designed to make theme creation and management a breeze for theme authors. We know you will have a ton of questions but please be patient with us if we keep saying "wait for next blog entry" :smile:

26,265 views

Matt

September 26, 201312 yr

4.0 - Sharelinks

We refer to the icons you can use to post to third party services such as Facebook, Twitter and Digg as "Sharelinks" in our software suite, and we consider these an important tool both for community promotion and for search engine optimization. Not only can you get links to your community out there on other large, popular sites on the internet where you might be able to drive back more traffic to your own site, but search engines will also see these links to your site on the other large popular sites, follow them, and rank the pages they reach accordingly.

Share links were supported in 3.x, however while planning 4.0 we felt that the implementation could be improved, and so we've done just that. We have tidied up the interface to make managing the services easier for the average admin, provided more flexibility for third parties who wish to developer additional share link services, and we've made it much easier to use from a development stand point.

Managing Sharelinks

Within the admin control panel, you must be able to manage the sharelink services that are available. You may only want to offer buttons to share to Facebook and Twitter, removing clutter that you don't feel your community is familiar with. Or you may want to enable every share service link possible, because your community is full of technical-oriented users who will make use of them. Wherever you fall within this spectrum, the process should be simple and straightforward.

We have removed the ability to add and delete sharelinks, because the reality is most services require far more integration than simply specifying a URL. Thus, we have made the system plugin-based, which allows developers who are familiar with the process far more control, while greatly simplifying the interface for the average administrator. If you are comfortable with adding a link and an icon, building a plugin (see below) is a very simple process. Otherwise, if you don't know what an "HTML" is, you will now be able to work with this page in a far easier manner.

There is a generic settings button at the top, which allows you to globally enable and disable share links, as well as specify whether you want users to have the opportunity to automatically share links to new content with supported services. When you choose to "Edit" a given service, you can specify which groups can access that share link, and specify any service-specific settings related to that service (for instance, to change the default Twitter hash tag used when sharing via Twitter, you would click to edit the Twitter service).

Integrating a New Service

While we ship with some of the most popular services already supported (including support for LinkedIn sharing, new in 4.0!), it is a very simple process to add support for new services. When you build a new sharelink service and drop it into the appropriate folder, it will automatically be installed as soon as you visit the sharelinks management page in the ACP, where you can then choose to enable/disable the service and configure any available options. If you delete a plugin file, the service will automatically be deleted again when you visit this page in the ACP. No further interaction is required to install or uninstall a service, other than visiting the management page in the ACP.

The basic template for a plugin file is as follows

<?php namespace IPSContentShareServices; class _Servicename { /** * @brief URL to the content item */ protected $url = NULL; /** * @brief Title of the content item */ protected $title = NULL; /** * Constructor * * @param IPSHttpUrl $url URL to the content [optional - if omitted, some services will figure out on their own] * @param string $title Default text for the content, usually the title [optional - if omitted, some services will figure out on their own] * @return void */ public function __construct( IPSHttpUrl $url=NULL, $title=NULL ) { $this->url = $url; $this->title = $title; } /** * Add any additional form elements to the configuration form. These must be setting keys that the service configuration form can save as a setting. * * @param IPSHelpersForm $form Configuration form for this service * @return void */ public function modifyForm( IPSHelpersForm &$form ) { } /** * Return the HTML code to show the share link * * @return string */ public function __toString() { return "<b>Some HTML</b>"; } }
The class name "_Servicename" should be the same as the filename, minus the _ (the underscore is part of hooks and plugins system in 4.0, which you can read about in a later blog entry). So this filename would be "Servicename.php" and would be located in /system/Content/ShareServices/. The modifyForm() accepts a reference to the form object that is displayed when configuring the service. Here, you can add new configuration options that will be saved automatically (the configuration options should be settings). If you need to specify any HTML or CSS that needs to be manually loaded for the service, you can add assets to both the <head> of the document, or insert content right before the closing </body> tag, depending upon the service's needs in the constructor. The __toString() magic method should return the HTML necessary to generate the share service link.

It is really that simple - there are no hidden "gotchas" to watch out for.

As an aside, the built in ability to email a link has been greatly simplified for third party developers as well. If you implement third party applications by extending the appropriate classes (which we will blog more about later), the ability to email a link to your page with permission checking built in will all be handled automatically for you. You don't need any plugin files specifically to facilitate emailing links to your content items in 4.0.

Implementing Sharelinks in Applications

To implement the sharelinks in your third party applications is equally simple. As mentioned above, assuming you extend the appropriate classes to generate content items (which will be blogged about in detail at a later date), you need only do two things to implement share service integration in your application.

First, your class that extends IPSContentItem must implement the interface IPSContentShareable. This automatically enables the share links in your application and adds support for any functionality the share services utilize.

Second, your template should include the appropriate sharelinks template where-ever you wish to display the share links

{template="sharelinks" group="global" location="front" params="$contentItem"}
If you wish to render the share links in some manner beyond our default generic rendering, you can simply use whatever HTML you need to, however we feel that most content items can utilize our generic template just fine.

A Few Notes in Closing

We feel that these changes will make implementing share links as easy as possible while still providing you all the flexibility you may need to customize the interaction and display of the links at every level.

We have also decided to remove the "print" and "download" share links at this time. In researching their usage and their functionality, we feel that it is no longer worth maintaining these unnecessary links which simply add clutter to the page. All browsers allow you to save a page (i.e. download it) already, and all browsers allow you to print a page already. We will include a print stylesheet with 4.0, just as we did with 3.x, so when you choose to print a page the output will be better tailored for printed media. We feel, however, that retaining the links adds no real value for the vast majority of users, and is more inline with what most users encounter on other similar websites.

We hope that the improvements and decluttered interface, both on the front end and the ACP, make configuring and using these services (and adding support for others) much simpler than in previous versions.

9,024 views

bfarber

September 19, 201312 yr

4.0 - Email templates

In 3.x, we support HTML emails being sent by the software. However, due to constraints we had at the time, HTML emails use pretty much the same content as plain text emails, but wrapped in a simple HTML wrapper. Additionally, users had to explicitly decide whether they wanted to receive HTML or plain text emails via a preference setting - quite an anachronism. All in all, not a very satisfactory user experience.

Email handling in 4.0

In 4.0, users no longer choose which type of email to receive. Our email handler sends both types in a single email, and the email client chooses the most appropriate to show based on its capabilities. If it can display a fancy HTML version, that's what they'll see by default, but plain text is used if not.

Email template system

In 3.x, email content is defined by the language system, and each email has one language string which forms the content for both the plain text and HTML versions. Clearly, if we were going to improve the HTML templates we ship with, this would have to change.

In 4.x, each type of email has two templates - one for HTML, one for plain text. This means a better display of content can be created for HTML emails, while keeping the plain text ones simple and to the point. Email templates make use of the skinning system foundation (which we'll reveal later), meaning they have full use of logic, template tags and more - so we can also customize the emails depending on the user they are being sent to (note though that email templates are not per-skin; they are global to the site). And, of course, email templates can be added and edited via an interface in the AdminCP. This isn't groundbreaking stuff, but a vast improvement on email handling in 3.x.

Email template design

We also wanted to improve our email templates, so that each type of email sent was designed specifically for the purpose. The data shown in a registration email will be different to a topic digest, for example, and the email should reflect that.

Coding email templates is not a trivial thing, unfortunately. The latest version of Microsoft Outlook uses the Microsoft Word rendering engine(!!), while GMail strips out all CSS included in style tags - and that's just the start of the gotchas. This makes designing email templates a tricky business, and one that requires lots of testing to ensure compatibility. For our first 10 templates alone, I reviewed 900 screenshots to spot problems.

As a result, we've taken the approach of creating email templates which are simple in appearance and would work well for most sites, with the goal of hopefully avoiding the need of most sites to edit them at all (though you can, if you wish). The colors we've used are fairly neutral, for this reason.

For those mail agents that are a little more... advanced, our email templates in 4.0 will be responsive. They will look great on mobile devices as well as desktop clients.

I have included some examples of email templates, along with their mobile counterparts. I should note at this point that this does not reveal the main skin design. As discussed above, emails are intentionally separate in design.

Admin-completed registration

Friend request

New personal message

New profile comment

16,879 views

Rikki

September 15, 201312 yr

4.0 - Introducing the new AdminCP

We've been hard at work on IPS 4.0 for some time now, and we're finally at a stage where we are ready to reveal the new AdminCP to you. I won't be showing you everything the ACP has to offer - some things will be revealed in more detail in later blog entries. But lets get to an overview.

Background information

IPS4 brings with it a new CSS framework that aims to modularize our styles. This is something we started to work towards in IPB 3.2, but at that time we couldn't completely replace our structure. We no longer have a monolithic ipb_styles.css file. We now have a bunch of small CSS files, and each one handles something in particular. There's one each for forms, tables, pagination, buttons, layout and so on.

This brings a few key benefits. Firstly, when we need to make a bug fix in, say, the forms CSS file, IPS4 will still be able to automatically upgrade all the other css files for you. In 3.x, one bug fix in ipb_styles.css could mean the whole file had to be manually upgraded. Secondly, it will be a lot more obvious for skinners where to look for particular things. Need to style a button? Look like buttons.css. Easy. And thirdly, if you're building pages in IP.Content, and you want to use our button styles, you can simply include that one CSS file without needing to include the entire CSS framework.

CSS is of course concatenated and compressed before being delivered to the browser, but in a development environment, it exists as I described it above.

In IPS4, both front end and AdminCP share the same CSS (and Javascript) framework. Skinners will be able to ship skins that work on both the front end and AdminCP with only a little extra work - and, of course, when we make bug fixes to the framework, it'll fix both areas.

Before we go further, I want to make this part clear: The front-end and AdminCP look different. What you'll see shortly isn't what the front-end looks like. We will reveal that separately later. While the same framework is used, the AdminCP extends and overrides parts of it to suit its needs and style.

Goals

What did we want to achieve with the AdminCP? Our current AdminCP is often regarded as the best out of the big forum software platforms, so redesigning is a big undertaking.

Better user of space. Our current ACP uses vertical space for the main menu, and horizontal space for the application menu. In an era of widescreen desktops being standard, this could be improved. Get rid of dropdown menus. The main menu currently uses dropdowns for navigation, but this can be difficult to use - especially if you want access something in a 3rd party app, meaning you have to traverse the Other Apps menu. More consistency across pages. Our current ACP has some interactive tables (e.g. the member list) - but not every table makes use of the functionality. We should be enhancing every page with similar functionality, if it makes sense. Better styling. People aren't a fan of pink, it turns out. I guess it'll have to go. The blue gradients are showing their age too. And the big one: Better mobile support. You can't effectively use the AdminCP on a mobile device. It's time you were able to manage your entire community from your phone with all of the same functionality, right?

Responsive by default

That last one is what we're most excited about. The AdminCP in IPS4 is fully responsive, and allows you to do everything just on a phone or tablet. What is responsiveness? It means that the page automatically changes to better suit the device you're using. While a desktop user would see full navigation menus and tables of data, a mobile user will see a reduced view (but with all the same data present!). Whether you need to manage your members, change some settings, send a bulk email or run some diagnostics, it can all be done on the go. This is a first for the big community software platforms, as far as I'm aware.

Preview

Here is a sample page from the new AdminCP, as seen on a desktop, with the same page shown at a mobile resolution:

Although I won't include it here, tablets will see an 'intermediate' view with a reduced menu on the left. So, let's go over some of the key features of the screenshots.

Navigation

First, and perhaps most importantly, is the navigation. On a desktop, your applications are now arranged down the left-hand side, with their respective section menus available simply by hovering on the application - no dropdown menus to traverse. The application menu can be reordered per-admin, allowing each staff member to set the menu up to best suit their role.

On a mobile, there's obviously not the space for a wide navigation menu. Therefore, the application/module menu is activated by clicking the top-right icon. This opens a sidebar, from which you can navigate:

Tables

What you see in the screenshots are our new default way of displaying tables of data. On the desktop view, we have filters across the top, a search box (and advanced search popup), and table headers can be clicked to dynamically sort the data via ajax.

On a mobile view, this all collapses down - filters and sorting become menus, while table rows collapse to show data in a more suitable view. Responsive tables are a tricky thing to do right and there's a few different approaches, but given the types of data our AdminCP tables typically show, we think this is the best approach for us.

Forms

As has been discussed in some of our developer blogs, the IPS 4.0 framework supports a wide range of form field types - everything from text inputs to tree selectors to matrices. All of these field types work both on desktop and with a responsive mobile view.

Here's a simple AdminCP form on both desktop and mobile:

Tabs

Tabs are used extensively, where appropriate. Here's a screenshot showing a typical tabbed page (and it also shows a tree view):

Video of the mobile view in action

I've taken a short video of the member section in action, showing filtering, live searching and the advanced search popup. I'm using the iOS simulator here, which has some display jitters and requires me to use the mouse, but it should give you a good idea of how the AdminCP will work on a phone.

Conclusion

So there we go - an overview of the new AdminCP. We still have more to show you. Individual features and pages that are noteworthy will be blogged about in due course in more detail, so keep an eye on this blog and our developer blog for more.

Please do bear in mind that this is pre-alpha software, and everything you see is subject to change. We look forward to your feedback!

32,641 views

Rikki

September 9, 201312 yr

IPS 4.0: Plugins

Introduction

Modifications, add-ons, plugins, hooks - whatever your preferred name for them is - 3rd party code modifications are an important part of any successful web application. It wasn't that long ago that the way you did this was manually opening up files and copying and pasting bits of code in, or the really cool web applications had points scattered throughout the code for modifications to be injected into, or even scripts which opened up the files and made the changes for you (I'm not joking, that's seriously what used to go on!). In fact, IP.Board was one of the first web applications to, using OOP, support modifications in a more structured way.

Currently, we largely have 2 types of modifications: applications, which add whole new areas and functionality to your site (all of our applications: IP.Blog, IP.Gallery, IP.Downloads, IP.Chat, IP.Content and IP.Nexus use this architecture) and hooks which modify or extend the functionality of the IPS Social Suite or of applications.

Applications themselves are sort of self-governing so there isn't much to say about them, with one exception: applications will now be able to be downloaded and subsequently installed into your Admin CP as one file - you will not have to FTP upload application source files. The file will just be a regular .tar file, so course, if you were so inclined, you could open it and go old skool.

For the rest of this blog entry, I'm going to focus on hooks. Though parts of this blog entry will be more technical in nature than our others, I've tried to keep it just to what everyone will be interested in, and leave the boring stuff until the end.

Terminology

The term "hook" in 3.x is ambiguous. Sometimes it refers to the whole thing (e.g. "install a hook") and sometimes it refers to a specific technical part of that - the code which overloads other code (e.g. "skin hook", "library hook"), which are, even more confusingly, sometimes called "hook files".

In 4.0, we've decided to rename hooks to plugins. The technical parts which make up a plugin will still be referred to as hooks.

Sandboxing

Plugins, by their nature, extend functionality already present on your site. Up until now, if a plugin experiences a problem (for example, if a new version is installed which the plugin doesn't support) it can cause an error on your site, which disabling the plugin fixes.

Starting in 4.0, plugins will be sandboxed. This means that if a plugin experiences an unexpected error (such as a database driver error), your site will automatically fallback to the default behaviour, and your users will never know anything went wrong.

Simple (yet advanced) settings

In IP.Board 3.x, the Admin CP maintained a massive central area for managing most (though not all) settings. Plugins could add settings to this area, though there was no real standard to where to do that. Also, because this area was separate from the area where you install plugins, it could sometimes be confusing how to configure a plugin after installing it.

In 4.0, each plugin is allocated a settings page which is accessed just by hitting the "Edit" button on the list of plugins. Plugin authors can manage this page how they like - rather than being confined to the strictly tabular layout and specific input types in 3.x.

Versioning

In 3.x, unlike with applications, there was no particularly clear way to upgrade a plugin from one version to another. In 4.x, plugins now support full versioning, so you can just upload a new version, and an upgrader will take care of it.

Hook Types

In 3.x, there were several different underlying types of hooks:
Action overloaders - which allowed overloading the PHP class for any controller. Library hooks - which allowed overloading the PHP class for some (though not all) other classes. Data hooks - which allowed the modification of variables at specific, defined places in the code. Skin overloaders - which allowed overloading the compiled PHP class representing a group of templates. Template hooks - which allowed content to be inserted at specific points in templates.

For 4.0, we've made some quite radical changes:

Code Hooks

The first 3 have been merged into one concept we call "Code Hooks". Code Hooks can overload any class (even things which presently can't be overloaded like extensions) through a technique called monkey-patching (more details have been mentioned in the developer channel). This, combined with the use of Active Record models for all content items (so "Topic", etc. is a class that can be overloaded) also makes data hooks obsolete.

Theme Hooks

The last 2 have also been merged into a concept called "Theme Hooks" (we're also renaming "skin" to "theme"). The way the current template hooks work is to insert content around certain pre-defined tags in the template. The problem is, not always is the point the plugin author needs available, also this is done in a way the content being inserted isn't aware of it's surroundings, which makes it difficult for things like adding a button to every post, which would need to know information about that post.

After thinking for ages about a better way to facilitate theme hooks (I was halfway through a system which injected hook points automatically at compile time), our designer Rikki reminded us that a pretty well-known method for selecting HTML elements already exists... CSS selectors.

Video demonstration

What's really cool about this is that the content used acts as if it was part of the template - if for example, it's inserted in a foreach loop, the variables created by that are available. It can also use template logic and everything else templates themselves can do.

On the back-end, these are compiled into a file which behaves like a 3.x skin overloader - so if it is necessary (or just desired) to overload the compiled version of the template, that is still possible.

Theme hooks work for the Admin CP as well as the front-end.

Developer information

Developers no doubt would like to know the technical information of how this all works. Rather than write a blog entry covering all the different parts of plugins, we thought you might be interested to just see the developer documentation. We have 2 articles we can show you - one covering all the technical details of plugins, and another which provides a step-by-step guide for how to create a plugin.

11,437 views

Mark

September 4, 201312 yr

IPS Job Opening: Piracy Dept.

** We have enough applications to fill this position. Thank you for your interest! **

Piracy is something that all software companies face and IPS is no exception. Our losses due to credit card fraud and software piracy are significant and to minimize passing along costs to customers, we are seeking to expand our piracy department and take a harder stance against piracy and pursue those who engage in it.

The position entails:

- Identifying customers, using internal tools, that have inactive licenses and are using later versions of the software than their license allows and report to customer service for license termination.
- Identifying customers, using internal tools, that have shared IPS products or marketplace purchases with illegal download sites and report to customer service for license termination.
- Following up on usage piracy complaints.
- Vigorously pursuing distribution hubs.
- Working with web hosts, ISPs and law enforcement.

To qualify you MUST:

- Be at least 18 years old (for legal reasons, no exceptions to this policy can be made.)
- Have excellent written communication skills. English is a must.
- Be familiar with identifying the owner and host of a website (i.e.: Using WHOIS and other similar tools.)
- Be familiar with the DMCA and associated procedures.
- Reside in the United States.

** We have enough applications to fill this position. Thank you for your interest! **

Thank you for your interest!

17,776 views

Lindy

August 18, 201312 yr

IPS 4.0: Internationalization and Localization

One of the things we wanted to focus on for IPS Social Suite 4.0 right from the beginning was providing better support for sites which do not use English or use multiple languages (or, as it was scribbled on my whiteboard, "++ i18n/L19n"). In this blog entry I'm going to cover some of those changes and new features.

Translatable Everything

Currently when you create a forum, user group, custom profile field, etc. you have to give it a title and can only do this in one language. If you have more that one language installed, you might want to provide different titles for different languages.

In 4.0 you can do exactly that - if you have only one language installed, these fields will continue to show as normal text boxes - however, if you have more than one installed you'll see several text boxes like this:

Visual Language Editor

One feature that has been really popular in IP.Board is the Visual Skin Editor - a tool which allows you to browse your site, and click on elements to bring up a colour selector to change it. What if we could take this idea and apply it to translating as well? Allowing you to click on any word or phrase on your site and translate it there immediately. In 4.0, you can.

Easier Language Management

In addition to the visual translation we've also made several improvements to the traditional translation method:
As you search for a language string, results appear as you type. Editing a language string saves immediately without needing to click a save button. Filter tabs can show you words/phrases which have not yet been translated or the translation is out of date (meaning we've changed the default English value for the word/phrase since it was translated).

We've also made importing/exporting much faster and more reliable - no matter how large your language is (it will grow as you add more applications of course) there is now no risk of hitting an error importing/exporting (for those interested in the technical side of how this is achieved, see this blog entry).

An exported language pack will also now maintain information on the version of each application it was exported from, so that the filter which shows outdated language strings is always accurate.

Automatic Language Detection

Let's say you have Spanish and French languages installed on your site - up until now, you'd have to choose one default language, and users who want the other would have to manually choose it (which can be extremely difficult to find how to do when you're browsing a site in a foreign language).

In 4.0, we automatically examine the information that the user's browser sends (which includes their preferred language) to choose the best one out of what's available, if that user hasn't already set an explicit preference.

Pluralisation

In English, pluralisation is very simple - for most nouns, you just append "s" on the end, with some variation for certain words.

This however, isn't the case in all languages - for example, I was speaking with the owner of a site in Slovak recently who was telling me that the word "records" changes depending on the number of records there are - for 2 records, it's "2 články", but for 5 records it's "5 článkov". Currently, most language strings only have a singular and plural form (as is all that's needed in English) - meaning having the site show "2 články"/"5 článkov" was impossible.

In 4.0, we've introduced some really basic logic into language strings to accommodate this. Rather than having, for example, two language strings with the singular and the plural, there is now one with a value like this:
{# [1:record][?:records]}
The # indicates where the number will go, then each set of square brackets represents a possible value - the number before the : indicating the number which will cause that to show, and ? meaning "all other numbers".

So for our Slovak example, we'd set the value to:

{# [1:článok][5:článkov][?:články]}
On display, it will automatically show the appropriate version.

Lists

Along a similar thread to pluralisation, we've also made the way lists are formatted to be customised through a special language string. For example, a list in English looks like "one, two and three". However, in Japanese, it's "一、二、三。" (the comma symbol is different and there's no "and") - similarly Arabic, Thai and others have similar differences. In 4.0, simply by changing an example language string, this can be changed.

In the default language, this language string is:

a, b and c
For our Japanese example, we'd just change it to:

a、b、c

UTF-8

Without wanting to get into too much technical detail - UTF-8 is the most common of many ways text can be encoded for storage and display on webpages. UTF-8 has been the default encoding in our software since IP.Board 3.0.

Some sites which have been around for a long while though may not be using UTF-8. This can cause issues with some features where UTF-8 encoding is expected (for example, many features which rely on JavaScript require UTF-8 due to JSON only supporting it and nothing else). In addition, some sites may try to use UTF-8, but content is actually stored differently as the database is set to a different encoding, which can also cause issues.

In 4.0, we're going all UTF-8. If you're not already on it, the upgrader will convert data. This means a much more reliable and compatible way of handling text.

27,352 views

Mark

August 5, 201312 yr

Platform

Solutions

Guides

Help & Resources

Configure browser push notifications

Chrome (Android)

Chrome (Desktop)

Safari (iOS 16.4+)

Safari (macOS)

Edge (Android)

Edge (Desktop)

Firefox (Android)

Firefox (Desktop)