Drupal Feeds

Happy Friday everyone, and a happy 4th of July weekend. This week we have April Sides on the program to talk about how much fun Drupal Camps are and what you will take away from them. 


With Buenos Aires Argentina user group we are organizing a meeting on Sat 22nd and Mon 24th of July

It's been a long time since our last camp was done on BsAs (2009) and thanks to the inspiration of Drupal Camp Chile we've been planning doing another for a while.

We finally put a day thanks to a visit from Enzo. We are calling it a "PicNic" and not a camp due to the extend it'll have, it will be two days:

  • On Saturday 22nd we'll have an sprint with mentoring
  • On Monday 24th there will be technical conferences

You can find more details on our event page.

The first release of the CDN module for Drupal was 9.5 years ago yesterday: cdn 5.x-1.0-beta1 was released on January 8, 2008!


On January 27, 2008, the first RC followed, with boatloads of new features. Over the years, it was ported to Drupal 61, 7 and 8 and gained more features (I effectively added every single feature that was requested — I loved empowering the site builder). I did the same with my Hierarchical Select module.

I was a Computer Science student for the first half of those 9.5 years, and it was super exciting to see people actually use my code on hundreds, thousands and even tens of thousands of sites! In stark contrast with the assignments at university, where the results were graded, then discarded.


Unfortunately this approach resulted in feature-rich modules, with complex UIs to configure them, and many, many bug reports and support requests, because they were so brittle and confusing. Rather than making the 80% case simple, I supported 99% of needed features, and made things confusing and complex for 100% of the users.

Main CDN module configuration UI in Drupal 7.


In my job in Acquia’s Office of the CTO, my job is effectively “make Drupal better & faster”.

In 2012–2013, it was improving the authoring experience by adding in-place editing and tightly integrating CKEditor. Then it shifted in 2014 and 2015 to “make Drupal 8 shippable”, first by working on the cache system, then on the render pipeline and finally on the intersection of both: Dynamic Page Cache and BigPipe. After Drupal 8 shipped at the end of 2015, the next thing became “improve Drupal 8’s REST APIs”, which grew into the API-First Initiative.

All this time (5 years already!), I’ve been helping to build Drupal itself (the system, the APIs, the infrastructure, the overarching architecture), and have seen the long-term consequences from both up close and afar: the concepts required to understand how it all works, the APIs to extend, override and plug in to. In that half decade, I’ve often cursed past commits, including my own!

That’s what led to:

  • my insistence that the dynamic_page_cache and big_pipe modules in Drupal 8 core do not have a UI, nor any configuration, and rely entirely on existing APIs and metadata to do their thing (with only a handful of bug reports in >18 months!)
  • my “Backwards Compatibility: Burden & Benefit” talk a few months ago
  • and of course this rewrite of the CDN module
CDN module in Drupal 8: radically simpler

I started porting the CDN module to Drupal 8 in March 2016 — a few months after the release of Drupal 8. It is much simpler to use (just look at the UI). It has less overhead (the UI is in a separate module, the altering of file URLs has far simpler logic). It has lower technical complexity (File Conveyor support was dropped, it no longer needs to detect HTTP vs HTTPS: it always uses protocol-relative URLs, less unnecessary configurability, the farfuture functionality no longer tries to generate file and no longer has extremely detailed configurability).

In other words: the CDN module in Drupal 8 is much simpler. And has much better test coverage too. (You can see this in the tarball size too: it’s about half of the Drupal 7 version of the module, despite significantly more test coverage!)

CDN UI module in Drupal 8.

all the fundamentals
  • the ability to use simple CDN mappings, including conditional ones depending on file extensions, auto-balancing, and complex combinations of all of the above
  • preconnecting (and DNS prefetching for older browsers)
  • a simple UI to set it up — in fact, much simpler than before!
  1. the CDN module now always uses protocol-relative URLs, which means there’s no more need to distinguish between HTTP and HTTPS, which simplifies a lot
  2. the UI is now a separate module
  3. the UI is optional: for power users there is a sensible configuration structure with strict config schema validation
  4. complete unit test coverage of the heart of the CDN module, thanks to D8’s improved architecture
  5. preconnecting (and DNS prefetching) using headers rather than tags in , which allows a much simpler/cleaner Symfony response subscriber
  6. tours instead of advanced help, which very often was ignored
  7. there is nothing to configure for the SEO (duplicate content prevention) feature anymore
  8. nor is there anything to configure for the Forever cacheable files feature anymore (named Far Future expiration in Drupal 7), and it’s a lot more robust
  1. File Conveyor support
  2. separate HTTPS mapping (also mentioned above)
  3. all the exceptions (blacklist, whitelist, based on Drupal path, file path…) — all of them are a maintenance/debugging/cacheability nightmare
  4. configurability of SEO feature
  5. configurability of unique file identifiers for the Forever cacheable files feature
  6. testing mode

For very complex mappings, you must manipulate cdn.settings.yml — there’s inline documentation with examples there. Those who need the complex setups don’t mind reading three commented examples in a YAML file. This used to be configurable through the UI, but it also was possible to configure it “incorrectly”, resulting in broken sites — that’s no longer possible.

There’s comprehensive test coverage for everything in the critical path, and basic integration test coverage. Together, they ensure peace of mind, and uncover bugs in the next minor Drupal 8 release: BC breaks are detected early and automatically.

The results after 8 months: contributed module maintainer bliss

The first stable release of the CDN module for Drupal 8 was published on December 2, 2016. Today, I released the first patch release: cdn 8.x-3.1. The change log is tiny: a PHP notice fixed, two minor automated testing infrastructure problems fixed, and two new minor features added.

We can now compare the Drupal 7 and 8 versions of the CDN module:

In other words: maintaining this contributed module now requires pretty much zero effort!


For your own Drupal 8 modules, no matter if they’re contributed or custom, I recommend a few key rules:

  • Selective feature set.
  • Comprehensive unit test coverage for critical code paths (UnitTestCase)2 + basic integration test coverage (BrowserTestBase) maximizes confidence while minimizing time spent.
  • Don’t provide/build APIs (that includes hooks) unless you see a strong use case for it. Prefer coarse over granular APIs unless you’re absolutely certain.
  • Avoid configurability if possible. Otherwise, use config schemas to your advantage, provide a simple UI for the 80% use case. Leave the rest to contrib/custom modules.

This is more empowering for the Drupal site builder persona, because they can’t shoot themselves in the foot anymore. It’s no longer necessary to learn the complex edge cases in each contributed module’s domain, because they’re no longer exposed in the UI. In other words: domain complexities no longer leak into the UI.

At the same time, it hugely decreases the risk of burnout in module maintainers!

And of course: use the CDN module, it’s rock solid! :)

Related reading

Finally, read Amitai Burstein’s “OG8 Development Mindset”! He makes very similar observations, albeit about a much bigger contributed module (Organic Groups). Some of my favorite quotes:

  1. About edge cases & complexity:
Edge cases are no longer my concern. I mean, I’m making sure that edge cases can be done and the API will cater to it, but I won’t go too far and implement them. […] we’ve somewhat reduced the flexibility in order to reduce the complexity; but while doing so, made sure edge cases can still hook into the process.

2. About tests:

I think there is another hidden merit in tests. By taking the time to carefully go over your own code - and using it - you give yourself some pause to think about the necessity of your recently added code. Do you really need it? If you are not afraid of writing code and then throwing it out the window, and you are true to yourself, you can create a better, less complex, and polished module.

3. About feature set & UI:

One of the mistakes that I feel made in OG7 was exposing a lot of the advanced functionality in the UI. […] But these are all advanced use cases. When thinking about how to port them to OG8, I think found the perfect solution: we did’t port it.

  1. I also did my bachelor thesis about Drupal + CDN integration, which led to the Drupal 6 version of the module. ↩︎

  2. Unit tests in Drupal 8 are wonderful, they’re nigh impossible in Drupal 7. They finish running in seconds. ↩︎

Drupal's Entity reference fields are the magic sauce that allows site builders and developers to relate different types of content. Because the fields allows builders and administrators to reference different types of content (entities), it facilitates the building of complex data models and site architectures.

Like anything in Drupal, the community takes the core tools and builds additional functionality on top. Here is a slew of modules that extend or complement the Drupal 8 core reference field so you can do even more!

Entity Reference Revisions

This module is from the team that brought you the Paragraphs module. Adds an Entity Reference field type that has revision support. It's based on the core Entity Reference module but allows you to reference a specific revision of an entity.

Use case:

An entity is actually part of a parent entity (with an embedded entity form). When the parent entity is updated, the referenced entity is also updated, thus the previous revision of the parent entity should still be pointing to the previous version of the entity in order to fully support revision diff and rollback.

Entity Reference Override

An entity reference field paired with a text field. You can use this module to

  • Override the title if you are linking to the referenced entity.
  • Add an extra CSS class to the referenced entity.
  • Override the default display mode for the field on an entity-by-entity basis.

Use case:

Aggregate lists of referenced entities like related articles, but you want to override the name or appearance of individual items.

Entity references with text

Allows you to provide custom text along with one or more entity references.

Use case:

  • Add a referenced author, the word "and ”, and then another referenced author.
  • On another node, Add a referenced author, the words "with support from ”, and then another referenced author.
  • On another node, Add a referenced author, a comma ", ”, another referenced author, the word "and ”, and then another referenced author.
Entity Reference Display

This module adds a field type that allows you to select the display mode for entity reference fields. This allows an editor to select from different display modes such as Teaser, Full, or any you add.

It also includes a Selected display mode field formatter which renders the referenced entities with the selected display mode.

Use case:

Allowing the administrator to change the display of related articles from a grid display mode to a list display mode.

Entity Reference Views Select

This module allows you to change your Entity reference fields to be displayed as a select list, or checkboxes/radio buttons in administrative forms. It does this by allowing you to use Views as the reference method, where you can format the results giving the administrator a much better experience.

Use case:

Showing an icon or thumbnail in a selectable list when referencing a list, or a referenced image.

Entity Reference Tab / Accordion Formatter

This cool little module works on both Entity Reference and Entity Reference Revisions fields and provides a field formatter for displaying the referenced entity in jQuery Tabs or jQuery Accordion.

Use case:

Returning multivalue Paragraphs items in tabs or accordion format.

Views Entity Reference Filter

Provides a new admin friendly Views filter for configuring entity reference fields. It allows users to select the labels of the entities they want to filter on rather than manually entering the IDs.

Use case:

Providing a better admin experience.

Better Entity Reference Formatter

This module extends Drupal's default field formatter for entity reference fields in order to make it more flexible by introducing a new field formatter plugin. Along side the view mode option, you can also define the number of entities to return, or a specific entity, like the first, last, or offset them.

Use case:

Showing the first related product referenced from another product.

Entity Reference Validators

The plural in its name suggests more is coming, but currently this module adds a single validator for Entity Reference fields, the Circular reference validator. This prevents you from using the entity reference field to reference itself.

Use case:

Preventing an entity reference field on node 1 from linking to node 1.

Entity Reference Integrity

This interesting sounding module lists other entities that reference your entity.

It also includes a sub-module Entity Reference Integrity Enforce which will attempt to protect entities that are referenced by other entities, and not allowing its deletion.

Use case:

Protect the integrity of the site by protecting referenced content.

Entity Reference Quantity

This module extends the default entity reference field that includes a "Quantity" value in the field definition so you don't have to build a separate entity just to store two distinct fields.

It also includes autocomplete and dropdown field widgets that allow you to select which entity and add the quantity value.

Use case:

I'll use the example from this great blog on the module: A real world example might be a deck builder for a trading card game like Magic: The Gathering or the DragonBall Z TCG. We want to reference a card from a deck entity and put in the quantity at the same time.

Entity Reference Formatter

This module creates a generic field formatter for referenced entities which allows you to select the formatter based on the referenced entity in the display settings form.

Use case:

When referencing custom entities that don't have view-modes of their own, you would not need to write your own custom formatters

Permissions by field

This module extends the Entity Reference field that adds permissions along with the referenced entity. By adding this field, you can manage access to the entities referenced by this field and select permission level (none, view, update, delete).

Use case:

A lighter version of Organic Groups, or the Group modules.

Views Reference Field

In Drupal 8, Views are now entities! Drupal core's Entity Reference field is able to reference Views, however you can't actually reference the Views displays. This module extends core's entity reference module to add the display ID so that a View can be rendered in a field formatter.

Use case:

Adding a Views reference field to a Paragraphs bundle so you can have a view in and around other paragraph bundles. We implemented this technique in the Bootstrap Paragraphs module.

Dynamic Entity Reference

So cool! This awesome module adds the functionality to let you reference more than one entity type. It create a single field in which you can reference Users, Blocks, Nodes, Contact Forms, Taxonomy Terms, etc!

Use case:

Creating a "related” field, and allowing your administrators to select anything they want.

Entity Reference Drag & Drop

This module creates a Drag & Drop widget for the standard Entity reference fields. It provides you with a list of available entities on the left, and you can select them by dragging and dropping them to the list on the right.

Use case:

Providing a better admin experience.

Phew! Thanks for making it to the end! Do you have a favorite Entity Reference module that we missed? Let us know on Twitter at @xenophiles and @thejimbirch

Happy Drupaling!


Thanks to Mike Acklin for his help with this article, and to all the awesome module maintainers and contributors!

Photo by Bethany Legg on Unsplash

Annually, the information technology research firm Gartner publishes its magic quadrant report comparing web content management systems (CMS) at the enterprise level. At this writing, the most recent report places Acquia/Drupal, Adobe Experience Manager (AEM), and Sitecore as the three leaders in the field, based on both their completeness of vision and their ability to execute on organizational requirements.

We'll walkthrough setting up your local development LAMP environment, installing Drupal 8, configuring Composer, and your first module: Simple FB Connect.

10 best practices for implementing the Drupal coding standards

Learn about the Drupal community coding standards and best practices that every Drupal developer should care whenever writing the code for Drupal. If you are truly committed to Drupal, then you should guarantee the code you contribute back be standards compliant. Here are ten of the best practices for implementing Drupal coding standards:

1. Spacing and Tabbing

  • Use double space (not tab, yes both are different) for indentation 
  • Often, the IDE/Editor that we use for Drupal development aggravates this issue as most of the IDE is configured to use tab for every line-break.
  • Press ensure that it aligns the cursor to the same indent as previous line with tabbing that caused this indentation issue.

2. Code comments

  • Check this link below for Drupal comment standards (https://www.drupal.org/node/1354). Comments are generally defined and used to state what the following line of code or block of code is doing and why we are writing the logic that way if it needs explanation for any future Drupal developer.
  • Three types of comments can be used in Drupal, Single line commenting (starts with //), Multi-line commenting (starts with /*) and Doxygen commenting (starts with /**).
  • Single line commenting and Doxygen commenting has a wide following in Drupal. Even for the comments with more than a line, it is handled with repeat use of single line commenting. The following example shows the usage pattern:

         // The first line of the comment goes here.
        // Some other comment here.
        // Some more comments here.
        // This saves the $node object and creates/updates the node

  • Comments are strictly not to be used to invalidate the code, which means you can’t use the comments to comment-out some set of code that you think are not needed. 
  • If you think some block of code is not really needed, just remove them instead of commenting-it-out. 
  • Sometimes you might find, the block of code that may be needed in future but not needed right now. In such instances, you can invalidate the code by placing those unwanted code in the condition like mentioned below.

         if (0) {
         // Some big logic goes here
        // that are not needed in this release for production

  • The above code gets invalidated, that is will not be executed ever as the condition "if (0)" always returns "FALSE", So the block of code inside that condition will not be executed.

3. Naming the function and variables

  • PHP was just procedural at the time of initial Drupal release. So all the coding standard in Drupal follows as such. That means all the function and variables should follow snake  case structure (as of Drupal7), which means variable names should start with small-letter words and underscore should be used to connect the words if the variable is going to contain multiple words. ($snake_case)
  • With the release of Drupal 8, the naming of variables and functions can also be used using camelCase structure, which means variable names should start with small-letter words with uppercase initials for the connective words in case of multi-word variable. (Eg. $camelCase)
  • In either way, we need to follow only one case throughout the file.
  • What we forget is, we mix cases (camelCase and snake_case) sometimes. This should be avoided. Sometimes we define functions without grouping of the function name. In Drupal, all the functions inside a module should be prefixed with the module name, which is called grouping of the function. This helps in avoiding the name conflicts between modules.

4. Uppercase variables

  • According to Drupal coding standard, UPPERCASE variables are considered as constants whether it's PHP constants (TRUE, FALSE, NULL) or Drupal constants (Eg: LANGUAGE_NONE).
  • Sometimes in order to stress the importance of variables, we name the variables in uppercase. This should be avoided.

5. Operator and logical statements

  •  We often forget to leave a space before and after the usage of operator (Eg. if(arg(0)=='node')). According to the Drupal coding standards, all the operators should have single space before and after the operator (Eg. if (arg(0) == 'node')).
  •  Use single space before the start curly braces. The opening curly should be on the same line as the opening statement, guided by single space. The closing curly brace should be on the end of the block and indented to the same level as the opening statement.

6. Line length and Wrapping

  • In general, all lines of code should be no longer than 80 characters. However, there are exceptions to the character limit for the variable and function name that are quite longer when correctly indented.
  • We often wrap the condition of the control statement for readability. Drupal coding standard encourages us to split the multiple conditions and evaluate each complex conditions into a variable and use that in the control statement for better readability.

7. Module placement

As far as Drupal 7 is considered, all the contributed modules should be grouped under the directory called "contrib" in "/sites/all/modules", whereas the custom modules should go inside "/sites/all/modules/custom". In Drupal 8, the same can be followed or utilize the "/module" directory and use the same grouping of the  modules.

8. Writing Javascript

  • Always use Drupal behavior for your custom scripts which runs every time there is change in DOM elements unlike the traditional jQuery.ready which runs only once during the page execution when the DOM elements are ready.

9. Placeholders for translate function t()

  • Use the placeholders for dynamic strings used inside t() function.
  • Generally t() function is used to translate the given strings, sometimes we might use the dynamic strings inside t() function by concatenating the values, which is the not the best practice formulated by Drupal.


  • return t('@username, welcome to my website', array('@username' => $account->name));

10. Module file

  • Use the module file only for Drupal hooks and some commonly used custom functions that you need frequently. 
  • Use .inc file to define menu callbacks and other helper functions that are not needed to be defined in module file.

If we all code to standards, Drupal will be a stronger, more performant, more secure platform. Drupal will continue to grow and strengthen it’s community due to the quality of it’s codebase. Anubavam has been building Drupal sites and providing services such as Drupal 8 upgrade and migration services, Drupal E-commerce development services, and more. Anubavam is participating in Drupal core development since 2006 and has delivered 250+ projects to 100+ happy clients in 22 countries worldwide.

admin Fri, 07/14/2017 - 09:18 Drupal developer Drupal Application Development

Cron, A daemon/background process that runs at periodic intervals of time. It can be run periodically at pre-decided times and intervals. To describe in real time, I have met with a case where i have to fetch the content from a site, where new content might be created everyday and create it on my site. To handle this, i have created a cron job, configured it to run everyday at specific time let’s say at 05.00 AM. So whenever the cron runs, I have written a script to fetch the content that is created on that day and creating on my site. All this is achieved using the cron in Drupal.

Cron is a utility which executes commands at set intervals known as "cron jobs".
According to drupal.org “A "cron job" is a time-triggered action that is usually (and most…

Adding AMP support could be very tricky and complex depending on your project needs. In this blog post I won't be using AMP module. Instead I created something more simple and easier to use for simple AMP integration. The Simple AMP module is still using Lullabot's AMP PHP library. The module is a starter module and most likely won't be very useful out of the box, but it can get you going very fast. It is available for download here https://github.com/chapter-three/simple_amp.

First thing you need to do is to install composer require lullabot/amp, the module won't work without this library.

Once you install the module modify few lines of code in the module:

On 10-11 of June in Kyiv there was an annual all-Ukrainian event - Drupal Camp Kyiv 2017. This is a place where experienced back-end, front-end developers, DevOps and managers share their knowledge. Traditionally Drupal Camp took place in two days: a conference day which includes 5 streams of presentations and code sprint where passionate developers can work together for improving Drupal and developing community. A few interesting statistics about this year’s event: 403 attendees, 5 streams of lectures, 42 speaker, 10+ international speakers, 70+ code sprint participants and 100+ patches made during code sprint.
Read more »

(It's not too late to submit a session—and register for DrupalCamp soon, since early bird pricing ends on August 1!)

The organizers behind DrupalCamp St. Louis 2017 are happy to announce we have a speaker scheduled to present the Keynote, Adam Bergstein—Associate Director of Engineering at CivicActions!

Adam's Keynote is titled "Restoring Our Lost Information", and here's a short summary:

What an honor it was to be selected to present at Drupal Camp Asheville again! This event just gets better and better each year. I want to thank the organizers, volunteers, attendees, and sponsors for making it so awesome!

Below you will find the video for my talk, slide deck, and related git repo for:

"Live Demo: How to Create a Winning Website with Drupal Best Practice".

Git repo: https://github.com/shrop/dcavl2017-livedemo

Blog Category: 

In this two-part series of blog posts, I'm going to show you how we built a Drupal 8 photo gallery site, integrated with Amazon S3, Rekognition, and Lambda to automatically detect faces (allowing us to automatically identify names!) and objects found in our photos.

Tags: acquia drupal planet

In a fast moving industry like ours, it is imperative that we have tools that allow us to build environments (front and back-end), quickly, while providing consistency all across. The same way we have DevOps processes for quickly spinning off a complete Drupal built with composer, drush, Drupal console and more, we need a system that automates the process of creating Drupal themes which include all the essential tools needed for a modern, best practices and standards compliant environment.

If you are a Drupal developer coming new to CiviCRM, it can be a bit of a "culture shock" to realize that CiviCRM is not your typical Drupal module.

CiviCRM has a separate and independent evolution and ecosystem, and its standard practices and APIs reflect that. From installation of the module itself, to creating customizations and modifications of its standard behavior, you are entering into a different "world" when you implement and develop client solutions with CiviCRM.

CiviCRM Entity can help a Drupal developer make the transistion by enabling them to use some of the standard Drupal API features they have grown accustommed to, while still providing insight into the data structures and interconnections of CiviCRM.

For people who spend the majority of their time developing in CiviCRM, it can feel the same way, in reverse. For all-day CiviCRM developers, CiviCRM Entity can be an opportunity to better leverage your Drupal CMS for customizations and new features.  So this introduction to Developing with CiviCRM Entity and the Drupal API is for you too.

How's it work?

The premise behind CiviCRM Entity is really quite simple, though its ramications are profound. What CiviCRM Entity does is automate the process of exposing CiviCRM API entities and actions as Drupal entity types. Basically a Drupal entity type is the standard Drupal data model for a database table.  You map metadata to columns, and this provides one consistent way to store, retrieve, and manipulate database table data for Drupal Core and the entire ecosystem of contributed modules that can go with it. Because CiviCRM does not by itself engage its data with Drupal's Entity API, the majority of Drupal modules are not aware of CiviCRM's data and cannot act on it.

CiviCRM Entity implements all the necessay hooks to define the CiviCRM data as Drupal entity types.  It registers the entity types with hook_entity_info(), sets up the metadata with a hook_entity_property_info_alter() implementation, and extends the default Entity API objects and controllers.  Inside the controller responsible for load, save, and delete, instead of using Drupal's standard PDO SQL query operations, CiviCRM API calls are used.  This makes CiviCRM Entity a "remote entity" module, but specifically designed to work with CiviCRM only. 

This bit alone does the most important thing. It makes Drupal think CiviCRM data is Drupal data.  You can attach Drupal fields, to CiviCRM data.  You can use Drupal's entity_metadata_wrapper. All the rest of the code in the module and its submodules dealing with specific integration enhancements is just gravy.

Using the metadata wrapper, we built up one bit of Drupal Form API code, that woks with all the entities, and provides Drupal standard CRUD forms. Now you got Manage Fields and Manage Display pages for each entity type. Now the Rules module will play nice. Now Drupal developers can build cool custom stuff, using their familar tools.

Entity Field Query

EntityFieldQuery is Drupal 7's standard programmatic way to query the database tables exposed as entities. So let's say we want to find all the Home location type addresses for a particular contact. If there are results there will be an array with key of the entity type name containing objects keyed by id.

$contact_id = 3099; $query = new EntityFieldQuery(); $address_ids = $query->entityCondition('entity_type', 'civicrm_address') ->propertyCondition('contact_id', $contact_id) ->propertyCondition('location_type_id', 1) ->execute(); if (!empty($address_ids['civicrm_address'])) { // do something } Load Drupal Entity objects

Following the example above, we have a query result, and now want to load the entity objects.

if (!empty($address_ids['civicrm_address'])) { // entity_load returns an array of entity objects keyed by id $address_entities = entity_load('civicrm_address', array_keys($address_ids['civicrm_address'])); // maybe you just want the individual entity objects... foreach ($address_ids['civicrm_address'] as $id => $result) { $address_entity = entity_load_single('civicrm_address', $id); // get the city of the address $city = $address_entity->city; } } Saving entities

Now lets make sure our city in our address has every word capitolized, and save the address. The data as you see it in the CiviCRM admin backend will immediately reflect the changes.

$address_entity->city = ucwords($address_entity->city); entity_save('civicrm_address', $address_entity); Deleting Entities

If you want to delete an entity, you can use entity_delete().  Remember that these functions eventually get to the controller, which is a wrapper around CiviCRM API calls.  This matters especially for contacts, because by default deleting contacts sends them to the CiviCRM "trash", instead of completely deleting them.

entity_delete('civicrm_address', $address_entity->id); The Entity Metadata Wrapper 

If you start getting serious about programmatically manipulating entities, you want to start using the Entity Metadata Wrapper. This object encapsulates all these operations in an object oriented way.  It becomes especially useful when you are manipulating multi-lingual fields. It also can use entity level validation based on the entity metadata for each property of the entity type.  I would encourage its use in favor of manipulating the entity object directly, or using the entity_X functions. The code is much more readable and easier to write, and with validation it is much safer. There is a great article about the benefits of the wrapper which goes into detail.

You can pass the entity_metadata_wrapper function the entity object, or simply the id of the entity, and it will lazy load the object. If all you have is the id to start, no need to load the entity object first.

$address_wrapper = entity_metadata_wrapper('civicrm_address', $address_id); $city = $address_wrapper->city->value(); if($address_wrapper->city->validate(ucwords($city))) { $address_wrapper->city = ucwords($city); $address_wrapper->save(); } // get the updated entity object $updated_address_entity = $address_wrapper->value(); // nevermind, lets just delete the entity $address_wrapper->delete(); Custom Rules Action Example

A very practical use case of using the Drupal API for CiviCRM is creating custom Rules conditions or actions. Lets say we want to encapsulate this logic of automatically making the city of an address have uppercase words.  We may want to encapuslate functionality like this and pass it on to our site builders or clients who can use it when they need it. Once you find out how easy it is to create custom Rules actions, you'll have a powerful tool in your toolbox. There's lots of documentation on the web for doing this. 

Lets put this in a little module, I'm calling it civicrm_custom. Create a directory in your sites/all/modules directory named civicrm_custom

To read the rest of the article, and to get the code to build the Rules action, visit the Skvare.com blog.


This is Part 2 of 2 of my Drupal vs Sitecore blog series. In the first part, I've compared the two from the perspectives of content authoring, marketing, and business. In this part, I look at the two platforms from an IT and community perspective. I also need to repeat my disclaimer that I'm a long-time Drupalist, but in this blog post I endeavor to be even-minded and objective.

For those who aren’t familiar with the concept of Pattern-Lab (or a Pattern Library), it’s essentially a living style guide; a common tool in… Read More

Memberships are not all the same. Some memberships last a lifetime, others last a year, or a month. Some memberships are for an individual, others for a couple, others for an entire family.

Some memberships are for a particular time period -- the 2017 season, the 2017/18 school year, Summer -- others are for a particular length of time starting when you purchase it.

Drupal 8Drupal PlanetMembershipCustom DevelopmentCRM

Oh! Hey there, my name is Piyush Jain and as a new staff member at the Drupal Association I wanted to learn what the community likes so much about DrupalCon. 

This week, I spoke with Rachel Lawson (rachel_norfolk), who has been part of the Drupal community for 11 years, and attended 6 DrupalCons.