So, we now have all of our CSS and HTML in our sub-theme. In this lesson, we've moved over the remaining files that our theme will need, like the images folder, and our node template files. The last step to finish this theme up, is to modify our CSS to take advantage of the responsive framework we already have in place. To do that we'll:
- Review the theme files
- Look at our default CSS file
- See the responsive changes
We're in the home stretch with our theme, so let's make our CSS responsive and wrap things up.
You can download the final Ninesixty Robots Omega theme as a regular project from Drupal.org.
Additional resources
You can download the final Ninesixty Robots Omega theme as a regular project from Drupal.org.
In this lesson we have fast-forwarded some by completing the conversion of our old page.tpl.php into the new Omage theme. We'll take a look at the work we've done to get to this point, and then deal with what looks like could be a tricky HTML wrapper problem by creating a new zone for our theme, and configuring it to meet our needs. So, we'll:
- Review templates and variables
- Add a new zone to our theme
- Configure our regions with the new zone
This is where we can really see how to blend the usefulness of code and configuration in Omega, to accomplish our task in a very simple way.
Additional resources
You can download the final Ninesixty Robots Omega theme as a regular project from Drupal.org.
We have a custom template file that has the HTML that we want, but not all of variables are coming through yet, and instead we are getting "Undefined variable" errors. In this lesson we're going to take care of that, as well as making sure our custom variables from the original 960 Robots get moved over as well. Omega has its own best practices around adding preprocess and process functions to a sub-theme, so we'll walk through what Omega expects, and how to use the files and examples that Omega is providing for us. So we're going to:
- Look at the Omega best practices
- Create a process include file
- Add our region variables
- Add our custom variable from 960 Robots
Additional resources
You can download the final Ninesixty Robots Omega theme as a regular project from Drupal.org.
For this lesson we get to finally start to convert our 90 Robots theme into our Omega sub-theme. We're going to take a look at what we have the original 960 Robots files, and start to move that into our 960 Robots Omega theme. To start things off we will:
- Review theme files
- Move main.css into the global.css file
- Begin converting the page.tpl.php
- Create a custom region template
Here is where the rubber meets the road for making our sub-theme look the way we want it to, so let's dive in.
Additional resources
You can download the final Ninesixty Robots Omega theme as a regular project from Drupal.org.
The combination of Omega, Alpha and our new 960 robots base theme means that there are a pile ton of CSS files included in our pages now. These CSS files provide the foundation for some of the coolest features in Omega like the mobile first approach and the ability to provide a responsive design. Lets take a look at
- The various CSS files included by alpha, Omega, and our subtheme and how they work together
- Do a quick expirement to demonstrate the various CSS files associated with Omega's media queries
- Talk abou the HTML output by the Omega theme and how it's structured.
So put on your goggles beacuse we're about dive deep into the land of responsive CSS.
Additional resources
You can download the final Ninesixty Robots Omega theme as a regular project from Drupal.org.
In this lesson we will be covering how take all the settings we have made for our 960 robots subtheme and export it into code. We will cover multiple ways of doing this and why this is a good practice to get into when working with different environements and/or other team members. We also cover adding features to the .info file from our exisiting theme into our new Omega sub-theme. So basically, this lesson will cover
- Exporting your theme
- Why export?
- 3 Different methods of export
- More theme conversion
Once the lesson is complete you will become an exporting guru and impress your friends at just about any gathering with your Omega Exporting amesomeness.
Additional resources
You can download the final Ninesixty Robots Omega theme as a regular project from Drupal.org.
This video shows how to target a specific form with the hook_form_FORM_ID_alter and creating a customized validation function for a form.
Note: There is a typo in this video. (The code is correct in the downloadable example file attached to the previous video.)
In the demo_validate_password() function, the following line shown in the video if (in_array($form['values']['pass'], $badpasswords)) { should be if (in_array($form_state['values']['pass'], $badpasswords)) {.
Besides working with sections, zones, regions, and responzive settings, Omega provides lots of other features that make using it a good choice for your theme. Omega also offers:
- Ability to enable/disable script libraries
- Ability to enable/disable theme style sheets
- Ability to enable/disable core/contrib stylesheets
- Typical theme settings
Getting to know these settings certianly helps set the look and fell as well as the capabilties of your theme. With the ability to do things like adding the Equal heights library and enabling it across your zones is just a handy feature and it's free with Omega.
In this lesson we're going to get started with Omega by getting the base theme and creating our new sub-theme. We're going to be doing the following tasks:
- Enable Omega and Omega Tools
- Use Omega Tools to create our sub-theme
- Enable the new theme
- Review the files of the new theme
Omega offers a simple, yet nice set, of debugging tools that assist you when it comes to laying your site out in a 960 grid. Grid layous consist of columns that your content can span accross and part of these debuggung tools is the ability to turn on and off a visual indication of the particular column layout you are using. Omega also gives you the ability to toggle on and off a visual indication of all the regions availabile in your theme. Inside the theme settings you also have the ability to turn these features on or off all together or by role. So in this lesson we will cover:
- Omega debugging tools
- Grid and region visual indicators
- Omega debugging settings
We will also show you how these tools can cause some frustration when it comes to testing the layout of your site espcially in areas that don't have content yet available.
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
In this lesson we're going to take a look at the Omega theme, cover some basic terminology around it, and discuss the advantages and challenges of using it. Specifically this lesson will cover:
- Omega features
- Helper modules
- Where to find documentation
- Omega terminology
Additional resources
- Omega theme
- Omega Tools module
- Delta module
- Omega Handbook
In this lesson, we pull our work together by creating a new view on the site that uses the work we've done so far with exposing our data, and creating our handlers. Once we create the view, we'll export it and add it to our module as a default view.
In this lesson Joe demonstrates how to extend the default views sort handler and create a new one for use on our table that will allow us to sort the data returned from a query with the rows that belong to the currently logged in user at the top of the list. This lesson builds on information from the previous couple of lessons regarding implementing views handlers and general coding for views best practices.
In this lesson Joe takes a look at writing a custom filter handler by building on the knowledge gained about writing handlers from the previous lessons. Filter handlers control how data in a table is treated when being used in the context of a views filter including things like how the data is represented, what the form for filtering looks like and more.
In our original Databasics module, we had some access control around who could see the tab we are providing on the user page. Now that we have switched that tab to being a view, we need to still add that access control back. In this lesson, we will work with a new feature of Views: plugins. We will create an access plugin that gives us the freedom to add our own custom access control, along with settings to give our users a choice about what access they'd like to use.
Domain Access can do its magic because of the Drupal node access system. In this tutorial we'll walk through the basics of how this system works, highlighting the two main methods, and then explain why this may be important information for you. We won't be diving into the code side of things, but instead outline the basic concepts for anyone who needs to interact with this system. When using a module like Domain Access, you should be aware of the Drupal context in which you are working, even if you hopefully never have to dive into the details.
Additional resources
Controlling Access to Content Overview (drupal.org handbook)
Node access developer documentation (api.drupal.org)
Testing, and quality assurance, are an important part of maintaining high-quality software. Together they ensure that the code we write functions as it is intended to, and that changes made later on do not introduce any regressions into our application. Its tedious work and generally involves coming up with a list of tasks that prove a specific feature is working, and then repeating the list of tasks every time a change is made.
Automated testing is the process of writing code to reduce the number of things we need to do manually when testing our software. That list you created to ensure your software is working correctly is likely something that can be easily automated with a testing framework like SimpleTest. Doing so can dramatically reduce the amount of time it takes to perform QA, and improve the overall stability of our applications.
The SimpleTest testing framework was introduced into Drupal core early on in the Drupal 7 development cycle. Since then it has had a profound impact on the way our community develops Drupal. Core now contains a whole suite of tests that cover somewhere in the neighborhood of 75% of the softwares functionality. Every time a new features is introduced, or a bug is fixed, this battery of tests confirms that the fix to the date formatting function didn't inadvertently break something else.
In this series we'll learn to write our own automated tests for Drupal 7 using SimpleTests. We'll walk through enabling SimpleTest, and running one or more test cases with both the SimpleTest UI, and with drush. Then we'll cover some of the related terminology like the difference between functional tests and unit tests. As well as discuss why testing is an important part of development and worth the investment.
Then we'll walk through writing a test case and a set of assertions in orders to verify that various features of our site are working. We'll use functional tests based on the DrupalWebTestCase class, which simulates a browser navigating our site and clicking on links, and filling out forms. And the DrupalUnitTestCase class, which allows us to write super fast unit tests for the business logic contained within our code.
After watching this series you should be able to:
- Install the SimpleTest module and run the tests included with core.
- Define and know the difference between functional tests, unit tests, test cases, and assertions.
- Create a new test case so that SimpleTest can discover and run your tests.
- Write assertions that test the validity of your application in a given state.
- Use the test browser to click on links and navigate to pages on a site.
- Fill out and submit forms and AJAX form elements using the test case browser.
- Handle file and image uploads in test cases.
- Write unit tests, and understand how the workflow for running unit tests differs from that of functional tests.
- Use the SimpleTest 7.x-2.x module from contrib to test existing websites.
This series assumes that you have basic understanding of Object Oriented PHP, and are familiar with Drupal module development. If you need to brush up on your module development watch our series on Drupal 7 Module Development. And, while not required to run tests, we do make use of drush in this series so knowing how to run drush commands is helpful.
Writing tests can be a challenging. But it doesn't have to be. And the benefits of doing so are huge. Especially as our web applications become more complex, as our teams grow, and as the multitude of ways in which people interact with our web applications changes constantly. Spending some time learning how to write tests will not only make your applications more reliable, it'll also make you a better developer.
Additional resources
Developers write tests for a variety of different reasons and understanding why, and how, writing tests can improve the quality of our code and our sanity helps motivate ourselves to write tests. The tests we write usually take one of two forms. Functional tests are used to test an applications behavior. When I click this link does it take me to the about page? Unit tests are used to verify the logic within a small segment, or unit, of code. When I call this function that is supposed to return a link with these specific parameters does it return the correct data? There are a ton of reasons that investing time and resources into writing automated tests is a big win in the long run and in this lesson we'll cover a bunch of them, including:
- Eliminate repetitive tasks.
- Improve overall stability of an application.
- Ensure critical paths & edge cases function.
- Reduce (not eliminate) the number of tests that need to be performed manually.
Types of Tests
There are are two main types of tests and we're going to be writing. Functional tests, and Unit tests.
Functional tests, also known as integration tests, test the functionality of a particular aspect of an application by simulating normal interaction with that system. In the case of web software this usually refers to simulating a user navigating and interacting with the website as if they where using their browser, keyboard, and mouse.
Unit testing is the art and practice of taking a small portion of code, a unit, and subjecting it to programmatic tests to prove its correctness. For example, testing a function that performs unit conversion by comparing a known input with an anticipated result.
UPDATE: This video references qa.drupal.org which is no longer in use. On Friday, October 23rd 2015 - qa.drupal.org received and processed it's last
test. The qa.drupal.org testbots have now been superseded by DrupalCI - and test results are now displayed directly on Drupal.org. While the mechanics are different now, the end result is still all patches to Drupal core are automatically tested.