-
Implementing the new Reactions feature on your content items is relatively straightforward. In your content item class, add the \IPS\Content\Reactable trait to your class. And then defined a reactionType() method within your content class - note that this is required so as to differentiate your content from the rest of the applications installed - this is equivalent to the $reputationType property in IPS 4.1 and, if your application implemented reputation previously, should be the same as the pr
-
Invision Community 4.2 has introduced the new Clubs feature. This feature allows members to create their own sub-communities within the community. 3rd party developers can extend Clubs to allow users to add Nodes specific to that Club.
Implementing Club Support
In order to add Club support to your nodes, the following adjustments must be made to your Node model. First, you must add the \IPS\Content\ClubContainer trait to your Model, which will then expose the following methods f
-
\IPS\core\modules\front\contact\contact::canUseContactUs()
This method is now deprecated, and you should now use \IPS\Member::canUseContactUs() instead. This method will be completely removed in Invision Community 4.3.
/**
* Is the current user allowed to use the contact us form
*
* @return bool
*/
public function canUseContactUs()
\IPS\Content::reputation()
This method is now deprecated, and you should now use \IPS\Content\Reactable::reactionCount() instead. Th
-
PHP Traits
Invision Community 4.2 has introduced the usage of PHP Traits. While Traits are a fairly standard feature in PHP, due to the way our autoloader and monkey patching works for plugins, the class_uses() function will not work properly. As such, if you need to check if a specific class uses a trait, then you should use \IPS\IPS::classUsesTrait() instead - this will check all classes in the extension chain.
/**
* Small utility function to check if a class has a trait as PHP doe
-
All Content Items, Comments, and Reviews that implement the \IPS\Content\Hideable interface will automatically work with the Delayed Deletes system. The information below is just for reference only.
The \IPS\core\DeletionLog class is an Active Record class that handles content queued for deletion.
namespace IPS\core;
/**
* Deletion Log Model
*/
class _DeletionLog extends \IPS\Patterns\ActiveRecord
{
/**
* @brief Database Table
*/
public static $databaseTable = 'core_deletion_lo
-
The Content Meta Data system is a feature that will allow third party developers to store arbitrary data regarding a content item, that may not necessarily need it's own storage space, while also being efficient. This is particularly useful to when your application is intended to support multiple content types, as well as avoiding unnecessary alterations on large databases to add a single column and / or avoid creating small mapping tables that you must join on.
To support storing Meta Data
-
Invision Community 4.2 introduces the new Content Message feature, which allows moderators to post messages that will appear above all comments, on all pages, on a specific content item.
To add this feature to your content item, you must first implement the \IPS\Content\MetaData interface to add support for storing Meta Data on your content item.
Once Meta Data has implemented, you need to add core_ContentMessages to your supportedMetaDataTypes() method.
public static function supp
-
Invision Community 4.2 introduces the new Recommended Replies feature, which allows moderators to recommend comment on content items, that will then appear above all comments, on all pages.
To add this feature to your content item, you must first implement the \IPS\Content\MetaData interface to add support for storing Meta Data on your content item.
Once Meta Data has implemented, you need to add core_FeaturedComments to your supportedMetaDataTypes() method.
public static function
-
Invision Community 4.2 has introduced the new Member History feature. This feature allows an application to store a log any time an account is altered from within the application, along with arbitrary data outlining what has changed.
Logging a change to an account is as simple as making a called to the \IPS\Member::logHistory() method.
/**
* Log Member Action
*
* @param mixed $app The application action applies to
* @param string $type Log type
* @param mixed $extra