[*]Content [*]Uploads [*]Customisation and BBCode [*]Special features




































Video Demonstration





Video Demonstration












Video Demonstration






oEmbed

• IP.Board 3.4.5
• IP.Blog 2.6.3
• IP.Content 2.3.6
• IP.Chat 1.4.4
• IP.Downloads 2.5.4
• IP.Gallery 5.0.5
• IP.Nexus 1.5.8
• IP.Calendar 3.3.4
  

• The editor, both within IP.Board (topics/posts) and in other areas (such as IP.Content articles, IP.Blog entries, etc.). Pay attention both to the editor itself (i.e. when typing out and formatting your post, and toggling the editor back and forth) and the final post that is submitted.
• Rebuilding posts, specifically upon upgrading from an older version of the software. Pay attention specifically to quotes to be sure they display correctly.
• Any IP.Nexus functionality that has to do with grouped renewals. Cancelling packages where renewals are grouped, reactivating those packages, changing those packages, etc.
  

VigLink is a content monetization service used by tens of thousands of publishers. While most monetization services focus on the traffic you receive - usually by displaying ads that distract and interrupt - VigLink is focused on the traffic that’s already [i]leaving[/i] your community. Here’s how it works: Often your communities will post links to retail sites like eBay or Amazon. With VigLink, clicks on these links are automatically monetized. There’s no change to the user experience. It’s simple: when a user clicks and purchases something, you earn a commission. Through their relationships with over

30,000 merchants

, including over 90% of the top 500 affiliating retailers on the web, VigLink automatically monetizes more links than any relevant competitor. Because of their size and success they have negotiated spectacular commissions with some of the top merchants. If you or your community already posts affiliate links or uses any other form of monetization, VigLink will not interfere.

To further increase your revenue, VigLink also offers Link Insertion, a technology that can automatically create links when brands, products, and stores are mentioned. These links are normal, everyday links, except for the fact that they can earn you money. For example, if a user posts about a camera they are thinking of buying, VigLink can detect the product mentioned and link it to a retailer that pays top commissions. Typically, publishers get more than half of their earnings from this technology.

There are others who try to offer similar technologies, however we have selected to integrate with VigLink because of their superior technology, performance, and customer service, especially among discussion-based communities. The largest network of its kind, VigLink processes billions of page views and over three hundred million clicks every month.

• Objects in a tree often have parent/child relationships. Sometimes this relationship is between the same type of object (for example, forums in IP.Board or categories in IP.Downloads), sometimes the relationship is between different types of object (for example, applications and modules, where modules are always the child of applications) and sometimes it's a mix of both (for example, packages in IP.Nexus are always children of package groups, but package groups may or may not be children of each other).
• Objects in a tree can usually, but not always be reordered by the administrator.
• Objects in a tree can sometimes be enabled and disabled without being deleted, for example applications and modules. Sometimes individual objects can't when the rest can (for example, you can't disable the "Core" application).
• Trees usually have controls for adding, editing, assigning permissions, duplicating and deleting objects, though a subset of these controls, or additional controls may be available (for example, you can't edit the permissions on a package in IP.Nexus, but you can run a purchase report, which you can't do in any other trees).
  

/**
 * Custom Profile Field Group Node
 */
class _Group extends IPSNodeModel
{
	/**
	 * @brief	[ActiveRecord] Multiton Store
	 */
	protected static $multitons;
	
	/**
	 * @brief	[ActiveRecord] Default Values
	 */
	protected static $defaultValues = NULL;
	
	/**
	 * @brief	[ActiveRecord] Database Table
	 */
	public static $databaseTable = 'core_pfields_groups';
	
	/**
	 * @brief	[ActiveRecord] Database Prefix
	 */
	public static $databasePrefix = 'pf_group_';
	
	/**
	 * @brief	[ActiveRecord] ID Database Column
	 */
	public static $databaseColumnId = 'id';
		
	/**
	 * @brief	[Node] Node Title
	 */
	public static $nodeTitle = 'profile_fields';
		
}

• $multitons and $defaultValues are required by the IPSPatternsActiveRecord class. We don't need to do anything with them other than declare them.
• $databaseTable tells the IPSPatternsActiveRecord class what database table the records we need are in.
• $databasePrefix tells the IPSPatternsActiveRecord class the prefix used on all database columns. This isn't necessary, but since all the columns in my table start with "pf_group_", putting it here will save me typing it out every time.
• $databaseColumnId tells the IPSPatternsActiveRecord class which column contains the primary key.
• $nodeTitle tells the IPSNodeModel class what language string to use as the title on my page that shows the tree.
  

namespace IPScoremodulesadminmembersettings;

/**
 * Profile Fields and Settings
 */
class _profiles extends IPSNodeController
{
	/**
	 * Node Class
	 */
	protected $nodeClass = 'IPScoreProfileFieldsGroup';

}

Now I have a page which looks like this:





Customising the rows

You'll notice I now have two rows (because I have two rows in my database), but both are blank. This is because the IPSNodeModel class doesn't know what to use for the record title. Let's fix that by adding a method to our class:

	/**
	 * [Node] Get Node Title
	 *
	 * @return	string
	 */
	protected function get__title()
	{
		$key = "core_pfieldgroups_{$this->id}";
		return IPSLang::i()->$key;
	}

That code might seem a bit confusing, but note:

• $this->id gets the value of the "pf_group_id" column in the database. This is because the IPSPatternsActiveRecord class provides us with a __get method for retrieving the database row values. This is handy if we want to be able to modify the value returned for whatever reason, as we can override that method.
• We're retrieving the value for a language key rather than some kind of title field in the database. This is because in IPS Social Suite 4, data like this will be translatable, so if you have more than one language you can display different values depending on the user's language choice.
  

	/**
	 * [Node] Does the currently logged in user have permission to edit permissions for this node?
	 *
	 * @return	bool
	 */
	public function canManagePermissions()
	{
		return false;
	}

And now it's gone:





Making the buttons work

The first buttons I need to make work are the add on the "root" row, and the edit on each row below that. I'm going to ignore the add button on each record row for now as that is for adding a child record and we haven't got to that yet - it will start working automatically when we add support for children.

These buttons will display a form. In a previous blog entry I talked about our form helper class. I'm going to use this to build the add/edit form.

To do this, I'll add two methods to my class to display the form and to save it's values - here they are:

	/**
	 * [Node] Add/Edit Form
	 *
	 * @param	IPSHelpersForm	$form	The form
	 * @return	void
	 */
	public function form( &$form )
	{
		$form->add( new IPSHelpersFormTranslatable( 'pfield_group_title', NULL, TRUE, array( 'app' => 'core', 'key' => ( $this->id ? "core_pfieldgroups_{$this->id}" : NULL ) ) ) );
	}
	
	/**
	 * [Node] Save Add/Edit Form
	 *
	 * @param	array	$values	Values from the form
	 * @return	void
	 */
	public function saveForm( $values )
	{
		if ( !$this->id )
		{
			$this->save();
		}
		
		IPSLang::saveCustom( 'core', "core_pfieldgroups_{$this->id}", $values['pfield_group_title'] );
	}

Most of that should be self explanatory - however in the blog entry about forms I didn't mention the Translatable class. If you have one language installed, this will just display a normal text field, however, if you have more than one, it will show one for each language. It then returns an array, which we can pass to IPSLang::saveCustom() to save the values.

This is what our form might look like if I have several languages installed:


Or, more commonly, if I just have one:



Now the add and edit forms are working, but since these are very small forms (they only have one input field) I'd like them to display in a modal popup rather than take the user to a new page (if the user has JavaScript disabled, a new page will do). To do this, I just add a property to my class:

	/**
	 * @brief	[Node] Show forms modally?
	 */
	public static $modalForms = TRUE;

Next we have the copy and delete buttons. These will actually work by themselves (the central class will handle copying and deleting the records from the database), however, since we have translatable values, we need to make sure those too are copied and deleted appropriately. To do this, I'll override the two methods which handle copying and deleting:

	/**
	 * [ActiveRecord] Duplicate
	 *
	 * @return	void
	 */
	public function __clone()
	{
		$oldId = $this->id;
		parent::__clone();
		IPSLang::saveCustom( 'core', "core_pfieldgroups_{$this->id}", IPSDb::i()->buildAndFetchAll( array( 'select' => '*', 'from' => 'core_sys_lang_words', 'where' => array( 'word_key=?', "core_pfieldgroups_{$oldId}" ) ), 'lang_id', 'word_custom' ) );
	}
	
	/**
	 * [ActiveRecord] Delete Record
	 *
	 * @return	void
	 */
	public function delete()
	{
		parent::delete();
		IPSLang::deleteCustom( 'core', 'core_pfieldgroups_' . $this->id );
	}

Search

You'll notice that the system has automatically added a search box at the top of the table. In order to make this work, we need to add a simple search method:

	/**
	 * Search
	 *
	 * @param	string		$column	Column to search
	 * @param	string		$query	Search query
	 * @param	string|null	$order	Column to order by
	 * @return	array
	 */
	public static function search( $column, $query, $order )
	{	
		if ( $column === '_title' )
		{
			$return = array();			
			foreach ( IPSLang::i()->searchCustom( 'core_pfieldgroups_', $query ) as $key => $value )
			{
				try
				{
					$return[ $key ] = self::load( $key );
				}
				catch ( Exception $e ) { }
			}
			return $return;
		}
		return parent::search( $column, $query, $order );
	}

Making the rows re-orderable

The last thing I need to do to finish the handling of groups is make it so we can drag and drop to reorder them. To do this I just add another property to my class telling IPSPatternsActiveRecord which column contains the order ID:

	/**
	 * @brief	[Node] Order Database Column
	 */
	public static $databaseColumnOrder = 'order';

ACP Restrictions

It's important of course to make sure we honour ACP restrictions. The easiest way to do this is to create individual ACP restrictions for add/edit/delete (this can be done in the developer center) with a common prefix, and then specify like so:

	/**
	 * @brief	[Node] ACP Restrictions
	 */
	protected static $restrictions = array(
		'app'		=> 'core',
		'module'	=> 'membersettings',
		'prefix'	=> 'profilefieldgroups_',
	);

The system will now look for ACP restrictions with the keys "profilefieldgroups_add", "profilefieldgroups_edit" and "profilefieldgroups_delete" when performing those actions.


Children

Let's recap what we have so far with a video:
http://screencast.com/t/TUBuuYBSBON
Now that we have groups sorted, we're going to create another class for the actual fields which will show as children. The process is almost exactly the same as for groups. Since the process is the same, I won't go through the process step-by-step, but here is the class I've written if you're interested:
Field.php

The only changes are:

• I've declared two additional properties specifying the class name of the parent ("IPScoreProfileFieldsGroup") and which column contains the parent ID.
• I've declared an additional method to fetch an icon for the row so we can see what type of field this is.
• Just like we overwrote canManagePermissions for groups, I've also overridden canAdd in the same way, as you cannot add children to profile fields.
  

	/**
	 * @brief	[Node] Subnode class
	 */
	public static $subnodeClass = 'IPScoreProfileFieldsField';

The system will now automatically change the behaviour of our page in the following ways:

• When clicking on a group, it will expand out to show the fields under it.
• The search box will include fields as well as groups in its results.
• When clicking the "Add" button for a group, it will show the field to add a field to that group.
• When clicking the "Copy" button for a group, you'll have the option to copy children too or not.
• When clicking the "Delete" button for a group, you'll have the option to move children elsewhere or delete them too.
• (This is my favourite feature) In addition to being able to drag and drop fields to reorder, you can drag a field out of one group and into another.
  

• "Blank" - which will create the class with no other logic, so the section will be blank.
• "Table" which will create a class with a boilerplate for displaying a table.
• "Node Controller" - which will create a boilerplate for displaying a tree of containers such as IP.Board forums, IP.Downloads categories, IP.Nexus groups, etc. We've not posted how this class works, but a future blog entry will give more details.
  

• "Internal", which is for accounts created natively through the suite.
• Facebook
• Twitter
• Microsoft (this is currently referred to as "Windows Live", though they rebranded to "Microsoft Account" a short while ago)
• LDAP
• "IPS Connect", which is our SSO solution for connecting your site with other IPS Social Suite installations or third-party applications.
• A generic handler for any MySQL database you have access to.
  

		/* Create the table */
		$table = new IPSHelpersTableDb( 'core_members', 'app=core&module=members&section=members' );
		
		/* Display */
		IPSOutput::i()->output	= IPSOutput::i()->getTemplate( 'global' )->block( 'members', $table );

With just those two lines, you'll see this:


Some things to note:

• We're calling IPSHelpersTableDb - the "Db" part indicates that the source of data for our table is a database table. There are other classes to use, for example, a JSON document as the data source.
• We pass it the name of our database table (or for the other classes, whatever the data source is) and the query string part of the URL where we're going to be displaying this (which we need to build the links and AJAX calls).
• I'm passing it to the output through a template called "block" which simply adds the dark-blue bar at the top, which isn't actually part of the table itself, and some padding. The "members" parameter is the key for the langauge string to use in that dark-blue bar.
• I'm passing $table directly to the template - the helper class has a __toString method which renders the table, so the output class thinks it's been given a normal string.
  

$table->include = array( 'name', 'email', 'joined', 'member_group_id', 'ip_address' );

In this example, I'm giving the helper class a list of columns to include - I could alternatively pass a list of columns to exclude, if that would be more appropriate.

The output is now this:


Some things to note:

• It's worked out pagination itself. When you click a pagination link, the contents of the table will update with AJAX, including changing your browser's URL (unless you have JavaScript disabled of course, in which case it will work like a normal link). Pagination defaults to 25 results per page, but you can change that just by changing a property in the class.
• All the columns are clickable, which will resort the results. You can sort any column ascending or descending. Resorting will also update with AJAX (including changing your browser's URL), unless JavaScript is disabled.
  

$table->langPrefix = 'members_';

And I'll then create some language strings that match that (so "members_name", "members_email", etc.).

The output is now this:





Next - we need to change how we display some of those values. The joined date and the group are displaying the raw values from the database, but we want something more meaningful than that.

To format the values, we simply create an array of lambda functions - one for each we want to format:

		$table->parsers = array(
			'joined'			=> function( $val, $row )
			{
				return IPSDateTime::ts( $val )->localeDate();
			},
			'member_group_id'	=> function( $val, $row )
			{
				return IPSMemberGroup::load( $val )->formattedName();
			}
		);

I'm also going to add one additional line to specify the "main" column, which applies some additional styles:

$table->mainColumn = 'name';

The output is now this:


Some things to note:

• I'm using the IPSDateTime class to format the joined date. The ts method in this is a factory method which takes a UNIX timestamp and returns an object of IPSDateTime. IPSDateTime extends DateTime, so all the features of that class are available to us. The localeDate method returns a string with the date formatted appropriately according to user's locale.
• The IPSMemberGroup::load call being executed for each result may look like it might be resource intensive, but it caches objects it creates, so it's only actually "loading" each group once.
  

$table->include = array( 'photo', 'name', 'email', 'joined', 'member_group_id', 'ip_address' );

		$table->parsers = array(
			'photo'				=> function( $val, $row )
			{
				return IPSMember::constructFromData( $row )->photo('mini');
			},

I'll also want to specify that we cannot use the photo column for sorting:

$table->noSort	= array( 'photo' );

The output is now this:



Some things to note:

• Since this isn't a value which exists in the database, the value of $val in the lambda function will be NULL, however, $row has all the data for that record.
• We're not using IPSMember::load to get the member object, since that would execute an additional query for every result, which would be resource intensive, and unnecessary since we already have that data. Instead, we use the constructFromData method and pass it the row from the database.
  

		$table->sortBy = $table->sortBy ?: 'joined';
		$table->sortDirection = $table->sortDirection ?: 'desc';

The output is now this:





Now, I want to add a quick search box. All we need to do is specify which column the quick search should look at:

$table->quickSearch = 'name';

The output is now this:


Some things to note:

• As you type, results are obtained with AJAX.
• You can page through your results (the number of pages will update automatically) and reorder your results by clicking the headers without loosing your search.
  

		$table->advancedSearch = array(
			'member_id'			=> IPSHelpersTableSEARCH_CONTAINS_TEXT,
			'email'				=> IPSHelpersTableSEARCH_CONTAINS_TEXT,
			'ip_address'		=> IPSHelpersTableSEARCH_CONTAINS_TEXT,
			'member_group_id'	=> array( IPSHelpersTableSEARCH_SELECT, array( 'options' => $groups ), function( $val )
			{
				return array( 'member_group_id=? OR ? IN(mgroup_others)', $val, $val );
			} ),
			'joined'			=> IPSHelpersTableSEARCH_DATE_RANGE,
			);

To explain what's going on here:

• The keys are the columns we're letting the user search on.
• The values are usually a constant indicating the type of search that is appropriate for that column.
• The member_group_id element is a bit more complicated. It has to specify an array of options (I've omitted the code to generate $groups in this snippet, but it'll be at the end of this blog entry), and, because we need to search both primary and secondary groups based on the value, there's a lambda function to get the proper WHERE clause for the query.
  

• The date entry boxes use the HTML5 date input type:
  
  If your browser doesn't support that, there's a JavaScript fallback:
  
  And if you're really awkward and are using a browser that doesn't support the HTML5 date input type and have JavaScript disabled, you'll see a regular text box where you can enter a date in practically any format, and it'll work it out.
• After performing the search, you can reorder your results by clicking the headers without loosing your search.
  

		/* Filters */
		$table->filters = array(
			'members_filter_banned'		=> 'member_banned=1',
			'members_filter_locked'		=> 'failed_login_count>=' . (int) IPSSettings::i()->ipb_bruteforce_attempts,
			'members_filter_spam'		=> '(members_bitoptions & ' . IPSMember::$bitOptions['bw_is_spammer'] . ') != 0',
			'members_filter_validating'	=> 'v.lost_pass=0 AND v.vid IS NOT NULL'
		);

For this though, I'll also need to join the core_validating database table, so we add one more line for that:

$table->joins = array( array( 'from' => array( 'core_validating' => 'v' ), 'where' => 'v.member_id=_0.member_id' ) );

The output is now this:


Some things to note:

• The helper class will add the "All" filter automatically.
• It's getting the word to use for the filter by looking for a language string with the same key as the key in the array passed.
• Like everything else, clicking a filter updates the results with AJAX and the filter is retained in searches.
  

		$table->rootButtons = array(
			'add'	=> array(
				'icon'		=> array( 'icons/add.png', 'core' ),
				'title'		=> 'members_add',
				'link'		=> 'app=members&module=members&section=members&do=add',
			)
		);
		$table->rowButtons = function( $row )
		{
			return array(
				'edit'	=> array(
					'icon'		=> array( 'icons/edit.png', 'core' ),
					'title'		=> 'edit',
					'link'		=> 'app=members&module=members&section=members&do=edit&id=' . $row['member_id'],
				),
				'delete'	=> array(
					'icon'		=> array( 'icons/delete.png', 'core' ),
					'title'		=> 'delete',
					'link'		=> 'app=members&module=members&section=members&do=delete&id=' . $row['member_id'],
					'class'		=> 'delete',
				),
			);
		};

Our finished table looks like this:


And behaves like this:
http://screencast.com/t/KMFq8zCE



To recap, here's the code, in it's entirety to generate that table:

		/* Create the table */
		$table = new IPSHelpersTableDb( 'core_members', 'app=core&module=members&section=members' );
		$table->langPrefix = 'members_';
				
		/* Columns we need */
		$table->include = array( 'photo', 'name', 'email', 'joined', 'member_group_id', 'ip_address' );
		$table->mainColumn = 'name';
		$table->noSort	= array( 'photo' );
		
		/* Default sort options */
		$table->sortBy = $table->sortBy ?: 'joined';
		$table->sortDirection = $table->sortDirection ?: 'desc';
		
		/* Filters */
		$table->joins = array( array( 'from' => array( 'core_validating' => 'v' ), 'where' => 'v.member_id=_0.member_id' ) );
		$table->filters = array(
			'members_filter_banned'		=> 'member_banned=1',
			'members_filter_locked'		=> 'failed_login_count>=' . (int) IPSSettings::i()->ipb_bruteforce_attempts, /*@todo*/
			'members_filter_spam'		=> '(members_bitoptions & ' . IPSMember::$bitOptions['bw_is_spammer'] . ') != 0',
			'members_filter_validating'	=> 'v.lost_pass=0 AND v.vid IS NOT NULL'
		);
		
		/* Groups for advanced filter (need to do it this way because array_merge renumbers the result */
		$groups = array( '' => 'any_group' );
		foreach ( IPSMemberGroup::groups() as $k => $v )
		{
			$groups[ $k ] = $v;
		}
		
		/* Search */
		$table->quickSearch = 'name';
		$table->advancedSearch = array(
			'member_id'			=> IPSHelpersTableSEARCH_CONTAINS_TEXT,
			'email'				=> IPSHelpersTableSEARCH_CONTAINS_TEXT,
			'ip_address'		=> IPSHelpersTableSEARCH_CONTAINS_TEXT,
			'member_group_id'	=> array( IPSHelpersTableSEARCH_SELECT, array( 'options' => $groups ), function( $val )
			{
				return array( 'member_group_id=? OR ? IN(mgroup_others)', $val, $val );
			} ),
			'joined'			=> IPSHelpersTableSEARCH_DATE_RANGE,
			);
		
		/* Custom parsers */
		$table->parsers = array(
			'photo'				=> function( $val, $row )
			{
				return IPSMember::constructFromData( $row )->photo('mini');
			},
			'joined'			=> function( $val, $row )
			{
				return IPSDateTime::ts( $val )->localeDate();
			},
			'member_group_id'	=> function( $val, $row )
			{
				return IPSMemberGroup::load( $val )->formattedName();
			}
		);
		
		/* Specify the buttons */
		$table->rootButtons = array(
			'add'	=> array(
				'icon'		=> array( 'icons/add.png', 'core' ),
				'title'		=> 'members_add',
				'link'		=> 'app=members&module=members&section=members&do=add',
			)
		);
		$table->rowButtons = function( $row )
		{
			return array(
				'edit'	=> array(
					'icon'		=> array( 'icons/edit.png', 'core' ),
					'title'		=> 'edit',
					'link'		=> 'app=members&module=members&section=members&do=edit&id=' . $row['member_id'],
				),
				'delete'	=> array(
					'icon'		=> array( 'icons/delete.png', 'core' ),
					'title'		=> 'delete',
					'link'		=> 'app=members&module=members&section=members&do=delete&id=' . $row['member_id'],
					'class'		=> 'delete',
				),
			);
		};
		
		/* Display */
		IPSOutput::i()->output	= IPSOutput::i()->getTemplate( 'global' )->block( 'members', $table );

• Make the change locally
• Change the installer
• Add the query to make the change to the upgrader for whatever version we're working on
• Let the other developers know so they can run the query to make the change in their installs.
  

$form = new IPSHelpersForm();
$form->add( new IPSHelpersFormText( 'name', 'default value' ) );
IPSOutput::i()->output .= $form;

The helper will automatically look for language strings with the same name as the form element and use them. If there is a language string with the same name and then "_desc" - it'll use that as the description.

So the above code, in the ACP, produces something like this:



Required

Let's say I want the field to be required - I just pass a third argument indicating so. When the form is submitted, if no value has been provided, it will automatically display an inline error:

new IPSHelpersFormText( 'name', '', TRUE )

Options

The fourth argument I can pass is an array with options dependent on the type of input field I'm adding. These options may change the way a field is displayed or add additional validation.

So for a text field, I can specify the minimum and maximum length (which, naturally takes multibyte languages into consideration):

new IPSHelpersFormText( 'name', '', TRUE, array( 'minLength' => 5 ) )

For a number field, I might specify the number of decimal points to round to, which it will do on the fly:

new IPSHelpersFormNumber( 'name', 0, TRUE, array( 'decimals' => 2 ) )

Watch Video


Or I could add an "Unlimited" checkbox, which is quite common for Admin CP settings:

new IPSHelpersFormNumber( 'name', 0, TRUE, array( 'unlimited' => TRUE ) )

Custom Validation

If the built-in options don't provide enough validation for a given need, you can pass a lambda function as a 5th argument:

new IPSHelpersFormText( 'name', '', TRUE, array(), function( $val )
{
	if ( $val === 'Bad Value' )
	{
		throw new IPSHelpersFormException( 'That value is not allowed.' );
	}
} )

Uploads

Of course - simple input fields aren't all that can be done. How does drag and drop uploading sound?

new IPSHelpersFormUpload( 'name', NULL, FALSE, array( 'multiple' => TRUE ) )

Watch Video

(By the way, you'll notice a stripy bar flashes up briefly - this is a real progress bar, but because I'm uploading to localhost it's filling faster than it displays - in practice, you'll see a nice smooth-filling progress bar)


Getting the values

The form helper will by default (you can override it of course) submit to the same page it's on. You can check if it has been submitted (and passed validation) and obtain the values if so simply by calling the values() method - here's an example:

$form = new IPSHelpersForm();

$form->add( ... );

if ( $values = $form->values() )
{
	// $values contains the values from the form
}
else
{
	IPSOutput::i()->output .= $form;
}

The values will be returned in a way that is appropriate to the input type. For example, a text input field will return a string, number input will return either an integer or float, an upload field will return an IPSFile object (or array of them, if you're accepting multiple files), etc.

• Moving our documentation to the main website
• Improving minor areas of IP.Downloads and IP.Nexus to allow clients to better help themselves, or to allow a smoother work flow within the administration areas our employees utilize every day
• Scripts on our end that allow us to better manage certain services
• Cleaning up old content in our installation, such as removing unused IP.Content blocks and deleting left over files on our server
  

IPSDb::i()->insert( 'table', array( 'foo' => 'bar' ) );

However, where previously the database class would try to work out the type of variable passed to it - it now binds these to a prepared statement.

The real usefulness of this change though, is apparent when you need to use a where clause. Where previously you'd have to do something like this:

$this->DB->buildAndFetch( array( 'select' => '*', 'from' => 'table', 'where' => "foo='" . $this->DB->addSlashes( $foo ) . "'" ) );

You can now do:

IPSDb::i()->buildAndFetch( array( 'select' => '*', 'from' => 'table', 'where' => array( 'foo=?', $foo ) ) );

We calculate the datatype based on the variable datatype, so previously where you had to do things like $this->DB->setDataType( 'foo', 'string' ) when you wanted to store a value like '01' - ew) - you can now just cast the variable to whatever datatype you like.
For example, if you wanted to ensure that the variable was cast as a string to avoid issues where a user name of '007' was detected as an integer and converted to '7' then you'd use:

IPSDb::i()->buildAndFetch( array( 'select' => '*', 'from' => 'table', 'where' => array( 'foo=?', (string) $foo ) ) );

Not only is this easier to type and to read, it ensures that the database class always takes care of escaping things properly.

• Bug fixes
  

• Bug fixes
  

• Bug fixes
  

• Bug fixes
  

• Bug fixes
  

• Bug fixes
• Multiple featured files now supported
• Ability for clients to manage renewals for purchased files now supported
  

• Bug fixes
• Ability to create Gallery IP.Content feeds filtering on "featured" status now supported
  

• Bug fixes
• Integration with the bulk mailer supported
• Ability to leave a customer note when voiding account added
  

• extensions
• dev
  
• css
• html
• img
• js
• lang



• admin
• front (it's "front" rather than "public" now)

• classDb (/ips_kernel/classDb.php) is now IPSDb and located in /system/Db/Db.php
• output (/admin/sources/classes/output/publicOutput.php) is now IPSOutput and located in /system/Output/Output.php
• class_forums (/admin/applications/forums/sources/classes/forums/class_forums.php) is now IPSforumsForum and located in /applications/forums/sources/Forum/Forum.php
• IPSDispatcherFront and IPSDispatcherAdmin are two new classes (with similar functionality to ipsController in 3.x) and both extend IPSDispatcherDispatcher - all 3 are located in /system/Dispatcher/ in individual files.
  

• All areas of the suite will support the mobile interface.
• We are heavily investigating using a "response design" for 4.0.
• We will be switching to jQuery
• We will be embracing HTML 5 fully
  

• PHP 5.3 will be the minimum supported version of PHP
• MySQL 5.0.3 will be the minimum supported version of MySQL
• IP.Board will fully utilize namespaces in PHP
• The entire directory structure, class naming structure and more will be completely overhauled
• Applications will truly be self-contained within their own folders (currently javascript, skin and language files, for instance, are scattered throughout miscellaneous directories)
• The entire code base will be modernized. More use of formal design patterns will be employed, where appropriate. Dumping ground classes (such as IPSLib) will be avoided at all costs. More consistency between how applications implement functionality will be seen. Naming conventions will be more consistent.
• The way hooks work will be completely rewritten, making things simpler for us and for developers, and making hook usage behind the scenes more reliable (no more loadLibrary calls - everything is handled automatically by the framework instead).
  

• From a user standpoint, the software will be more consistent. You won't have situations where a feature is available in Application X but not in Application Y.
• From a technological standpoint, we will be forced to implement functionality in an optimal manner where it can be utilized by all areas of the suite. There will be less application-dependencies for features that are intended to be suite-wide. There will be much, much less duplicated code as features will be designed from the start to work in multiple areas.
• Point #2 above will also benefit modders - APIs will be much more robust, yet more generic and reusable, for features implemented suite-wide rather than features implemented for one application and then shared across others.