Dec 12 2019
Dec 12

So you heard of React, the JavaScript library developed by Facebook for creating fast and interactive user interfaces, and thought “Wow! It would be awesome if I could use this with Drupal.”

Well, today I will show you exactly how you can add React to any Drupal site, as well as provide you a module with all the boilerplate code required to get you up and running with React as quickly as possible.

Before getting started, we need to understand decoupling. Decoupling is the idea of separating content management from content presentation. In a traditional or coupled Drupal site, Drupal is responsible for both content management and content presentation. I won’t bore you with long drawn out explanations, just know there are two common approaches to decoupling Drupal.


Content Management: Drupal

Content Presentation: Any Front-End Framework (Angular, React, etc.)


Content Management: Drupal

Content Presentation: Drupal + Any Front-End Framework (Angular, React, etc.)

Headless decoupling is perfect for building something like an Android or IOS app because Drupal runs only on the back-end and your entire front-end code can be written in a device’s native language or any front-end javascript framework.

More often than not, you don’t need a full headless implementation, but just one or two highly interactive elements on a few pages of your website. This is Progressive decoupling where React is used as part of what a user sees on the page. In this case, Drupal’s standard theme layer is responsible for outputting the primary user experience, and React is used to enhance it.

Progressively Decoupling Drupal

Before we install the React module and start writing any code, we need to configure Drupal to send data to the React app via an API (application programming interface), we can very easily do this with the Views and RESTful Web Services modules included in Drupal core.

Login to your Drupal site

  1. Navigate to Manage > Extend
  2. Enable the following modules:

  1. Navigate to Manage > Structure > Views
  2. Create a new view as a REST Export and provide an endpoint for your React app to access:

In this example, we’re creating an event list. However, you can use any data from Drupal you’d like (content types, paragraph types, users, taxonomy, etc.).

I like to prefix all my endpoints with “api” to avoid any conflicting path names

  1. In your newly created View under Format > Settings select JSON
  2. Then add and configure all the fields you want to export

To make sure everything is working, navigate back to the homepage of your Drupal site and add your API path to the end of the URL- in my case it is http://mysite.local/api/events. You should see a JSON object containing key/value pairs of your field names and their respective content.

That’s it! Now we can add React.

Install the React Module

Setting up a standalone React app is a quick and easy process using the “create-react-app” script. However, it’s not that simple when using React within a Drupal module. Luckily for you, I have already created a sandbox React/Redux Boilerplate module so you can skip all the setup and get started writing your own React code right away.

To install the module, visit and follow the detailed instructions on the project page to get started. 

Using the React Module

This module works great in any scenario where you want a few highly interactive elements on a few pages on your site, because it’s using the Drupal block system you can place it anywhere on any content type you need. Maybe you’re building an appointment or event scheduler and need a calendar and posts feed that updates in real time, this is a perfect scenario for React.

Further Module Documentation

This session from Texas Camp covers everything you need from Drupal to React/Redux basics, with a more thorough example of this module in action utilizing POST and DELETE requests as well.

If you’re completely new to React and/or Redux, I highly encourage you to read some documentation before getting started.

Whether you’re a Drupal developer with little React knowledge or a React developer with little Drupal knowledge, you can get up and running with this module in a matter of minutes. I recommend you give progressive decoupling a try and spice up the user experience of your next site.

Nov 21 2019
Nov 21

November 21, 2019 - 9:30am


Rebecca Kellogg

Account Management and Drupal An Account Manager Girl in a Web Developer World

A few weeks ago I had the privilege of attending Texas Camp with the web team here at Texas Creative. Texas Camp is a day of curated sessions and panel conversations, and is hosted by volunteers from the regional Drupal community. I know what you’re thinking, why would an Account Manager go to a day-long session about web development? Well, 1. Websites are secretly (probably not-so secret to some of my co-workers) my favorite projects to work on and 2. I personally think that it benefits everyone (both clients and agency employees) to learn as much as possible in the ever-changing digital space.

I went to six sessions throughout the day and learned about topics ranging from crafting the perfect case study, to SEO and content creation, accessibility, and even a little bit about Salesforce integration. For all of my Account Managers and clients out there, here are a few of the things I learned at Texas Camp, and why I think even you should go next year if you have the chance. 

The first session was about writing case studies, which was great because I have to write case studies frequently for new businesses and it wasn’t something I expected to get out of my day at Texas Camp. In this session, we discussed how to frame up your case study in order to clearly sell the business value of your work, as well as the right tone and length to put together a successful case study. I’ve actually been able to use the tips I learned in this session multiple times in the last few weeks and it has made the process of writing case studies much easier. 

One of the other sessions I went to was all about website accessibility, which is a very big topic in the advertising world right now. During this session we walked through tools that can help make the process of building an accessible website easier. While the actual technicals of how these things work was a bit over my head, it was helpful to hear what I, as an Account Manager, should be looking out for throughout  the design and development process on a website, and how we as an agency can help educate our clients on how to improve their site’s accessibility. 

The last session I sat in was all about SEO content strategy. This session walked through the subject of topic clusters, what they are and how they work, and how to reorganize the content on your site into these topic clusters to help boost your site’s SEO. In other words, how to improve your search engine ranking, without paying to play! Who doesn’t want to know how to do that? 

Overall, I really enjoyed my Texas Camp experience and would definitely go back next year. I would encourage anyone who has the opportunity to go to Texas Camp to go, even if you think it’s “not for you”, because you never know what you might learn! Did you go to Texas Camp 2019? If so, feel free to share what you learned in some of your favorite sessions!

Nov 07 2019
Nov 07

Most software projects in the PHP ecosystem, including Drupal, can be installed and managed by using Composer, the PHP dependency manager. 

A dependency manager is a software tool that reads a configuration file for a project. Then it determines all of the underlying software that the project needs in order to work, along with what versions of those applications are compatible with all parts of the project. This sort of work would be difficult to do manually for a project with more than a handful of dependencies.

Why Drupal 8 Needs Composer?

Since adopting this idea of “Proudly Built Elsewhere”, the Drupal project has incorporated many Symfony components and other libraries as dependencies for the project. Doing this allows Drupal to focus more energy on things that make Drupal unique. All of the basic things that all CMS’s do like Routing, Http Requests, and Validation can be handled by Symfony components. Composer simplifies the process of determining what the dependencies are, what version should be used, downloading the dependencies, and placing them in the project where they are expected.


The most obvious “con” of using Composer is needing to learn a new thing.  For developers, this is not so much a “con” because learning new technologies is what we do for a living. But for someone who usually downloads Wordpress and FTPs it into a hosting account, the hurdle of Composer is significant.

Before any of this will work you will need to:

Folder Structure

If you’ve never installed Drupal using drupal-composer/drupal-project, it’s important to know that the folder structure is different. The folder that you create your project within is the project root or repo root (I’m assuming that you will be using version control like Git). This is not your Drupal root (webroot), so any files and folders at this level are not directly addressable with a URL. The exception is the “web” folder which IS the Drupal root. You’ll need to configure your hosting environment to use the ‘web’ folder as the webroot.

  • Composer & Git commands need to be run from the top project folder.
  • Drush, however, may need to be run from within /web.

Additionally, this Drupal-project scaffolding creates two folders (‘contrib’ & ‘custom’) under each of the following folders (web/profiles, web/modules, & web/themes).  

  • Any profiles, modules, or themes installed via Composer will be placed inside the respective ‘contrib’ folders which are ignored by Git version control. These don’t need to be committed to version control because they can be easily attained by Composer anytime you clone the repo (see ‘composer install’ command).
  • Your custom code should be placed inside a ‘custom’ folder which will be included in your repository when you make a commit.

Adding Modules and Other Drupal Dependencies

  1. Run composer require drupal/<module>:<version>
  2. Then enable the module in Drupal or with Drush

Package Versions

  • ~ : will only increase the last part of the version number (after the rightmost ‘.’
  • ^ : increases based on semver (semantic versioning) rules
  • 1.x-dev or dev-1.x : latest dev release for 1.x branch

Instead of setting specific version numbers, I prefer to let my versions update within limits.

  • For Drupal Core, I use the tilde(~) with all three version places (~8.7.0) so Composer will update core automatically but not move to a new minor version without intervention.
  • For Drupal modules, I use the tilde(~) with only two version places (~2.0) so Composer will update with minor releases but not move to a new version of the module that could contain breaking updates like 2.x to 3.x.
  • For non-Drupal packages, I still tend to use tilde(~) but you’ll need to look at the history of the project and see how updates are handled to see where breaking changes are allowed in order to best prevent them without intervention.

Removing Modules and Other Dependencies

  2. To remove the code from the project, run composer remove drupal/<module>Non-drupal use the full package name as it appears in or another packagist that you may have added (see Bonus Tip).

Checking for Packages That Need to Be Updated

This command will output a list of dependencies that you’ve added that aren’t up to date. It won’t display dependencies of dependencies but that’s useful here because we can’t fix those directly.  The package maintainer of the project calling the outdated dependency will need to update their project first. If you want to contribute to those projects then run the command without –direct and then report the issues.

  • Run composer outdated --direct

Performing Updates 

Composer will update the code base, but be sure to run the database updates.  Also, I always run Steps 1-4 in a local or development environment:

  1. To update the code base, run composer update --with-dependencies
  2. To update any database schema, enable ‘Maintenance Mode’ then run
    drush updb OR go to https://<yourDEVsite>/update.php from your Drupal backend
  3. Test
  4. Commit to the repository
  5. Switch to the Live environment and get the latest code from the repo.  This is usually a ‘git pull’ command but may be more complex depending on your environment and DevOps setup.
  6. To get all of the same package updates on the Live site that were added through step #1, run composer install on the Live environment.
  7. To update the database schema on the Live site as in step #2, enable ‘Maintenance Mode’ then rundrush updb on the Live Environment. 

Note: ‘–with-dependencies’ tells Composer to update everything, not just your dependencies, but also the dependencies or dependencies, ad Infinitum.

Note 2: While ‘composer update’ checks for new versions and resolves all the dependencies, ‘composer install’ will only download and deploy the previously resolved dependencies. That’s what the composer.lock file is for.  Composer.lock is created on every update. Many times it will be the only changed file in your git commit.

Memory Issues

Composer can use a lot of memory, so sometimes you need to let it use all the memory.  This can be achieved on a per-command basis like:

  • Run php -d memory_limit=-1 composer update  --with-dependencies

Or permanently in your environment:

  • Create/Edit the /etc/php-cli.ini file
  • Modify the line:
    • memory_limit = -1  

Bonus Tip: Install NPM and Bower Packages With Composer

When a Drupal module needs you to install a library, especially a js or CSS library, you can do it with Composer by setting up Asset Packagist.  My suggestion here is only using this for libraries that are used when rendering a page for your end-user. This is not a good way to install your SASS or JS build system that you may use during development.

Follow the instructions at

Oct 18 2019
Oct 18

This is a beginner’s tutorial that will quickly get you up and running with media entities and a media entity browser in Drupal 8.

One of the best parts of Drupal 8 is the in-core feature of media entities. This allows Drupal to manage resources that otherwise it would not be able to. It accomplishes this by creating a bridge relationship between Drupal’s CMS, media files and external sources. It’s basically an entity referencing all kinds of media files like images, videos, documents or other external sources like Tweets, embed videos, etc.

This tutorial is for the core “media” module set up, not to be confused with the contributed module “media_entity” module. If your Drupal setup already has this module and its sub-modules enabled in your setup, you may want to migrate your setup to the core module “media” following the instructions on the project page at

First Things First, Enable the Media Module:

Enable the media module (NOT entity_media). The “media” module comes with Drupal core so you don’t need to install it. All you have to do is enable it.

Using the Drush command:

drush en media -y

- Or: In the Drupal’s interface, go to /admin/modules, search for media in the search box, check the Media module and install to enable the module.

Configure or Create Media types:

Once the Media module is enabled, it will create the basic media types. You can find these under the structure menu. Media types are entity types just like nodes allowing you to add custom fields and adjust or make new displays to your needs.

To keep things simple in this tutorial, I will concentrate on the “Image” Media type. But you can apply the same principals to any other type. The difference will be on how the sources are being added and display just like node types.

Display the ”name” field (optional) :

It’s my personal preference to always enable the “Name” field in the forms of media types. This way you will be forced to add a name to your media type that you can later use for searching in the media browser.
(For even more searching options, you can add taxonomy tag field to group resources and so on. But for this example, let’s keep it simple.)

For this example navigate to /admin/structure/media/manage/image/form-display

Now drag into the content area “Name” field and drag to hide or disable all other fields with the exception of the “Image” field, so all you have displayed on the form is the image and name field. This will come in handy when creating the media browser view in the next step.

Installing the Entity Browser Modules and Creating Media Browsers:

The media browser is what you will use to pick and add new images to the content where the media entity reference field is being used. It basically adds a widget for your field. The media entities can also be managed via the content page in the “Media” tab.

Install these Modules: Chaos Tools, Entity Browser:

composer require drupal/ctools
composer require drupal/entity_browser
composer require drupal/inline_entity_form

Then enable Chaos Tools, Entity Browser, and Entity Browser IEF.

drush en ctools, entity_browser, inline_entity_form, entity_browser_entity_form

- Or: In the Drupal’s interface, go to /admin/modules  Ctools, Entity Browser, and Entity Browser IEF (you may have to enable the entity browser first).

Create a View to Use in the Media Browser.

We create this view first, in order to use it in the media browser we will create later, to list the available images in the media browser.

1. Go to /admin/structure/views/add:

  • Name your new view “Image Media Entity Browser Listing” 
  • View Settings: Show: Media of type: Image sorted by: Newest first
  • Click on Save and Edit

2. Now Configure the view:

  • Top left under “Displays” click on the “+Add” button and select “Entity browser”
  • FORMAT: pick Table
  • Add FIELDS:
    • Name
    • Thumbnail - options:
      • Label: Thumbnail
      • Formatter: Image
      • Image Style: Thumbnail
    • Entity browser bulk select form - options:
      • Label: Select
  • Rearrange the fields in this order: Entity Select, Thumbnail, Name
    • Name (media) - options:
      • Check the “Expose this filer to visitors”
      • Label: Search by name
      • Operator: Contains
  • Save the view.

Create the Entity Browser for Image media:

Got to /admin/config/content/entity_browser and click on the “+Add Entity Browser” button.

  • General Setting tab:
    • Label: Image Media Entity Browser
  • Widget Settings tab:
    • Add widget plugin:
      • View - options:
        • Label: Image Library
        • Submit button text: Select
        • View, view display: Media Browser: Image Media Entity Browser Listing
      • Entity Form - options:
        • Label: Image Upload
        • Submit button text: Upload
        • Entity type: Media
        • Bundle: Image
        • Form mode: Default

Create a Media Entity Reference Field to Use the Image Media Browser

Congrats! So you already set up the media entities and the media browser. Now all you have to do is start using it on your content builds.

Now, whenever you’re creating content, you will have a field that opens the media browser on a modal window with options to search, select, and upload new images.

That’s it! - Now all you have to do is repeat the process, configure things to your preferences and soon you will be a pro on media entities. Next, I’ll add a few other recommendations if you want to improve upon your setup.

Recommended modules that can add more power to your entity setups:

  • embed
  • video_embed_field
  • entity_embed
  • dropzonejs

Migrating Existing File Fields:

If you are working on an existing Drupal 8 setup and you want to migrate old file fields to a media entity field, follow this tutorial for instructions: Basic Migration Of File Fields To Media Entities.

Happy coding!

Oct 18 2019
Oct 18

The Migrate File to Media module provides an easy way to migrate old file fields like images, files, videos, etc, into the media entities with a few drush commands.

So you can have an understanding of how the migration process works, In this tutorial, we will run through a few quick step-by-step instructions on how to migrate specific image field types to image entity reference fields.

Media Module

The core media module is what creates the “media” entity types. If you haven’t set this up yet, or if you are not too familiar with media entity setup, I highly recommend following this tutorial “Drupal 8 Basic Media And Media Browser Setup For Beginners”, before you continue with this tutorial. 

If you still want to continue with a basic setup of media entities, simply enable/install the core media module that already comes with Drupal 8 core (NOT the media_entity module). Upon installation, it will automatically create a few media entity bundles for you, including the image media bundle we will be using for this tutorial.

Migrate File to Media module

Now for the migration, install the “Migrate File to Media module” - ( Only compatible with Drush 9 and up )

composer require drupal/migrate_file_to_media

Enable the “migrate_file_to_media” module:

drush en migrate_file_to_media

It will warn you that it will enable the following (“migrate”,”migrate_drupal”, “migate_plus” and “migrate_tools”) if they’re not enabled yet.

Once we have all of this in place, we can start using some simple commands to do the work for us. However, first, we need to create some mapping so that the migration module knows from what source fields to what destination fields.


We can’t migrate a source without a road map and destination. In the example of this tutorial, we will be performing a migration of the field “field_image” (image field type), in the content bundle “article” (node entity type) into a new media entity reference field that we will be creating using drush commands.

When migrating a site with a vast amount of content, I recommend to become familiar with the site’s content structure, the document where all the images are located, and in what content type bundles.

Generate the destination media field in the article node types using drush:

drush migrate:file-media-fields node article image image

Command bisection:

drush migrate:file-media-fields [entity_type] [bundle] [source_field_type] [destination_media_bundle]

  • [entity_type]: (The parent entity type) In the case of our example, it is a node content type. But other bundle types, like paragraphs or taxonomies for example, can be used.
  • [bundle]: (The parent bundle type) In this example, the “article”
  • [source_field_type]: (The source field type) This will be the source field type. Not to be confused with the name of the field, but the type of field. When running the command, this will check for all the fields of type “image” as in this tutorial.
  • [destination_media_bundle]: (The destination field media bundle) This will be the destination field bundle type. This will create a media entity reference field of type “images” for every image field found on the parent node bundle type. It will also give it the same name with the suffix of “_media” as in this tutorial.


Ok, so we created the destination. Now let’s create the roadmap so that the migration knows where and how to migrate data from the old to new by generating some YML files.

Before generating the YML files, we need to generate/create a custom module where the new files will reside: (Just generate the module, don’t enable it yet.)

Basic module drupal generate command, run on web-root:

drupal generate:module
# Note: follow the instructions on the screen and give it the machine name “basic_migration_example”

- Or: Module generate command with all options for this tutorial, run on your web-root:

drupal generate:module --module="Basic Migration Example 101" --machine-name="basic_migration_example" --module-path="modules/custom" --description="Basic Migration Tutorial 101" --core="8.x" --package="Custom" --features-bundle=”no” --test=”yes” --dependencies=”no” --twigtemplate=”no” --composer --module-file

Once the module is generated, clear the cache:

drush cr

Now we are ready to start generating the YML files, run:

drush generate yml-migrate_file_to_media_migration_media

You will get something like this. For this tutorial please follow the instructions as follows:

Welcome to yml-migrate_file_to_media_migration_media generator!


 Module machine name:
 ➤ basic_migration_example

 Module name:
 ➤ Basic Migration Example 101

 Plugin label [Example]:
 ➤ article_media_basic_migration

 Plugin ID [example]:
 ➤ article_media_basic_migration

 Migration Group [media]:
 ➤ ( Press Enter Button to use suggested "media" )

 Entity Type [node]:
 ➤ ( Press Enter Button to use suggested "node")

 Source Bundle:
 ➤ article

 Source Field Names (comma separated) [field_image]:
 ➤ ( Press Enter Button to use suggested "field_image" )

 Target Media Type [image]:
 ➤ ( Press Enter Button to use suggested "image" )

 Target Field [field_media_image]:
 ➤ ( Press Enter Button to use suggested "field_media_image" )
# Be sure to use the name of the field inside the Media Entity for the Target Field, and not the name of the media field on the node. 
 Language Code [en]:
 ➤ ( Press Enter Button to use suggested "en" )

 Translation languages (comma separated) [none]:
 ➤ ( Press Enter Button "none" )

The new files will be created in your new module folder /config/install.

There will be two YML files generated per migration ID, these file names will be suffixed with _step1 and _step2. You can open these files and adjust them as needed, but for this tutorial, the configuration we gave it on the YML generation process is just what we need.

If you want to look at YML examples, you will find some under the migrate_file_to_media module folder: modules/contrib/migrate_file_to_media/migrate_file_to_media_example/

Once you install/enable the new module we just created for this migration, all the YML configurations will be loaded to your Drupal 8 database setup.

Editing Migration Configurations after installation:

Once loaded into the system, if you need to make modifications, you need to get familiarized with the configuration management interface and how it all works to make changes. Here is a good read on that:

Install a New Module and YML files:

Ok, so now that the YML files are created, let’s enable/install the new module, and the new YML configuration files will be added to the system as well.

Enable new custom module:

drush en basic_migration_example

And now, check the migration status by running: (This will also give you the generated migration ids)

drush migrate:status

You will get a result of something like this:

Group Migration ID Status Total Imported Unprs media article-media-basic-migration_step1 Idle 3 0 3 media article-media-basic-migration_step2 Idle 3 0 3            

Duplicate File Detection (!)

– This is an important step, DO NOT SKIP – In order to run migrations, first you need to run a file duplication check for all migrations.

drush migrate:duplicate-file-detection [migration-id]

For our tutorial, run file duplication checks run “_step1” of the migration. You will have to do this for every first instance of your migrations one by one as I have not been able to figure out another way to make this command just run through all in one command.

For this tutorial, run:

drush migrate:duplicate-file-detection article_media_basic_migration_step1

Check for existing medias (optional)

If you already have images or files loaded in the medias entities run this command to check for media duplicates:

drush migrate:duplicate-media-detection image --all
# Run: drush migrate:duplicate-media-detection -help for extra options 

Migration time:

Now, if all is set up correctly, we can run a migration:

Migrate all migration of media group by group id:

drush migrate:import --group=media 

- Or: Run single migration by ids:

drush migrate:import article_media_basic_migration_step1 
drush migrate:import article_media_basic_migration_step2 

If it all goes well, you should see that the imported will match the total and unprocessed will be 0. Run:

drush migrate:status

Results should look like this:

Group Migration ID Status Total Imported Unprs media article-media-basic-migration_step1 Idle 3 3 0 media article-media-basic-migration_step2 Idle 3 3 0            

Take a look at the content of your article. You will now see that the new fields have been populated with the right image media entity reference. Just adjust your displays to show the new media field and hide or remove them altogether with the old image field when all your migration is complete.

A few more drush migration commands that may come useful:

  • drush migrate –help
  • drush migrate:rollback
  • drush migrate:stop
  • drush migrate:reset-status
  • drush migrate:import  [_OPTIONS_] :
    • –feedback - Frequency of progress messages, in seconds or items processed ( great for debugging)
    • –update - In addition to processing unimported items from the source, update previously-imported items with new data
    • –group - Name of the migration group to run
    • –idlist - A comma-delimited list of ids to import or rollback. If unspecified, migrate imports all pending items or rolls back all items for the content set.
    • –limit - Limit on the length of each migration process, expressed in seconds or number of items
    • –rollback - Rollback specified migration(s) if applicable
    • –stop - Stop specified migration(s) if applicable
    • Less commonly used options:
      • –file_function - Override file function to use when migrating images
      • –force - Force an operation to run, even if all dependencies are not satisfied
      • –needs-update - Reimport up to 10K records where needs_update=1. This option is only needed when your Drupal DB is on a different DB server from your source data. Otherwise, these records get migrated with just migrate-import.
      • –instrument - Capture performance information (timer, memory, or all)

Further information on Drush Migrate Tools commands visit:

Happy coding!

Sep 12 2019
Sep 12

The profession of building websites has seen many changes in the last few years. SEO, website performance, multi-screen responsiveness, and accessibility are no longer luxuries. On top of that, tools have emerged that have improved the development experience and simplified scalability. Finding a modern CMS or framework that can incorporate ALL of these considerations is difficult. Especially when the flexibility to be able to create unique websites is also important. This is where Drupal 8 outshines other frameworks.

Here is a list of major benefits that you are missing out on if your website is built in Drupal 7 (or below), WordPress, or most other common content management systems.

1. Website Accessibility, Security, and Scalability  

Accessibility - One of the major changes in web development these days is the standard of building sites that are easily accessible by all visitors no matter their abilities or disabilities. For some clients, this is no longer a luxury but a regulation. For others, there is no law, but they can be opening themselves up to discrimination lawsuits by not making an effort to build a site that is accessible. A well-implemented Drupal 8 site can automate many aspects of accessibility and facilitate best practices in maintaining the accessibility of the site. Compliance will also help your website gain points with major search engines.

Security - One reason that major companies and government agencies move to Drupal is because of its fast security updates, and the large community of experienced developers who stand behind it. Drupal 8’s adoption of standard technologies, such as Composer, makes it a lot easier to keep your site up to date and secure. This also means less time fixing the code and more time improving and adding new features.

Scalability - In the past whenever there was a new major release of Drupal, version 6 to 7, it wasn’t just an update. It really meant a full install of the new version of the Drupal core, then maliciously and painfully rebuilding and migrating custom code, configurations, users, and all of the content from the old site to the new site. In other words, hundreds of hours of rebuilding and months before the new site was ready. After Drupal 8, that will no longer be a problem. Drupal 8 was built to allow major updates without having to rebuild the site. Three to five years down the road, all you may need is a fresh facelift to have your website up to date with new trends. So taking the time to architect a well built Drupal 8 site will pay off in the long run.

2. Drupal 8 as API first

Drupal 8 was created as an API (Application Programming Interface), making it more powerful than ever. It now has the ability to skip the generation of all the HTML markup and simply serving the data required to be implemented on the front end of the website, allowing other technologies like javascript to serve dynamically generated pages specifically targeted to the user.

Best of all, it can be used to connect back and forth with other APIs to get any information you want to serve and share as a service. All of this is already built into Drupal 8 to serve any data without having to write one single line of code.

If you haven’t wrapped your mind around what this means yet. Let me give you a couple of examples of this: “Web Apps” & “Mobile apps”. These can be developed to use the same data living in Drupal 8. Your Drupal site becomes the backbone content management system without having to update multiple sources of data to keep things in sync. Think about it… your website, your mobile apps, your own intranet, and content from other places all managed in one place, making one perfect ecosystem.

3. Development  

Drupal 8 was completely recoded from scratch with all new improved code.  Many things that were a constant hassle in the older versions are now a breeze to build.

Migration of old to new: If you have a website with large amounts of content, for example, news, products, or blogs, setting up an automated migrating of all the data into Drupal 8 is possible from almost any source. Yes, that even means if your old website was built in WordPress.

One of my favorite development improvements for sure is Configuration Management. Now you are able to export and import configuration changes from a live site to your local development, or vice versa, without affecting content. That feature alone has cut hundreds of hours from my development workflow. This not only helps reduce the cost of overall development but it gives developers time to concentrate on getting the features built and not wasting time deploying already built features manually.

The implementation of Composer as the dependency manager to install and maintain modules, custom code, and patches, makes it super easy to create copies of your website in a development environment and automatically turn on all the development helper features by just having a few files on hand that are environment-aware. With a few simple commands to sync code and configurations, you are ready to develop and deploy in no time.

After a couple of years of developing in Drupal 8, I wonder how I was able to do without all the new development features for so long.

Drupal 8 is a dream-machine for large or small websites. All of these features make it quick to build a simple website and powerful enough to build the largest, most complex websites.  Drupal’s flexible and innovative system is only limited by your imagination.

Happy coding!

Jul 11 2019
Jul 11

Existing Values Autocomplete WidgetProviding the content creator a field with a list of values to choose from is a common requirement when building a Drupal site. It’s also something that can be achieved in a variety of ways, each having pros and cons to the approach. Texas Creative’s web team has developed a module that we believe fills a missing gap in this type of field called Existing Values Autocomplete Widget.

In the following analysis, we will discuss each possible approach, the use case for it, along with an example. The final approach includes using our new module. 

1. Taxonomy Term Field

The approach with the most flexibility and functionality, but also the most overhead and potentially unwanted “features”, is to create a new Taxonomy Vocabulary and use a Taxonomy Term Field to allow the content creator to choose from the list. The user can create/manage terms easily. However, each term will have its own “page” that displays every node that uses that term. If you don’t want that, it can be dealt with using the rabbit hole module among others, but it will have to be dealt with on some level. There is also some overhead added to the system in terms of additional code and additional database calls/joins for this extra layer of functionality.

Criteria:  If your use-case can leverage the “relationship” of the taxonomy term and the display pages that are created, then this is the best choice.

Example: Company Departments: They may change in the future and you may have an interest in associating many content types to the departments in order to aggregate them on a single landing page for that department.

2. Text Field (List) with Allowed Values

A simpler approach, with some serious limitations, is to provide a simple text field (list) and populate the ‘allowed values’ with all possible values needed. The advantage here is the simplicity of setup, assuming you have a small well-defined list. In most cases, the content creator will not be given permission to add/change allowed values, so the developer will need to facilitate any future changes to this field. Additionally, it becomes difficult to “remove” options since there are values assigned to them already so Drupal will not allow those deletions. 

Criteria: If the list of values is small and unlikely to be changed, and you are not interested in the “relationship” aspect of taxonomies, then this is a good option.

Example: Outcome Status like (Sold, Returned, In Inventory, Backorder): This is a small, rarely changing list so the additional hassle of managing the list is not a concern and we would not be interested in the “relationship” to this value. You would only be likely to display this status or have it as a filter option on a list of nodes both of which are possible with the text field.

3. Text Field with Existing Values Autocomplete Widget

At Texas Creative, we often find ourselves in the middle of these two approaches. We want a simple field without all of the taxonomy overhead and complexity, but the list of values is not known or finite, so the client needs to be able to add new ones easily. The Existing Values Autocomplete Widget was born to fill this gap by providing a way to pull any value previously entered in the text field as an option on the fly. This module creates a new field widget for text fields with autocomplete suggestions using previously entered values.

Drupal 8 Render API allows for an autocomplete callback to be registered on a render array’s element. Then the Render API handles all the AJAX. The module provides a controller, as the autocomplete callback, responsible for returning the autocomplete suggestions to the field widget.

Criteria: If the values are unknown or unlimited, and you’d like to reduce most of the duplication of similar values, then this approach finds a happy medium.

Example: Park Amenities: The values of this field could vary widely across the parks but it would be helpful to use the same wording for similar amenities such as Playground, Paddling Trails, Disc Golf, etc.

Instructions for Using the Existing Values Autocomplete Widget

  1. Install & enable module per usual process.
  2. Visit any content type ‘Manage Form Display’ page.
  3. Change “Textfield” widget to “Autocomplete: existing values”.
  4. Configure how many suggestions to show in the widget configuration. (default: 15)
  5. Enter values in the field and they will become suggestions next time.

Advice that is often given in the Drupal community is that you should get involved by “scratching your own itch”, meaning solve the problems and use cases that bother you.  An important part of that is to then share your solutions. It is inevitable that someone else has the same “itch” and may not even realize it until they see your solution. The Existing Values Autocomplete Widget is the most recent example of this for the Texas Creative web team.  We like solving problems from the simple to the complex. We also like knowing when our solutions helped someone else. Please comment below if you find this post or module useful, and join us in the issue queue with any bugs or feature requests. You can also see our team’s Drupal contributions on our organization page.

For more Drupal knowledge from the Texas Creative web team check out our other blog posts on web development topics.

Jun 06 2019
Jun 06

Sometimes when working with Drupal’s exposed forms, you might get stuck with a field type that you don’t want. Often times you can find a module to help improve the style or functionality of these forms. However, in some cases using a module will not be available and you will have to make modifications directly to the code.

If you are just getting started with Drupal, and come from a JavaScript background, this will clearly be the easiest method for you. If you are familiar with PHP and want to better understand Drupal, I encourage you to try a form_alter function!

JavaScript Method (jQuery):

For the JavaScript we’ll start with a simple select field with three options (my favorite web technologies). I like to use jQuery because it’s a bit easier to read and write than Vanilla JavaScript. A quick overview, we’ll target the select field, loop through the options, and map them each to their own <a> tags in separate divs. This allows for each link to be styled individually, auto submit the form, append URL parameters, and more.

First, we’ll start with a Select Field inside of a Form Element each with a respective ID.

Now that we’re on the same page, let’s get started initializing Drupal behaviors and jQuery. In your theme folder, you’ll need a .js file for this code to live. I called mine script.js. You can read more about Drupal behaviors here.

(function(Drupal, $) {
  Drupal.behaviors.HOOK = {
    attach: function(context, settings) {
})(Drupal, jQuery);

// First lets get the form by ID so we have a place to append our newly created links
  $("#TheForm").append(() => {
    // Next we will hide the original select field
    // and create a new container div for our links to live in
    const customLinks = $('<div id="CustomLinks"></div>');

// Here we target the options on the select field
    const selectOptions = $(this).find("#SelectField option");
    // Now we can loop through each option and get the properties we want
    // IMPORTANT: Use the function declaration to scope the "this" keyword, not an arrow function
    selectOptions.each(function() {
      // Initialize variables for the properties we want on our new links
      let optionText = $(this).text();
      et optionVal = $(this).val();
      // Create each link with assigned properties and append to our newly created container div
      let customLink = $(
        `<div class="${optionVal}"><a href="#${optionVal}">${optionText}</a></div>`
    // And last but not least return our variable
    return customLinks;

That’s it! You’ve now mastered jQuery, and can begin styling. A real use case of this method is on a site of ours that is currently in development where we have a Location “Content Type” using the List(Text) field to determine the location’s type and are outputting the locations in a view. These links append the option’s value to the URL query and submit the form on click.

Using a Form_Alter Function (PHP)

Using a Drupal form_alter function in your THEME.theme file might be a little more straight forward, but in this case we’ll turn a number input field into a select field with custom build options. This will allow us to go from a non-user-friendly keyboard input to a nice, clickable option set.

Drupal has many preprocess and form_alter functions for you to use depending on your specific use case. You can learn more here. For this case, I am again outputting the form in a view, exposed to the user, so I will use “THEME_form_views_exposed_form_alter”

You’ll first need to create the optionset, which can be done through a simple function that returns an associative array, replacing THEME with the name of your theme.

function THEME_build_distance_options() {
  return [
    '5' => '5 miles',
    '10' => '10 miles',
    '15' => '15 miles',
    '20' => '20 miles',
    '25' => '25 miles',
    '50' => '50 miles',

With our optionset ready to go, let’s modify the input field. Within your form_alter function, you might want to start by logging or printing your form so you can track down exactly where your element’s type value is. To do so, simply uncomment the first line in the function.

function THEME_form_views_exposed_form_alter(&$form, $form_state, $form_id) {
  // Turn distance text input to Dropdown selector
  $form['distance']['value']['#type'] = 'select';
  $form['distance']['value']['#multiple'] = FALSE;
  $form['distance']['value']['#empty_option'] = t('Distance');
  // Call your build options function and assign it to the new select element
  $form['distance']['value']['#options'] = txc_base_build_distance_options();
  // And use unset to remove fields not needed for our new element type

Hopefully now you understand the power of using jQuery and/or Drupal form_alter functions to modify any element to your exact needs, and continue building awesome websites! To see more helpful tutorials on using Drupal visit some more of our blogs here.

Mar 28 2019
Mar 28

There are a lot of migration articles online that explain how to edit YAML configurations and custom migration plugins, so I am skipping over that.

You should be familiar with the full migration concepts first.  But before you start the migration process, you will need to clean up a few things from the old D7 site as well as prepare the new D8 site to make it able to take the old data including installing new modules for specific field types. That is what this article is about.

By cleaning up data before and after migration things will go more smoothly, minimizing the need to write complicated YAML or PHP scripts.

IMPORTANT NOTE: Do not work directly from the live D7 site. It’s best to backup and export your D7 database to a new database first. This way you will be able to clean up the database content with a few SQL commands.

Now for the workarounds… including some helper SQL commands I use when doing a Drupal 7 to Drupal 8 migration.

1. The annoying “value cannot be NULL errors” in body_value on import.

This can happen in any field, but for this example, I will use the “body_value” column in the “body__value” table. For the sake of this example, this field is required by the default body field in D8.

In the old D7 database, “body_value” sometimes may be NULL. The simple fix, if you can get away with it, is specifying a default value. Maybe it can be a special string that you can go back after the migration and search with a simple SQL query to find all the missing values so that you can replace with actual content.

Option 2 is to copy content that can be used from another field or column.

In my latest migration, the “body_value” column was NULL in a large number of records, but I did have a value I could use in the “body_summary” column in every single record.

The quick easy fix is to run this query in the D7 database. In my case, it fixed 400+ records not only making the import smooth, but also correcting the storage of the content.

UPDATE field_data_body SET body_value = body_summary WHERE body_value='' AND bundle='>>REPLACE WITH YOUR BUNDLE TYPE<<';

If you just want to set the value to some default value, you can.

UPDATE field_data_body SET body_value = '>>REPLACE WITH SOME DEFAULT VALUE<<' WHERE body_value='' AND bundle='>>REPLACE WITH YOUR BUNDLE TYPE<<';

Here is another useful one if the D7 site was in English only. It will set all the records to have en(English) as default language instead of und(undefined).

UPDATE field_data_body SET `language`='en' WHERE `language`='und'

2. Importing Redirects issues to the new site.

In my experience, Redirects import without much of problem and do not make adjustments to the YAML file. However, I did notice that the Redirects status came in wrong. Redirects status code cannot be “0” or NULL in Drupal 8 so you have to default it to 301 (moved permanently) or any other acceptable HTML redirect code you prefer. Again you can edit the YAML or, for easy quick clean up, just run this code:

Run this on the D7 database before import:

UPDATE redirect SET status_code=301 WHERE status_code=0;
UPDATE redirect SET status_code=301 WHERE status_code IS NULL;

Or, run this on the D8 database after import:

UPDATE redirect SET status_code=301 WHERE status_code IS NULL;

3. Importing URL Aliases from Drupal 7 to Drupal 8 is easy.

Ok, this requires a little more work than just running a SQL command, but I promise it will save you a lot of headaches as opposed to doing the Drupal migration because the aliases may create all kinds of problems.

I found that the easiest way is to simply export the “url_alias” table from the old site and import it replacing the new Drupal 8 database “url_alias” table. The replacement of the aliases in the new D8 site is to be done as a final stage of migration. Once you have completed the full migration of your content, nodes, entities, taxonomies, configurations, etc., you have tested that all the content has migrated successfully and you are ready to wrap it all up. Then follow these steps:

First, if you are using “Pathauto”, make sure you have the module installed and the URL alias patterns to match those from the D7. Pathauto configuration is at: /admin/config/search/path/patterns

Delete the D8 database “url_alias” table so that you can replace it with the new table and run this command in the D8 database: (You may want to back up this table before deleting all of the URL aliases)

DROP TABLE url_alias;

Export the table “url_alias” from the D7 database and import into the new D8 database using your preferred database management application.

Fix the URLs so that it works with D8 and run this SQL commands on the D8 database:

UPDATE url_alias SET url_alias.source = concat("/",url_alias.source);
UPDATE url_alias SET url_alias.alias = concat("/",url_alias.alias);

Now let’s change the name of the “language” column to “lancode” in the D8 database:

ALTER TABLE url_alias CHANGE language langcode varchar(12);

Now, if you are using Pathauto, let’s auto regenerate any missing aliases: Check all the types of aliases to regenerate all. And make sure that the “Generate a URL alias for un-aliased paths only” is checked so that it doesn’t overwrite all the aliases we just imported, and let it run. (You may notice that it may only create a few, if any. That’s okay because if we did the job right, all the alias should already be created) /admin/config/search/path/update_bulk

Check and test that all your aliases are working.

In conclusion, if you take the time to clean up your data before the migration, things will be a lot easier. Also, if later you need to pull an updated database from the old site, saving all your SQL commands and tracking your process, you will be able to clean up a fresh database in no time for re-import.

Dec 13 2018
Dec 13

There are great opportunities with local, state and federal government contracting. That’s why we made a strategic decision over 10 years ago to build a government public affairs and marketing area of our company’s service offerings. It wasn’t easy, it was a long process, but it worked. Here’s how we did it and what it has meant to the growth of Texas Creative.

Get Your Certifications:

Our first stop was the South Central Texas Regional Certification Agency (SCTRCA), where we received our Small Business Enterprise (SBE) Certification and our Women-owned Business Enterprise (WBE) Certification. Most local entities, and certainly the State of Texas, regard this regional certification as gold. These are renewed every two years and audits can be part of the equation, only to ensure that the company is being run as indicated in the applications.  Other certifications are available through the agency, so check all that apply to you.

Texas HUB (Texas Historically Underutilized Business) Certification is the statewide database of woman-owned, minority-owned, small-business, veteran-owned businesses that are available for state agencies and prime contractor HUB subcontracting. In our category of business, most state and local agencies target 26% of their spending with HUB companies. This certification can really lift your visibility with buyers and give your proposals a stronger appeal.

Get on the Schedule:

We tried getting on the Federal GSA (General Services Administration) Schedule by ourselves, but the paperwork and technical language barrier were too much to handle, so we hired a federal contracting specialist company to help us complete the process and get on the schedule. It took us nearly two years to complete that process, but we succeeded in getting onto the 541-5 schedule which is the Integrated Marketing Services defined within The Professional Services Schedule (PSS) Advertising & Integrated Marketing Solutions (AIMS) Schedules. Our GSA has led us to engagements with the Maine Air National Guard, The Peace Corps, Army Medical Department, and the US Air Force.

Once you are on the federal schedule you can apply to be on the comparable state schedule called Texas Multiple-Award Schedule (TXMAS) through the Texas Comptroller’s Office. The TXMAS contract follows the same offerings of your GSA Contract. This process took us another year so plan on playing the long game if you want to play in this marketplace. Our work with Texas Commission on Environmental Quality (TCEQ) for public affairs campaigns for Take Care of Texas and Galveston Back the Bay, website design, website development and hosting have been very rewarding work for ourselves and the taxpayers of Texas. We have helped food insecure families in Texas find information about the Summer Food Program offered by the Texas Department of Agriculture, and we’ve helped Texas Department of Transportation (Two Steps, One Sticker) change the behavior of millions when it comes to state inspection of their vehicles.  

Our most recent accomplishment has been 5 years in the making and we were just awarded a Comprehensive Web Development and Management Services contract through the Texas Department of Information Resources Agency (Texas DIR). All state agencies are required by law to procure web development projects through the DIR. Optionally, universities and local school districts, local governmental agencies may use the DIR contracting tools. We are able to offer our full-service, in-house web development and hosting services throughout the state. This is big news for our small company. Our previous TXMAS work for TCEQ, the Governor’s Office and the University of Texas can know fall into the DIR seamlessly.

These sales range from small task-oriented projects for Texas Department of Public Safety (DPS) and Employees Retirement System of Texas (ERS) to media planning and buying for Texas Tech University and upwards of multi-million dollar contracts with other state agencies to assist them in getting the word out about their amazing programs. It’s work we love and it’s work that makes the lives of Texans better. Can we help your agency successfully raise awareness and engagement for your programs?

For more information on our contracts please visit:

Texas Creative GSA Contract

Texas Creative TXMAS Contract

Texas Creative DIR Contract 

Check out a couple of our recent projects for our government clients. 

[embedded content]
[embedded content]

May 24 2018
May 24

SVGs are ideal for the web due to their low file sizes and crisp appearance, making them perfect for icons, logos, and illustrations. However, working with them is often more complicated than typical file formats like JPG, PNG or GIF. Out of the box, Drupal’s default image and file fields don’t support the use of SVGs. Here are 3 Drupal modules to help you quickly and easily get SVGs into your content types. 

1. SVG Image (TXC Recommended)

The SVG Image module makes things easy by equipping the core Image Field with the ability to accept SVG files. This can be easily configured by adding the .SVG file extension to the list of allowed types in your image field configuration settings. This module is great since you don’t have to add a new field to use SVGs on your site. The SVG Image module currently has 2,440 users and over 32k downloads.

Download this module.

2. SVG Image Field

The SVG Image Field module adds a completely new “SVG Image” field, widget, and formatter. After installing and enabling this module, all you need to do is add the “SVG Image” field to your content type instead of an image or file field. The SVG Image Field currently has 1,060 users and around 14k downloads.

Download this module.

3. SVG Formatter

SVG Formatter makes use of the core File Field (contrasted with the SVG Image module which uses the core Image Field), allowing it to accept SVG files. Once installed, you can select the “SVG formatter” under “Format” in your Manage display settings on any fieldable content type. Much like the SVG Image module, the user will need to add the SVG file type extension in the field configuration settings. The SVG Formatter currently has 1,245 users and over 7k downloads.

Download this module.

Additional Features All 3 Modules Share

  • Ability to select width and height of the image in formatter settings
  • Ability to render SVG image as <img> or <svg> tags.

With any of these modules, it’s recommended that the pixel dimensions of your SVG are set within the SVG itself, as the height and width attributes offered by these modules apply to the field as a whole (which may not be desired in all use cases). Otherwise, styling with CSS will definitely be necessary.

The Future of SVG Support in Drupal

Ideally, SVG support should be integrated into core. In fact, at the time of writing, we discovered there is currently an open core issue that’s working towards allowing image fields to use any file extension supported by the currently used image toolkit. This could even mean support for using PDFs in image fields. The foundation of this functionality was added to core 8.5, but in our testing, it wasn’t yet working in any usable form—so one of the above modules is still required.

For information on creating a better SVG check out this article here:

Exporting A Better SVG

Apr 26 2018
Apr 26

Recently, we were helping a client get their Drupal 8 website set up for hosting on the Pantheon platform. They would eventually take over updates of both core and contrib modules for the site.

While gathering resources to help them with the process, we found that, although Pantheon had documentation for Drupal core and contrib updates via Composer and/or Git, it didn’t have the process outlined for updated contrib modules via the Drupal administration GUI.

The solution was to write our own guide for this process. Afterwards, I felt others could use this same outline to assist with their own workflow, hence this blog post.

This guide describes the process for performing updates on contrib modules for a Drupal site hosted on the Pantheon platform. While this guide details the process for Drupal 8, the same workflow can be applied to Drupal 7 or WordPress sites.

Preparing the Site for Updates

Once you have navigated to your project’s Dev page, ensure the Development Mode is switched to SFTP, not Git. 

SFTP mode enables the website’s code to be altered in an online dev environment, as opposed to Git mode where you must pull the repository to your local environment to alter any code.

Once the Development Mode has successfully changed, navigate to the Development Site.

Updating Modules via Admin GUI

In your development site, go to the Extend tab (located in the administration navigation menu) and go to the Update page. 
(You can also navigate to the Extend page to view all currently installed modules)

Once there, you can select the modules you’d like to update.   It is important to check the recommended version number against the already-installed number.

General rule-of-thumb is if a module’s recommended release minor version number is incremented by 1 from your installed version, it will be safe to update it. If the minor version number is any more than one, or if the major version has changed, it’s good practice to check the release notes on (a link is provided next to the Recommended Version number, as shown in Figure 4). 

Figure 4 – Drupal 8’s Update page.

Once you’ve selected the modules you’d like to update, click the ‘Download these updates’ button and let Drupal do the rest. After they have updated successfully, you’ll be shown the following message.

Some modules will require an update to their database table(s). Review these updates, apply, and then run them.

Once the database updates are complete, you’ll be shown a log of any messages, warnings, or errors.  

You can now go back to the main site and test a few pages to ensure nothing has changed.


Assuming there were no issues in the update process, you can exit the development site and go back to the project dashboard on Platform. In the Dev tab, you’ll notice your code changes ready to commit to Git. You can add a commit message, then switch the Dev site from SFTP back to Git mode, which will stage your commit to push to the Test environment.


In the Test tab, you’ll see a highlighted section detailing what commits are ready to be tested against the live site.  All the checkboxes should be selected, and you can add a Deploy Log Message if you’d like.

Pantheon will perform the options selected, and you’ll then be able to test the updated code against the live database and files by clicking the Visit Test Site button. 


After checking for issues on the Test site, you can navigate back to Pantheon and to the Live tab. The process here is the same for deploying from Dev to Test.

Check a few pages one last time on the Live site to ensure there are no problems.

Mar 29 2018
Mar 29

Creating a frosted glass effect using CSS is a better method than the old javascript hacks. Using CSS to create the frosted effect uses fewer resources from the site visitors computer by using the native browser rendering engine.

To test this just drag the frosted glass example in the top right of this page. 

Ok, without wasting much of your time I’m going to jump straight into it.

The main components used for a classic frosted glass effect are:

  • > The original content
  •  - - > The frosted glass container ( Exp. <div> )
  •  - - - - > Original content copy inside the glass container (the element that mimics the content on the page with a blur effect).

For a basic idea of how this works. Here is a simple example:

HTML structure:

 <div id="frosted-glass-mask" >
  <div id="body-content-clone" ></div>

The CSS:

 width: 100vw;
 height: 900px;
 background-image: url( background-image.jpg);
 background-repeat: no-repeat;
 background-attachment: fixed;

 width: 500px;
 height: 500px;
 overflow: hidden;
 position: absolute;
 border: #ffffff63 solid 2px;
 left: 40px;
 top: 40px;
 box-shadow: 6px 7px 5px #00000075;

 left: -40px;
 top: -40px;
 width: 1000px;
 height: 1000px;
 background-image: url( background-image.jpg);
 background-repeat: no-repeat;   
 background-attachment: fixed;
 filter: blur(10px);

In this example, I’m setting the background-attachment as fixed, so the backgrounds for the body and the #body-content-clone element align to the top of the window. This way, we won’t have to worry about aligning the clone element with the original, and won’t have to use complicated CSS alignments or javascript to align the elements.

Test the sample code

In order to create the frosted effect, we are basically mimicking the original content with the #body-content-clone, aligning it, and sizing it on top of the original content.

Once we have the content lined up with the content clone, we can apply the blur filter effect on the #body-content-clone{ filter: blur(5px) } .

Lastly; “#frosted-glass-mask”, the parent div of the cloned content, acts as the glass element masking the content inside it.

For added detail you can use the psesudo “:after” and/or “:before” to add inside shadows, highlights and whatever else you want to style the content to your liking.

As always, it’s up to you to get creative.

Try it and let me know how you liked this quick tutorial blog, and if you end up using it in your project, please share a link in the comments to see your work.

Happy coding!

Nov 09 2017
Nov 09

Recently we needed to build a knowledge base for a SaaS client to house support content in both text and video format. Since a lot of this type of content has a progression to it (first do this, then this) it made sense to dust off the Book Module.

The Book Module

The Book module has been in Drupal core since 2001, so it’s pretty much always been there. It provides a hierarchy to pages in Drupal that allow a next/previous functionality that is useful when you have content with an order to it. Additionally, the Book module comes with a table of contents block that outlines the hierarchy of the book for easy navigation.

The core table of contents block is fine for a basic outline, but in our case, we had some customization to this table of contents that necessitated a custom solution. We wanted to show a video icon next to any page that had a video on it. We also wanted to remove the topmost page of the book from the hierarchy. Lastly, we wanted to retain the functionality to display which page the user is on using an “active” class. After searching for a module that provided the customization we needed and coming up short, we realized that we could get Views to help us build this block without any custom code needed.

Custom Table of Contents Block

The Views Tree module provided the basic hierarchical structure. It only has a dev version for Drupal 8, but we haven’t run into any issues so far with it. The module displays the view results in a hierarchy once you set up hidden fields in the view for the node id of the page and it’s parent (setup documentation).

Video Icon

The video icon will be added via a css class. To accomplish this we added the video field we had defined on our content type to the view as a hidden field. Then we chose to rewrite the results of the field and just output the text ‘video’ when there was a value present in the field.  Next, under the “No Results Behavior” section of the view we check the boxes for “Hide if empty” and “Hide rewriting if empty”. Lastly, we added the token for the video field to one of the elements under “Style Settings” on the Title field (which is the only field we are allowing views to display). In our case, we made the wrapper HTML element a span and added the class for the video field there.

Hide Topmost Book Page

Add a contextual filter to the view for book depth and set it to “not equal to” 1. The topmost page in a book has a depth of 1 so this will not display that page on any book. Originally, we were just excluding the node id for the top page since we only have one book, but decided to change the filter to book depth so that it will work for any book on the site.

Add ‘Active’ Class

This is similar to the video class, but requires a little snippet of a twig conditional statement and a contextual filter to make it work. First add a contextual filter to your view called “Global: Null”.  The Global: Null filter allows you to get some information from the URL without actually impacting the query that Views is making. In this case “Provide default value” on the contextual filter should equal “Content ID from URL”

Next add an additional hidden (Exclude from display) Content: ID field to the view. Under the “Rewrite Results” section, check “Override the output of this field with custom text”. In the text box add a twig conditional that compares this nid value to the Global:Null (arguments.null) you just setup and returns a string for the ‘active’ class if they match. Here is what ours looks like:

{{ (nid == arguments.null) ? 'active' : '' }}

It’s important to make sure you are comparing the right nids because you should have 3 nid fields on this view right now: 1 for the page’s nid, 1 for the parents nid, and this one we are working on now. The first two were created during the Views Tree module setup instructions.
Now add the token for this hidden nid field to the same place we added the video class (see screenshot in Video Icon section above).


This View accomplished our needs for the table of contents, and can easily be added to if we ever need a New or Updated flag. The flexibility gained is worth the effort and we didn’t have to edit TWIG templates, write custom preprocess hook, or write a custom module.

TLDR; See the View’s yaml file and screenshot below. You will need to replace the field names and content types with your own.

Read our other Drupal-related blog posts.

Oct 12 2017
Oct 12

An Account Manager writing a blog on something web related… it sounds scary, I know. But technically, I speak client, and I also really enjoy the web/digital side of my job. So, what I want to translate into non-technical speak for you is why your Content Management System (CMS in agency lingo) choice matters.

There are so many CMS options to choose from today, WordPress, Joomla, Typo3, ExpressionEngine, Drupal…. I can keep going… but not all CMS are created equal. In the process of building or rebuilding your website, the design is important, but it’s the CMS that’s going to either make your life easy or cause you to scream and pull your hair out.

As you may know from some of our previous blogs, Drupal is our CMS of choice here at Texas Creative. The question I get asked the most when meeting with clients about a new website is, “What is Drupal going to do for me that something like *insert CMS of choice here* can’t?” Good question. Here are 4 things I have found to be true when it comes to using Drupal as your Content Management System.

1. It’s going to be easy for you and your team to update.

Working at an agency, sometimes we forget that not everyone is as comfortable as we are with technology. A lot of clients think that they need coding experience to make content updates or swap out an image on their website, but Drupal makes it easy for even the most tech-challenged of people to make updates without any coding knowledge.

The backend of Drupal is organized by content types and contains text fields/image upload fields for each content type, which makes it extremely simple to update. So while you may have a page with over 100 different pieces of information listed, editing one of those pieces is one click away and as simple as filling out a form.

2. It’s going to be easy for me to update.

I know what you’re saying at this point, “I don’t have the time nor do I want to make updates myself.” That’s OK, not all of our clients want to do it either. The great thing about Drupal is that it is easy for your Account Manager to make content, image and other minor updates for you. That means if you call with an edit, I can easily complete it without having to send it back to the web team, which makes for a shorter turnaround time. But if I can’t solve the problem for you, I can easily walk to the other side of the office and ask someone who can.

3. It can do anything.

You name it; we’ve probably built a site for it in Drupal. From selling high-end luggage products to cattle, Drupal has the flexibility to accommodate all of your website needs. But no matter how complex your site is, our team builds the CMS with the end user in mind, which allows our clients to make updates without the fear of breaking their site.

Here are some links to a few of the projects Drupal has helped us build:

Take Care of Texas

The University of Texas at Austin

The San Antonio Medical Foundation

4.     It’s open source.

I’m slipping into technical speak here (don’t leave, come back), but basically all this means is that Drupal is one big group project. Because Drupal has no license fees, there are thousands of Drupal developers working to build new and better technology all the time. This matters to you as a client because your site is not only portable (aka you’re not handcuffed to one agency) but it is constantly being worked on, which leads to improvements and helps increase your site’s security.  

So, to sum all of this up for you (I told you I’d make this simple), it may seem like an intimidating subject but YOUR CMS IS REALLY IMPORTANT. Whether you go with Drupal or not, you should feel comfortable working in the backend of your site. Your website should be working hard for your brand, you should not be working hard to maintain your website.

Aug 24 2017
Aug 24

I started in web development about a year ago. When I was hired on at Texas Creative in early October of 2016, I still only knew the bare minimum, but I was eager to learn more to further my career path.  Here at Texas Creative, we use Drupal, a content management system (CMS) I had no prior experience in. The idea of that seemed daunting, but I was eager to learn, and with the mentorship of my team in the past few months, I’ve certainly learned a lot and have grown to love Drupal.

At first, when I was told Drupal was a CMS, my mind instantly thought of Wordpress. I hadn’t played with Wordpress much either, but being the world’s most popular CMS, I had heard many stories from other developers, many of those were complaints about its lack of flexibility.  However, once I started the planning and development of my first site at Texas Creative, I quickly learned that was not the case with Drupal.

Drupal acts more like a build-your-own CMS rather than an out of the box framework like Wordpress. Of course, you can easily add a premade theme, such as Omega and Adaptive, and with the core and wide selection of contrib modules, you can have a basic site. However, Drupal allows you to edit the root files directly, which is perfect for an agency that wants to produce fully custom designs and functionality for their clients. This gives Drupal a much steeper learning curve, so my experience in core web development languages and the mentorship from my teammates were essential.

At Texas Creative, we have a base site which is essentially a clean slate with no real theme and only modules we deemed necessary for every site. During planning, we figure out which modules need to be installed and enabled to fit the client’s needs. We then add content and begin the theming process with a design at hand. Sometimes, the DOM generated by the content or paragraph types isn’t the best for theming the content to match the said design. A simple solution for this is using the Field Group module to help organize your DOM as you’d like.  Unfortunately, this doesn’t work for every situation, and when it doesn’t, you’ll need to utilize Drupal’s templating engine: Twig.

Twig works similarly to how you would build a basic HTML structure, but Twig, in conjunction with the Drupal preprocess functions, allows you to sort through the PHP objects to get the values you need and build your HTML exactly how you want it for the section you want to alter.  This can be a bit hard to tackle at first but after some practice in traversing through Drupal’s PHP objects, you get the hang of exactly where to look. This works well when wanting to add extra elements to attach some Javascript functionality to in order to make the user experience of the website top notch, an example being the tab functionality on the homepage of Kaliff’s website.

One of my favorite things about Drupal is the fact that it is completely open sourced. This means you can not only create your own contrib modules for others to install and use but if you find a way to improve the core code, you can easily open an issue on and help the community by fixing and improving this code. With Drupal being one of the most widely-used content management systems out there, issues get resolved and better functionality is added regularly by the community.

Coming from only developing sites with a bare-bones PHP framework, Drupal has really impressed me in the few months that I’ve been developing with it. While frameworks such as Laravel can be great, it can be a hassle when you have to either edit the template files directly to make changes, or create your own pseudo-CMS to change content on your pages. Drupal provides you with many different ways to edit content right out of the box, without having to deal with that much code. For an agency that wants content entry to be simple for clients and tailored to their needs and level of expertise, Drupal makes the most sense. Even in personal projects, I’ll still continue to use Drupal for its power right out of the box. Providing such a great back-end leaves a developer such as myself to focus on developing better functionality and theming beautiful pages.

Feel free to leave a comment with any insights or similar experiences you have had and check out some other Drupal related blogs by Texas Creative:

First Impressions During a Drupal 8 Website Build

Block Exclude Pages Module (Drupal 8)

3 Tips for Client Friendly Paragraphs in Drupal 8

Jul 27 2017
Jul 27

The improved blocks system in Drupal 8 provides a lot of flexibility to the site builder.  But, have you ever had the problem of blocks showing on undesired pages because of the limits to visibility patterns?

The Problem Scenario

Say you added a custom block that only shows for users, so you set a visibility path with a wildcard like so: “/user/*”. All works great, as it should, and life is great!

Oh but no! Don’t celebrate too fast says your project manager. Here comes the problem. Your project manager, now (despite that it all works like it should) for no reason whatsoever, wants to hide that neat custom block from an specific page under “user/*”path.

Ok, all hell breaks loose. How do you prevent that specific page from showing the block when you have already set to show on all pages under the “/user*”path? Sure, in Drupal 7 you had the option of adding some custom PHP code to accomplish that. But what about Drupal 8, where you are not allowed to use any PHP code in the interface?

At Texas Creative, we work for the most part on large scale websites with data connection from multiple sources such as API’s and interactive pages. The block excluding problem was a common issue that we kept stumbling across. Each developer was coming up with creative ways to work around it, but that made it hard to maintain as each site is different and some solutions were just too “hacky”. It was time to create a module, called Block Exclude Pages, that would solve this issue using the standard Drupal block visibility interface.

How to Exclude Pages From Block Visibility

When installed in your Drupal website, the Block Exclude Pages module adds a new pattern for page visibility that will exclude a path pattern. Simply prefix the path pattern with an ‘!’.

When the page visibility option is set to: “Show for the listed pages”, then the excluded paths, prefixed with “!” will hide the block on those pages despite the other matches. On the other hand, if the page visibility option is set to “Hide for the listed pages” the excluded paths, prefixed with “!”, will show the block on those pages despite other matches in the list.

In the following example, this block is placed on a user page, but the block is excluded from the ‘jc’ user page and all subpages for that user page:


This module has become an important tool in our arsenal for complex websites. I hope it will become a good tool for you too. 

Happy Coding! ;)

Below are some other Drupal related blogs by Texas Creative:

3 Tips For Client Friendly Paragraphs In Drupal 8

Update Extended Module: Drupal Updates…No Regressions!

Common Drupal 7 Coding Mistakes

Jun 15 2017
Jun 15

We, the website development team at Texas Creative, are big fans of the Paragraphs Module. For the last couple of years, it has become a larger and larger part of our Drupal 7 and Drupal 8 websites. In this post, I will give three tips we’ve discovered that make Paragraphs even easier for the end-user to use, in our case clients.

What is the Paragraphs Module?

To quote the Paragraph module description page: “Instead of putting all their content in one WYSIWYG body field including images and videos, end-users can now choose on-the-fly between predefined Paragraph Types independent from one another.”
In short, it helps Drupal do structured, repeatable content even better than before. The end-user doesn’t need any technical HTML skills. The web designer can design specific sections/layouts of content and give tremendous flexibility to the end-user to edit, create, or reorder without compromising the design integrity. If you aren’t using this module in your Drupal 8 builds, you are really missing out.

Tip 1: Add Publishing options to an Individual Paragraph

Who knew you could add the “Published” checkbox to each paragraph in the Manage Form Display for the Paragraph Type by just dragging the “published” field out of the Disabled section and then setting its widget to ‘Single On/Off Checkbox’? After this is set up, the paragraph is only displayed when the box is checked. This is useful for content like slides on a rotator block which may need to be taken out of rotation for a time and then reinstated. This feature has been in Paragraphs for a long time but isn’t completely obvious.


Tip 2:  Rename Your Paragraphs Field Titles

Most of our clients aren’t familiar with Drupalisms, so the term “Paragraphs” can be a bit confusing on a content edit form. It doesn’t explain what exactly is being added. The Paragraphs module maintainers luckily anticipated this and provided a way to customize the user-facing language.

On the parent entity’s Manage Form Display tab, where you setup your Paragraphs reference field, you can customize the singular and plural for the Title of the field. This changes the interface wherever the word “Paragraphs” would normally appear and is customizable on each Paragraph field.  

We often add Paragraph types that are interchangeable, full-width areas below the main page content. The word “Panel” just fits what they are so we change the title to “Panel”. To an experienced Drupal developer “Panels” is a very different thing, but to our clients “Panels” are those flexible, repeatable, full-width areas they can add to the bottoms of their pages. It makes much more sense to them than “Paragraphs”.


Tip 3: Add Contextual Links to Paragraphs

As more Paragraphs are added to a piece of content, it quickly becomes difficult to edit due to the size and complexity. A simple solution to this is to install the Paragraphs Edit module on your site. This module adds contextual links to individual paragraphs to edit, delete and clone. Now the end-user can hover the paragraph on the frontend of the site and see options to edit a single paragraph without needing to edit the entire page worth of paragraphs. Note: The 2.x-dev version has more compatibility with complex paragraphs and advanced features, but requires Drupal 8.3 or higher.


Importance of User Experience with Paragraphs

For us and our clients, any criticisms of Drupal’s out-of-the-box experience become irrelevant since we don’t leave it that way. The work has to be put into the client experience just like it is the site visitor experience. The accumulation of these kinds of small wins in user experience add up to a happy client. So, customize your customers’ Paragraphs experience.

Recent Projects:

San Antonio Bioscience Research

Take Care of Texas

Feb 02 2017
Feb 02

February 2, 2017 - 3:49pm


Marcus Harrison

Drupal and Web Development The Future is Encrypted

Google is leading the charge to a more secure web. The tech giant is taking steps in the way it handles non-secure websites in both search rankings and for its over 1 billion Google Chrome users. In search results, non-secure websites will now take a back seat to those that are secured with trusted SSL certificates. Texas Creative has answered the call by retroactively adding free SSL encryption to all of our Drupal websites.

What is SSL?

SSL (Secure Sockets Layer) is a web technology that creates an encrypted connection between the server and the browser to secure the data while in transit. Sites equipped with SSL signify this with a lock icon in the address bar. Until recently, you’ve likely only encountered this on your bank’s website or any site that is collecting personal information like credit card numbers.

Why SSL Now?

The likelihood of your non-secure data falling into the wrongs hands today is much higher than it was 5 years ago. For this reason, industry leaders like Google, Facebook and Cisco are aligning to make encryption the norm instead of the exception.

Starting with Chrome 56, Google has taken things a step further by changing the way the address bar appears on non-secure sites with password or credit card entry fields. In the near future they will expand this to include all non-secure sites effectively shaming them with a warning triangle indicator coupled with the words “Not secure” in red.

The good news is encrypting sites with SSL has never been easier or more affordable. Let’s Encrypt is a certificate authority providing free SSL while eliminating the complex installation procedures for domain-validated certificates. Let’s Encrypt was formed by the Internet Security Research Group (ISRG), a non-profit with an impressive list of sponsors.

Doing Our Part

Texas Creative now includes SSL encryption on all Drupal sites, hosted on our servers, free of charge. We’ve even gone back and set up SSL on every hosted Drupal site built in the last 5 years, free of charge. This added service is a tremendous benefit for our clients in terms of SEO and data security. Texas Creative remains at the forefront of the crusade towards a more secure web experience for all.

May 20 2016
May 20

It’s Official!  We have finished setting up the necessary infrastructure and processes for building client sites in Drupal 8 moving forward.  A lot of that work was done during our first Drupal 8 website build, which is nearing completion.  What follows is a brief glance of my first impressions and future aspirations about Drupal 8 development.

The Project

As website builds worked their way through the pipeline in the first part of 2016, I was on the lookout for the right one to be our first D8 site.  The project I chose is a portal for this company’s contractors to log their daily activity out in the field.  The portal also generates various reports from the activity for our client to use.  This project is unique in a couple of different ways that makes it the clear choice for our first foray into Drupal 8:

  1. Since it is a portal, it required very minimal design and the site functionality could reasonably be built BEFORE the design.
  2. One of the client stakeholders has a personal connection to a Drupal developer, which made them open to using D8 even if 100% of their desired features aren’t currently available.  They were the ones who initially brought up the subject of using Drupal 8. (Most of our clients do not come to us looking for Drupal, they are just looking for a website.  So the decision about CMS technology is usually an internal one.)

I should also say here that I cannot provide links or show any screenshots since the site is a login-only portal.

First Impressions

Drupal 8 is a thing of beauty!  Granted it takes some time to wrap your mind around some parts.  And there are a lot of, “this isn’t the way Drupal 7 does it,” thoughts that go through your head.  But once those “first date” jitters are out of the way…WOW!

What is the right way to install D8?

Composer - Dependency Manager for PHPThis is the first difference with Drupal 8 that jumps right out.  And the answer is not really clear.  After a lot of soul-searching (aka research: The definitive introduction to D8 and Composer, Composer Manager for Drupal 8, Goodbye Drush Make, Hello Composer) I determined that the approach that best fit our DevOps process and automation tools is the “sugar-free composer” route mentioned in Bojan’s article.  Even though Composer is a bit slow in installing new things, the flexibility to automate nearly all of the site setup, build, maintenance and deployment will pay huge dividends for us.

TIP: If you are building one site in D8 which doesn’t need DevOps automation, don’t bother with Composer, just download the zip or tarball and move on down the road.  You can always plug Composer back in later if needed.

Where is _______, that I use in Drupal 7?

The other main first impression I had is that there are a number of small, but sometimes critical, pieces missing in D8.  The gaps are being filled in rapid fashion, but some still exist.  For example, the Date field is missing an end Date and repeating dates at the time of this writing.  There are also some “critical” contributed modules that are still in alpha.  We are forced to use them and hope that nothing breaks whenever they go to beta or full release.  [Insert standard appeal to jump in the issue queues and help out.]  I found a number of patches to Drupal core issues which fix various bugs so some of this just needs testing and/or prodding of maintainers to commit them.  In nearly all cases I was able to work around, patch or do without these things.  But it was certainly helpful to have a client who was so understanding of the hurdles.  And none of these things would prevent me from starting a new project with D8 right now.

Installing patches when using either of the composer-based installation methods is super simple and easy to maintain.

Future Aspirations

With so many new parts to Drupal 8, we’ve only scratched the surface of what’s possible.  And with the new six-month release cycle, we can now expect improvements to come more regularly.  The future is bright!  

At Texas Creative, we love automation and Drupal 8 will become a snowball of automation that will build upon itself long into the future.  The advantage of this to our clients is that our time can be spent on planning, content strategy, and achieving higher levels of refinement in the site.  It eliminates the need to re-assemble all of the same components we do on every site before reaching the point in the process where true customization begins.

In time, those missing pieces from D8 will be built by us or you.  But in the meantime, there are few compelling reasons why you wouldn’t want to jump into the D8 waters.  Excluding e-commerce projects, Texas Creative will build sites going forward using Drupal 8.

Apr 13 2016
Apr 13

Whether you are new to Drupal or a total Drupal superstar with 1,000,000 hours on the metaphorical “Drupal wheel”, making decisions about what modules to update to what version is not as straight-forward as it sounds. We’ve found many situations where the Drupal update page actually suggests that you “upgrade” a module to an older version. This has resulted in regressions and extra work more times than we’d care to admit. But it is clearly a problem begging for a good solution.

Our first solution to the problem was extensive training about the various situations you run across and what to do, but when updates are performed only once a month it’s hard for even the most experienced Drupal developer to remember every nuance of the “rules.” Enter… the Update Extended module. It brings into code all of those “rules” and provides more information and options to help you make good decisions about what modules to update to what version.

TL;DR The Update Extended module does super cool stuff and will make your update decisions easier! (Trust me, you will thank me later.) Let’s dive into its impressive benefits.

To give you an idea, here are a few scenarios where this module will prove extremely helpful to your website(s):

The Update Extended module will give you the option to update to the newer “-dev” version and will default to that newest version, “-dev” or full, if the currently installed module is “-dev”.NO MORE mistakenly regressing to an older version of a module — creating chaos in the universe!

Suppose you need a module on your site that has a bug somewhere that is only fixed in the “-dev” version so you install that release and now it all works perfectly. But a week later, it comes time to do updates and there is a new “-dev” release but not a new full recommended release.

Problem: The update page, out-of-the-box will show an update to the “recommended version” (Full Release), even though it is an older version. And you may end up reverting the module to the older version that still has the bug. You have to remember to compare the dates of the two versions.

Solution: The Update Extended module will not only give you the option to update to the newer “-dev” version, it will default to that newest version, “-dev” or full, if the currently installed module is “-dev”. This prevents the regression. Catastrophe averted!

NO MORE spending hours sweating and slaving away with updates on multiple websites!

Problem: When updating multiple sites the biggest problem is deciding if updating a module will regress it to an older version if you have one or many -dev versions installed. That means you have to diligently check sites one by one, again and again — Uff! I’m sweating just thinking about it!

Solution: You guessed it … Update Extended … you’re so smart! Since the module intelligently selects the correct version to update to, it’s easy just to do a  “select all” at the top and run the update. It will cut your time by a significant amount so that you can update your status on Facebook. Oh! I mean do some wicked development work.

NO MORE playing a guessing game — Oh Lawd, am I doing the right thing here???!

Besides adding extra modules and automatically selecting the latest one to download, I continued to further enhance the update by listening to feedback. I added visual elements that will make it easier to select the module option you want to make changes to. For now, it displays the date and time the module was created (if it is a major release), links to release notes, and tells you if the module is an older version than the one already installed.

Do you want more? Well, we think there is even more potential for this module, like Drush integration, so you are not dependent on configuration pages to get these benefits. If you have other ideas, please stop by the issue queue and leave a suggestion. Web development is constantly evolving and I just can’t wait to sink my teeth into the next challenge, or into a yummy breakfast taco. Either would make my day!

Once again, UPDATE EXTENDED — Download Here

Happy Coding!

Mar 01 2016
Mar 01

This series will cover three Drupal 7 mistakes that I see regularly when training developers, or perusing the issue queues of Drupal modules, and I’ve personally made each of these mistakes.  Getting a handle on these concepts, and breaking these bad habits will make you a better Drupal developer.

Using [‘und’]? You’re Doing It Wrong

Whether it’s in your theme’s template.php file or the custom field formatter module you wrote, don’t use [‘und’] … ever … seriously … don’t do it. The term ‘und’ simply stands for ‘undefined’. The place [‘und’] holds in an entity object is representative of the language of the content you are traversing. You may be thinking, “but it works”. The only reason [‘und’] works is because your site is not multi-lingual, so every piece of content is set to language undefined. But the moment you move that code to a site with a language setup, it will break.

If you look at my custom modules from four to five years ago you’d think I was a complete hypocrite for taking such a hard stand, but I’ve seen the light, and it is good. I don’t believe there is a good reason to leave [‘und’] in production code. But, if you find yourself facing down an [‘und’] what can you do? There are two ways of dealing with this situation.

1. Set a $language variable

In the entity object you are working with replace [‘und’] with a $language variable. Then your code will be able to adjust to the site language. This is still not ideal since you aren’t using proper entity objects, but in some cases, such as in a theme template.php file, it can get the job done simply. Especially if you know the field will always have data, and the site will only ever have one language.

For example, when I use dpm($node); to see a node object there will be arrays for each custom field. Let’s assume there is an author field called ‘field_blog_author’. I may be tempted to access the content like this in a template file:

$author = $node->field_blog_author[‘und’][0][‘value’];

However, if you look around on the $node object you’ll notice that $node→language is likely set to ‘und’. If I use the following code instead, everything will still continue to work in the event the language on the node is changed:

$language = $node->language;
$author = $node->field_blog_author[$language][0][‘value’];

While this solution is better than using [‘und’] it can still become problematic if the targeted field has multiple values or no value at all. So this approach should be reserved for rare situations.

2. Use entity_metadata_wrapper()

To properly deal with entity objects such as nodes, fields, taxonomy terms, users, etc. you should rely on the Entity API module, which is likely already enabled on your site.

The Entity module provides a unified way to traverse any entity object allowing for languages, multiple values, raw (unescaped) content, and many other common scenarios. All you need to do is run your entity object through the entity_metadata_wrapper() function.

$node_wrapper = entity_metadata_wrapper(‘node’, $node);

The first parameter is the type of entity you are working with. The second parameter is the object to wrap. This can be the $node object as in our example or simply the node ID if that’s all we have at this point. The entity wrapper declares methods that allow us to get at the value without needing to care about what language, how many, or even if there are any values at all. We can even chain into our author field since it’s also an entity, and get it’s value without any additional processes.

To get the author in our example we would write this:

$node_wrapper = entity_metadata_wrapper(‘node’, $node);
$author = $node_wrapper->field_blog_author->value();

This is simple for another developer (or a future you) to read and it is easier to maintain when requirements change.

For a deeper dive into the entity_metadata_wrapper() I recommend the following articles:

And to learn more about Drupal Commerce entity_metadata_wrapper() specifics read this guide:

Up Next:  The next common mistake that we will tackle involves using ‘context’ in Drupal Behaviors. Check back in a few weeks.

Jan 15 2016
Jan 15

#Celebr8D8 with @texascreative developers @To_Be_Benji & @jvative.

— Art Williams (@ArtisWilliams) November 20, 2015

Inevitably, if you are a Drupal-based agency, and have been around for awhile, with the trumpeted release of Drupal 8, you will get some variation of the following questions:

Client: “You tell me my site is on Drupal 7, and that you keep it up to date, but I see that Drupal 8 is out … what!? And why do I need to rebuild a ‘new’ site to get on Drupal 8?”

You: “Good question Mr. Client! I’m so glad you asked!”

Let’s start with a very brief history of the magic that is Drupal 7 (hereafter referred to lovingly as D7). D7 was originally released in 2011. At the time it was released, it was immediately an incredible and powerful tool to build wonderful websites with. D7 solidly established its place as a website powerhouse, and a robust alternative to the likes of WordPress, Joomla, and others. However, we in the industry can attest to you that web technologies and standards, both on the front and back-end, have drastically evolved since that time. D7 does indeed receive a steady stream of updates, however these are security patches and ‘bug’ fixes, and not functionality upgrades.

In fact, in referencing this very thing, and on the release of Drupal 8 (D8) the great Larry Garfield makes the following point:

“I’m happy that all of the changes we’ve made have enabled Drupal to switch to a more traditional, predictable, stable release schedule. Drupal has never really had feature releases before; we’ve had bug fixes, and API-breaking majors, but our architecture has never really supported non-breaking improvements before, at least not on a large scale. Now it can, and we’re now shifting our development culture to support it, too. That makes an investment in Drupal 8, and in helping to develop Drupal 8 itself, much more valuable than ever before.”

Times, they are a-changin have drastically changed!

The platform we are working with in D7 is almost 5 years old! In terms of technology, that’s ancient! You wouldn’t expect the original iPhone to do all of the things your shiny new iPhone 6S can do, would you? Of course not! That said, D7 is still entirely relevant, and we will support your site like crazy Mr. Client! But, we will always be limited by the core technologies and underlying code used when D7 was released.

Drupal 8 is an evolution of the platform and has been coded using modern, cutting-edge web technologies. D8 is architected in such a way as to have landed squarely in the ‘now’, with a clear pathway and vision for the future (of the platform, and web development) in ways that are not possible on the previous versions of Drupal. It will be faster and more flexible than D7 can ever be.

So what you’re saying is … ?

Drupal 8 ensures that a site will be built using industry standard web languages, providing the modern web browsing experience you and your visitors expect. Building your ‘new’ site on D8 means that your website/application can grow with you in ways never possible before. You can rest assured that your site will be ready for the future, and as the industry and technology changes, you won’t be left behind.

And that Mr. Client, is why Drupal 8 is the way forward!

Apr 18 2014
Apr 18

Sometime back in the mid to late 2000s when most web developers/designers began seeing the writing on the wall when it came to content management systems, most of us bit the bullet and also decided try one out. After all, our clients were pushing for it and it’s what all the cool kids were doing, so we begrudgingly fit it into our workflow.

Open-source CMS’s drew the most attention, especially the ‘big three’ — Joomla, WordPress and Drupal.

Naturally, I was curious about each so I evaluated all three, which usually involved installing one and then attempting to figure out how to make it look a specific way by the end of an afternoon. I’m a visual designer and was working on my own in those days, so if I couldn’t quickly and easily get things to look the way I wanted, it wouldn’t work for me.

I’ll freely admit that I’m an avid reader of and that Chris Coyier has a definite affinity for WordPress. Although I’d like to say I made my decision on which CMS to use based on my own trial and error, the truth is that I needed to get up and running quickly, so Chris’ teaching style hooked me. Drupal and Joomla quickly fell by the wayside and I’d made my choice.

Now fast forward seven years. After using WordPress for almost every purpose under the sun, and for the most part enjoying it, I started working at Texas Creative, which is notoriously Drupal focused. I knew this upon coming in and was excited to see what Drupal was capable of. Entering the Drupal world with a WordPress perspective taught me three things that were very surprising.

No Loop

In WordPress, we live and die by the loop, but Drupal functions differently. As a matter of fact, what surprised me most in the first six months of working in Drupal was that I hadn’t written a single line of PHP and precious little HTML. Granted, we have very talented Drupal developers on staff at Texas Creative and I’m primarily a UI designer. Still, after working as a WordPress themer for seven years, I was used to opening up page.php to hack out loop variables and opening the CSS to style what I’d written. So imagine my surprise when I realized how Drupal was so different in these aspects, specifically: 

  1. Drupal manages primarily through the admin UI, so are you adding a chunk of random content (block) to a sidebar? No PHP needed.
  2. Want to sort all your products and expose filters to your user? No PHP needed.
  3. Need to create dozens of image styles for your users to upload in different areas of the site? No PHP needed.

No more functions.php.

The beauty of this approach, in my opinion, is that the admin UI allows the client (who’s managing content) to make multiple changes to their site without needing to understand the code that powers the CMS. Which is what a CMS is suppose to do, right?

Now, you’ll get VERY familiar with the Drupal ‘views’ module, which will at times have you wishing you could just hack it out in PHP, but in reality, this non-reliance on straight PHP speaks to the maturity inherent to the Drupal experience. It’s much less “fly by the seat of your pants” in many ways, which can be both good and bad.

Incredible Drupal Images Styles

WordPress developers are familiar with thumbnails, medium and small image styles, and the ability to create custom styles. But what if you could upload ONE image for an article and display that image in any number of ways?

  • Convert photos to black and white
  • Define a focus area so auto cropping comes out nicely
  • Desaturate an image
  • Round corners
  • Increase brightness
  • Add a watermark

All on the fly!

We used the ‘area of focus’ cropping tool for the Tobin Center’s website we recently launched. The user simply uploads one show photo and Drupal automatically creates a banner image, a featured image for the box office and two thumbnails — one color and one black and white.

I’m certain this functionality could be reproduced in WordPress, but would it be worth it? How much plug-in hacking would be required? In Drupal, only a few key modules are required and then the image styles are ready to roll.

Content Types, not Posts or Pages

When was the last time you built a site in WordPress and had something other than a traditional post or page? I don’t think I’ve ever built one of those. It seems like the client always wants calendars, slideshows, advertisements, testimonials, etc. Now, you can tack those onto pages and posts in WordPress, create custom post types or use advanced custom fields, but it’s not always easy and the implementation isn’t always consistent.

Drupal solves this issue by forcing you to make all content a content type from the get-go. Need a calendar? Create an event content type and a calendar view that pulls from that content type; then when a user creates an event, it’s woven into the site wherever that content type is displayed (as long as it meets the criteria defined for that particular display). It can be used in a calendar view, an individual event (node) view, etc. You could even relate events to one another and display related events in the sidebar of each individual event.

No more short codes to include a calendar on a particular page.

These are three quick things that distinguish these two very popular CMS’s. At the end of the day, I love both and believe each has its specialty. Agree or disagree with any of my insights? Let’s talk about it in the comment section.

About Drupal Sun

Drupal Sun is an Evolving Web project. It allows you to:

  • Do full-text search on all the articles in Drupal Planet (thanks to Apache Solr)
  • Facet based on tags, author, or feed
  • Flip through articles quickly (with j/k or arrow keys) to find what you're interested in
  • View the entire article text inline, or in the context of the site where it was created

See the blog post at Evolving Web

Evolving Web