In these tutorials on markup in Views, we learned
:

• What affects markup in Views
• How to use the Views UI to change markup
• How formats affect markup output
• How to customize row and field wrapper markup
• How to rewrite output with replacement tokens
• How to override Views template files
• How to add a CSS class to your View

As you learned, there are a number of ways to affect markup in Views ranging from utilizing the UI to editing a template file in code.

Ready for a challenge?

Now that you’ve learned all about markup in Views, can you apply what you’ve learned? Use your knowledge of customizing markup using the Views UI and your knowledge of overriding Views template files to apply the HTML markup in the pattern lab prototype to a view of recent posts. Download the demo files and database containing the view of recent posts in the additional resources section below. Contained in the top-level of the files download is a directory called "misc." Inside "misc" you'll find the demo-pattern-lab files:

• The latest posts file is located in misc/demo-pattern-lab/source/_patterns/02-organisms/03-sections/00-latest-posts.mustache
• The media block file is located in misc/demo-prototype/source/_patterns/01-molecules/02-blocks/00-media-block.mustache

Use your knowledge of inspecting views template files to locate the read more link markup in order to customize the markup and placement of the read more link, to match the prototype markup. You can find the setting to turn on the more link in the Views UI under the pager section in the middle column.

Here’s another hint: you’ll want to update the field settings for the body field to display a trimmed or summary display instead of the full body value.

Finally, For a bonus challenge, create an image style that matches the prototype image dimensions, and apply it to the image field in your view. To learn more about image styles in views, check out the video Using Image Styles with Views in the Drupalize.Me library.

Good luck with this challenge!

Additional resources

Using Image Styles with Views

Being able to display search results using the Views module provides a huge amount of flexibility with respect to what is listed, what it looks like, and more. In this tutorial we'll look at using the Search API Views module, included in the Search API project, to create a view that allows users to search our Solr index and display the results as a table, or really, in any other way that Views can display content. We'll also cover some special considerations regarding access control and entity relationships that we need to keep in mind when using Views to display search results.

The biggest difference between creating a view that lists a bunch of nodes, and one that displays search results is that you need to use your Search API index as the base table from which you're building your view. Then, by default, the view only has access to the fields that are in the Solr index. This allows you to build the entire view without having to query the database. Or you can use the Views module's ability to define relationships to other buckets of content to query the database and pull in additional information. There's a huge amount of flexibility.

When building views from the Solr index you can optionally expose one or more filters. Essentially creating a form that allows someone to construct a search query. This can be as simple as exposing a keyword text field, or as complex as you would like to get. We'll look at using exposed filters to create a form that users can perform a search with and create a more complete search experience. We'll also look at how you can move those exposed filters into a block that can be displayed on the home page of our site, allowing us to replace the functionality provided to the Drupal core Search module with Views and Solr.

By the end of this tutorial you should be able to create a view that displays search results using the Search API Views module.

Additional resources

• Introduction to Views series

Before we can really dive in to learning Omega we need to do a couple of basic setup tasks. Mostly, we need a Drupal 7 site that has some content for us to look at while we are theming. In this lesson we're going to:

• Generate some content with devel generate module
• Install the 960 Robots theme from drupal.org
• Place some blocks in to the regions provided by the 960 Robots theme and talk a bit about what it gives us so that we can begin to understand how we might convert it to an Omega sub-theme

Under the Downloads tab, there is a copy of the final database and the files directory for this Demo site.

Additional resources

• 960 Robots theme
• Devel module

Before we can start building our custom field we need a vanilla Drupal site to work with and a skeleton module. This lesson will ensure you've got Drupal 7 up and running and walk through creation of a basic .info file and .module file for the module we'll be building. If you're already familiar with Drupal module development this lesson can likely be skipped and you can simply download the attached starter files, add them to an existing Drupal site, and continue on with the next lesson.

Grab a fresh copy of Drupal 7, and install it. If you need a refresher on installing Drupal checkout this series.

You'll also want to download and install the devel module as we'll make use of some of the debugging functions in provides (namely dsm()) in later lessons in this series.

Alternatly, you can grab the .zip file under the companion files listed on this page which contains Drupal 7, and a database dump you can import to get started.

When you learn how Drupal handles dates, you can create event functionality, listing pages with a unique result set, and calendars. The Dates Series begins with basic configurations and the contributed modules required to integrate with other functionality. In addition to creating a new content type for our Date field via the wizard, we also explore all possible configuration choices by diving deeper into the Date field. Once we have content on our site, we move into displaying the content in unique ways in Views by using basic filters, exposed filters and contextual filters. Other demonstrations in this series include working with multiple date fields, repeating dates and integrating with the Context module.

If you would like to work along with the video, the entire demo site can be downloaded and set up (it is found on the introduction video's Downloads tab). The zip file includes the Drupal files, the database, and a README.txt file to explain setting it up. The site was created using the Demonstration module so that you can switch back and forth among the finished states of the various chapters.

In this introductory series you will learn how use the Domain Access project to let you manage multiple "sites" with different domain names from just one Drupal installation. Domain Access "multisite" works differently from the core multisite feature in that you truly only have one site to manage. There is just one code base and one database. Domain Access takes advantage of Drupal's node access system to give the illusion of multiple sites. In this series we start off by getting some context through several presentations that explain what Domain Access offers, and why you might use it, how DNS and Apache web servers work, and what you need to understand about the node access system. Once we dive into the hands-on work, you will configure Apache to work with multiple domain names, and get Domain Access installed on your site. Then you will configure a very basic Domain Access site, learning how to share and restrict content, change themes, and set up permissions for fine-grained access control.

Additional resources

Domain Access project (drupal.org)

Depending on the data that is being searched, some shorter general words, like "a", "the", or "is" can adversely effect search result relevancy. Consider the word "the", which in a standard description of a fish in our database could easily appear hundreds of times or more. When a search is performed, part of the algorithm that calculates the relevancy of any document in the index is to count the number of times a word appears in the text being searched. The more often it appears, the more relevant the document. Words like "the" however often have little to no real bearing on a document's actual relevancy. These words should instead be excluded from the ranking algorithm.

Stop words can also serve another purpose. You can filter out words that are so common in a particular set of data that the system can't handle them in a useful way. For example, consider the word "fish" in our dataset. It's probably very common. With only 500 fish being indexed it's not really going to make much difference, but what if we were indexing five million fish, and each one had the word "fish" in the description even just five times? That's 25 million occurrences of the word "fish". Eventually we might start to hit the upper limit of what Solr can handle. The word "fish" in this case is probably also not very useful in a search query. You're browsing a fish database. Are you really likely to search for the query fish and expect any meaningful results? Likely it would instead return every result. It would be like going to Drupal.org and searching for the word "drupal" and expecting to get something useful. Not going to happen.

Solr has the ability to read in a list of stop words, or words that should be ignored during indexing, so that those words do not clutter your index and are removed from influencing result relevancy. In this tutorial we'll take a look at configuring stop words for Solr.

First, we'll use the Solr web UI to see the most common terms in our index for the body field. Then, based on that list, and the list of common stop words provided by the Solr team, we'll configure our stopwords.txt file. Finally, we'll re-index all the content of our site so that it makes use of the new stop words configuration and re-examine the most common terms noting that our stop words no longer appear in the list.

By the end of this tutorial you should be able to use the Solr web UI to get a list of the most common terms in your index, and know how to add terms to Solr's stopwords.txt file to prevent them from showing up in your index.

Additional resources

• List of common stop words
• Synonyms and Stopwords by Lucidworks
• Solr Stop Filter Factory documentation
• Written tutorial based on this video

Back in the olden days of Drupal, we used to write raw SQL. Now, Views does all of this for us. Views allows you to create a list of only the content that you want, based on criteria that you define.

In this video we demonstrate the first things to do when creating a View: selecting our Base Table, specifying the Display, looking at Advanced Features to filter content, and specifying the HTML output.

Throughout the course of this series, we're going to start with the content types and fields that we created during the Intro to Fields for Site Builders video series. We'll continue the job board example, and create unique listings.

Our apologies! The audio on this video is really bad and hard to listen to because of some background hissing. On top of that, the transcript interface using the "T" icon is broken on this video. Double-boo! Here is the text of the audio. Note: You can also mute the audio and display the captions by clicking the "cc" icon on the lower right corner of the video player.

Views is the most popular contributed module. In the subsequent chapters, we'll show you step-by-step how to use Views.

Views is a query builder that makes lists of your content. But what does that mean? Let's pretend we're looking for a new car. And we want our salesperson to only show us green cars. No, let's make that blue cars. Or maybe, we only want to see trucks.

Think of all of your content as this giant parking lot. Views allows you to create a list of only the content that you want, based on the criteria that you define. And you can concatenate this criteria. You can say, show me all the content that is of the type, article and, authored by the admin user.

Back in the olden days of Drupal, we used to write raw SQL. Now, Views does all of this for us. To create a list of content on our site, we don't need to know anything about the database at all. Views will give us an administrative interface where we can click around to configure our criteria, and also how we'd like it to be output. The previous slide showed us that there are a lot of options to select from. But in basic terms-- Views sucks data in, fires off magic thingies, and then outputs hotness.

When creating a View, the first thing that we select is our Base Table. This is the pool of data from where we want to start creating our lists. Do we want to show information about nodes, or users, or comments, even. And then we can select what we'd like our first Display to be. Should our list to be a page, with a unique URL. Or a block, that we can place in any region in our site. For a Display, in addition to selecting the filter criteria, we can specify which fields we want to appear. And also, what order we'd like our content listed. Advanced Features allows us to filter content based on a current condition-- like the URL, or the logged-in user.

We also can gather information that is related to our current result. Views allows us to have multiple displays for each View. For each subsequent Display you create, it will inherit the configurations of your first Display. Although the new Display utilizes your previous settings, you can override that. Once we've selected our Base Table, and configured our Display settings, Views will also allow us to specify the HTML output. We can choose from a simple div structure, and ordered lists, or even a table.

Views is a powerful and highly-configurable list maker. Throughout the course of these videos, we're going to take the content types and fields that we created during the Intro to Fields for Site Builders video series. We'll continue the job board example, and create unique listings. The Views module contains so many configurations and settings. Through our practical examples, we aim to demystify it. So let's dive in.

Additional resources

Views module at Drupal.org

Make SQL queries in Drupal, make HTTP requests to external websites, and use this data to validate a form.

A multisite Drupal installation allows you to host multiple, separate websites while relying on the same set of code. Large organizations often rely on a multisite installation to cut down on the operational upkeep of multiple sites. Hosting a multisite in Docker poses several additional challenges. Fortunately, the process is not dissimilar from configuring a bare-metal server to run a multisite.

In this tutorial, we'll:

• Outline a multisite's additional requirements for Docker containers.
• Configure alternate, local domain names to resolve each site.
• Learn how to configure a multisite to use alternate domain names.

Running your own migration requires a bit of setup and boilerplate code, Drupal needs to know where to find the source data, and the Migrate module needs to be provided with some basic information about our custom code. In this lesson we'll look at setting up Drupal to be able to connect to multiple databases, and then create the skeleton of a simple module which will house our custom migration code and an implementation of hook_migrate_api(). Finally we'll create a base class from which we can begin writing our own custom migrations, and talk about why this is a good way to start organizing our migration.

With our domains and Apache configuration in place, we need to make sure all three sites can be installed at the different domains by creating our multisite directories in the sites folder. In this tutorial, we'll create the necessary Drupal site directories and settings files for the three sites so they are all running smoothly, check the domains and install the other two sites, and wrap up by changing the theme on the alumni site.

Before we get started, you should make sure you have two empty databases created for the two new sites we'll be installing.

In this tutorial we're going to be working directly on a server using the command line. You can feel free to use a GUI interface for your site, like an SFTP app or just your local machine file browser and editor apps. If you want to brush up on using the command line, you can check out our free Command Line Basics series.

Once you have your site up and running it is very important to keep your site up to date and secure. Both Drupal core and contributed projects continue to improve the software with bug fixes and security updates. In this chapter we look at using the core Update Manager, and explain how to read the various reports about our site's status. Before we walk through the process up updating a contributed module, as well as our version of Drupal core, we also make sure we do a backup.