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 preprocess 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 Preprocess Function (PHP)

Using a Drupal preprocess 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 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 preprocess 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 preprocess 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 drupal.org (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 Drupal.org 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. pic.twitter.com/LM1E2IcvX5

— 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 CSS-Tricks.com 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