You may notice that even though you are using a translation that you have installed, there might still be some untranslated text peeking out here and there. This will become more likely as you add contributed modules. Almost no site will have absolutely 100% language coverage out of the box, so you will probably need to translate a few items yourself. Drupal has a built-in system to do this with the Locale module, but there is also a contributed “Localization client” module which extends this core feature. In this lesson we'll take a look at Localization Client, see why want to use it, and how it works.

Additional resources

Localization Client project
Using Drupal, 2nd edition
Using Drupal source code

Additional resources

Using Drupal, 2nd edition Using Drupal source code

In this lesson we will cover all the settings that are new available in the Features module from the Bean module.  We will update our current feature with all of the settings we have configured from creating different Bean types. We will discuss what has been added and be reminded that content is not stored in the feature.  It is good practice to setup all of your configurations and get those configurations into code, then move those settings to your final environment before you start creating content.

In this lesson we will install the Bean module and tour the changes it adds to the core block system. We will also look at and learn about block types, and how we can add fields to these types.

Now that Blocks are fieldable and we can have different types, lets demo how this works.  In this lesson we will create different block types and show how they can be used just like content.  We will also show how we can edit a block that was created with Bean.

In this lesson we will demonstrate how Beans are available in the Context UI.  We will place some of the these blocks in different locations and also demonstrate how using different block displays with different context allows us to have a block appear differently based on context.

One of the biggest downsides of the core block system are its permissions.  To allow different roles to do different things with blocks is basically an all or none permission. The Bean module provides more granularity for block permissions. We can now add the ability to have site content creators create blocks but not give them permissions to all the other block admin pages.

Much like using Context to enhance the core block system, the Bean module takes blocks to a whole new level. The Bean module makes blocks act more like content types.  It allows for different block types and for adding fields to blocks. We are also able to manage the display of a block, which comes in handy with Context. We can have a block look different based on the Context of the block.

Additional resources

Written tutorial based on this video

In this lesson we'll get started with Context by installing the module on our site, and then walking through the user interface we have to work with. We'll discuss things like conditions and reactions, and see how things are set up.

In this lesson we will discuss different use cases for when one would use Context module. We will demo a site that has a home page and a user dashboard that acts as an authenticated users home page. We will demonstrate one of the advantages of Context by placing blocks in different locations depending on which page we're looking at.

One of the key problems with the block system in core is it's very limiting. You are limited to a small set of tools for when and how to show a block. Once you lay out your blocks you are basically done—blocks can't be placed in multiple regions. Most importantly, block configurations are not exportable. With the Context module, you lay things out based on the context of your site.  A block can exist in one region for one context and a different region for another. Essentially Context is a more advanced block placement form.

In this lesson we will go over one of the main reason for using Context over core blocks; exportability. Using the Features module we are able to take all of the work we do in the Context UI and export it as standalone or with other features.  The advantage of this is now all of our settings are stored in code and are deployable.

In this lesson we will perform a simple operation that site builders do when using the Context module. This is not necessary, but a good idea if there are multiple people managing your site. We will disable all blocks in the block UI since we will be using the Context module to manage this part of our website. The core block UI will then only be used to manage block titles as Context does not allow for this (a disadvantage we learned about previously).

As Drupal site-builders and developers we are all very aware that Drupal 7 is not the most useful product out of the box. We constantly add modules and custom code to make Drupal do what we need. There is nothing wrong with this, in fact it is what attracts people to using Drupal in the first place.  The block system that comes with core is what we get after installation as our real only means to laying "stuff" out for our website. People have done things like turning nodes into blocks, or making every block on our a site a view. These concepts work, but have a lot of draw backs for usability and performance.  There are lots of layout tools to use, but this series is going to take a look at the Context and Bean modules.  These two modules are really two completely different modules but when used together give us some pretty powerful options in place of Drupal's core block system.

Additional resources

Context module

Bean module