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

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

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

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://<domain>/<endpoint-path/node.json (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[orderby][property]=<asc|desc>


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&parameters[type]=blog_post&options[parameters_op][type]=!=&fields=nid,changed

Drupal Entities – PHP Class per bundle

If you would like a bit more polymorphism in your drupal entities, this might cheer you up 😀

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.

Continue reading

hook_theme doesn’t get called

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)

/**
 * 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.