Support for Complicated Entity Hierarchies and Relationships in Drupal

Client

Abrams Learning Trends

Challenge
In moving their web presence to Drupal, Abrams wanted to redefine their product organization in such a way where product updates were streamlined, and product relationships were dynamically displayed within the site.

Solution
With hundreds of products sold both individually and in bundles, and related to one another through various, often hierarchical categorizations, making sense of the Abrams product catalog was a major piece of this project. Both the client and Pixeldust worked closely together to build a sustainable product structure that met both the client’s organizational and update wishes, and fit neatly into Drupal’s capabilities.

We broke down our problem-solving approach into:  1) Organization, 2) Product Updates, and 3) Product Relationship Display.

1) Organization
We pinpointed the product relationships that mattered to the client as:

  • categorization through normal taxonomy tags.
  • categorization through hierarchical taxonomy tags, where one item may belong to several tags within the same hierarchical taxonomy.
  • parent – child relationships: whether or not the current product is also sold in a larger bundle, and whether or not the current product contains child products that can be purchased separately.
  • related products.

For a while, we bogged down conceptually on the notion that every product fits somewhere in a grand taxonomical hierarchy of groups and products. While this is true from an organizational standpoint, the Drupal taxonomy system isn’t meant to handle many-to-many relationships, and this approach would be replicating product nodes as taxonomy terms, which is unnecessary work!

We eventually settled on a hierarchical taxonomy for the non-salable groups, flat taxonomies for other tags, and entity reference fields for the rest. Related products as entity reference fields was a hard choice, as that would mean the relationships would be manual, but the client desired fine control over the related products.

2) Product Updates
The initial products were populated from a CSV dump of their old product database (a non-Drupal data-driven solution). Also, Abrams preferred to work from CSVs to update their products.

Feeds was the natural solution, but we found that there was not an existing way to import hierarchical taxonomy terms, which was the crux of the client’s organizational structure. Possibly Feeds Tamper PHP might have gotten the job done, but we wanted to steer clear of putting php in the database. We found one sandbox module that purported to import hierarchical terms, but it wasn’t working for us, and didn’t allow for importing multiple hierarchical terms in the same taxonomy. In the end, we had to build a Feeds import plugin to both import hierarchical terms and import multiple hierarchical terms on one item within the same taxonomy. This not only addressed the client’s issue, but did so within the context of Drupal best practices – leveraging and extending existing, stable, contributed modules.

Once the Feeds Import was set up, Abrams could easily update their products through the import UI.

3) Product Relationship Display
Now that we had our Drupal organization configured and populated with tagged products, we needed a way to dynamically display the various product relationships.

The client identified the main organizational component as their hierarchical categorization of Family, Series, and product group type. This hierarchy varied term-by-term, and could vary from year-to-year depending on their current product catalog. What needed to be displayed varied based on term depth and whether or not child terms were present, and everything had to be dynamically determined. Views alone didn’t quite get us where we needed to be.

For the main organization, we set up two views: one to show non-salable child term pages if they existed, and one to show pages for products tagged with the target term if no child terms existed. But we then had to dynamically determine which view to use for each term. We wrote a module with functions to find term depth and the presence of child terms. We created a content type just for the non-salable grouping pages, then created a template for this content type that evaluated term depth and child terms in order to embed the correct view.

The other tags and entity reference fields were also embedded views, but they did not require any fancy logic.

The end result is a display system that can accommodate both a changing product catalog, and a margin of disparity within the driving organizational structure.

Results

Abrams is happy with how their products are handled on the new site. We helped them through a tough ideation on organization, so they can now easily interface with their products using their preferred methods, and their product organization just ‘works’ without any effort on their part.

While client satisfaction is key, producing a good product is also important. Part of the elegance of the Drupal CMS is that both core and contributed functionality can be extended into new territory without loss of stability. Unlike many other CMSs, Drupal is natively built to support extension. When done within Drupal’s standards and best practices, Drupal can gracefully rise to the challenges of customized functionality as it did on Abrams Learning Trends.

Additionally, our work on the hierarchical feeds importer can be used by the Drupal community in the true collaborative spirit of Drupal.