Embedding Drupal Views with the Paragraphs module

The Paragraphs module has been super helpful to developers and site builders who want to provide content editors with a solution to create amazing looking sites without having to know HTML.

I’m currently using Panels/Panelizer and Fieldable Panels Panes in the Drupal build at work to allow content editors to create the pages they want. Panels overall is great but I’ve come across situations where the In-Place Editor is buggy and/or creates confusion for users. The editing experience is a little wonky for them because between the node edit form and the In-Place Editor, there’s too many ways to skin a cat.

So, with our new department sites roll-out, I’m trying something new and moving away from Panels and going all in with Paragraphs. An immediate roadblock I ran into was How do I embed a View in my paragraphs page?

Viewreference module + Paragraphs

After asking around in Drupal IRC, a nice fellow pointed me in the direction of Viewreference. Once I came across this module, things started falling into place.

At a glance
  1. Install module
  2. Create a Paragraph bundle called “Embed view”
  3. Add a Viewreference field to the bundle
  4. Viola! Embed your views.

Install module

drush en viewreference -y

or download, unpack and upload to your module’s folder.

Create a paragraph bundle called “Embed view”

Add a view_reference field to the bundle


Now you can embed Views within a Paragraph bundle!

The result:

Sharing content between Drupal multi-sites with RESTful and Feeds modules

At Oswego, when we decided to go with Drupal multi-site, one of the biggest drawbacks was the ability “out of the box” to share content between sites. But when you think of it, how much of Drupal works just as you’d like right out of the box? We looked at a few options but what we ended up settling on was a combination of modules that is doing the trick nicely.

Problem

We have a branch campus that needs to pull in program information from another site (graduate studies). The branch campus editors should not be able to edit the content being brought in since they are not the content experts on the subject. Graduate studies maintains the “master” content, then needs to be periodically pulled into the branch campus site. Then, using views we can display a list of content that we pulled in.

Solution

Being a semi-Drupal-newbie, this took quite a bit of trial and error before I figured out something that will work. If you know of another solution to this, by all means leave a comment! I’d love to hear it.

First thing I did was set up the RESTful module on the graduate studies site. This module makes it very easy to be able to expose our graduate program data as a read-only REST endpoint. I experimented with exporting it as RSS, or trying to build something to export the graduate programs as CSV or some other form of structured data but ended up going with JSON via the REST module. JSON is so widely supported, readable, and consumable by so many other applications that it seemed like it was the best route to go.

I’m currently working on a post about setting up the RESTful module! Sign up for email updates to get notified.

The feeds module alone doesn’t consume JSON, but luckily there is a really nice module called Feeds Extensible Parsers.

I’m also working on a post about setting up the Feeds Extensible Parsers module to read JSON!

I currently have it set up to update the branch campus’ program content every 3 hours. Using Drupal’s role and permissions, I can configure it so the branch campus editors can only read the program content, keeping it in sync with the “master” copy.

Creating a hero page template in Drupal

Prerequisites

  • Using Panopoly + Panels + Panelizer

Our current sub-pages look like this:

Screen Shot 2015-04-30 at 3.56.24 PM

 

Drupal is really good at having a consistent header throughout the site. But what if you want to have a landing page that looks like this:

Screen Shot 2015-04-30 at 3.58.00 PM

At first this seemed impossible to me, but after reading about theme_hook_suggestions and preprocess functions, I began to see the light.

  1. Create Hero Landing Page content type with appropriate fields
  2. Create image style to ensure the image is always the right size for the hero area
  3. Add theme_preprocess_page function to grab the image from the node
  4. Add a theme_hook_suggestion to load a different page template file
  5. Disable the hero image field in the default panels
  6. Profit

1. Create Hero Landing Page content type with appropriate fields

You don’t technically have to create a separate content type, but you do need a specific field to hold your hero image. I created a separate content type for landing pages because our landing pages will have some differences from basic pages within our system.

First thing I needed to do was create a “Hero Landing Page” content type that would be able to crank these types of pages out. Within this content type, I created a “Hero Image” field that would be used to hold the appropriate image. Keep note of the “field_landingpage_hero_image” field. That’s what we’ll need later to grab our image.

fields2. Create an image style for the hero image

If you don’t create an image style, you’ll be stuck with Drupal’s defaults which probably won’t suit your needs. In our case, we need the hero image to be 1920px x 768px in order to fit nicely within the theme. Navigate to admin/config/media/image-styles and create a new Image Style called “Landing Page Hero Image”. Under “Effect” choose “Scale and crop” and enter in 1920 for the width and 768 for the height. Once we apply this image style to the hero image field, this will take any image the user uploads and wrangle it into those dimensions.

image_style

3 + 4. Pull out the hero image so we can use it within our page template file & and a theme_hook_suggestion

Using Drupal’s hook system, we can override the template_preprocess_page() function to grab the hero image (if it exists) and make it accessible to the page template file. The way template_preprocess_page works is, you substitute your theme’s machine name for the word ‘template’, and pass in a reference to the $variable’s array. Now within the function you can play with the variables that Drupal is about to render on the page.


/**
* Implements template_preprocess_page().
*/
function oswego_preprocess_page(&$variables) {

  // Check to see if a hero image field is set
  if (isset($variables['node']->field_landingpage_hero_image[LANGUAGE_NONE][0])) {

    // Store the image into $img for easy reference
    $img = $variables['node']->field_landingpage_hero_image[LANGUAGE_NONE][0];

    // Build the $hero array to be used in templates/page/page--hero.tpl.php
    $variables['hero']['path'] = image_style_url('landing_page_hero_image', $img['uri']);
    $variables['hero']['alt'] = $img['alt'];
    $variables['hero']['title'] = $img['title'];

    // Add a theme hook suggestion to load templates/page/page--hero.tpl.php
    $variables['theme_hook_suggestions'][] = 'page__hero';
  }
}

Note the function ‘image_style_url’ that is being called. The first parameter takes the machine name of an image style. In our case, we created our image style in step 2, so I’ll use the machine name of that image style. The function will then return the URL of the image using the specified image style.

By making a $variables[‘hero’] array, we can now access items within it on our page template file using $hero. For example, $hero[‘path’] will point to the URL that image_style_url built in our preprocess function. You can see within the code comments above that I make reference to a file called page–hero.tpl.php. By adding ‘page__hero’ to $variables[‘theme_hook_suggestions’], Drupal will now look for a page template file named page–hero.tpl.php.

Copy your existing page.tpl.php and name it page–hero.tpl.php. I won’t go into the specifics of how I used CSS to style it, but now it is possible to add the hero image in the new page–hero.tpl.php file. Example:


<div class="hero-image">
  <img src="<?php print $hero['path']; ?>" alt="<?php print $hero['alt']; ?>" title="<?php print $hero['title']; ?>">
  <?php if ($title): ?>
    <div class="hero-header">

    <div class="row">
      <div class="section-title-container">
        <div class="section-title-inner">
          <?php print $breadcrumb; ?>
        </div>
      </div>
    </div>

    <h1 class="hero-title"><?php print $title; ?></h1>
    </div>
  <?php endif; ?>
</div>

Disable the Hero Image within your panels configuration

This step will differ greatly depending on how you’re using panels/panelizer. For us, we have a default template that the content type goes into. By default I disabled the node:field_landingpage_hero_image pane so that the image wouldn’t display twice and confuse editors.

disable


And that’s all! Quite a different process than I’m used to when I used to make WordPress themes, but still very effective. Drupal’s powerful hook system allows you to tap into the process and modify data, giving a themer and developer a ton of control. Drupal’s ability to separate logic (template.php) from the theme (*.tpl.php) files is pretty nice as well.

Migrating to Drupal

At work, we’re migrating a 10,000+ page site with 300+ editors to a single Drupal installation. At first, the task is extremely daunting, but if you learn to embrace the confusion, stick with it, and plan accordingly, a task as massive as this is absolutely doable and even rewarding!

I started a “Drupal Migration” category on my blog to document our journey to the promise land in hopes that it will help others in the same situation. I’m going to be talking in ideals here, but know that it’s basically impossible to stick to these absolutely. If you make an honest effort, gains will be had, even if you don’t execute perfectly. I’m going to go over where we’re currently at in this journey.

Work hard. Don’t be an asshole. Share what you know.
Brad Frost

Define the problem

Moving to a new CMS for no reason is a great recipe for pain. You need to have clear goals if the project is going to be a success. Some people on your team will be behind the goals more than others, and that’s absolutely fine — that’s life. As long as you know what you’re working towards, you can control the parts of the project that’s within your grasp.

In our case, our main goals for migrating are to have:

  • Reusable, structured content
  • A better editing experience (we’re migrating from Ingeniux)
  • Improved content quality
  • An updated look and feel

I’ve read articles on how people + process + technology is the magical equation for a successful IT related project. It’s naive to try to solve all three on your own. Establishing who is in charge of each of these areas will make the project go much smoother. Plenty of teams complete projects without balancing these three criteria, but I bet they have a few more grey hairs afterwards. The focus of most of these posts will be on technology and process, although I’d be willing to bet I touch on people as well.

Plan it out

Let’s clear something up right away. Drupal is not like WordPress. It’s not a CMS that you can slap a theme on and instantly have a site. It’s not like Webydoo, Wix, Weebly, or any other drag and drop website builder. It’s so much more than that. It can handle anything you throw at it, but you have to have a plan and understand how it works. This takes time. If you’re 2 weeks away from a deadline and you want to jump into Drupal and whip up a complex site, you’re going to have a bad time.

Since that’s out of the way, let’s talk about planning. When you’re migrating to Drupal, you’re not just shoveling content over from your previous CMS. If that’s your plan, you’re doing it wrong! I’d assume you want to move to Drupal in order to take advantage of how Drupal handles structured content. What you’re really doing is building a data layer for your entire organization. It’s so much more than a CMS.

Drupal and content strategy go hand in hand. Being able to think abstractly about your content will ensure you get the most out of Drupal. For example, in the context of a University website, what is a department page? What does that piece of content consist of? If you want to pull information in from other areas of your site, mapping out the structure of your content is absolutely vital. Nail it down, have meetings, have arguments, just figure it out. In our base case, we decided departments consist of:

  • A featured image
  • Positioning statement
  • List of degree programs
  • List of faculty
  • Student opportunities
  • Outcomes
  • List of events
  • List of announcements
  • Contact information

Items listed in bold refer to separate pieces of content which all consist of their own pieces. For example, abstractly, a faculty member might consist of:

  • Photo head shot
  • Full name
  • Title
  • Research interests
  • Department
  • Office hours

I could go on, but I hope you see my point. If you can think abstractly about the different pieces of content on your site, Drupal can help you weave this information together into something useful. I’d highly recommend reading Palantir’s Plan or Perish blog post. They do a fantastic job of explaining the importance of planning.

Helpful resources

Dare to fail

Unless you are a Drupal expert, it is very likely that your first try will be less than ideal. Drupal is a powerful, yet complex system. Give yourself time to learn the platform. Make mistakes. Break shit. Learn what doesn’t work. Acquia has a free development tool that allows you to mess around with Drupal on your local machine before committing to a live site. It’s much better to break stuff in a development environment than in production. The more times you fail, if you learn from it, the closer you are to succeeding.

Reach out for help

Drupal has a robust community of professionals that, in my experience, have been super helpful. To avoid a RTFM response, I’d recommend playing around locally and learning the ropes before reaching out to the community. Not because they won’t try to help you, but because there’s certain concepts that you learn about Drupal only after experiencing it first hand. Drupal.org is kind of a mess, but there’s lots of very useful information there. Take the time to learn.

Once you have a decent understanding of how some popular modules work, reach out to the community for clarification of how to reach your goals. I’d recommend having a good grasp of how the following modules function before you can really benefit from the community’s help:

  • Ctools
  • Views
  • Panels
  • Context
  • Organic Groups
  • Page manager
  • Am I missing any?

As I said earlier, Drupal is complex, but learning basics about the system will reap major benefits when you go to implement your site. Also become familiar with the following Drupal concepts:

  • Entities
  • Nodes
  • Contextual arguments (within Views)
  • Relationships (within Views)
  • View modes
  • Theme layer basics

Helpful resources

I’ve recently re-discovered the treasure trove that is IRC. IRC is where a lot of community members hang out, talk about Drupal, and help people with questions. I’ve had some great success in asking questions in #drupal, #panopoly, and #drupal-support channels. I’d highly recommend downloading an IRC client for your computer — or use KiwiIRC if you want to try it out — and logging into Freenode.

Wrapping up

That’s currently where we are in the process. We’ve hammered out most of the project requirements, got our hands dirty in a Drupal development environment, thought abstractly about our content, and gotten involved in the community. You may be thinking that’s a lot of work for still not having a live production site.

I’d agree that it’s a lot of work, but I’d rather measure twice and cut once.