Drupal on despatches

Drupal 8 error: "The following reasons prevent the modules from being uninstalled: Fields pending deletion"

Thu, 28 Sep 2017 15:53:15 +0000

When you try and uninstall a module which has a field that you have used, it can throw the following error:

``` The following reasons prevent the modules from being uninstalled: Fields pending deletion\ ```

This is an issue in both Drupal 7 and Drupal 8. This is due to the fact that drupal doesn't actually delete the data for the field when you delete the field. It deletes the data during cron runs. If cron hasn't been run enough times since you deleted the field, drupal won't let you uninstall the module.

To force drupal to purge the data, you can run the following command

```bash drush php-eval \'field_purge_batch(500);\'\ ```

Increase 500 to a high enough number to wipe out the data. Afte this has completed, you should be able to uninstall the module

References:
Module uninstall dependencies (drupal stackexchange)
Message "Required by Drupal (Fields Pending Deletion)" baffles users
Can't uninstall YAML because of following reason: Fields pending deletion

Drupal 7 + Services: Paging & Filtering the index endpoint

Sun, 03 Sep 2017 12:20:54 +0000

There are a lot of ways to manipulate the data returned by the index endpoint. In this post, we are going to consider the node index endpoint. By default, this endpoint returns all nodes sorted in descending order of last update with 20 items per page.

You access the node index endpoint by going to

http:/// (or the alias given to node in the resources section)


You can replace .json with with other extensions to get the same data in
different formats
To access the second page, you can use the page parameter
```
node.json?page=2
node.json?page=5
```
To change the number of items on each page, you need the “perform unlimited
index” queries permission. You use the pagesize parameter to change it
```
node.json?pagesize=100
node.json?pagesize=50
```
To filter a field, you can use the parameters[property] where ‘property’ is the
field on which you want to filter. It needs to be a field on the node table, and
not a drupal field as it does not do the joins to pull in field data.
```
node.json?parameters[type]=blog_post
node.json?parameters[type]=article
```
To apply a different filter than of equality, you can use
options[parameters_op][property] where property is the same as above.
```
node.json?parameters[created]=1431065220&options[parameters_op][created]=<
node.json?parameters[changed]=1431065220&options[parameters_op][changed]=>
```
To return fewer fields, you can use fields and comma separate the properties.
Once again, you can only specify properties on the entity (i.e fields on the
base table)
```
node.json?fields=nid,changed
node.json?fields=nid,created,title
```
you can sort the results by using options[property]=
```
node.json?options[orderby][nid]=asc
node.json?options[orderby][created]=desc
```
You can also mix and match these separate options
```
node.json?page=10&pagesize=100¶meters[type]=blog_post&options[parameters_op][type]=!=&fields=nid,changed
```



Drupal Entities - PHP Class per bundle
Thu, 17 Apr 2014 11:18:08 +0000
If you would like a bit more polymorphism in your drupal entities, this might
cheer you up :-D
I was looking for a way to have a class hierarchy that matched the bundle
“hierarchy” of entities in drupal. Yes, they are all “subclasses” of ONE parent,
but it is still useful to be able to have a class per bundle.
The
entity bundle plugin does
a good job of providing a plugin framework to instantiate classes per bundle
type. There is also
an example of how to use this.
However, this was a bit of overkill for me. I did however borrow the idea (and
some code) to implement it in a simpler fashion.
Implement a custom controller and override the create and the query methods
```phg
    class MyEntityAPIController extends EntityAPIController {
      /**
       * Overrides EntityAPIController::query().
       */
      public function query($ids, $conditions, $revision_id = FALSE) {
        $query = $this->buildQuery($ids, $conditions, $revision_id);
        $result = $query->execute();
        $result->setFetchMode(PDO::FETCH_ASSOC);

        // Build the resulting objects ourselves, since the standard PDO ways of
        // doing that are completely useless.
        $objects = array();
        foreach ($result as $row) {
          $row['is_new'] = FALSE;
          $objects[] = $this->create($row);
        }
        return $objects;
      }

      /**
       * Overrides EntityAPIController::create().
       */
      public function create(array $values = array()) {
        if (!isset($values[$this->entityInfo['entity keys']['bundle']])) {
          throw new Exception(t('No bundle provided to MyEntityAPIController::create().'));
        }

        $bundle = $values[$this->entityInfo['entity keys']['bundle']];
          // Add is_new property if it is not set.
        $values += array(
          'is_new' => TRUE,
        );

        $default_class = isset($this->entityInfo['entity class']) ? $this->entityInfo['entity class'] : NULL;
        $class = isset($this->entityInfo['bundles'][$bundle]['entity class']) ? $this->entityInfo['bundles'][$bundle]['entity class'] : $default_class;
        if (!class_exists($class)) {
          $class = "Entity";
        }

        return new $class($values, $this->entityType);
      }

    }
```
I can now define a PHP class for each bundle as follows in hook_entity_info
```php
      $entity['myentity'] = array(
        'label' => t('myentity'),
        'module' => 'mymodule',
        'entity class' => 'MyEntity',  // Default entity class if not defined in bundle
        'controller class' => 'MyEntityAPIController',
        'base table' => 'myentity',
        'entity keys' => array(
          'id' => 'id',
          'label' => 'name',
          'bundle' => 'bundle',
        ),
        'bundles' => array(
          'bundle1' => array(
            'label' => 'Bundle 1',
            'entity class' => 'Bundle1Entity',
          ),
          'bundle2' => array(
            'label' => 'Bundle 2',
            'entity class' => 'Bundle2Entity',
          ),
        ),
```
Don’t forget to clear the cache and you should be able to get bundle specific
classes instantiated. It will fall back to the ’entity class’ defined for the
entity if the bundle ’entity class’ is not defined or cannot be found.



hook_theme doesn't get called
Tue, 22 Feb 2011 20:20:11 +0000
I was developing a new module in drupal and it needed a theme function to be
implemented.
As per the instructions, it was implemented as follows (to use a template)
```phg
/**
 * Implementation of hook_theme().
 */
function my_module_results_theme($existing, $type, $theme, $path) {

    return array(
        'my_block' => array(
            'template' => 'my_block',
            'arguments' => array(
                'var1' => NULL
            )
        )
    );
}
```
However, when trying to apply the theme, it didn’t work. I tried various things
and identified that the hook above was just not being called. A little bit of
digging helped me discover that themes are cached. This happens even in the dev
mode. To resolve this, go to
Administer  -> Performance -> Clear Cached Data (right at the bottom of the
page)
and et voila my theme was now being utilised.