Ryan Ashbrook

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 Any extra data for the type * @param mixed $by The member performing the action. NULL for currently logged in member or FALSE for no member * * @return void */ public function logHistory( $app, $type, $extra=NULL, $by=NULL ) $app - This is the application key the log is associated with. $type - This is the log "type" which we will use to identify and parse the log for display later. $extra - This is an array of extra arbitrary data that needs to be stored (display name changes, for example, store both the old and the new username in the form of array( 'old' => 'Old Name', 'new' => 'new Name' );). $by - This is the user performing the change. Member History Logs are parsed and displayed in the Admin CP (Members > Edit a Member > Member History) by the use of Extensions. Each application can create multiple extensions, however one extensions can also handle multiple log types. The extension has two methods: /** * Parse LogData column * * @param string $value column value * @param array $row entire log row * @return string */ public function parseLogData( $value, $row ) /** * Parse LogType column * * @param string $value column value * @param array $row entire log row * @return string */ public function parseLogType( $value, $row ) parseLogData() is used to format the log information so that it displays correctly in the Member History table. $value is the data that was passed through to the $extra parameter of \IPS\Member::logHistory(), and $row is the entire row from the core_member_history table. Note that value will be json_encode()'d so the value will need to be manually passed to json_decode() to get the true value. parseLogType() is used to show a simple icon on the table, where supported.

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 supportedMetaDataTypes() { return array( 'core_FeaturedComments' ); } Once Recommend Replies has been added as a supported data type, then you must add the following line to your comments template, where you want Recommend Replies to show. {template="featuredComments" group="global" app="core" params="$item->featuredComments(), $item->url()->setQueryString( 'recommended', 'comments' )"} Or, if you application supports both Comments and Reviews: {template="featuredComments" group="global" app="core" params="$item->featuredComments(), $item->url()->setQueryString('tab', 'comments')->setQueryString('recommended', 'comments')"} Additionally, the featuredComments template supports two additional parameters: $titleLang - This is the title of the recommend replies area (default: recommended_replies). $commentLang - This is the title of each individual comment (default: __defart_comment). Applications that use the comment and commentContainer templates from the System application will not need to do anything further. Applications that use custom templates, however, need to add the following to their comment template, where their moderation menu is: {{if $comment->isFeatured() AND $item->canUnfeatureComment()}} <li class='ipsMenu_item'><a href='{$comment->url('unfeature')->csrf()->setQueryString('page',\IPS\Request::i()->page)}' data-action="unrecommendComment">{lang="unrecommend_content"}</a></li> {{endif}} {{if !$comment->isFeatured() AND $item->canFeatureComment()}} <li class='ipsMenu_item'><a href='{$comment->url('feature')->csrf()->setQueryString('page', \IPS\Request::i()->page)}' data-ipsDialog data-ipsDialog-title='{lang="recommend_comment"}' data-ipsDialog-remoteSubmit data-ipsDialog-size='narrow' data-action="recommendComment">{lang="recommend_content"}</a></li> {{endif}} And then, if you want to highlight recommend content, the following changes need to be made. For commentContainer you need to add the following to your <article> tags class attribute: {{if $comment->isFeatured()}}ipsComment_popular{{endif}} And then in your comment template, add the following immediately inside your opening <div> tag: {{if $comment->isFeatured()}} <strong class='ipsComment_popularFlag' data-ipsTooltip title='{lang="this_is_a_featured_post"}'><i class='fa fa-star'></i></strong> {{endif}}

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 supportedMetaDataTypes() { return array( 'core_ContentMessages' ); } Once Content Messages has been added as a supported data type, displaying them within your content items templates is as simple as adding the following line where you want the messages to be displayed: {template="contentItemMessages" group="global" app="core" params="$item->getMessages(), $item"} And then add the following to your Moderation Menu: {{if $item->canOnMessage( 'add' )}} <li class='ipsMenu_item'><a href='{$item->url()->csrf()->setQueryString( array( 'do' => 'messageForm' ) )}' data-ipsDialog data-ipsDialog-title='{lang="add_message"}'>{lang="add_message"}</a></li> {{endif}} And that is all that is required to implement Content Messages.

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, your Content Item Model must implement the \IPS\Content\MetaData interface, and then define meta_data in your column map. namespace IPS\myapp; class _MyClass implements \IPS\Content\MetaData { public static $databaseColumnMap = array( /* etc */ 'meta_data' => 'item_meta_data', ); } Additionally, you must add a BIT(1) column to your content items database table. This column is used to determine if the item has any meta data stored at all. If an item does not have any data, then the software will not attempt to load anything from the core_content_meta table (thus, making it more efficient than automatically attempting to load every time a content item is viewed). ALTER TABLE myapp_content ADD COLUMN item_meta_data bit(1) NOT NULL DEFAULT b'0'; Once done, your Content Item will inherit the following methods: /** * Meta data types supported by this content * * @return array|NULL */ public static function supportedMetaDataTypes() /** * Check if this content has meta data * * @return bool * @throws \BadMethodCallException */ public function hasMetaData() /** * Fetch Meta Data * * @return array * @throws \BadMethodCallException */ public function getMeta() /** * Add Meta Data * * @param string The type of data * @param array The data * @return int * @throws \BadMethodCallException */ public function addMeta( $type, $data ) /** * Edit Meta Data * * @param int The Meta Data ID from core_content_meta * @param array The data * @return void * @throws \BadMethodCallException */ public function editMeta( $id, $data ) /** * Delete Meta Data * * @param int The Meta Data ID from core_content_meta * @return void */ public function deleteMeta( $id ) /** * Delete All Meta Data relating to this content item * * @return void */ public function deleteAllMeta() Important notes regarding specific methods: supportedMetaDataTypes() - Your content item model must define this method in your content item model, with a return value similar too return array( 'myappkey_ExtensionKey' ); with each member of the return array being a specific extension, with the first part being the application the extension belongs too, and the second being the extension key, separated by an underscore. This is useful for checking to ensure that a specific content item support that specific type of data. This method returns NULL by default to indicate the content item does not support storing any data. hasMetaData() - This method does not check against the core_content_meta table to see if there is data present. Instead, it will check against the meta_data column that you have specified in your items column map, which acts as a simple flag and as the return value of this method, type-casted to a boolean (1 will return TRUE, 0 will return FALSE). getMeta() - This method will return all meta data associated with this particular content item in the format of array( 'myappkey_ExtensionKey' => array( X => array( 'data' ) ) ); where "myappkey_ExtensionKey" is the type as defined in supportedMetaDataTypes(), X is the value of meta_id in the core_content_meta table, and then finally the data (which has been json_decode()'d from the database). addMeta() - The $type parameter here must be at least one of the array members as defned by the supportedMetaDataTypes() method. The $data parameter must be an array that will be json_encode()'d and stored in the meta_data column of core_content_meta. editMeta() - This method is exactly the same as addMeta(), however the first parameter is the value of meta_id in core_content_meta, and the second is the new data that should be stored. When called, the method will compare all members of the $data array with the stored version. If it's value differs, then it will automatically store the new value while retaining any that already exist. As such, it is not necessary to specify every member of the array, if only one has changed. deleteMeta() - As with editMeta(), the $id parameter must be the value of meta_id from core_content_meta. The Extensions While the extensions are required, to verify what application a specific type of data belongs too, there is no enforced structure / required methods which must be present within the extension. You are free to use the meta data methods from within \IPS\Content\Item directly, within your own content model, or you can use the extension to define "helper" methods for formatting the data (for a real life example of this, you can reference the two extensions located at /applications/core/extensions/core/MetaData/). Real World Examples The Content Message and Recommended Replies features both utilize the Content Meta Data feature for storing their data.