As I create Drupal sites I create many types of content. Sometimes I want to create content which has a use on the website, but the data related to the content entry shouldn’t be seen by the public as a Node (Nodes default url is public in Drupal by default). Nodes are also heavyweight in Drupal — Entities are lighter. So I’d love to make entities for everything. But, entities can be cumbersome to create. Recently I found the EntitySpice module which uses Drush to create a generator function that will output a complete useable (basic) module for a custom Entity. You may then tweak the resulting code and Entity from within Drupal. Allow me to give a full example of using Entityspice and its cook generator command.
dgurba at odin in ~/.../all/modules/entityspice $ drush help cook Create a module containing an entity (Cook an entity type). Arguments: machine_name Machine name of generated entity. Options: --admin_bundle This is a URI relative to admin/ path. Do not include admin/ --camel_label Label of entity displayed in CamelCase. --default_uri Default path from which the entity can be accessed. IMPORTANT: currently this must be a two part menu path, such as xxxx/yyy/ with final slash. --delete_form_redirect When an entity is deleted, It's path will become invalid and user should be redirected to a new path. --description Description of module in .info file. --has_bundle Whether entity type supports bundle or not (TRUE/FALSE). --has_revision Whether entity type supports revisioning or not (TRUE/FALSE). --label Label of entity displayed in admin pages. --machine_camel Must match the regular machine name! --menu_label --name Name of module in .info file. --package Package to which this module belongs (In modules page) for .info file. Aliases: cook
You can then try to create a custom entity by supplying all the values as needed, I then selected the default options:
$ drush cook mailing_config --admin_bundle=mailing_config --camel_label=MailingConfig --default_uri=mailing_config/entry/ --description="A sample custom mail template configuration entity for Drupal7." --has_bundle=TRUE --has_revision=TRUE --label="Mailing Configuration" --machine_camel=mailing_config --menu_label="mailing configurations" --name=mailingconfig --package=other Do you want to use default options? (y/n): y [ ... Lots of output of command running ... ]
Then you can see that the custom entity is created in sites/all/modules:
dgurba at odin in ~/.../sites/all/modules $ ls mailing_config -l total 20 drwxrwxr-x 2 dgurba dgurba 4096 Jul 24 20:24 inc drwxrwxr-x 2 dgurba dgurba 4096 Jul 24 20:24 lib -rw-rw-r-- 1 dgurba dgurba 219 Jul 24 20:24 mailing_config.info -rw-rw-r-- 1 dgurba dgurba 689 Jul 24 20:24 mailing_config.install -rw-rw-r-- 1 dgurba dgurba 1002 Jul 24 20:24 mailing_config.module
What this is creating is an includes directory which has Drupal (Core) entity functions and form functions implemented in separate files. All the files are creating a basic, entity with no fields attached to it currently. It can then be enabled as any other module:
$ drush en mailing_config -y The following extensions will be enabled: mailing_config Do you really want to continue? (y/n): y mailing_config was enabled successfully. [ok] mailing_config defines the following permissions: administer mailing_config bundles, administer mailing_config, manage mailing_config, access mailing_config, view own mailing_config, edit own mailing_config
Once our entity is created in code we can configure it further using the Drupal admin UI. Head over to /es/ and EntitySpice will tell you that it knows about a Mailing Config entity — but no bundles (instances) of this entity definition exist in the system. We will make a bundle called “recurring emails” (this is somewhat a poor name, but bear with me). This entity + bundle will allow us to define database entries that denote an adminstrative label for a message to be sent, the date the message should be sent, the email template to use and the status of whether or not the email was sent. So we can at any time configure new emails to be sent from the system, and manage and maintain email notifications to groups of users in this system.
We create the bundle and fields:

We can try to add a new mailing configuration, but we must 1st define a bundle instance for them (because we said this entity supported bundles).

EntitySpice offers a bundle administration screen. It is very similar to the /admin/structure/content_types page found in drupal core.

Example fields for our bundle. This is where we have a title, date, type of email template and sending status fields.
We can then add some example entries for this bundle:

After creating the bundle configuration — I created some sample entries. This could be entries for a webapp that has a window of operation and will notifiy sets of users about site availability.
So, after alllll that what did we achieve. We created a new Entity in Drupal that can store fields, supports bundle(s) and is currently revision-able. I gave an example of a bundle of this entity that could hold mailing configurations. This great because I have an existing application that uses a simple php array to store configuration in plain variables and outputs:

This pre-existing mailing configuration uses 3 variables and a php multidimensional array to store configuration. Entityspice + Entities would be more flexible!
By leveraging EntitySpice and Entities we could replace this simple Array with usable entities (think php Objects) and I could then add Rules to process queues of these entities on Cron, use entity reference to relate components within the system together, use Views to make lists of these entries. The possibilities are limitless. EntitySpice is a great simple generator system that creates alot of boilerplate code for custom entites for you!
Looking for quality web hosting? Look no further than Arvixe Web Hosting!