In this lesson we will convert the style guide into a series of stubs which we can view in a Web browser. The design was originally created using the templates from the 960gs. We'll use this same grid framework to ensure all of our margins are automatically adopted. Grid frameworks are excellent for rapid prototyping of designs. Ultimately many front end developers choose choose to write their own for the final theme; however, if you're just getting started try to stick with a grid framework to reduce the number of things that you need to fight with.
The original theme that was created for this design used the NineSixty base theme. There are some nifty features in this theme which are great for more complex designs; however, it is not responsive, and does not use Sass. To bring the lessons up-to-date we'll be using the 960-Compass Plugin to generate our stub files and give us some sample Sass output to work with.
By the end of this lesson you will be able to convert a style guide to a series of stub files in Sass (or CSS) using SMACSS conventions and a grid framework.
Additional resources
SMACSS (Scalable and Modular Architecture for CSS)
In SMACSS there are both major and minor layout rules that need to be created. The major layout rules are often handled by a grid framework and are used to describe big areas on your site, such as your Drupal regions. The minor rules are used for the components (for example how a picture aligns next to a paragraph of text). In this lesson we'll start by review how Sass allows us to use semantic naming for our CSS layout classes. Then we'll adapt the sample Sass provided by the 960 Compass Plugin so that it uses the necessary structure for our design.
By the end of this lesson, you will be able to implement the layout rules from your style guide as a Sass file using the 960 Compass Plugin as a reference.
Additional resources
The final step before we step back into Drupal is to create a checklist for all the things we need to implement in Drupal. Using our style guide as a starting point, we'll ensure that every design decision which has been made can be implemented in Drupal. Your checklist might also include notes about which modules should be used to build each of the components from within Drupal. Creating a checklist might seem like a trivial task, but it's really important that you know exactly what you're about to build so that you don't get overwhelmed once you step into Drupal. By the end of this lesson you should be able to create a document with all the instructions, and notes you will need to apply your style guide to a Drupal site.
Technically a theme can be installed onto any Drupal site, but it never quite works this way in real life. In this lesson we'll create a playground so that we can try out our theme before deploying it to a live server. We'll start by installing Drupal and adding some “fake” content and menus with the devel generate module. For these tasks we'll use Drupal's default theme, Bartik. By the end of this lesson you will be able to install Drupal in an environment where a development version of the theme can be safely tested.
Additional resources
One of the most time consuming things a content editor can be forced to do is resize images before creating their content. Fortunately we can get Drupal to do the resizing for us. It's not perfect—it's just a plain resize, but it's enough for most basic sites. By the end of this lesson, you will be able to configure Drupal to resize images to your specification when they are uploaded using the image field type.
It's pretty typical for a site to have one or two pieces of content that need to be easily edited, but also aren't nodes. For example: text in the footer. There are a number of ways to create this content. We'll use blocks to create this content as this is the easiest way to place content into a specific region without additional helper module. By the end of this lesson you will be able to create custom blocks, and place them into specific regions within your Drupal theme.
A base theme is someone's idea of a really great starting point. It might include the stub files for CSS overrides, template files which bring Drupal core's markup up-to-date with HTML5, useful theme overrides which create new template variables. In other words: a base theme can provide you with a lot of really great stuff! The first version of the Domicile Theme used the NineSixty base theme—just enough for a simple site, but not so much overhead that it was complicated to learn. This version of the theme doesn't use a base theme. That's because, thanks to Sass, we'll be able to get almost all of the power of the NineSixty base theme through a gem plug-in. In this lesson you will learn which folders are typically used to keep Drupal themes neat and tidy.
A theme is comprised of a collection of related files. Our completed theme will have CSS and PHP (with HTML fragments). To ensure all of these files are loaded, we need to tell Drupal where to find them, by listing the files in the theme's .info file. To begin working with our theme's info file we'll start with the only values which are required: name, version of Drupal core this theme can be applied to. We'll also add a few recommended pieces of information: description of the theme, the template engine, and a screen shot for easier selection of the theme from the administrative area. By the end of this lesson, you will be able to create an info file for a theme, and explore the relevant drupal.org handbook pages for more information on refining your theme's info file.
Our main focus for the Domicile theme is restyling Drupal's markup with CSS. Although it is tempting to put all of your CSS into a single file, things can quickly grow out of control. In our theme we'll break our CSS into smaller stub files to make the theme easier to maintain using the file naming conventions for Drupal 8.By the end of this lesson you will be able to incorporate CSS files into your theme via the theme's .info file.
Additional resources
Drupal uses a series of nested template files to build out the rendered HTML pages we see in our browser. The template file page.tpl.php holds markup between <body> and </body> tags. We talked about the nested nature of template files in Lesson 3: Theming by Component.
In this lesson we will:
- create the file page.tpl.php
- add the relevant markup, and CSS classes for our grid framework
- insert relevant PHP variables so that Drupal can render each of its page components.
By the end of this lesson you will be able to create, or adapt, a page.tpl.php file to suit the conventions you identified in your style guide.
Designs often have a few elements which don't need to be easily edited and can essentially be "hard wired" into the template files. In our design there are three or four images which fall into this category. In this lesson we'll edit the page.tpl.php file to insert our design assets from Lesson 5: Extract Design Assets. By the end of this lesson you will know which variables can be used in a template file to ensure the correct directory is always used for hard-coded image files.
It's always smart to do your development work in a local environment, but eventually you will need to upload your theme your server. In this lesson we'll upload our theme to our web server using Filezilla. By the end of this lesson you will know which folder your theme needs to be uploaded to, and at least one application suitable for uploading files.
Additional resources
Once your theme is uploaded you still need to enable it before it will be applied to your site. By the end of this lesson you will be able to enable new themes for your Drupal site.
Once all of the elements are in place, it's time to get down to the real work of theming the components. In this lesson we will:
- use our style guide and checklist to find each component
- check to see if the style looks "right"
- troubleshoot broken styles so that each component looks as good as the designer's original, static files
By the end of this lesson you will be able to identify elements on a rendered Drupal page which do not have the correct styles applied, determine the source of the problem, and alter the markup or styles to correct the output displayed in a browser.
To go from design to theme we worked through three major steps: building a style guide; building out Drupal; and finally applying the style guide to Drupal. In this lesson we'll review each of the steps outlined in this learning series:
- creating a style guide with base rules, layout rules, and component rules
- extracting design assets
- configuring Drupal
- creating theme files
- debugging components from within Drupal
By the end of this lesson you will be able to outline the process needed to transform a static design file into a functional Drupal theme.
This learning series covered just the tip of the theming iceberg. Hopefully you're now feeling motivated to learn even more about theming. In this lesson we will review some of the other topics you will want to explore next including: advanced theming techniques, using a base theme, such as Omega, layout modules. By the end of this lesson you will by able to identify which videos you should (or could) watch next to learn more about theming Drupal.
In this video we cover a new Drupal 7 feature which lets us create suggestions for theme functions, in addition to suggestions for templates. We'll use this to modify the tags displaying on a node in our site.
Notes:
In the example: $item['#options]['attributes'] += $variables['item_attributes_array'][$delta];
+= is a shortcut for array_merge. So it is ensuring the contents of $variables['item_attributes_array'][$delta] are included in $item['#options]['attributes'] so that any class, rdf info or other html attributes are appropriate applied to the tag links. It's possible for any number of modules to set HTML attributes on the tags field in the theme we need to make sure that they get printed out appropriately.
Additional resources
This chapter gives an introduction to how you work with Drupal's renderable, form arrays by adding an image button to the search form. It also walks through the process of adding the necessary classes to a form element so that the image button is properly aligned. The Forms API reference document is a pretty essential reference document for creating and editing forms in Drupal.
Although we use the function dsm() in this video, this should probably be dpm() as that's the preferred function name. The functions dsm() and dpm() are identical.
Additional resources
You can use custom image sizes for automatic display in your Views!
We already know that being able to set a standard for image display creates consistency and a better user experience. It also makes it for easier site administration because you don’t need to cut all of you images before you upload them. Drupal does all the work for you!! Not only can we specify what the image will look like at the node-level, we can also specify what the image will look like in Views.
I am assuming that you already know how to create custom image style presets, and are familiar with the Views module.
For this tutorial, you need to make sure the Image module that comes with Drupal Core is enabled and that you have already downloaded and enabled the Views module along with its prerequisites.
We will use the example of a blog, where we add our scaled images to display in the listing.
Walks through the process of enabling the theme developer module and showing the themer info, which is like Firebug for Drupal theming. You can choose specific elements on the page to see what Drupal template files or theme functions were involved with outputting it to the screen. You can easily look at the candidate template names that are available, as well as see all of the variables that are available from that template file. A list of documented variables can be found within the node module's node.tpl.php file, but sometimes there are undocumented variables that are coming from contributed modules or elsewhere. It's a super handy tool to have available, but only enable it when you really need it since it can adversely affect the mark-up on your page and cause some wonky behavior.
Additional notes:
The Theme Developer module is on Drupal.org at http://drupal.org/project/devel_themer. Once you find a module on Drupal.org, you can see the "machine name" for the module in the URL (it is the same name as is used to for the module's .info file as well). That is the name that Drush uses. So, in this instance, Drush is looking for "devel_themer".
drush dl devel_themer