Example 1: Basic usage with generic forms

If using the operation handlers that provide generic edit and add forms, an entity type can be created with only four functions. No form builder is needed, as it is provided by the operation handlers.

You might want to use the generic form operation handlers if your entity relies on FieldAPI to provide form elements, and has either only a title database field to show in the form, or no database fields to show in the form at all.

Note however that a limitation in drupal_write_record() means that entities cannot be saved to the database if the only database column that would be written is the serial id. This means that you need at least one of the title database property or the bundle property in order to ensure that the record to write for the new entity contains at least one column to write.

Another limitation of the generic approach is that because a generic form is used, all operation forms have the same form ID. This makes manipulating the form with hook_form_alter() more difficult.

Define the table in hook_schema()

You first need to define a table schema for the entity with hook_schema(). This can contain anything you like.

Define the entity type in hook_entity_info()

The Entity Operations UI requires some properties to be defined in hook_entity_info(), as additional properties to what Drupal Core expects.

The following Entity API properties are also required:

• 'module': This must specify the providing module for the entity type, i.e., the module that is implementing the hook.
• 'entity class': This must be set to 'Entity' or a subclass of that.
• 'access callback': This must be set to the Entity API access callback function, as the operations make use of entity_access().

The following is an example of defining operations in hook_entity_info():

<?php
function mymodule_entity_info() {
  $return = array(
    'myentity' => array(
      // Core properties.
      // ...
      // Entity API properties.
      'module' => 'mymodule',
      'entity class' => 'Entity',
      'access callback' => 'myentity_access', // See below
      // Entity Operations API
      'operations ui' => array(
        // The base path for your entities. This is the same as your entity's URI
        // but without the ID suffix. (In fact, you can set
        // entity_operations_entity_uri() as your URI callback, which will use the
        // value here).
        'path' => 'myentity',
      ),
    ),
  );
  return $return;
}
?>

Define the operations

The actual operations are defined in hook_entity_operation_info(). This is separate from hook_entity_info() because unlike entity info, it does not generally need to be loaded very often.

 <?php
function mymodule_entity_operation_info() {
 $info = array(
    'myentity' => array(
      // List of operations this entity type uses.
      'view' => array(
        // The handler class.
        'handler' => 'EntityOperationsOperationEntityView',
        // The places this operation is exposed.
        'provision' => array(
          // Show as an entity tab.
          'menu' => array(
            // Marks this as the default operation tab, that is, the one that
            // shows for the entity's URI.
            'default' => TRUE,
            // Properties for the menu item.
            'menu item' => array(
              // Override the title.
              'title' => 'Foobar',
            ),
          ),
          // A field handler for Views.
          // If there are no further settings, for easier DX it suffices to set
          // a provision item's value to TRUE.
          'views field' => TRUE,
        ),
      ),
      'add' => array(
        'handler' => 'EntityOperationsOperationAddGeneric',
        'provision' => array(
          'menu' => TRUE,
        ),
      ),
      'edit' => array(
        'handler' => 'EntityOperationsOperationEditGeneric',
        'provision' => array(
          'menu' => TRUE,
          'views field' => TRUE,
        ),
      ),
      'publish' => array(
        'handler' => 'EntityOperationsOperationEntityPublish',
        'provision' => array(
          // Show the operation form as an entity tab.
          'menu' => TRUE,
        ),
      ),
    ),
  );
  return $info;
}
?>

Define the access in callback_entity_access()

Most operation handlers call entity_access() to determine whether the user has access to the operation. Your module should implement this callback, for example:

<?php
function myentity_access($op, $entity, $account, $entity_type) {
  // Return TRUE or FALSE to grant or deny access.
}
?>

While within Entity API, the values of $op are one of 'view', 'update', 'create' or 'delete', Entity Operations extends this with whatever verb the handler defines for the operation.