The Secret Sauce, Ep. 01: How to Prepare for Drupal 8

This is the first in our weekly bonus podcast called the Secret Sauce that deals with shorter tips and resources that will help you with some straightforward facet of your web project. This week Larry "Crell" Garfield helps you prepare for Drupal 8.

This is the first in our weekly bonus podcast that deals with shorter tips and resources that will help you with some straightforward facet of your web project. It's a compliment to our monthly, long-form podcast On the Air With Palantir. That's why we call it the Secret Sauce.

Some episodes will focus on strategy, design, metrics, or other such topics, while others will be more technical in nature. Whatever the focus, we want these to be useful for you, so we draw from our real world experience.

iTunes | RSS Feed | Download

 

This time around Allison Manley lets Larry Garfield take the mic to talk about Drupal 8, how you can prepare for it properly, and how the changes in this new version push us toward a content strategy approach. While applicable to anyone considering Drupal 8, this particular episode is mostly technical in nature and geared more toward site builders and developers.

Look for the Secret Sauce bonus podcast released weekly on Tuesdays.

We want to make your project a success.

Let's Chat.

Transcript

Allison Manley [AM]: Hello, and welcome to the Secret Sauce, brought to you by Palantir.net. This is the first episode of a very short podcast, just five to 10 minutes, that offers a quick tip on some small thing that you can do to help your business run better. Think of it as a protein boost to your company’s milkshake. Some of the tips will be technical in nature and might involve code or something more deep than that, but some will be design-related, some related to project management, human resources, etc. etc. But whatever it is, it will be something useful. If you’re a web design and development shop using open source, as Palantir is, most likely every tip will be useful. But I would say if you’re any other type of organization, maybe some of the technical tips aren’t specific to your needs, but all of the non-technical tips will be applicable to you as well.

I’m Allison Manley, an account manager here at Palantir, and today’s advice comes from Larry Garfield, who’s going to discuss how to get your website ready for Drupal 8.

Larry Garfield [LG]: Hello, this is Larry Garfield, senior architect and community lead with Palantir.net. Today I’m going to talk about some tips for thinking correctly in Drupal 8. Drupal 8 is of course a big change from some past versions of Drupal, and a lot of people are concerned about how to prepare for it properly. But in many ways there’s a lot that’s the same. I want to talk specifically to site builders and developers on a couple of points.

For the site builders in the audience, you’ve probably heard that Drupal 8 includes a lot more functionality in core. And that’s completely true. There’s a lot you can do with just Drupal 8 core which you can’t do with any previous version of Drupal. That doesn’t mean you won’t be using Contrib. There’s still a lot of functionality that exists outside the core system, and if in the past you had 30 modules that you installed by default on every site, you’ll now have maybe seven. And that’s fine.

A lot of those changes in core, though, push us as developers toward a content strategy approach to Drupal, more so than past versions have. This is, I think, crucially important. Drupal is fundamentally these days a tool for content strategists. It is a tool for doing content modelling, a tool for doing business rules for how content will get displayed, rather than editing the content itself per se. If you’re building out a site, don’t think in terms of pages. Think in terms of content strategy. What content objects do I have? How am I going to show bits and pieces of that content on the page, and where? What are the rules I’m going to have around how that content gets displayed? Think in terms of design components. How am I going to show this piece of content, this event, this news item, this faculty member, whatever your content is? How am I surfacing that information? What does it look like? What data do I need to support that?

A lot of these concepts have existed for a long time in Drupal, but are coming more and more to the forefront. And with Drupal 8, just core alone lets you tackle a lot of these questions. For example, I have these events, in the abstract. I now want to show some events on my home page. All right, what representation of an event am I showing on the home page? What is that called? All right, I make a view out of those. I can then use that same representation on other pages. In Drupal, that’s a view mode. By building it as that stock piece that we can reuse, called a view mode, we now have a guide for designers, who can design a single representation of an event in a given style. Maybe it’s a teaser version or an illustrated list version, and for a site builder, we can reuse that all over the site. That makes the site more consistent for us as site builders, for designers, and for end users.

At the same time, Drupal 8 does include a lot of robust new features for editing blobs of content, especially the in-place editing support and built-in WYSIWIG. Those are useful for what they do, but don’t fall into the trap of using them as a crutch. You still want to have structured data with Drupal. Don’t look at a WYSIWIG editor in Drupal as a way to edit the tool — in fact, I would not even call it a WSYIWIG editor. Let’s not use that phrase again. Instead, it is a rich text editor. It is an advanced way of formatting a textual chunk within your content. Instead of mixing content together into one big blob, break it out into separate fields or even separate entities. Use tools like Entity Embed, which is a new module for Drupal, 8 to interject one piece of content into another in a clear, repeatable, structured fashion.

For developers, one of the most common questions I hear is: do I need to learn Symfony? And the answer is no. Drupal 8 uses a lot of components out of Symfony, but also uses components from other PHP projects as well. Symfony was simply the first and the largest of the projects from the larger PHP community that we’ve adopted. You do need to learn modern PHP practices for Drupal 8. I’m not going to tell you not to learn Symfony — it’s a good framework — but you don’t need to go learn Symfony first to learn Drupal 8. You just need to learn good modern PHP.

One of the most important parts of that is what I’m going to call explicit context. In Drupal 7 and in the past, very often there was an implicit context as we were developing, that, well, we’re assuming we’re in a request, and it’s a web request, so I’ve got these global variables set up, and I can call this function and expect it’ll just work – all of that goes away. In Drupal 8, everything is and should be explicit. If you have a piece of code that’s using some other service, some other library, that’s an explicit dependency. You don’t just call a function randomly – you have a service that gets injected into your object and then you can use it. And then you have an explicit list of what your code depends on. That lets you know what’s going on, and it also lets the system know what’s going on. And that makes it easier for you to refactor and for the system to optimize itself.

When generating output, the same thing applies. In Drupal 7, it was common to call Drupal add JS, Drupal add CSS, Drupal set title, other functions that set values that would get used later in the process, and in the meantime they’re stored somewhere in a global, probably. Don’t do that. That is probably one of the reasons why, for example, in Drupal 7 the performance between an authenticated user and an anonymous user was so huge. Because with an authenticated user or logged in, there might somewhere be changes in one page request response versus another, and so we can make no assumptions at all. In Drupal 8, everything is explicitly declared. You have to explicitly pass values back in render arrays, which means the system can know — oh, this piece of content in this block depends on this CSS file, so I can now cache that rendered version of that block and the knowledge that needs this CSS file. And then when the second request comes in, we don’t need to recalculate that block. We already know it’s string and the CSS file it needs. It’s a very simple example, but that idea of making things explicit is where most of the performance work in Drupal 8 is happening. Once you have explicit knowledge about your system, there’s enormous power that comes with that to automate a lot of processes.

Also, it’s a lot easier for you to understand your own code a week later. Because, Lord knows, I don’t understand my own code a week later half the time. But being explicit with our code, explicit with our dependencies, explicit with what we’re passing back, makes that a lot easier both for the system and for us as developers.

Some tools to support that? Use strong types wherever possible. Use objects, even if they’re small simple objects. Use objects with clear properties and documentation over anonymous arrays. Anonymous arrays are inherently non-explicit. The more you give yourself that strong type to build on, the easier it’ll be for you and for whoever comes after you. I’d also suggest minimizing your dependence on Drupal. We’re driving a Drupal module, but most of the code should be, if possible, decoupled from Drupal itself. If you have some interesting business logic, break it away. And then have a thin glue layer that can attach it into Drupal. Maybe you spin it out as a separate project, maybe not, it doesn’t matter. But by keeping the surface area between your code and Drupal as small as possible, that gives you a lot more flexibility to refactor your own code, to allow Drupal to change without breaking your code, and to test your code as well, independently of needing a whole running Drupal site.

I’d also recommend to assume that your code will get used in an environment that has a staging server. One of the pitfalls of Drupal 7 earlier is that we stored everything in the database — content, configuration, everything. Which meant that doing staging and deployment was hard. In Drupal 8 we split up data storage into very clear, discrete components, each of which serves a different purpose. For example, if you want to save information that a user has provided for your module, ask yourself the question: is this a configuration that should be made on a staging server and pushed forward to production? Or is this something that is only relevant on production and should not get transferred between production and your staging server? It could be either one, but there’s different systems to store that data. If you want it to get moved from a staging server to production, use the configuration system for that. If it’s data that’s only relevant on production — say, the last user that logged in, or the last time Cron ran, things like that — use the key values storage system or the state api, and store that in a dedicated place there. But ask yourself the question: assuming that there is going to be a staging server, what do I want my users to do on a staging server, and what do I want them to do on production? There are things in both categories, but you again need to be explicit and understand which one is going to be which. 

Have fun!

AM: Thanks, Larry! For more great tips, follow us on Twitter at @palantir, or read our website at palantir.net. Have a great day!
 

Development Drupal