Club Drupal

<?php

/**

 * @file

 * This file contains no working PHP code; it exists to provide additional

 * documentation for doxygen as well as to document hooks in the standard

 * Drupal manner.

 */

/**

 * @defgroup rules Rules module integrations.

 *

 * Module integrations with the rules module.

 *

 * The Rules developer documentation describes how modules can integrate with

 * rules: http://drupal.org/node/298486.

 */

/**

 * @defgroup rules_hooks Rules' hooks

 * @{

 * Hooks that can be implemented by other modules in order to extend rules.

 */

/**

 * Define rules compatible actions.

 *

 * This hook is required in order to add a new rules action. It should be

 * placed into the file MODULENAME.rules.inc, which gets automatically included

 * when the hook is invoked.

 *

 * However, as an alternative to implementing this hook, class based plugin

 * handlers may be provided by implementing RulesActionHandlerInterface. See

 * the interface for details.

 *

 * @return

 *   An array of information about the module's provided rules actions.

 *   The array contains a sub-array for each action, with the action name as

 *   the key. Actions names may only contain lowercase alpha-numeric characters

 *   and underscores and should be prefixed with the providing module name.

 *   Possible attributes for each sub-array are:

 *   - label: The label of the action. Start capitalized. Required.

 *   - group: A group for this element, used for grouping the actions in the

 *     interface. Should start with a capital letter and be translated.

 *     Required.

 *   - parameter: (optional) An array describing all parameter of the action

 *     with the parameter's name as key. Each parameter has to be

 *     described by a sub-array with possible attributes as described

 *     afterwards, whereas the name of a parameter needs to be a lowercase,

 *     valid PHP variable name.

 *   - provides: (optional) An array describing the variables the action

 *     provides to the evaluation state with the variable name as key. Each

 *     variable has to be described by a sub-array with possible attributes as

 *     described afterwards, whereas the name of a parameter needs to be a

 *     lowercase, valid PHP variable name.

 *   - 'named parameter': (optional) If set to TRUE, the arguments will be

 *     passed as a single array with the parameter names as keys. This emulates

 *     named parameters in PHP and is in particular useful if the number of

 *     parameters can vary. Defaults to FALSE.

 *   - base: (optional) The base for action implementation callbacks to use

 *     instead of the action's name. Defaults to the action name.

 *   - callbacks: (optional) An array which allows to set specific function

 *     callbacks for the action. The default for each callback is the actions

 *     base appended by '_' and the callback name.

 *   - 'access callback': (optional) A callback which has to return whether the

 *     currently logged in user is allowed to configure this action. See

 *     rules_node_integration_access() for an example callback.

 *  Each 'parameter' array may contain the following properties:

 *   - label: The label of the parameter. Start capitalized. Required.

 *   - type: The rules data type of the parameter, which is to be passed to the

 *     action. All types declared in hook_rules_data_info() may be specified, as

 *     well as an array of possible types. Also lists and lists of a given type

 *     can be specified by using the notating list<integer> as introduced by

 *     the entity metadata module, see hook_entity_property_info(). The special

 *     keyword '*' can be used when all types should be allowed. Required.

 *   - bundles: (optional) An array of bundle names. When the specified type is

 *     set to a single entity type, this may be used to restrict the allowed

 *     bundles.

 *   - description: (optional) If necessary, a further description of the

 *     parameter.

 *   - options list: (optional) A callback that returns an array of possible

 *     values for this parameter. The callback has to return an array as used

 *     by hook_options_list(). For an example implementation see

 *     rules_data_action_type_options().

 *   - save: (optional) If this is set to TRUE, the parameter will be saved by

 *     rules when the rules evaluation ends. This is only supported for savable

 *     data types. If the action returns FALSE, saving is skipped.

 *   - optional: (optional) May be set to TRUE, when the parameter isn't

 *     required.

 *   - 'default value': (optional) The value to pass to the action, in case the

 *     parameter is optional and there is no specified value.

 *   - 'allow null': (optional) Usually Rules will not pass any NULL values as

 *     argument, but abort the evaluation if a NULL value is present. If set to

 *     TRUE, Rules will not abort and pass the NULL value through. Defaults to

 *     FALSE.

 *   - restriction: (optional) Restrict how the argument for this parameter may

 *     be provided. Supported values are 'selector' and 'input'.

 *   - default mode: (optional) Customize the default mode for providing the

 *     argument value for a parameter. Supported values are 'selector' and

 *     'input'. The default depends on the required data type.

 *   - sanitize: (optional) Allows parameters of type 'text' to demand an

 *     already sanitized argument. If enabled, any user specified value won't be

 *     sanitized itself, but replacements applied by input evaluators are as

 *     well as values retrieved from selected data sources.

 *   - translatable: (optional) If set to TRUE, the provided argument value

 *     of the parameter is translatable via i18n String translation. This is

 *     applicable for textual parameters only, i.e. parameters of type 'text',

 *     'token', 'list<text>' and 'list<token>'. Defaults to FALSE.

 *   - ui class: (optional) Allows overriding the UI class, which is used to

 *     generate the configuration UI of a parameter. Defaults to the UI class of

 *     the specified data type.

 *   - cleaning callback: (optional) A callback that input evaluators may use

 *     to clean inserted replacements; e.g. this is used by the token evaluator.

 *   - wrapped: (optional) Set this to TRUE in case the data should be passed

 *     wrapped. This only applies to wrapped data types, e.g. entities.

 *  Each 'provides' array may contain the following properties:

 *   - label: The label of the variable. Start capitalized. Required.

 *   - type: The rules data type of the variable. All types declared in

 *     hook_rules_data_info() may be specified. Types may be parametrized e.g.

 *     the types node<page> or list<integer> are valid.

 *   - save: (optional) If this is set to TRUE, the provided variable is saved

 *     by rules when the rules evaluation ends. Only possible for savable data

 *     types. Defaults to FALSE.

 *

 *  The module has to provide an implementation for each action, being a

 *  function named as specified in the 'base' key or for the execution callback.

 *  All other possible callbacks are optional.

 *  Supported action callbacks by rules are defined and documented in the

 *  RulesPluginImplInterface. However any module may extend the action plugin

 *  based upon a defined interface using hook_rules_plugin_info(). All methods

 *  defined in those interfaces can be overridden by the action implementation.

 *  The callback implementations for those interfaces may reside in any file

 *  specified in hook_rules_file_info().

 *

 *  @see hook_rules_file_info()

 *  @see rules_action_execution_callback()

 *  @see hook_rules_plugin_info()

 *  @see RulesPluginImplInterface

 */

function hook_rules_action_info() {

  return array(

    'mail_user' => array(

      'label' => t('Send a mail to a user'),

      'parameter' => array(

        'user' => array('type' => 'user', 'label' => t('Recipient')),

      ),

      'group' => t('System'),

      'base' => 'rules_action_mail_user',

      'callbacks' => array(

        'validate' => 'rules_action_custom_validation',

        'help' => 'rules_mail_help',

      ),

    ),

  );

}

/**

 * Define categories for Rules items, e.g. actions, conditions or events.

 *

 * Categories are similar to the previously used 'group' key in e.g.

 * hook_rules_action_info(), but have a machine name and some more optional

 * keys like a weight, or an icon.

 *

 * For best compatibility, modules may keep using the 'group' key for referring

 * to categories. However, if a 'group' key and a 'category' is given the group

 * will be treated as grouping in the given category (e.g. group "paypal" in

 * category "commerce payment").

 *

 * @return

 *   An array of information about the module's provided categories.

 *   The array contains a sub-array for each category, with the category name as

 *   the key. Names may only contain lowercase alpha-numeric characters

 *   and underscores and should be prefixed with the providing module name.

 *   Possible attributes for each sub-array are:

 *   - label: The label of the category. Start capitalized. Required.

 *   - weight: (optional) A weight for sorting the category. Defaults to 0.

 *   - equals group: (optional) For BC, categories may be defined that equal

 *     a previsouly used 'group'.

 *   - icon: (optional) The file path of an icon to use, relative to the module

 *     or specified icon path. The icon should be a transparent SVG containing

 *     no colors (only #fff). See https://drupal.org/node/2090265 for

 *     instructions on how to create a suiting icon.

 *     Note that the icon is currently not used by Rules, however other UIs

 *     building upon Rules (like fluxkraft) do, and future releases of Rules

 *     might do as well. Consequently, the definition of an icon is optional.

 *     However, if both an icon font and icon is given, the icon is preferred.

 *   - icon path: (optional) The base path for the icon. Defaults to the

 *     providing module's directory.

 *   - icon font class: (optional) An icon font class referring to a suiting

 *     icon. Icon font class names should map to the ones as defined by Font

 *     Awesome, while themes might want to choose to provide another icon font.

 *     See http://fortawesome.github.io/Font-Awesome/cheatsheet/.

 *   - icon background color: (optional) The color used as icon background.

 *     Should have a high contrast to white. Defaults to #ddd.

 */

function hook_rules_category_info() {

  return array(

    'rules_data' => array(

      'label' => t('Data'),

      'equals group' => t('Data'),

      'weight' => -50,

    ),

    'fluxtwitter' => array(

      'label' => t('Twitter'),

      'icon font class' => 'icon-twitter',

      'icon font background color' => '#30a9fd',

    ),

  );

}

/**

 * Specify files containing rules integration code.

 *

 * All files specified in that hook will be included when rules looks for

 * existing callbacks for any plugin. Rules remembers which callback is found in

 * which file and automatically includes the right file before it is executing

 * a plugin method callback. The file yourmodule.rules.inc is added by default

 * and need not be specified here.

 * This allows you to add new include files only containing functions serving as

 * plugin method callbacks in any file without having to care about file

 * inclusion.

 *

 * @return

 *   An array of file names without the file ending which defaults to '.inc'.

 */

function hook_rules_file_info() {

  return array('yourmodule.rules-eval');

}

/**

 * Specifies directories for class-based plugin handler discovery.

 *

 * Implementing this hook is not a requirement, it is just one option to load

 * the files containing the classes during discovery - see

 * rules_discover_plugins().

 *

 * @return string|array

 *   A directory relative to the module directory, which holds the files

 *   containing rules plugin handlers, or multiple directories keyed by the

 *   module the directory is contained in.

 *   All files in those directories having a 'php' or 'inc' file extension will

 *   be loaded during discovery. Optionally, wildcards ('*') may be used to

 *   match multiple directories.

 *

 * @see rules_discover_plugins()

 */

function hook_rules_directory() {

  return 'lib/Drupal/fluxtwitter/Rules/*';

}

/**

 * The execution callback for an action.

 *

 * It should be placed in any file included by your module or in a file

 * specified using hook_rules_file_info().

 *

 * @param

 *   The callback gets arguments passed as described as parameter in

 *   hook_rules_action_info() as well as an array containing the action's

 *   configuration settings.

 * @return

 *   The action may return an array containg parameter or provided variables

 *   with their names as key. This is used update the value of a parameter or to

 *   provdide the value for a provided variable.

 *   Apart from that any parameters which have the key 'save' set to TRUE will

 *   be remembered to be saved by rules unless the action returns FALSE.

 *   Conditions have to return a boolean value in any case.

 *

 * @see hook_rules_action_info()

 * @see hook_rules_file_info()

 */

function rules_action_execution_callback($node, $title, $settings) {

  $node->title = $title;

  return array('node' => $node);

}

/**

 * Define rules conditions.

 *

 * This hook is required in order to add a new rules condition. It should be

 * placed into the file MODULENAME.rules.inc, which gets automatically included

 * when the hook is invoked.

 *

 * However, as an alternative to implementing this hook, class based plugin

 * handlers may be provided by implementing RulesConditionHandlerInterface. See

 * the interface for details.

 *

 * Adding conditions works exactly the same way as adding actions, with the

 * exception that conditions can't provide variables and cannot save parameters.

 * Thus the 'provides' attribute is not supported. Furthermore the condition

 * implementation callback has to return a boolean value.

 *

 * @see hook_rules_action_info()

 */

function hook_rules_condition_info() {

  return array(

    'rules_condition_text_compare' => array(

      'label' => t('Textual comparison'),

      'parameter' => array(

        'text1' => array('label' => t('Text 1'), 'type' => 'text'),

        'text2' => array('label' => t('Text 2'), 'type' => 'text'),

      ),

      'group' => t('Rules'),

    ),

  );

}

/**

 * Define rules events.

 *

 * This hook is required in order to add a new rules event. It should be

 * placed into the file MODULENAME.rules.inc, which gets automatically included

 * when the hook is invoked.

 * The module has to invoke the event when it occurs using rules_invoke_event().

 * This function call has to happen outside of MODULENAME.rules.inc,

 * usually it's invoked directly from the providing module but wrapped by a

 * module_exists('rules') check.

 *

 * However, as an alternative to implementing this hook, class based event

 * handlers may be provided by implementing RulesEventHandlerInterface. See

 * the interface for details.

 *

 * @return

 *   An array of information about the module's provided rules events. The array

 *   contains a sub-array for each event, with the event name as the key. The

 *   name may only contain lower case alpha-numeric characters and underscores

 *   and should be prefixed with the providing module name. Possible attributes

 *   for each sub-array are:

 *   - label: The label of the event. Start capitalized. Required.

 *   - group: A group for this element, used for grouping the events in the

 *     interface. Should start with a capital letter and be translated.

 *     Required.

 *   - class: (optional) An event handler class implementing the

 *     RulesEventHandlerInterface. If none is specified the

 *     RulesEventDefaultHandler class will be used. While the default event

 *     handler has no settings, custom event handlers may be implemented to

 *     to make an event configurable. See RulesEventHandlerInterface.

 *   - access callback: (optional) An callback, which has to return whether the

 *     currently logged in user is allowed to configure rules for this event.

 *     Access should be only granted, if the user at least may access all the

 *     variables provided by the event.

 *   - help: (optional) A help text for rules reaction on this event.

 *   - variables: (optional) An array describing all variables that are

 *     available for elements reacting on this event. Each variable has to be

 *     described by a sub-array with the possible attributes:

 *     - label: The label of the variable. Start capitalized. Required.

 *     - type: The rules data type of the variable. All types declared in

 *       hook_rules_data_info() or supported by hook_entity_property_info() may

 *       be specified.

 *     - bundle: (optional) If the type is an entity type, the bundle of the

 *       entity.

 *     - description: (optional) A description for the variable.

 *     - 'options list': (optional) A callback that returns an array of possible

 *       values for this variable as specified for entity properties at

 *       hook_entity_property_info().

 *     - 'skip save': (optional) If the variable is saved after the event has

 *       occurred anyway, set this to TRUE. So rules won't save the variable a

 *       second time. Defaults to FALSE.

 *     - handler: (optional) A handler to load the actual variable value. This

 *       is useful for lazy loading variables. The handler gets all so far

 *       available variables passed in the order as defined. Also see

 *       http://drupal.org/node/884554.

 *       Note that for lazy-loading entities just the entity id may be passed

 *       as variable value, so a handler is not necessary in that case.

 *

 *  @see rules_invoke_event()

 */

function hook_rules_event_info() {

  $items = array(

    'node_insert' => array(

      'label' => t('After saving new content'),

      'group' => t('Node'),

      'variables' => rules_events_node_variables(t('created content')),

    ),

    'node_update' => array(

      'label' => t('After updating existing content'),

      'group' => t('Node'),

      'variables' => rules_events_node_variables(t('updated content'), TRUE),

    ),

    'node_presave' => array(

      'label' => t('Content is going to be saved'),

      'group' => t('Node'),

      'variables' => rules_events_node_variables(t('saved content'), TRUE),

    ),

    'node_view' => array(

      'label' => t('Content is going to be viewed'),

      'group' => t('Node'),

      'variables' => rules_events_node_variables(t('viewed content')) + array(

        'view_mode' => array('type' => 'text', 'label' => t('view mode')),

      ),

    ),

    'node_delete' => array(

      'label' => t('After deleting content'),

      'group' => t('Node'),

      'variables' => rules_events_node_variables(t('deleted content')),

    ),

  );

  // Specify that on presave the node is saved anyway.

  $items['node_presave']['variables']['node']['skip save'] = TRUE;

  return $items;

}

/**

 * Define rules data types.

 *

 * This hook is required in order to add a new rules data type. It should be

 * placed into the file MODULENAME.rules.inc, which gets automatically included

 * when the hook is invoked.

 * Rules builds upon the entity metadata module, thus to improve the support of

 * your data in rules, make it an entity if possible and provide metadata about

 * its properties and CRUD functions by integrating with the entity metadata

 * module.

 * For a list of data types defined by rules see rules_rules_core_data_info().

 *

 *

 * @return

 *   An array of information about the module's provided data types. The array

 *   contains a sub-array for each data type, with the data type name as the

 *   key. The name may only contain lower case alpha-numeric characters and

 *   underscores and should be prefixed with the providing module name. Possible

 *   attributes for each sub-array are:

 *   - label: The label of the data type. Start uncapitalized. Required.

 *   - parent: (optional) A parent type may be set to specify a sub-type

 *     relationship, which will be only used for checking compatible types. E.g.

 *     the 'entity' data type is parent of the 'node' data type, thus a node may

 *     be also used for any action needing an 'entity' parameter. Can be set to

 *     any known rules data type.

 *   - ui class: (optional) Specify a class that is used to generate the

 *     configuration UI to configure parameters of this type. The given class

 *     must extend RulesDataUI and may implement the

 *     RulesDataDirectInputFormInterface in order to allow the direct data input

 *     configuration mode. For supporting selecting values from options lists,

 *     the UI class may implement RulesDataInputOptionsListInterface also.

 *     Defaults to RulesDataUI.

 *   - wrap: (optional) If set to TRUE, the data is wrapped internally using

 *     wrappers provided by the entity API module. This is required for entities

 *     and data structures to support selecting a property via the data selector

 *     and for intelligent saving.

 *   - is wrapped: (optional) In case the data wrapper is already wrapped when

 *     passed to Rules and Rules should not unwrap it when passing the data as

 *     argument, e.g. to an action, set this to TRUE. The default FALSE is fine

 *     in most cases.

 *   - wrapper class: (optional) Allows the specification of a custom wrapper

 *     class, which has to inherit from 'EntityMetadataWrapper'. If given Rules

 *     makes use of the class for wrapping the data of the given type. However

 *     note that if data is already wrapped when it is passed to Rules, the

 *     existing wrappers will be kept.

 *     For modules implementing identifiable data types being non-entites the

 *     class RulesIdentifiableDataWrapper is provided, which can be used as base

 *     for a custom wrapper class. See RulesIdentifiableDataWrapper for details.

 *   - property info: (optional) May be used for non-entity data structures to

 *     provide info about the data properties, such that data selectors via an

 *     entity metadata wrapper are supported. Specify an array as expected by

 *     the $info parameter of entity_metadata_wrapper().

 *   - creation callback: (optional) If 'property info' is given, an optional

 *     callback that makes use of the property info to create a new instance of

 *     this data type. Entities should use hook_entity_info() to specify the

 *     'creation callback' instead, as utilized by the entity API module. See

 *     rules_action_data_create_array() for an example callback.

 *   - property defaults: (optional) May be used for non-entity data structures

 *     to to provide property info defaults for the data properties. Specify an

 *     array as expected by entity_metadata_wrapper().

 *   - group: (optional) A group for this element, used for grouping the data

 *     types in the interface. Should start with a capital letter and be

 *     translated.

 *   - token type: (optional) The type name as used by the token module.

 *     Defaults to the type name as used by rules. Use FALSE to let token ignore

 *     this type.

 *   - cleaning callback: (optional) A callback that input evaluators may use

 *     to clean inserted replacements; e.g. this is used by the token evaluator.

 *

 *  @see entity_metadata_wrapper()

 *  @see hook_rules_data_info_alter()

 *  @see rules_rules_core_data_info()

 */

function hook_rules_data_info() {

  return array(

    'node' => array(

      'label' => t('content'),

      'parent' => 'entity',

      'group' => t('Node'),

    ),

    // Formatted text as used by in hook_entity_property_info() for text fields.

    'text_formatted' => array(

      'label' => t('formatted text'),

      'ui class' => 'RulesDataUITextFormatted',

      'wrap' => TRUE,

      'property info' => entity_property_text_formatted_info(),

    ),

  );

}

/**

 * Defines rules plugins.

 *

 * A rules configuration may consist of elements being instances of any rules

 * plugin. This hook can be used to define new or to extend rules plugins.

 *

 * @return

 *   An array of information about the module's provided rules plugins. The

 *   array contains a sub-array for each plugin, with the plugin name as the

 *   key. The name may only contain lower case alpha-numeric characters,

 *   underscores and spaces and should be prefixed with the providing module

 *   name. Possible attributes for

 *   each sub-array are:

 *   - label: A label for the plugin. Start capitalized. Required only for

 *     components (see below).

 *   - class: The implementation class. Has to extend the RulesPlugin class.

 *   - embeddable: A container class in which elements of those plugin may be

 *     embedded via the UI or FALSE to disallow embedding it via the UI. This

 *     has no implications on the API level though. Common classes that are

 *     used here are RulesConditionContainer and RulesActionContainer.

 *   - component: If set to TRUE, the rules admin UI will list elements of those

 *     plugin in the components UI and allows the creation of new components

 *     based upon this plugin. Optional.

 *   - extenders: This allows one to specify faces extenders, which may be used

 *     to dynamically implement interfaces. Optional. All extenders specified

 *     here are setup automatically by rules once the object is created. To

 *     specify set this to an array, where the keys are the implemented

 *     interfaces pointing to another array with the keys:

 *     - class: The class of the extender, implementing the FacesExtender

 *       and the specified interface. Either 'class' or 'methods' has to exist.

 *     - methods: An array of callbacks that implement the methods of the

 *       interface where the method names are the keys and the callback names

 *       the values. There has to be a callback for each defined method.

 *     - file: An optional array describing the file to include when a method

 *       of the interface is invoked. The array entries known are 'type',

 *       'module', and 'name' matching the parameters of module_load_include().

 *       Only 'module' is required as 'type' defaults to 'inc' and 'name' to

 *       NULL.

 *   - overrides: An optional array, which may be used to specify callbacks to

 *     override specific methods. For that the following keys are supported:

 *     - methods: As in the extenders array, but you may specify as many methods

 *       here as you like.

 *     - file: Optionally an array specifying a file to include for a method.

 *       For each method appearing in methods a file may be specified by using

 *       the method name as key and another array as value, which describes the

 *       file to include - looking like the file array supported by 'extenders'.

 *   - import keys: (optional) Embeddable plugins may specify an array of import

 *     keys, which the plugin make use for exporting. Defaults to the upper

 *     case plugin name, thus the key 'OR' in an export triggers the creation

 *     of the 'or' plugin. Note that only uppercase values are allowed, as

 *     lower case values are treated as action or condition exports.

 *

 *  @see class RulesPlugin

 *  @see hook_rules_plugin_info_alter()

 */

function hook_rules_plugin_info() {

  return array(

    'or' => array(

      'label' => t('Condition set (OR)'),

      'class' => 'RulesOr',

      'embeddable' => 'RulesConditionContainer',

      'component' => TRUE,

      'extenders' => array(

        'RulesPluginUIInterface' => array(

          'class' => 'RulesConditionContainerUI',

        ),

      ),

    ),

    'rule' => array(

      'class' => 'Rule',

      'embeddable' => 'RulesRuleSet',

      'extenders' => array(

        'RulesPluginUIInterface' => array(

          'class' => 'RulesRuleUI',

        ),

      ),

      'import keys' => array('DO', 'IF'),

    ),

  );

}

/**

 * Declare provided rules input evaluators.

 *

 * The hook implementation should be placed into the file MODULENAME.rules.inc,

 * which gets automatically included when the hook is invoked.

 * For implementing an input evaluator a class has to be provided which

 * extends the abstract RulesDataInputEvaluator class. Therefore the abstract

 * methods prepare() and evaluate() have to be implemented, as well as access()

 * and help() could be overridden in order to control access permissions or to

 * provide some usage help.

 *

 * @return

 *   An array of information about the module's provided input evaluators. The

 *   array contains a sub-array for each evaluator, with the evaluator name as

 *   the key. The name may only contain lower case alpha-numeric characters and

 *   underscores and should be prefixed with the providing module name. Possible

 *   attributes for each sub-array are:

 *   - class: The implementation class, which has to extend the

 *     RulesDataInputEvaluator class. Required.

 *   - weight: A weight for controlling the evaluation order of multiple

 *     evaluators. Required.

 *   - type: Optionally, the data types for which the input evaluator should be

 *     used. Defaults to 'text'. Multiple data types may be specified using an

 *     array.

 *

 *  @see class RulesDataInputEvaluator

 *  @see hook_rules_evaluator_info_alter()

 */

function hook_rules_evaluator_info() {

  return array(

    'token' => array(

      'class' => 'RulesTokenEvaluator',

      'type' => array('text', 'uri'),

      'weight' => 0,

     ),

  );

}

/**

 * Declare provided rules data processors.

 *

 * The hook implementation should be placed into the file MODULENAME.rules.inc,

 * which gets automatically included when the hook is invoked.

 * For implementing a data processors a class has to be provided which

 * extends the abstract RulesDataProcessor class. Therefore the abstract

 * method process() has to be implemented, but also the methods form() and

 * access() could be overridden in order to provide a configuration form or

 * to control access permissions.

 *

 * @return

 *   An array of information about the module's provided data processors. The

 *   array contains a sub-array for each processor, with the processor name as

 *   the key. The name may only contain lower case alpha-numeric characters and

 *   underscores and should be prefixed with the providing module name, whereas

 *   'select' is reserved as well.

 *   Possible attributes for each sub-array are:

 *   - class: The implementation class, which has to extend the

 *     RulesDataProcessor class. Required.

 *   - weight: A weight for controlling the processing order of multiple data

 *     processors. Required.

 *   - type: Optionally, the data types for which the data processor should be

 *     used. Defaults to 'text'. Multiple data types may be specified using an

 *     array.

 *

 *  @see class RulesDataProcessor

 *  @see hook_rules_data_processor_info_alter()

 */

function hook_rules_data_processor_info() {

  return array(

    'date_offset' => array(

      'class' => 'RulesDateOffsetProcessor',

      'type' => 'date',

      'weight' => -2,

     ),

  );

}

/**

 * Alter rules compatible actions.

 *

 * The implementation should be placed into the file MODULENAME.rules.inc, which

 * gets automatically included when the hook is invoked.

 *

 * @param $actions

 *   The items of all modules as returned from hook_rules_action_info().

 *

 * @see hook_rules_action_info().

 */

function hook_rules_action_info_alter(&$actions) {

  // The rules action is more powerful, so hide the core action

  unset($actions['rules_core_node_assign_owner_action']);

  // We prefer handling saving by rules - not by the user.

  unset($actions['rules_core_node_save_action']);

}

/**

 * Alter rules conditions.

 *

 * The implementation should be placed into the file MODULENAME.rules.inc, which

 * gets automatically included when the hook is invoked.

 *

 * @param $conditions

 *   The items of all modules as returned from hook_rules_condition_info().

 *

 * @see hook_rules_condition_info()

 */

function hook_rules_condition_info_alter(&$conditions) {

  // Change conditions.

}

/**

 * Alter rules events.

 *

 * The implementation should be placed into the file MODULENAME.rules.inc, which

 * gets automatically included when the hook is invoked.

 *

 * @param $events

 *   The items of all modules as returned from hook_rules_event_info().

 *

 * @see hook_rules_event_info().

 */

function hook_rules_event_info_alter(&$events) {

  // Change events.

}

/**

 * Alter rules data types.

 *

 * The implementation should be placed into the file MODULENAME.rules.inc, which

 * gets automatically included when the hook is invoked.

 *

 * @param $data_info

 *   The items of all modules as returned from hook_rules_data_info().

 *

 * @see hook_rules_data_info()

 */

function hook_rules_data_info_alter(&$data_info) {

  // Change data types.

}

/**

 * Alter rules plugin info.

 *

 * The implementation should be placed into the file MODULENAME.rules.inc, which

 * gets automatically included when the hook is invoked.

 *

 * @param $plugin_info

 *   The items of all modules as returned from hook_rules_plugin_info().

 *

 * @see hook_rules_plugin_info()

 */

function hook_rules_plugin_info_alter(&$plugin_info) {

  // Change plugin info.

}

/**

 * Alter rules input evaluator info.

 *

 * The implementation should be placed into the file MODULENAME.rules.inc, which

 * gets automatically included when the hook is invoked.

 *

 * @param $evaluator_info

 *   The items of all modules as returned from hook_rules_evaluator_info().

 *

 * @see hook_rules_evaluator_info()

 */

function hook_rules_evaluator_info_alter(&$evaluator_info) {

  // Change evaluator info.

}

/**

 * Alter rules data_processor info.

 *

 * The implementation should be placed into the file MODULENAME.rules.inc, which

 * gets automatically included when the hook is invoked.

 *

 * @param $processor_info

 *   The items of all modules as returned from hook_rules_data_processor_info().

 *

 * @see hook_rules_data_processor_info()

 */

function hook_rules_data_processor_info_alter(&$processor_info) {

  // Change processor info.

}

/**

 * Act on rules configuration being loaded from the database.

 *

 * This hook is invoked during rules configuration loading, which is handled

 * by entity_load(), via classes RulesEntityController and EntityCRUDController.

 *

 * @param $configs

 *   An array of rules configurations being loaded, keyed by id.

 */

function hook_rules_config_load($configs) {

  $result = db_query('SELECT id, foo FROM {mytable} WHERE id IN(:ids)', array(':ids' => array_keys($configs)));

  foreach ($result as $record) {

    $configs[$record->id]->foo = $record->foo;

  }

}

/**

 * Respond to creation of a new rules configuration.

 *

 * This hook is invoked after the rules configuration is inserted into the

 * the database.

 *

 * @param RulesPlugin $config

 *   The rules configuration that is being created.

 */

function hook_rules_config_insert($config) {

  db_insert('mytable')

    ->fields(array(

      'nid' => $config->id,

      'plugin' => $config->plugin,

    ))

    ->execute();

}

/**

 * Act on a rules configuration being inserted or updated.

 *

 * This hook is invoked before the rules configuration is saved to the

 * database.

 *

 * @param RulesPlugin $config

 *   The rules configuration that is being inserted or updated.

 */

function hook_rules_config_presave($config) {

  if ($config->id && $config->owner == 'your_module') {

    // Add custom condition.

    $config->conditon(/* Your condition */);

  }

}

/**

 * Respond to updates to a rules configuration.

 *

 * This hook is invoked after the configuration has been updated in the

 * database.

 *

 * @param RulesPlugin $config

 *   The rules configuration that is being updated.

 */

function hook_rules_config_update($config) {

  db_update('mytable')

    ->fields(array('plugin' => $config->plugin))

    ->condition('id', $config->id)

    ->execute();

}

/**

 * Respond to rules configuration deletion.

 *

 * This hook is invoked after the configuration has been removed from the

 * database.

 *

 * @param RulesPlugin $config

 *   The rules configuration that is being deleted.

 */

function hook_rules_config_delete($config) {

  db_delete('mytable')

    ->condition('id', $config->id)

    ->execute();

}

/**

 * Respond to rules configuration execution.

 *

 * This hook is invoked right before the rules configuration is executed.

 *

 * @param RulesPlugin $config

 *   The rules configuration that is being executed.

 */

function hook_rules_config_execute($config) {

}

/**

 * Define default rules configurations.

 *

 * This hook is invoked when rules configurations are loaded. The implementation

 * should be placed into the file MODULENAME.rules_defaults.inc, which gets

 * automatically included when the hook is invoked.

 *

 * @return

 *   An array of rules configurations with the configuration names as keys.

 *

 * @see hook_default_rules_configuration_alter()

 * @see hook_rules_config_defaults_rebuild()

 */

function hook_default_rules_configuration() {

  $rule = rules_reaction_rule();

  $rule->label = 'example default rule';

  $rule->active = FALSE;

  $rule->event('node_update')

       ->condition(rules_condition('data_is', array('data:select' => 'node:status', 'value' => TRUE))->negate())

       ->condition('data_is', array('data:select' => 'node:type', 'value' => 'page'))

       ->action('drupal_message', array('message' => 'A node has been updated.'));

  $configs['rules_test_default_1'] = $rule;

  return $configs;

}

/**

 * Alter default rules configurations.

 *

 * The implementation should be placed into the file

 * MODULENAME.rules_defaults.inc, which gets automatically included when the

 * hook is invoked.

 *

 * @param $configs

 *   The default configurations of all modules as returned from

 *   hook_default_rules_configuration().

 *

 * @see hook_default_rules_configuration()

 */

function hook_default_rules_configuration_alter(&$configs) {

  // Add custom condition.

  $configs['foo']->condition('bar');

}

/**

 * Act after rebuilding default configurations.

 *

 * This hook is invoked by the entity module after default rules configurations

 * have been rebuilt; i.e. defaults have been saved to the database.

 *

 * @param $rules_configs

 *   The array of default rules configurations which have been inserted or