Drupal 6 Attachment Views

Drupal 6 Attachment Views Use multiple-display views to add functionality and value to your site! J. Ayen Green BIRM...

Author: J. Ayen Green

20 downloads 786 Views 8MB Size Report

This content was uploaded by our users and we assume good faith they have the permission to share this book. If you own the copyright to this book and it is wrongfully on our website, we offer a simple DMCA procedure to remove your content from our site. Start by pressing the button below!
Report copyright / DMCA form

DOWNLOAD PDF

Drupal 6 Attachment Views

Use multiple-display views to add functionality and value to your site!

J. Ayen Green

BIRMINGHAM - MUMBAI

Download from Wow! eBook <www.wowebook.com>

Drupal 6 Attachment Views Copyright © 2010 Packt Publishing

All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, without the prior written permission of the publisher, except in the case of brief quotations embedded in critical articles or reviews. Every effort has been made in the preparation of this book to ensure the accuracy of the information presented. However, the information contained in this book is sold without warranty, either express or implied. Neither the author, nor Packt Publishing, and its dealers and distributors will be held liable for any damages caused or alleged to be caused directly or indirectly by this book. Packt Publishing has endeavored to provide trademark information about all of the companies and products mentioned in this book by the appropriate use of capitals. However, Packt Publishing cannot guarantee the accuracy of this information.

First published: February 2010

Production Reference: 1180210

Published by Packt Publishing Ltd. 32 Lincoln Road Olton Birmingham, B27 6PA, UK. ISBN 978-1-849510-80-6 www.packtpub.com

Cover Image by Filippo Sarti ([email protected])


Credits Author J. Ayen Green Reviewers Lena Doppel

Editorial Team Leader Gagandeep Singh Project Team Leader Lata Basantani

Dave Myburgh Project Coordinator Acquisition Editor

Poorvi Nair

Usha Iyer Proofreader Development Editor

Lesley Harrison

Dhiraj Chandiramani Graphics Technical Editor

Nilesh R. Mohite

Neha Damle Production Coordinator Indexer Rekha Nair

Shradha Vichare Dolly Dasilva Cover Work Shradha Vichare


About the Author J. Ayen Green is a software and website developer, writer, and poet. He is the

chief software designer at Ayen Designs. He and his wife, Sofía-Aileen, make their home in New York City. This was my second title for Packt, and was as enjoyable an experience as the first. That isn't coincidental, and I'd like to thank those responsible for the smooth ride: Usha Iyer, my acquisition editor, who has a keen eye for talent and a sharp sense of humor; Lata Basantani, projects team leader; Poorvi Nair, project coordinator, who is always warm and gracious, even when cracking the whip; Dhiraj Chandiramani, my development editor, Neha Damle, my technical editor, who is very adept at turning a mound of manuscript into what you're holding, and Patricia Weir, who always brings a smile to my face, and the rest of the Packt team, Rekha Nair, Gagandeep Singh, Lata Basantani, Lesley Harrison, Nilesh Mohite, Dolly Dasilva and Shradha Vichare, all of whom combined to create a beautiful publication. Constructively critiquing another's work is always a challenge, and my technical reviewers, Dave M and Lena Doppel were definitely up to it. Whatever I may think of my writing ability, I'm certain that your experience was the better for their efforts. This website used in this book was a live site, GuildBuildersInc. com, and its development occurred in parallel with the writing (not for the faint of heart). Many thanks to Scott Corley, its president, for sponsoring a fun project, being flexible regarding the design and timing (one usually doesn't measure website development in chapters), and for not changing the specs along the way—well, not too often.


My wife, Sofia-Aileen, once again, handled this project with the minimum of grumbling, despite our usually being two ships passing in the night. You're always there to give me a reason to get up in the morning—beyond brewing coffee for you. Finally, I must not fail to mention those who provided the foundation for this book. My thanks to Dries Buytaert, for his gift (and that of some of the world's best coders) of bringing Drupal to the world. Equal thanks go to Earl Miles, aka merlinofchaos, for his spectacular creation known as Views. And to the countless denizens of #drupal, #drupal-support, and the Drupal lists, especially Kenn_ VM, who are always willing to give advice, empathy and/or a laugh.


About the Reviewers Lena Doppel studied organizational development, computer science and web design. Currently she is working as a university lecturer, consultant, and web developer.

She is teaching media technology and web design at the University for Applied Arts, Vienna and is co-owner of 'cat-x media' providing Web and Drupal services for small companies, artists, museums, and exhibitions. When time allows she also blogs a little on her own website lenadoppel.com. I would like to thank Florian Prix for calling me his favorite girl geek, the Drupal community for just being there and Drupal for growing up the way it does.

Dave Myburgh has been involved with computers since before the web existed.

He studied as a molecular biologist, but discovered that he liked working with computers more than bacteria. He had his own computer business in South Africa (where he grew up) doing technical support and sales. He even created a few static websites for clients during that time. After moving to Canada, he got sucked into the world of Drupal a few years ago, when a friend wanted a site for a local historical society. Since then he has once again started his own company and now builds websites exclusively in Drupal (he doesn't "do static" anymore). There is no lack of work in the Drupal world and he now balances his time between work and family. He has reviewed several Drupal books including Drupal 5 Themes and Drupal 6 Themes. I would like to thank my family for being so supportive of me and what I do. Working from home can be a mixed blessing sometimes, but having the opportunity to watch my son grow up makes it all worthwhile.




This book is dedicated to my cousin Gerry. Aside from teaching me to play poker, stick ball, and the trumpet, and taking me on one of the most memorable joyrides I've ever been on, he is one of those rare people who is always there, and in so being tends to make things better.



Table of Contents

1 7

7 9 11 12 20 23 27

29

57

30 32 33 41 48 48 56 58 62 65 66 71 73 73 78


Table of Contents

79

80 86 94 96 106

107

139

107 111 115 124 130 137 139

159 168 172

173 174 175 184 185 190 196 199

201

219

202 206 206 210 211 216 218 219 222

[ ii ]


Table of Contents

226 228 234 238

239

251

239 240 240 241 242 242 243 243 244 245 245 245 246 246 246 247 247 248 248 249 249 249 250 250 250

252 256 256 256 257 257 257 258 258

[ iii ]


Table of Contents

258 259 261 262 262 263 263 264

265

271

265 266 266 266 267 269

[ iv ]


Preface This hands-on tutorial will teach Drupal developers across the experience spectrum how to use Attachment displays to make a quantum leap in View functionality and added-value to users. This book starts by introducing Attachment Views as reader activities. Here, we create a single Attachment View and take a closer look at giving each page an interactive feel. It also shows you how to create a View containing an Attachment View. Later, using practical examples, you will learn how to develop a 3-view composite display using two and three custom content types. You will also develop a composite display using multiple Attachment Views; to provide a control panel of sorts from which you can view the various content types. Finally, we will put the home page together making use of Views, blocks, a flash slide show, and other pieces.

What this book covers

Chapter 1, Something Old, Something New, contrasts the capabilities of a standard Drupal website to what will be achieved in the book, and in so doing, the rationale for the book is presented. Chapter 2, Attachment Views—A New Beginning, introduces Attachment Views as reader activities. Each View created would be able to stand alone, but will then have a single Attachment View created to give each page an interactive feel. Chapter 3, Interactive Page Regions, continues with single Attachment Views. In addition to creating another view and Attachment View, a small module will be created to provide the e-mail functionality needed for contact. Chapter 4, Additional Displays, helps the reader to create a view with an Attachment View, a Block display, and an additional Page display.


Preface

Chapter 5, Bios, will have the reader develop another 3-view composite display, using two custom content types. Chapter 6, Prior Jobs, will take the reader through another 3-view composite display, using two content types: jobs and bios, and the templates necessary to format it, with one of the attachment views being purely for display. The page will display prior jobs for the reader to select from, and once selected, a separate part of the page will display the job info and the appropriate bio. Chapter 7, A Different About-Us, we will develop a 3-view composite display using three custom content types. On most websites, this is a static, fairly uninspired page. Here, we will create a composite page so that the bios and prior jobs will be shown and selectable in addition to the company information that will be in a separate piece of content. Cascading View templates will be used for formatting the overall view. Chapter 8, Control Panel, develops a composite display using multiple Attachment Views, to provide a control panel of sorts from which management can view the various content types. Chapter 9, Front (Home) Page, puts together the home page; making use of Views, blocks, and other pieces. Chapter 10, Punch List, addresses the final tasks, such as defining roles, users and permissions, site configuration items, and more. Appendix A, Add-On Modules, contains information about a few modules that were used in the site and not in the book. Appendix B, Custom Content Types, presents introductory information regarding the creation of a content type followed by information about each type that was created for the site.

What you need for this book Drupal version 6.

Who this book is for

This guide is aimed at Drupal developers of any level, who have not yet explored this functionality.

[2]


Preface

Conventions

In this book, you will find a number of styles of text that distinguish between different kinds of information. Here are some examples of these styles, and an explanation of their meaning. Code words in text are shown as follows: "We can include other contexts through the use of the include directive." A block of code is set as follows:

When we wish to draw your attention to a particular part of a code block, the relevant lines or items are set in bold:

New terms and important words are shown in bold. Words that you see on the screen, in menus or dialog boxes for example, appear in the text like this: "clicking the Next button moves you to the next screen". Warnings or important notes appear in a box like this.

Tips and tricks appear like this.

[3]


Preface

Reader feedback

Feedback from our readers is always welcome. Let us know what you think about this book—what you liked or may have disliked. Reader feedback is important for us to develop titles that you really get the most out of. To send us general feedback, simply send an e-mail to [email protected], and mention the book title via the subject of your message. If there is a book that you need and would like to see us publish, please send us a note in the SUGGEST A TITLE form on www.packtpub.com or e-mail suggest@ packtpub.com. If there is a topic that you have expertise in and you are interested in either writing or contributing to a book on, see our author guide on www.packtpub.com/authors.

Customer support

Now that you are the proud owner of a Packt book, we have a number of things to help you to get the most from your purchase. Downloading the example code for the book Visit http://www.packtpub.com/files/code/0806_Code.zip to directly download the example code. The downloadable files contain instructions on how to use them.

Errata

Although we have taken every care to ensure the accuracy of our content, mistakes do happen. If you find a mistake in one of our books—maybe a mistake in the text or the code—we would be grateful if you would report this to us. By doing so, you can save other readers from frustration and help us improve subsequent versions of this book. If you find any errata, please report them by visiting http://www. packtpub.com/support, selecting your book, clicking on the let us know link, and entering the details of your errata. Once your errata are verified, your submission will be accepted and the errata will be uploaded on our website, or added to any list of existing errata, under the Errata section of that title. Any existing errata can be viewed by selecting your title from http://www.packtpub.com/support.

[4]


Preface

Piracy

Piracy of copyright material on the Internet is an ongoing problem across all media. At Packt, we take the protection of our copyright and licenses very seriously. If you come across any illegal copies of our works, in any form, on the Internet, please provide us with the location address or website name immediately so that we can pursue a remedy. Please contact us at [email protected] with a link to the suspected pirated material. We appreciate your help in protecting our authors, and our ability to bring you valuable content.

Questions

You can contact us at [email protected] if you are having a problem with any aspect of the book, and we will do our best to address it.

[5]



Something Old, Something New If you have developed Drupal websites before, you already know that you can only get so far in developing a site before you run into the need for Views. The first part of this chapter describes views, what they are typically used for, and how we will take their use to the next level. If you are already familiar with views, feel free to skim this chapter. The remainder of the chapter will be used to describe our project site, its underlying need, and how we will fulfill it.

Content management systems

A straight-forward case for a content management system is an online magazine, a website that will contain articles. They will be written by various authors on various topics. So, we have a framework that allows us to store and edit the articles. We also have a front (home) page on which we show 'teasers', excerpts of the articles. The articles are shown based on which was most recently published. We can specify that an article is published (available for viewing), and that it can be selected by the framework to show on the front page. We can also specify that an article should remain on the front page until we remove it, which is known as making it 'sticky'.


Something Old,Something New

Let's take a look at the Drupal CMS in action. Drupal is the brainchild of Dries Buytaert, and is a shining example of what can be achieved with an Open Source project. I have created a fresh installation, named the site, and added two articles.

We can see that the CMS has lived up to it's promise (implied by the virtue of being a CMS), and we have a nice, clean layout, our two articles as teasers, well-positioned, and links (Read more) to pages containing the full text of each. The system works very well, and can provide a functional site with very little effort beyond installation and configuration. So, our magazine begins to accumulate enough content for us to want to have 'departments', each focusing on specific topics, or categories. With that done, we want a page for each department. The first of these will be 'Travel'. Great! Just a couple of points: How do we do what the front page is doing, on another page? Having that page how do we show only articles that are about travel? We can mark the articles as being about travel through the use of taxonomy terms, but how do we specify that we want to display only articles so marked? The short answer is, we can't. Not with Drupal right out-of-the-box.

[8]


Chapter 1

However, if that were the final answer, this would be a very short book. The fact is that many great ideas and decisions go into the making of Drupal. One of these was to make the install package as 'light' as possible. In other words, instead of bogging down the installation with tons of options that may or may not be used, have them available as add-on modules.

Creating a taxonomy vocabulary

First, we will create a vocabulary that will contain our department names. We'll set it so that its entries are created as tags when creating the article (Story). In the following images, we'll create a vocabulary and see the resulting screen that shows it.

The create vocabulary is now available for the addition of terms.

[9]



With our vocabulary created, we'll edit our travel article.

We will also add a tag to it, which we'll later use to identify this as a travel article.

We can see an immediate change on the front page, as a result of assigning a taxonomy term to our article.

[ 10 ]


Chapter 1

The taxonomy term is included in the display of our article teaser. All the pieces are in place and ready for us to create our View.

Views

Enter Earl Miles, also known as merlinofchaos within the Drupal community. There is a 'trinity' of modules available for Drupal that offer an amazing leap in functionality (he wrote two of them), and Views is one of those modules. A view is originally a relational database term, referring to a temporary arrangement of information in the database so that it can be presented in a meaningful way which is different than the underlying table layout. The Views module accomplishes the same thing, and provides the glue to tie itself in to the rest of Drupal and, especially, the ability to theme the result with templates. In other words, it gives you the ability to look at Drupal content in a way you would otherwise be unable to (without custom code). So, for example, our magazine can create a View that allows us to view content as we do on the front page, but with the selection of that content filtered in a way that we define, which in this case would be by department. In fact, let's do that.

[ 11 ]



Creating a View

In order to create a View, the Views module needs to be installed. Ours already is, and the details for that are given in Appendix A. We'll navigate to the Views page. Via the menu, it would be Admin | Site Building | Views. We'll use the URL, which is admin/build/views.

[ 12 ]


Chapter 1

The idea behind a View is to control the building of an SQL statement, in order to retrieve only the rows that we want. In this case, the rows will be nodes, which is why we created a 'Node View'. The following image shows the sections of the Views panel labeled as they relate to an SQL statement.

We want to select only the nodes that have the taxonomy entry of the department we want, which in this case will be travel. There are three ways we can accomplish this: 1. Filter: We can specify a selection filter (equivalent to an SQL 'where' condition) requiring the taxonomy term to be equal to 'department'. 2. Exposed Filter: The same as the Filter option, but exposing the filter to the user so that the value can be changed. 3. Argument: An argument also creates an SQL 'where' condition, but can be set externally to the View and passed in the URL. We're going to select the argument method. The reason is that in accepting an argument that defines the taxonomy term instead of specifying it in the View, we can create a page capable of showing any department. How will we get the argument passed? Simple. We'll get to that once we create the View. There are two filters that we do want to create. Even though we'll be accepting the taxonomy term as an argument, we still want to make sure that we're only selecting Story nodes and that the nodes are marked as published. Let's create the filters.

[ 13 ]



1. The filter selection is grouped by the source of data. We want the Node items, and we'll check the boxes for Node: Published and Node: Type.

2. When we add the filters, we will receive a settings window for each filter. In

the Node: Published settings, we're simply specifying that the node needs to be published.

[ 14 ]


Chapter 1

3. In the Node: Type settings, we are offered the existing content types from

which to choose. We want to select Story nodes only.

4. We'll define a sort next. With this View, we can define our requirements in

any order. That's not always the case. For example, if we were going to use a relationship, it would need to be defined before we could select any fields using it.

[ 15 ]



5. We want the travel articles to appear in the order of most-recent to oldest. We could select Node: Published date as our sort, but if an article is subsequently re-edited, the published date won't change, but we want it to move to the top of the list. So, instead, we'll use Updated date.

6. In the settings window we'll choose Descending, because we want the most recent date first.

[ 16 ]


Chapter 1

7. We'll define our argument next.

8. We're going to request a department by passing the ID of the department's taxonomy term (tid). We'll go into more detail about that when we finish defining our view. For now, let's select Taxonomy ID from the argument list. There are several choices that look similar, so be careful.

[ 17 ]



9. For its settings, we'll leave everything as it is. We are then specifying, by default, that if no argument is passed, all department articles will be presented, and if a department is requested that does not exist, a 404 page will be given. In our current context we don't really care about the handling, because we will be controlling what is requested. The one caveat would be if a taxonomy term was removed, but the menu choice for that department was not.

[ 18 ]


Chapter 1

10. Right now, the View is expecting that we will select individual fields to display (the SQL 'where' arguments). We have another choice, which is to have the node selected, and that is what we want to do.

11. We want to show teaser articles on the department page, as opposed to the entire article, so we'll make that setting.

[ 19 ]



12. At this point the View, in terms of the SQL component, is fully defined. We can scroll down to the Live Preview section.

Narrowing the selection

1. We see that we have article teasers showing, with links to view the entire article (the article title is one, and the Read more is another). Wait! Wasn't the whole idea to show the articles for only the travel department? What is the Taming the Shrew article doing here? We haven't provided an argument to our preview, and if you remember, when no argument is present, the behavior we defined is to show all articles. Let's supply an argument. We need to have the tid of the taxonomy term in order to use it as an argument. If we hover the mouse cursor over the term travel, and look at the link URL in the bottom of our browser window, we can see what the tid is.

[ 20 ]


Chapter 1

2. We can now enter the tid into our Live Preview window and see

what happens.

[ 21 ]



3. Now we just have the travel article teaser. If we scroll down a little further, we can see the underlying SQL query that was generated based on our settings.

4. The only thing left to do in the View itself is to define a path to access it. As strange as it may seem, at this point there is nothing to access. We have not actually defined a display entity for this View. In other words, right now there is no output we can access from outside the View edit. We need to create a display. If you look at the top left of the View panel, above the Add Display button, you see that Page is the current choice, which is the one we want. Another choice in the drop-down list is Attachment, which is what this book is about. We'll start using that choice in Chapter 2, Attachment Views—A New Beginning.

5. For now, we'll click the Add display button.

[ 22 ]


Chapter 1

6. We want to create a path, which is set to None right now.

7. We'll name the path "displays".

8. We can now save the View. The only thing left to do is create a way to invoke it.

Creating the menu choice

1. We set out to be able to display articles for the travel department, and at this point, that is the only taxonomy term that we've defined. We need to edit our menu and add a choice. The menu editor is at Admin | Site Building | Menus (admin/build/menu) and from there, we want to select the Navigation menu to edit.

[ 23 ]



2. We want to add a menu choice to this menu.

3. The important setting here is the Path, which we'll set to departments/1. This serves to invoke the departments path, which is the path alias to which we assigned our View, and also to pass the argument 1 to the View, which is the tid of our travel department.

4. We'll navigate back to the home page, and select our new Travel Department menu choice.

[ 24 ]


Chapter 1

This is an example of what a View can do for us. We can create further menu choices for various departments too. This is fine for showing all the articles for our Travel department. However, what if we want our department page to provide the user a list of articles from which to select an article to view? We could define our View to present fields, instead of nodes, and then the page would show a list of titles, but the page would name when the user selected a title, and they would have to click the Back button, or some such, to return to the list and choose another title. What if we want the list and the article to appear on the same page? Two separate areas communicating with each other? That is the secret of Attachment Views, and we will begin looking at them in Chapter 2. Here, we have one more thing to do, and that is to present our project site.

The project site During the course of this book, we will be creating a website. The website is part of an actual project, and the development is live and occurring in parallel with the writing of the book. With this chapter actually being written last—because it's declarative about the direction of the book, and it's always easier to do that in hindsight—I can say now that I wouldn't recommend this approach when the site is for a client. Minds change, business needs change, things get delayed (but deadlines don't), it can make things messy! That said, it hasn't been too bad, but be forewarned! The website is for Guild Builders, Inc. of Rancocas, New Jersey, a commercial construction firm. The site will be their first web presence. It will serve as an initial point of sales information for clients, and a primary point for initial information about opportunities for subcontractors interested in providing services.

[ 25 ]



The business functions to be addressed (and the resulting pages, in parentheses) are: •

A 'landing' area (home page)

•

A way to contact the company (contact page)

•

Sign-up capability for subcontractors (subcontractor registration and profile)

•

Information about jobs open to bid (jobs page)

•

Biographical information about Guild Builders staff (bios page)

•

Examples of prior projects (prior-work page)

•

Company information (about us page)

•

An easy way for management to view the above (control panel)

These would seem to be independent, as pages on a static site. However, we're going to kick it up a notch. If we look more closely, we can see that many of these are related: Prior Work to Bios (the project manager), Subcontractors to Jobs, About Us to Prior Work, and so on. What we're going to do throughout the book is use Attachment displays (I'll be using that term synonymously with Attachment views) liberally to provide a visual and structural linkage between the functions on the same page. So, for example, when we choose an example of Prior Work, we will be presented information about the job and information about the project manager all on the same page! The project site uses the current version of Drupal 6 (6.13 at the time of this writing... oops...make that 6.14...don't blink) and several add-on modules. The details of the modules and their configuration are given in Appendix A. We are also going to use a handful of custom content types too. Story and Page are the installed content types of Drupal. We have created some that contain fields suited for the type of content they are. The details of these are given in Appendix B. It's time for you to move on to Chapter 2, and time for me to write the appendices!

[ 26 ]


Chapter 1

Summary

In this chapter, we learned what Views are, and what a standard View can provide to us in functionality that Drupal, as freshly installed, cannot. We also learned what the project site will be, and how we can deliver its requirements through the use of Views, and in particular, Attachment Views. In Chapter 2, we will be creating the first View for our project site and our first Attachment display for a View as well.

[ 27 ]



Attachment Views–A New Beginning Looking at just about anything worth doing, a question will often arise beginning with the words, "How do I." Often the challenge can seem daunting. Then, one finally intuits, discovers or otherwise stumbles upon the answer and simultaneously is offered several alternative opinions, each being offered as the best way to accomplish the same goal. This is the case whether planning a vacation route, taking a photograph, or creating part or all of an application. There are a number of ways to accomplish what we will be doing in the chapter. If you spend any time on the Drupal IRC (Internet Relay Chat) channels, you will most likely receive varying opinions as to the best approach and, perhaps, come away more confused than when you started. Sometimes, there is no clear answer. One approach would be to write custom code. Another might be to use the Panels module. Each approach is valid, and has different pros and cons in terms of features, effort, learning curve, and time. Here, we're going to face each challenge in the same way, with attachment views, which means less coding, less time, and a smaller learning curve.


Attachment Views – A New Beginning

Here's what we'll do in this chapter: •

Learn what an Attachment view is

•

Learn what you can do with an Attachment view

•

Consider in what situations an Attachment view can be useful

•

Cover basic view theming

•

Create a Page view

•

Create an Attachment view

•

Theme the view

What is an Attachment view?

What is a view? We created one in the previous chapter. If you skipped that chapter, or if you're still a little fuzzy on just what a view is, consider (re)reading Chapter 1, but here is a summary. A view is the dynamic display of one or more pieces of related content based on one or more criterion.

What does that mean in practice? Let's consider a simple example. Let's say we have created a number of nodes of the content type 'Story' and assign one or more taxonomy terms to each. Having done that, we want to be presented with a list of teasers for each Story that has 'travel' as one of its taxonomy terms. It's a fairly common requirement. If you're familiar with Joomla!, for example, it could be accomplished by means of a Section or Category Blog page. The fact, though, is that the architecture that makes Drupal so extensible results in there being no manner in which to accomplish this using a core module. Enter the Views module, which will allow us to specify that we want a page on which we want to view x number of nodes, their selection based on certain criteria, which in this case will be nodes containing the taxonomy term 'travel'.

[ 30 ]


Chapter 2

That, in a nutshell, describes views at their simplest. Now, how about Attachment views? Well, to continue using the same example, let's say that our requirement has changed, and we don't always want a page based on every node having to do with travel, but want to be able to select destinations from a list of regions shown on the same page, as illustrated in the following figure. DESTINATION Africa Asia Australia Carribean Island Europe North America Pasific Island South America

Cebu

Hong Kong

Bangkok

Osaka

Chennai

The box on the left shows the available travel regions, each of which is a taxonomy term, with Asia having been chosen. The boxes on the right are node teasers, each of which has Asia among its taxonomy terms. How can we accomplish this? One method would be to code a custom page in PHP and display it. That would work, but it would also set the page in stone to some extent, bypassing the flexibility that Drupal provides. We could also create a menu of destination regions and put it in the sidebar as a block. That would work too, but the menu would not be dynamic, and would have to be edited each time a region was added, changed, or removed. One further option would be to have two separate views. How can we have two views though? We could create one as a block, but let's say that the design calls for the selection choices to be in the content area of the page. So, that means we need to find a way to have both views as content. Enter Attachment views.

[ 31 ]



Reviewing the view requirements

The business for which our website is being built is a commercial builder's. As with most construction businesses, subcontractors represent the major source of labor. On this site, Subcontractors will be the user type that will need to register, in order to subsequently review jobs and bid for them. There will be other authenticated user types, such as management, job supervisors and admin, but they will have user records created for them and will not need to register. Customers will be anonymous users.

To that end, a custom profile has been created for subcontractors, to capture the necessary information. We're using the content_profile module (see Appendix A) so that each subcontractor profile will be a node. We are going to have a menu from which the user will select a contractor for which the details will be displayed. For a given view, we can create various displays. A view to be displayed like a node will have a Page display—'Page' can be thought of as a web page—and one that is to be displayed as a block will have a Block display.

[ 32 ]


Chapter 2

Considering our menu of subcontractors, and the display of a subcontractor's details, in conjunction with the terms 'Page display' and 'Attachment display', the reasonable inference is that the Attachment view will be the menu-style list of subcontractors, and the Page display will be the subcontractor details, the page being larger than an attachment, and the details being larger than the menu. However, that's not necessarily the case, and in subsequent examples we'll invert that assignment of content to display. The description of the subcontractor list may bring the thought 'Block' to mind. Often a block can be used in place of an Attachment display, and in fact, the option to create a Block display in the view is just one selection away from the Attachment type. We're using Attachment displays rather than Block displays because Attachments are not as entity-like in their construction, and are easier to place anywhere within the page content than Blocks, which are more easily placed in regions adjacent to the content area. Attachment views do not include paging as do Page views. We are only going to be showing one subcontractor's details at a time, so there is no paging issue there. However, when we list the subcontractors to select from, there could be dozens, or even hundreds, and that will require us to have paging available for that display, so the Page display for our view will be the subcontractor list. We'll build that first.

Activity 2-1–Subcontractor page view

The Subcontractor page will allow the user to view the details of a subcontractor chosen from a dynamic list. That is, the list of subcontractors will not be something separate that requires editing whenever a subcontractor is added or removed, and the list will be in the content area of the page and not in a navigational menu.

[ 33 ]



1. Let's create a new view. We're going to create a node view named subs, as shown in the following screenshot:

2. Click Next and the Views panel is presented. The panel will allow us to customize the view settings. We'll start by creating a Page display for the view. The Views page will always attempt to provide you with a real-time preview based on your settings. Often, the settings are being established in an order that is not conducive to creating the preview, because some information is missing. In that event, you will see a pink warning about this, for example, Fields is the display type but no fields have been chosen. Use the warnings as a way to tweak your memory about what you have left to do, but don't worry about them, as long as there are none remaining when you think you're done. [ 34 ]


Chapter 2

3.

We'll click on Title and change the view title, as shown in the following screenshot. Click Update default display when you are finished.

4. Let's look at some of the other configuration options in Basic Settings. Leave the style settings as it is. A style plugin isn't needed, because the view will eventually be themed, and since it will only be showing one record it doesn't require a table or grid. We'll also leave the Row style set as Fields, as we want the profile data to be displayed as a vertical list of fields. Again, changes can be made when the view is themed. We won't use AJAX at this time. We do want to use paging with this display. It's likely that the subcontractor list will be large, and so we'll only want a small amount being shown at one time. We'll change the Use pager setting to "yes", and from the config options choose Mini pager.

[ 35 ]



5. Leave the More link setting at no, we don't need a More link, and likewise, since each record is a separate subcontractor node, we're not concerned about unique records. 6. As this view is meant only for use by the management of Guild Builders, we'll want to restrict access to it. Change the Access setting to restrict access to a specific role.

A role called management has already been created for use by the management staff of Guild Builders. There will probably be more roles added later, such as one for staff and another for the subcontractors themselves. 7. We'll assign access to the management role.

We won't be caching the view, nor exposing the form in a block, so we'll leave the settings caching at one and expose form in block at no. There will be a page header and footer, but they can be added later. Empty text won't be an issue, because the node selection will come from a list based on existing nodes. That takes us to the end of the Basic Settings pane. Let's move on to Sort criteria. 1. We want the subcontractors to be shown in alphabetical order, so sort on Node title, which is the subcontractor name.

[ 36 ]


Chapter 2

The sort order will be set to ascending.

[ 37 ]



2. Next, we will look to the Filters pane. We only want to select Subcontractor nodes (described in Appendix B), so filter based on node type.

3. We need something to be shown in this view display, so select Node: Title in the Fields settings.

[ 38 ]

Chapter 2

4. In the subsequent dialog, specify that the value of the field will be output as a link, and point that link at the view path, with the contractor being used as ID. We'll use subs/ as part of the path for two reasons: to associate the content with the subs content type, and to make it easier to identify the intent of the path if we ever need to write module code to act based on the path. That is, the path makes it easy for the code to identify it as being subcontractor content.

[ 39 ]


5. The final thing to do in this display is to define the path.

6. With our view display complete, save it, and then test it. First, we'll run a quick check on it to make sure there aren't any configuration errors, by clicking the Analyze button.

The View analysis returns good news.

7. With no errors discernible, we're ready to preview. Looking at the Live preview section, we might already see preview output from our view, but we want to ensure that the expected output will appear for the Page display. But the preview normally shows the default display output unless changed.

[ 40 ]

Chapter 2

We'll need to theme this display later, so that it appears where we want it to on the page, but it's fine for now. We had created two test subcontractor records in advance, and both are listed. There's no sense clicking the links at this point, since what we need them to load is the display we're about to create. Next!

Activity 2-2–Subcontractor Attachment view

1. Let us begin by creating the Attachment display for our current view.

Remember to click the Override button when changing any settings for this display, so that they are only applied to this display and not the others!

2. In the Basic Settings pane, the only change to make is to set Items to display to 1, as we will be showing only one subcontractor record at a time.

[ 41 ]


3. Move on to the Arguments pane. We want to be able to supply this display with an argument, so that it will show us a specific subcontractor profile. Click on the + icon, and scroll down through the field list to add Node: Title. Remember, we're using the content_profile module, so each subcontractor profile will be a node.

Titles in custom content types In our custom content type, subcontractor, the label of the title field of the node creation form was changed from Title to Company. However, that doesn't change the internal field name, so when using that field as an argument or filter in a view, the field will still be selected as Node: Title.

The way an argument works is that it is appended to the URL when requesting the page. So, for example, the URL for our view, when live, will be http://guildbuildersinc.com/subs. To request the view showing the subcontractor Acme, the URL would be http://guildbuildersinc. com/subs/acme. Drupal will separate the argument from the rest of the URL, and pass it to the view processor as an argument array, $args. Key 0 of that array will be the argument count, and key 1 will be acme. This way, the view subs will know that it was called with the argument 'acme.'

[ 42 ]

Chapter 2

4. Adding the argument brings up a subsequent dialog. We want the title of the view to show as the subcontractor company name. Since that is the first (and only) argument, and thus is in position 1 in our argument list, put '%1' in the Title field to indicate that argument 1 will be used as the title. Remember, argument 0 is always a value indicating how many arguments are present in the URL. The first true argument in the second position, but we count from 0. So, for example, if our view took two arguments, first and last name, Joe Smith, the array received in the view would contain a 2 in array subscript 0, indicating two arguments are present. Subscript 1 would contain Joe, and subscript 2 would contain Smith. Specify that an empty page be displayed if either the argument is omitted or does not validate. Check the transform spaces to dashes in URL box, so that when the page URL is produced Acme Contracting becomes acme-contracting instead of the acme%20contracting we'd see if spaces remained in the name.

[ 43 ]


5. We had left the Row style as Fields, and now we need to identify which fields we want. Click the + in the Fields pane, and then check the boxes of the fields we want. Select all the Content fields (these are the custom CCK fields created for the Subcontractor content type—see Appendix B), as well as the user e-mail field. 6. We're asked whether we want to change the way the field data is handled. For most fields we won't want to make any changes, so just click Update for each one.

[ 44 ]

Chapter 2

7. We have a website field (field_website), which gives the URL for the subcontractor's website. Set this field to be displayed as a link, and enter a token, from the list of tokens presented, to use this field's contents for the link destination.

8. Next, we'll move on to the Attachment settings pane that we need to change, which is the Attachment settings pane. Specify that our Attachment display should be attached to the Page display.

[ 45 ]


The last thing we'll do to this display is reorder the fields. Right now they're in the same order that they were in when we checked the boxes, which is not the order in which we want them displayed. Click the up/down arrow icon next to Fields, and drag each field into the position we want, and then click Update.

9. That completes the construction of our primary view. In the following screenshot, we can see the changes we made reflected in the view summary pane.

[ 46 ]

Chapter 2

10. We're ready to preview the view and make sure the display is what we're expecting. First, enter the name of the test subcontractor into the preview argument field and make sure the Page display is selected.

11. Lastly, enter the URL into our browser and check the view with the theme.

[ 47 ]


Theming the subcontractor view

By looking at the previous screenshot, it is apparent that the presentation is far from being user-friendly. The list of subcontractors and the subcontractor details appear to be one large list, and this is with only two subcontractors in the list. Add a few more and the details will be pushed right off the visible page. We'll need to improve on this, and we can do it by theming our View. The thought of theming gives many people the shakes. While it is certainly a complex topic, we don't need to consume it in its entirety. Let's just work with small pieces for now. We'll do more theming throughout the book.

The makeup of a theme

A full theme is basically a combination of some or all of the following: •

One or more template files

•

A CSS file, or several

•

A set of functions

•

Supporting files

We won't be creating a full theme. We will just be adjusting the existing view theme somewhat. We need to simply create one template file, not even from scratch, and a few entries in one of our theme's CSS files.

Selecting a template file One of the most confusing aspects of theming to most people is the selection of (and naming of) the appropriate template file. I'll try and remove some of the mystery and headache for you. There are essentially four layers of output in our Node View. The specifics will vary based on selections made when defining the View, such as whether the style is Rows, Table, Grid, and so on. Let's focus on this view, but keep in mind that some of the following information will vary in subsequent views: 1. Fields: Things such as the subcontractor name, phone number, and so on. 2. Rows: Each node can be displayed as a 'row' of one or more fields.

[ 48 ]

Chapter 2

3. Styles: The output prior to styling being applied to it. 4. Display: The complete view, already formatted in sections, such as the Attachment, Page, Pager, More link, and so on. In deciding a name for the template file, the first step is to identify at what point we need to 'interrupt' the process and insert our requirements. We need to alter the formatting of one field, but only one, and we will do that via CSS. We don't need a template file for that. So, what do we need a template file for? We have two displays: the Page display containing the subcontractor list and the Attachment display containing the subcontractor details. We need to separate the two displays. The format of each display is acceptable as it is. That is, we don't want to change the way either display looks, we just want to take each en masse, as if it were a block, and affect its positioning in relation to the other. So, we can rule out the Field-layer templates, because we're not doing any formatting at the field layer. Likewise, we can eliminate Row-layer templates. Since we're not concerned with restyling the content of our displays, we will have no need for a Style-layer template. That leaves the Display-layer, and that is what we'll need. Note that you can select more than one template layer. For our current need, we're only working with one layer, but depending on the needs at the time, there could be one or more template files needed for one or more layer. So, we've decided we need a Display-layer template file. What do we do next? Well, here, the View panel can assist us. If we look at the bottom of the Basic settings pane, we will see Theme: Information. Normally, I'd recommend that you make certain you've selected the correct display before clicking the Information link, because the theme information is usually relevant to a specific display, but since we're going to be working at the View level, and not within a certain display, the current display is not a concern.

[ 49 ]


On clicking the Information link, we are presented with the information shown in the following screenshot.

This is usually where people's eyes start to cross or glaze over, followed by the shaking. First, look at the highlighted paragraph headings (which will be blue on your screen). The first is related to Display-layer theming, then Style-layer theming, Row-layer, and then a paragraph for each field in the Field-layer, with the Node Title field (the field that contains our subcontractor name) being the first in the list. At this point we're only concerned with the first paragraph, Display output. Following that highlighted identification in each paragraph is a series of template file names. If you have not done any theming with the View, the first will probably be bold. The bold filename indicates which file will currently be used to theme that layer. The filenames progress in each paragraph from the least specific to the most specific. That is, in looking for the first time at the initial paragraph, the first file is views-view-tpl.php. This file affects every view in your website. If you were to create your own version of the file and put it in your theme directory, it would then affect every field in every view displayed using that theme. [ 50 ]

Chapter 2

Now look at the highlighted filename in that paragraph: views-view-Subs-attachment-1.tpl.php. Wow! That's a long one, though the file-layer names are even longer. Ok, let's break it down and clear and uncross those eyes: •

views: This template is being used with a view

•

view: This template affects views at the individual view level

•

Subs: This template affects only the Subs view that we created

•

attachment: This template affects only the attachment display of the Subs view

•

This template affects only the first attachment display of the Subs view

We're going to create a template file that will affect the Subs view, and therefore, the name will be views-view—Subs.tpl.php. How do we create it? The good news is that we do not have to create the file from scratch. There are example files that we can modify, rename, and save to our theme. The location of these files is in the views module directory, which, depending on your site, will either be located at sites/all/modules/views/theme/ or modules/views/theme/. The following screenshot shows a list of the files available there to be copied.

[ 51 ]


We will choose the file that is listed first in the Theme: Information paragraph that represents the layer we're working with. That will be views-view.tpl.php. Let's get to it!

Activity 2-3–Creating the view template file Inside the file, we look for mention of attachments and rows, which is the data we need to separate, and find the following:

The variable $rows contains the contents of our Page display. $attachment_before or $attachment_after contains the output of our Attachment display, in this case, $attachment_after. What is happening here, with each set of

This block of code checks whether we have a Page display and at least one Attachment display. If so, it creates a container around those displays. We also need to end the container following the block of code that handles the $more link:

This block of code performs the same test as the first that we inserted, and if it determines the conditions are met, it inserts the instructions to turn off floating, and then closes the container. We need to turn off floating because we will turn it on via CSS in order to have the two displays side-by-side instead of one above the other. That's it. Now we just save that file in our theme directory, in our website sites/ all/themes/acquia_slate/, and name it as we discussed above, views-view-Subs.tpl.php. With that out of the way, we can move on to the CSS changes. Our theme uses a style.css file to handle positioning and formatting. It also has a local.css file in which overrides to the styles defined in styles.css are placed. In this way, if a newer version of the theme is released, we can update the style.css file without losing the changes we put in local.css.

[ 53 ]


CSS Files Each theme comes with its own supporting files, including CSS files, and they are defined in the theme's .info file. The theme being used for this site, Acquia Slate, comes with the local.css file.

The following are the things that we want to accomplish with our CSS changes: 1. Have the two view displays appear side-by-side. 2. Provide some demarcation between the two using spacing and a border. 3. Format the subcontractor name to stand out from the rest of the subcontractor details. To have our two displays appear side-by-side, we will add the following entry: .view-id-Subs .view-content,.view-id-Subs .attachment{ float: left }

The first thing to note is the selectors. The content of our page display is shown in a division with the class view-content. We could have a selector of just .viewcontent, but that would affect every view-content class on every page of the website. We further qualify our selection by specifying that we only want the viewcontent class that is nested within the div with a class of view-id-Subs, which limits this selection to our Subs view. The same is true for the class attachment, which contains the content of our Attachment display. Having selected them, we specify that instead of the normal behavior for a , where a new one begins on a new line, we want the content to float to the left, side-by-side. Having caused the two displays to appear side-by-side, we have the issue of there being no white space between them. Users need white space to imply boundaries, and to give the eyes a moment's rest while reading. Our next entry will add a right margin to the subcontractor list. .view-id-Subs .view-content { margin-right: 120px }

The next entry places a vertical border beside the Attachment display, to set the subcontractor details off from the rest of the page. .view-id-Subs .attachment { padding-left: 1em; border-left: 1px solid #dfa155 } [ 54 ]

Chapter 2

The remaining two entries are for formatting the subcontractor name. One adds a bottom margin to the that wraps the subcontractor name, and the other increases the text size of that name, makes it bold, and displays it as uppercase. .view-id-Subs .attachment .views-field-title { margin-bottom: 6px; } .view-id-Subs .attachment .views-field-title .field-content { font-size: 120%; font-weight: bold; text-transform: uppercase; }

Having made our template and CSS changes, we need to force Drupal to evaluate the new template file. Drupal caches the theme, and would ignore the fact that we've added a template file if cache were not cleared. Whenever a template file is added or deleted, Drupal's cache needs to be cleared. Subsequent edits to the template do not require the clearing of cache. The button to clear the cache can be found at admin/ settings/performance, as shown in the following screenshot.

The fruits of our labors can be seen as follows:

[ 55 ]


Summary

We learned what an Attachment view is, and how it can be useful. We created a view with a Page display, and added an Attachment display to provide added functionality. We also learned a little about theming a view by creating CSS and a template file. We're off to a good start, and have several more examples of using Attachment views in different situations ahead. Let's move on to Chapter 3, Interactive Page Regions, where we'll use an Attachment view for adding isolated functionality to a "Contact Us" page, and create a small module to modify the standard Contact form.

[ 56 ]

Interactive Page Regions Drupal has a built-in Contact subsystem that can be used to send messages to site members. Our website won't be used like that, but there is a need to provide the typical contact-us mechanism where users can send a message to the site owner, but with a few extra features. In this chapter, we'll be continuing with using an Attachment view in conjunction with the page view. We're going to add a little twist, though. Sometimes, the functionality we need isn't readily available by means of a view, even with an Attachment view. That's the case in this chapter, where we'll be souping up the site's default Contact Us feature. We'll still be using an Attachment view, but simply for displaying dynamic material along with the primary view. There won't be any interaction between the Page and Attachment displays—the additional functionality will come from modifying an existing Drupal service by way of a small custom module that we'll create. We'll be using some add-on modules in this chapter—Contact blocks, Captcha, Util and Embed_gmap, as well as a custom content type, Location. You can find more information on these in the appendices. In this chapter, you will learn the following: •

How to configure Drupal's Contact system

•

What the default Contact system does (and does not do)

•

How to add just a little pizazz to a page with an Attachment view and a module

•

How to add the Contact form to a view

•

The first steps you need to take with Drupal's module architecture and hook mechanism

Interactive Page Regions

•

How to modify the Contact form via a custom module

•

How to use an add-on module to make the Contact form available in a view

•

How to create an Attachment view

Lots to do—let's get started!

Activity 3-1–Configuring the contact subsystem

1. Navigate to the Contact form admin page (admin/build/contact) and click Add category. The Contact module is installed with Drupal, but is disabled by default. This step requires that the Contact module be enabled.

2. The Contact form will open. The information that we need to provide in it is a title in the Category field, an e-mail address in the Recipients field to which the contact e-mails should be sent.

[ 58 ]

Chapter 3

3. We've made a contact form available. Normally, the form would be shown on a page of its own, but we need the form to be shown in a view, and will eventually point our menu choice to the view instead of the normal contact page. The contact form isn't a node, feed, or any of the typical constituents of a view. So, how do we bring it into one? There are different approaches, but the easiest will be to use another add-on module: Content form blocks. We'll navigate to its administration page under Settings (admin/settings/ contact_form_blocks). This step requires that the Contact form blocks module be installed. Information about this module can be found in Appendix A and at http://drupal.org/project/contact_form_blocks.

4. The Contact module allows you to create categories of contact, such as feedback to the administrator, contact between users, and so on. On this site, the only contact that will be enabled is from users to the site owner. There's not a whole lot to configure here, since we only have one category of contact configured, but this is where you select which contact category will be available as a form inside a block. The following screenshot shows this configuration form ready to be saved.

5. Having saved that information, the module will have created a block for our use in the contact-us view. Go to the list of blocks (admin/build/block) and see. Remember to scroll down to the Disabled section of the list to find the block, because it's not been assigned to a region yet. Because we named the contact category General, the block will be called Contact form: General.

[ 59 ]


6. We want to assign the block to appear in the content area of our page, but the theme we are working with has not exposed Content as a region for our use. Let's change that. In the directory sites/all/themes/acquia_slate is the file acquia_slate.info. Edit it. 7. There is no mandatory order within a theme's .info file, but they are small enough that you should be able to find what you need at a glance. Look for a group of lines that each begin with the word 'regions,' as shown below: regions[sidebar_first] = sidebar first regions[sidebar_last] = sidebar last regions[banner] = banner regions[header_top] = header top regions[header_first] = header first regions[header_middle] = header middle regions[header_bottom] = header bottom regions[preface_sidebar] = front preface sidebar regions[content_top] = inner content top regions[content_bottom] = content bottom regions[postscript_first] = postscript first regions[postscript_middle] = postscript middle regions[postscript_last] = postscript last regions[footer] = footer regions[node_bottom] = node bottom

8. Each of those lines defines a region to which blocks can be assigned. We need to add one. Between the regions[content_top] and regions [content_bottom] lines insert the following: regions[content] = content

9. Save the file, and then go to the Performance page (admin/settings/ performance) and click the Clear cache button. 10. Return to the blocks page and assign the Contact block to the Content region, as shown in the following screenshot, so that it will appear along with our View content.

[ 60 ]

Chapter 3

11. We need to configure the block, otherwise it will appear along with every piece of content on the site. We'll click configure, and set the block to appear only on a specific page, as shown in the following screenshot. We'll need to provide the path of that page, but it doesn't exist yet. Luckily, the block administration does not validate the path. Since we'll have to do it at some point anyway, we'll create a name for our eventual view, contact-us, and use it here.

With the contact form now being hooked into a block, and the block configured to show in a single view, we need to create that view so that we can see the contact form.

[ 61 ]


Activity 3-2–Creating the contact-us view 1. The contact-us view we're going to create is simply going to be the glue for our pieces. By using a content type to provide contact information on the page, the site owner can easily have different versions of the page to use at different times of the year (like Google does on their home page) simply by creating a new node of the Location content type and having the desired one enabled. The view will make use of that content. Go to the views page (admin/build/views) click Add, and choose to create a Node view.

2. At this point, we're not interested in configuring the view to provide any content. In fact, what we want to do is prevent it from showing content. The reason is that the block we created, which will contain the contact form, will appear in the content region of the page showing this view. We don't need any other content at this point. However, we cannot save this view as it is, because, by default, the Row style is set to Fields, and we have no fields selected. So, click on Row style and change it to Node. 3. Having changed the Row style to Node will allow us get past the problem of not having defined any fields, and will allow us to save the view. However, that setting without any filters in place will cause the view to select every node, whereas we want it to select none, for now. There is no filter choice for Null display, but we can accomplish the equivalent easily. Select the filter Post date and set it to a date for which we know there are no posts. 4. Lastly, we want to create a Page display and assign a path to it, so that we can access the view. Name it contact-us.

[ 62 ]

Chapter 3

5. The view is ready to save. The panel settings are shown in the following screenshot.

[ 63 ]


6. With our skeletal view saved, navigate to its path (contact-us) and get a first look at the current contact form, as shown in the following screenshot:

The location information isn't displayed at this time, because we have not yet created that content. The important thing here is the contact form. The site owner wants to capture when someone completes the form, which would not be available given only the form's current fields, namely Company, Street address, and Phone. There isn't an admin mechanism for adding fields to the contact form, but there is a relatively easy way to do it, once you know how, and that's by creating a module.

[ 64 ]

Chapter 3

What's a Module? A module is how we can add our own logic to what Drupal does- to add extra functionality, or to alter the behavior of Drupal's existing functionality. With some web applications, the only way to do this is to change the existing code ('core' in Drupal parlance). The problem with that is that when a new version of the application is released, not only will those changes need to be made again to the new version, but in some cases the code you originally changed will be different in the new version, so that the changes you made originally cannot be made in the same way. Fortunately, Drupal's module architecture and the ability to hook into its events remove any need to change the core code.

Let's create a module!

Activity 3-3–The Guild Builders module

Creating modules is the stuff of a book in itself. So, we're not going to approach it as a soup-to-nuts narrative. Instead, we'll go through the steps of creating our module, which will give you the basic knowledge that you need to decide whether you'd like to investigate the topic further. A module typically has up to four core files: the file core to its functionality (the .module file), a file that describes the module to Drupal (the .info file), a file that provides installation and removal instructions to Drupal (the .install file), such as for creating database tables, and sometimes included files to separate out functional parts of the module (.inc files). Our module will only require the former two. 1. Creating the .info file. Open a text editor and add a few lines. name = GBI Custom

2. This line defines the name of the module as it will be displayed in the modules listing in admin. package = Guild Builders Inc.

3. We could omit this line, which would cause the module to be located in the other section of the modules listing. However, we want it to appear in a section of its own, and this line provides a title for that section. description = Custom functions

4. The description line provides the descriptive text that appears alongside the module entry in the modules list. core = 6.x

[ 65 ]


5. The core entry specifies which major version of Drupal the module is meant to work with, such as 5.x, 6.x, or 7.x. version = "6.x-1.0"

6. Finally, this line specifies the version of our module. It's meant to work with Drupal 6.x and is the first version of our module, and since we will not be releasing a pre-release version (0.x), we'll make it version 1.0. 7. Our file now looks as follows: name = GBI Custom package = Guild Builders Inc. description = Custom functions core = 6.x version = "6.x-1.0"

8. We need to create a directory in which our module will live. We already have the path sites/all/modules in which add-on modules are placed. First, create the path _custom, in which to put our own modules, so that we can find them easily. Put the underscore at the start of the name so that it appears first in the directory list. 9. Next, add the path guildbuilders as the home for this module. So, we now have the path sites/all/modules/_custom/guildbuilders, save our text file to that path as guildbuilders.info.

Creating the .module file

1. Open a new blank document in a text editor. Begin this one with an opening php tag, since the module file will contain php script.

8. With just that little bit of code, our display now looks like the following screenshot.

[ 132 ]

Chapter 5

9. We want to put some spacing between the employee name and the title above it, the image below it, and have the biography wrap around the right side of the image. Lets add some directives to our CSS file. The results are shown in the screenshot following the code. /* BIOS */ .view-bios .title { margin: 12px 0 } .view-bios img { margin: 12px 1em 0 0; border: 1px outset gray; } .view-bios .field-bio-photo-fid { float: left; } .view-bios .body { float: left; width: 240px } .view-bios .bio { width: 75% } /* !BIOS */

[ 133 ]

Bios

10. Our final step is to theme the display arrangement. Right now, the two lists appear one atop the other beneath the bio. What we want is for them to appear inside boxes, one atop the other, to the left of the biography. For this, make a copy of the file views-view.tpl.php from the sites/all/ modules/views/theme, name it views-view--bios.tpl.php and save it in our themes directory, sites/all/themes/acquia_slate. 11. The contents of this file, minus the comments, are as follows: [ 134 ]

Chapter 5

12. We'll just move the attachment-before section to follow the attachment-end, and add some div tags with floats. We're cheating somewhat by putting formatting statements in this file. It would have been better had we done it at the display level, but with only one row in our Page display, and because we're trying to keep the theming simple, we'll shove it all in the one file. The changed code is as follows, and the results are shown in the screenshot following the code. style="float:left"> [ 135 ]

Bios Previous Projects

[ 136 ]

Chapter 5

13. Our last step is to add to our CSS file to provide some spacing and outlines for our two lists. An image of the final result follows the code. .view-bios .attachment-after, .view-bios .view-content { margin: 12px 1em 0 0; border: 1px solid #4b4b4b; }

Summary

We created a Bio view with three displays, two Attachments and one Page. We learned to use relationships with a view, and how to do basic theming. In Chapter 6, we will do something similar to this chapter. We will again use the Bio and Job content types, but this time, the Job content type will be the focus, and our view functionality will be slightly different.

[ 137 ]

Prior Work In this chapter, we will again develop a 3-view composite display, using the same two custom content types as in the previous chapter. However, the focus of the page, this time around, is examples of prior construction work. In this chapter, you will build a view containing the following: •

A display from which to select prior work

•

A display that shows a bio of the prior work's project manager

•

A display to show the selected job

You will then create templates for formatting the view displays.

Activity 6-1–Creating the job selection display

We could simply export the Bios view, change the name, import it as this view, and make some changes. Instead, to practice our skills, we'll create the entire view from scratch.

Prior Work

1. Create a new view, which we'll call prior_work.

[ 140 ]

Chapter 6

2. Let's look at the default settings. We'll change some settings here that will apply to at least two of our displays, so that we have a few less later to set individually. Start with the sort, which will be based on the date the node was posted (Node: Post date). We'll sort descending, so that the most recent jobs are listed first. We'll set the granularity to day, because in the context of ordering job titles, it's unlikely that two jobs will have been posted on the same date, and even if they had, which one comes first is of no consequence.

[ 141 ]

Prior Work

Granularity allows us to say, "Consider everything the same beyond this level of detail", when comparing the dates and times of nodes.

3. With the sort settings complete, we'll consider the filter settings next. We want to select Job nodes, which means filtering based on node type. We also want to make sure that the node is published, and that the CCK field, Display completed job, is enabled. The node fields will be found among the fields prefixed with Node:, and the content field among those prefixed with Content: in the Add filters list. The following screenshot shows the three filters selected, but they appear together as the result of image editing. Filtering If you prefer, you can cut down on the amount of scrolling needed by selecting Content and, afterwards, Node, from the Groups select list, which itself filters the list of available filter choices.

[ 142 ]

Chapter 6

When the field you are selecting as a filter is a custom field defined with allowed values, you will find two choices for the filter, one like other listed fields, and the other with – Allowed values appended to the description. Selecting the former will require that you enter what the filter test (value) needs to be, which means remembering what the allowed values are. Selecting the latter results in a display of the allowed values from which you can select.

[ 143 ]

Prior Work

4. For each of the fields we choose as filters, we will need to specify the value(s) that the field must have to qualify. The first will be Content: Display completed job. We want only records containing the 'on' value of this field, which in this case is Display completed job.

5. The next field is Node: Published, and with it, we want to ensure that the node is, indeed published, because 'unpublishing' the node is the method used by the content administrator to prevent the node from being shown to users.

[ 144 ]

Chapter 6

Content Administration We won't be covering most of the basics of Content Administration in our examples, because of the target audience for this book. However, if more information on that topic interests you, see Packt's Drupal 6 Content Administration in the appendix.

6. The final field in our filter list is Node: Type, which we will use to limit the node selection to Job nodes.

[ 145 ]

Prior Work

The following is a screenshot of the resulting default settings for our view.

Activity 6-2–Creating the prior-work Page display

We're done with the default view, next we'll create our Page display. This will be used to produce the list of prior work from which the user can select. It will always have content, while the portion of the web page that shows the details will only show such content once a selection has been made. The details section is larger than the list, but its content is subordinate to the content of the list, and that makes the list a logical choice for a Page display, and the details for an attachment display, since an 'attachment' implies something subordinate.

[ 146 ]

Chapter 6

1. The first setting to make for our Page display is the path. We want the URL for the view to be prior-work.

2. Title the view Previous Projects.

3. We're going to want to offer paging, since we're only showing up to 10 titles in the list, and there will be more than that many prior jobs. Don't forget to click Override, so that the pager setting only affects the Page display. We'll offer full paging, since the mini pager is confusing to some people. At this point, I don't think there will be any other elements on the page that have a pager associated with them, so leave the index for this one set at 0. If it doesn't appear on the page when we test, we can come back and change it to another number at that time.

[ 147 ]

Prior Work

4. So far, we've specified how to select rows—via our filters—but not any information to be displayed from them, and the warning messages in the Live Preview area are a constant reminder of that. Let's fix that. The fields that we'll select are the node ID (nid) and the node title.

[ 148 ]

Chapter 6

5. The only field we need to display is the node title, which, in our Job content type, is the name of the Job (see Appendix B). We need the nid for use in the next step, but not to display. Remember to click Override before submitting.

6. We're going to have the title presented as a link. We'll elect to 'Output this field as a link', rather than 'Link this field to its node', because we don't want the link to take us to a display of the node, we want it to reload the view, passing the ID of the selected node as an argument, so that the view will load the selected job into an Attachment display. We know the URL of this view (we set it earlier as the path), but we need the nid appended to the end of the URL as an argument. The way we do this is to include the replacement pattern for the nid at the end of the URL.

[ 149 ]

Prior Work

My field isn't in the replacement pattern list If a field you've selected appears in the field list, but not in the replacement pattern list, it is probably because it appears in the field list after the field that needs it as a replacement pattern. When the replacement pattern list is constructed, only the fields that appear in the field list prior to the current field will be listed. You can remedy this by clicking the up/down arrows icon in the Fields box. This will give you a dialog window in which you can change the listing order of the fields.

[ 150 ]

Chapter 6

With that done, we've finished the Page display. Confirm it with a preview and by hovering the cursor over the link. In the following screenshot, you can see that the node title is output as a link, and that the URL of the link is our current view with the nid appended.

The following screenshot shows the settings for the completed Page display.

[ 151 ]

Prior Work

Activity 6-3–Creating the prior-work Bio Attachment display

This attachment display will be used to present the biography of job's project manager, if available. It will be an information-only display, offering no interaction with the user; a more classical use of an additional display. 1. Create the display.

2. Edit the display's name, so that it can be easily discerned from the second Attachment we'll be creating.

3. This display will need to show only one record, so change the Items to display setting to 1, remembering to click Override first.

[ 152 ]

Chapter 6

4. Declare which display this one will be attached to, which is the Page display.

5. Move over to the sort section next, and remove the sort, making sure to click Override before we click Remove. 6. We will be selecting the appropriate Bio node based on the Job node, and since this will assure the precise selection of one node, the only filter we'll need is to check that it's published (even though it's the correct node, if the admin unpublishes it, it should not be shown).

[ 153 ]

Prior Work

7. We're using two different content types, Bio and Job. Each project manager has a Bio node, and each Job node contains the name of the project manager responsible for that project. We need to retrieve the bio of the project manager listed in the Job node, so that the Bio of the project manager responsible for the project is shown. This means that we'll need a relationship defined between the two nodes, so let's do that. The relationship will be to the Project Manager field, which is in the Job node.

8. The relationship says that we will select the Bio node based upon the value that is in the Job node's project manager field, which is the Bio node ID. How, though, do we select the proper Job node? There is one Attachment display left to do, the one that presents a specific Job. That display will accept an argument, the Job nid. In this display, we want to inherit that argument and use it to identify which Job node we need, because even though we want the same Job node that the other attachment will be using, we could just as easily have a View where we do not want to use the same node, so the selection is not automatic. Change the Inherit arguments setting in Attachment settings to inherit, and click Update.

[ 154 ]

Chapter 6

9. Next, click the + icon in the Arguments box, and scroll down to Node: Nid (selecting Node from the drop-down will speed that up).

10. In the subsequent argument configuration window, no changes are needed. Simply click Update.

[ 155 ]

Prior Work

11. Next, go to the Fields section and edit the Node title field, remembering to click Override. First, select the Project Manager relationship from the Relationship dropdown. Next, clear the checkbox that output the field as a link. In the Bio display, the title, which is the project manager's name, will not be a link.

12. The final field is the employee's image, which is the Photo field in the bio record (field_bio_photo). Click the + icon in Fields to add a field, and scroll down to it in the Content section. Be sure to choose the Photo field and not the Photo-data field.

[ 156 ]

Chapter 6

13. Choose Project Manager from the Relationship dropdown, and thumbnail image from the Format dropdown. The format choices reflect the presets in the Imagecache add-on module configuration, which can be used to size an image on the fly. Set the label to None, and click Update.

[ 157 ]

Prior Work

14. Click the up-and-down arrows icon next to Fields, and place the node title under the image.

That completes our Attachment view. The only thing left to do is test it. We'll do a preview on the page display, providing it with a test argument, let's say 7.

The following screenshot shows the settings for the completed Bio display.

[ 158 ]

Chapter 6

Activity 6-4–Creating the Job Attachment display

The final display in our view is the one that will display the detail of the job. The content type was designed to be dual-use, holding the information necessary for a job in the bidding stage, as well as a completed job being shown as reference work. The display will show the fields.

[ 159 ]

Prior Work

1. Name this display Job Attachment.

2. We'll be showing only one node at a time with this attachment, so change the Items to display setting to 1, making sure to override the default.

3. In the Position setting of the Attachments box, change the order of this display to After, as we already have the Bio display set to Before.

[ 160 ]

Chapter 6

4. We need to attach this display. Attach it to the Page display.

5. This display will select a node based on a passed argument, so we need to define that argument. It will be the nid of the desired node.

[ 161 ]

Prior Work

6. Specify that if the argument is absent, an empty text message should be displayed.

[ 162 ]

Chapter 6

7. Since we've specified the use of empty text, we should define that text. We'll theme it later.

8. The last things to set on this display are the fields. We already have the Node title field, since we defined that as a default. We'll add the other fields that are needed, which, besides the Node body, are Content fields.

[ 163 ]

Prior Work

9. The only change we need to make to the Address field settings is to specify that no label is needed. For the Job photo, however, disable the label, and select the Full image format.

[ 164 ]

Chapter 6

10. With the Project manager field, specify that the format is not a link.

11. The Node body field contains the job description. Simply remove the label for the field.

[ 165 ]

Prior Work

That completes this display. We'll take a look at the preview and see the result, which is shown in the following screenshot. The final step will be to theme the output.

[ 166 ]

Chapter 6

The following is a screenshot of the Job display settings.

[ 167 ]

Prior Work

Activity 6-5–Theming the prior-work view

Please see the Chapter 5, Bios, for a fuller description of selecting and naming view template files. We're going to theme the overall view, in terms of the positioning of each display in relation to the others, and the Job display. The other two displays will be a simple list, and be themed via CSS. 1. We'll begin by theming the Job display. We'll copy the file views-viewfields.tpl.php from the directory sites/all/modules/views/theme. Whenever adding a new template file, or deleting one, you must clear the Drupal cache at admin/settings/performance for the system to recognize the change.

2. Following is the template code as it exists in the original file (except for the very useful comments). It iterates through the fields in each row ($fields) and prints them out based on some styling selections available in the view panel. > : class= "field-content"> > >

[ 168 ]

Chapter 6

3. This file was designed to handle any fields selected in a view, without needing to know which. We know exactly which fields we are working with, so we can remove the iteration and specify them individually in the order in which we want them. Another approach is to retain the iteration, and ensure that the fields are ordered properly in the Fields section of the view. The benefit to this approach is that fields can be reordered, removed, or added later without having to touch the template again.

4. Let's code our display.

5. We'll save this file as views-view-fields--prior-work--attachment -2.tpl.php. Finding Your Fields A quick way of discovering the field names available in this template is to dump the field names from the $fields variable, like this:

[ 169 ]

Prior Work

6. Let's add some CSS to style the output. We'll add a few declarations to the local.css file to provide some spacing and clarity through color and borders. /* PRIOR-WORK */ .view-prior-work .title-1 { margin: 12px 0 } .view-prior-work img { margin: 12px 1em 0 0; border: 1px outset gray; } .view-prior-work .body { width: 240px } .view-prior-work .field-project-manager-nid { margin-top: 0; margin-bottom: 12px; color: #dfb77c; } /* !PRIOR-WORK */

7. Our final step is to theme the display arrangement. For this, we will make a copy of the file views-view.tpl.php. The contents of this file, less the comments, are given in Chapter 5. 8. We'll change the contents to suit our purposes, by enclosing the displays in div wrappers. The changed code is as follows, and will begin around line 39, right after the line of the $exposed snippet, and end just before around line 72:

[ 170 ]

Chapter 6

9. We'll save the template file as views-view--prior-work.tpl.php and clear the cache. 10. Finally, we'll add some final styles to our CSS file to surround our displays with a border and some whitespace: .view-prior-work .view-content { margin: 12px 1em 0 0; border: 1px solid #4b4b4b; } .view-prior-work .attachment-after { margin: 12px 0 0 3em; float:left; }

[ 171 ]

Prior Work

That's it for this view. Let's take a look at the final version.

Summary

We created the prior-work view with three displays, two Attachments and one Page, with one Attachment being interactive, and the other not. We used a relationship with the view, and did some basic theming. In Chapter 7, we will create an interactive About Us page, with two interactive Attachment views, and a Page display that can have three different content states!

[ 172 ]

A Different 'About Us' In this chapter, we're going to spice up what is typically a functionally flat page on most sites, the 'About Us' page. The site visitor will go to this page to get information about the company, but in our case, that information can be more than the typical company history blurb. We're going to create a view with several displays, as follows: •

A link from which to select to view the company history

•

An attachment display from which to select a biography

•

An attachment display from which to select an example of prior work

•

Page displays to present the selected record from each page display

At this point, we could export the views we have already made, combine the needed elements, and import them as a new view, but it would be too complicated to show and explain here, so we'll create it. We're going to do something a little different than we have in the past couple of chapters; we'll make the small displays of selection lists the attachments, and the display of single selected records the page displays. The reason for this is that the lists from which the records are selected need to appear on multiple page displays, and attachment displays can be attached to more than one display.

A Different 'About Us'

Activity 7-1–Creating the About Us view The About us page will be a view. We'll create that before each of the displays. 1. Start by creating a new view of type Node, and name it about.us.

[ 174 ]

Chapter 7

2. Having created the view, we're looking at its panel. At this point, we haven't created a display, and we are looking at the default settings. Each display is different enough from the next that we won't use default settings. We have a number of displays to create. Let's get started.

Activity 7-2–Creating the Bio Page display

The trick behind our view is that it will have three different page displays with three different URLs. The URL selected, and thus the content of the display, will depend on whether the user chooses to see the company information, a biography or prior work. In this activity, we'll create the Page display used to show a single biography.

1. We're going to have three page displays in this view, so remove the ambiguity from this display by naming it Bio Page.

[ 175 ]


2. We'll be displaying only one record, so change the Items to display setting to reflect that. Click Override before updating, so that the setting change only affects this Page display.

3. The path for our page is the secret behind this view working. There will be three page displays, but only one will appear. How do we control that? Each page display will have a slightly different path. All three will contain aboutus but this one will have the path about-us/b with the 'b' for biography.

[ 176 ]

Chapter 7

4. We're going to need the URL to pass the bio node ID (nid) to the display, so that we know which record is being requested. Define an argument by clicking the + icon, and then selecting Node: Nid. Simply accept the settings in the subsequent dialog, as is, after clicking Override.

5. Select the fields to be included in this display, which are listed in the following image. The Node: Title field contains the name of the person whose bio has been selected, and the Node: Body contains the bio text.

[ 177 ]


6. With the Job Title field, specify that a label isn't needed.

[ 178 ]

Chapter 7

7. The photo field is a bit different. We can elect to receive the original image, but we have no idea what size that image might be. We've used the ImageCache module to define a preset, so that a 'bio image' is available to us, which will always have been scaled to a size within the parameters defined for that preset. Choose that from the format, and remove the field label.

[ 179 ]


8. The next field will be the Body field, which contains the text of the biography. The only change to make to it is to remove the field label.

9. The final field is the Title field, which with the Bio content type, contains the employee's name. The only change for this field is to remove its label.

[ 180 ]

Chapter 7

10. The fact is that, technically, we don't need any filters for this display, because we're providing the nid via the argument, which will determine the node we need. However, we'll create filters just to be sure, in case a manual link is entered with the wrong nid; for example, the case where someone bookmarks a display in which the node is later unpublished. Use the Node: Published and Node: Type as filters.

[ 181 ]


11. With the Published filter, select only published nodes.

12. The Node type filter gives the option of selecting one or more types of content. Select the Bio type.

[ 182 ]

Chapter 7

13. The final step for this display is to preview it. We'll specify the Bio Page display, and provide an argument, six, for example. The results are shown in the following screenshot.

[ 183 ]


Activity 7-3–Creating the prior-work display

The next display is the prior-work page display, to show the record selected from a list of completed jobs. The assembly of this display is so similar to that in Activity 7-2, that I'll forgo giving step-by-step instructions, and instead, will provide an image of the view panel with all the settings in place for this display, and identify the specifics as bullet points.

•

Make the display name Prior-Work.

•

The path should be set to about-us/p (as opposed to about-us/b for the Biography display).

[ 184 ]

Chapter 7

•

The Job photo will be used with the format set to full image, as well as the Address field.

•

The Node type filter needs to be changed to Job, and a filter added for Display completed job (Allowed values) to not be false.

Activity 7-4–Creating the About Us Page display

The display, which will present the company information, will simply display a piece of content, so the display settings will be more simplistic than the other two. Let's do it! 1. Start by creating a Page display.

2. Name this display About-Us Page.

[ 185 ]


3. This display will present an entire node, as opposed to the individual fields such as the other two displays. Change the Row style to Node to accomplish this.

4. Elect to display the entire node, instead of the teaser, and to not include the links that might otherwise accompany the output.

[ 186 ]

Chapter 7

5. Despite the fact that we'll be selecting the specific node to show via a filter, change the Items to display setting to 1, so that anyone subsequently looking at the view will realize that there should be only one record.

6. With the previous displays, we added a suffix to the path to differentiate them. With this Page display, simply make the path about-us, since this will be the display linked to by the menu.

[ 187 ]


7. We'll need two filters for this display. One filter is for Node: Published.

8. The other filter is for Node: Type.

[ 188 ]

Chapter 7

9. Our final step with this display is to preview it. Select the About-Us Page display. The results are shown in the following screenshot.

Why don't my images show in the preview? The node used above actually has an image embedded in it. What is appearing instead is the alt text for the image, in the form of name, phone, and partial address. You might notice that sometimes images appear in a view preview, and sometimes not. The reason the image doesn't appear in this one is that the image is located in the page theme's directory, and the theme being used for creating the view is not the same theme, so the file will not be found with the current theme.

How do I get rid of the post information? If your preview is showing post information (the name of the user, who posted the content, and the date it was posted) and you want to turn that off, navigate to admin/build/themes/settings. There you can enable or disable the showing of post information for each content type.

[ 189 ]


Activity 7-5–Creating the Bio Attachment display 1. Begin by creating an Attachment display.

2. Alter the display name, because there will be another Attachment display on the page, so a more descriptive name will help. Call this Bio Attachment.

3. We don't need this display to inherit the Page display's arguments. This display doesn't use arguments. Disable that.

[ 190 ]

Chapter 7

4. We want this Attachment display to appear no matter which Page display is being shown, so attach it to all three displays.

5. Override and remove the argument for this display. 6. For our Fields setting, select the Node: Nid and the Node: Title.

[ 191 ]


7. We don't want the nid to display. We simply need its value available to use in the link we will create with the node title. Exclude it from the display and remove its label.

8. The node title contains the name of the employee. The view will produce a list, and each list item will be a link to our Bio Page display. The link needs to include the nid as an argument, so that the Page display will know which node to display. Remove the label, specify that the field should be output as a link, and define that link as about-us/b/[nid], which is the path we created for the page (about-us/b) and the replacement pattern that will substitute [nid] with the actual nid.

[ 192 ]

Chapter 7

9. We may have multiple records to display, so we need a sort order. Sort based on the node title, which is the employee name in the Bio content type.

10. Sort the title in ascending order.

[ 193 ]


11. We need to filter the selection of nodes. The filters will be the Node: Published and Node: Type values.

12. For Node: Published, select a published node.

[ 194 ]

Chapter 7

13. For Node: Type, we want only Bio nodes to be selected.

14. The final step for this display is to preview it, and verify that the link it produces is correct. Simply place your mouse over the link to see what the browser sees.

[ 195 ]


Activity 7-6–Creating the prior-work Attachment display

We're going to handle the creation of the Prior-Work Attachment display in the same way as we did the Page display earlier, by showing the panel of the completed display along with a bulleted list of how it differs from the Bio Attachment display.

•

The display name is Prior-Work

•

The link created in the Node: Title field setting is about-us/p/[nid]

•

The node type filter is set to Job

•

A filter is added for Content: Display completed job (allowable values) set to Display completed job

[ 196 ]

Chapter 7

Preview this attachment and check the link.

The only thing left to do is look at the three pages as the user sees them, after some theming has been done. The three displays appear in the following images. The main page display is as follows:

[ 197 ]


The Prior-Work display is as follows:

The Bio display is shown as follows:

[ 198 ]

Chapter 7

Summary

In this chapter we created the 'Abous-Us' view with five displays, three Page displays, and two Attachment displays. In Chapter 8, we will create a control panel-like view for the management, so that you can have access to all the various content from one place!

[ 199 ]

Control Panel We've used a number of custom content types throughout this book (see Appendix B for more detail). The various backend users and roles, are free to go to the administrative page for content and investigate nodes of interest, or to create a view to present them as teasers. However, that isn't a very effective or user-friendly way. In this chapter, we're going to create a control panel, with one main view portal, and small displays from which to select the content to view. We're going to create a view with several displays, as follows: •

An attachment display for each content type

•

A portal for viewing the select node

•

The attachment displays themed as drop-down selections

Control Panel

Activity 8-1–Creating the Control Panel view Begin by adding a new view of the node type.

1. Make some settings to our default display that will be common among the Attachment displays. That way we don't have to set them separately for each display. Start by changing the displayed items from 10 to 0 to remove any limit. That might result in far too many for a normal display, but we'll be using drop-down list boxes.

[ 202 ]

Chapter 8

2. The fields we will need in each case will be the Node ID (Nid) for creating a link, and the Title, for the link text. Both are in the Node: section.

[ 203 ]

Control Panel

3. Remove the label of the Nid field.

4. The Node title will be the field that we use in the drop-down lists. Remove its label.

[ 204 ]

Chapter 8

5. It's a safe assumption that since the Node title is the only field that will be visible, it will also be the field on which we sort.

6. Sort in ascending order.

[ 205 ]

Control Panel

Normally we would create a filter to select only published nodes, but this display isn't meant for the viewing public, it's for the site owners, and they will want to see every node, not just the ones that are published.

Activity 8-2–Creating the Page display

1. We will configure the Page display after we're done with the Attachment displays, but we should create it now so that we have something to which we can attach the Attachment displays.

2. We also need to create a path for the display at this point. The View validation logic doesn't like having a Page display that isn't assigned to a path, and will complain about it. We'll want to preview our Attachment displays, and the preview won't run if validation fails. So, name a path.

Activity 8-3–Creating the Attachment displays

We'll be creating an Attachment display for each of the content types in use on the site. Each display will be precisely the same as the next, other than the Node type and Display name. We'll create the first one step-by-step, and then simply note the additional displays that are created in the same way.

[ 206 ]

Chapter 8

1. The first step will be the creation of the display.

2. We'll name this first one Bio Attachment.

3. Change the Inherit arguments setting, since the display will list all the nodes of the Bio content type, we don't need arguments.

4. Next, specify that the Attachment display should be attached to the Page display.

[ 207 ]

Control Panel

5. We made most of our selections on the Default page, so all that is left to do is to create a filter to specify the node type. Make sure to click Override before selecting the node type. Return to the Page display after creating this Attachment display, and remove any fields listed under Fields that should not be there.

[ 208 ]

Chapter 8

6. This display should select only Bio nodes.

7. Let's preview our display. We'll select Bio Attachment for the Live Preview display type.

[ 209 ]

Control Panel

Activity 8-4–Creating the other Attachment displays

We're going to repeat the steps in Activity 8-3 for each of our content types: AboutUs Info, Job, Location and Subcontractor, naming them appropriately and selecting the matching node type for the filter. The previews for each are as follows:

[ 210 ]

Chapter 8

Activity 8-5–Configuring the Page display

We already have created the Page display and assigned a path to it. Now, we'll finish configuring it. There are two different approaches we could use in this display regarding the content. We could make the display aware of the type of content it is displaying, and then theme accordingly for each content type. That's a lot of work, so we won't do that unless the need arises. Instead, we'll have the Page display present all content in the same fashion, without knowing which node type is being displayed. How? We're going to pass the Nid as an argument. If we elect to display the Node instead of Fields, with the Nid to define which node, we have all that we need. 1. Change the Row style to Node.

2. Elect to show the complete node, and to not include links.

[ 211 ]

Control Panel

3. This view is going to be for the Guild Builders staff only, so change the Access to being Role-based.

4. Select the management role.

[ 212 ]

Chapter 8

5. Create a menu item for this View. We already have a Guild Builders menu, for the use of the staff. Add it to that.

6. Create an argument for the display, which is important unless we want it to select every node. The argument will be the Nid.

[ 213 ]

Control Panel

7. If the page is requested without an argument, force the Nid for the About Us node. There is a chance, however, that at some point that node might be deleted, and thus that Nid will not longer exist. In that event, display the empty text.

8. Create some empty text.

[ 214 ]

Chapter 8

9. We're ready to preview. First, preview with no argument. In the following image, you'll see that the About Us node is selected, as we defined earlier.

10. Preview using an argument.

[ 215 ]

Control Panel

Activity 8-6–Theming the Attachment displays

1. We don't need to theme the Page display, because it will be displaying entire nodes. What we want to theme are the Attachment displays; to have each of them display a select box containing the node title links. To do this, theme each row of output as an option for a select control, and then embed the rows in that control. This is done in two different template files, since one has visibility to each row as a group of fields, and another to all the rows as a collection. 2. We have no need, at this point, to discern which attachment we're working with, because each will be handled in the same way. So, copy the unformatted template file from /sites/all/modules/views/theme. This is the file that contains all the rows as one collection. Name it the most specific theme name listed—under Information for an attachment in our view—that does not specifically number the attachment, which is: views-view-unformatted--control-panel--attachment.tpl.php. 3. Following are the initial contents of that file:

It's not easy on the eyes, with the php tags encasing each line. This style has not been without opinions on both sides, but the prevailing opinion is that it's easier to debug and faster to drop in HTML between the lines than it is to have the HTML encased in strings instead of the PHP being encased in tags.

4. Notice the highlighted row towards the middle of the listing; a for each statement. It loops through each row of our selected content type and prints it. Therefore, this file is being called once for each of our Attachment displays.

[ 216 ]

Chapter 8

5. We're going to modify it to format each row as a select control with options. Change the lines from the highlighted line to the end to read as follows: <select onchange="window.location='/ control-panel/'+this.value"> Select...

6. What we've done is eliminate the tags encasing each row; because each row will be a select option, so should not be a . We've also embedded the loop within and <select> tags, which will create our control for the Attachment display. 7. The <select> statement has the following parameter: onchange="window.location=' / control-panel/'+this.value"

The echo $base_url will insert the base URL, in our case http://localhost/guildbuildersinc.com. If we didn't have this, invoking the page the first time would work fine, but the second time we'd have a relative link appended to the view path, creating a repeated relative URL, which would not work. The - is the HTML for a hyphen, just to make sure we don't have an encoding issue. The remainder of the line, outside of the PHP tags, is JavaScript. The +this.value will append the value of the option currently selected, which is the Nid of the desired node, at the end of our URL. The onchange="window.location will make a request for a different web page whenever the selection is changed in the select box. If you notice that $base_url is not adding anything to your link, it is likely that the variable is not exposed within your script. Putting the line earlier in your file should solve the problem.

8. We've also inserted an tag. This will create an initial option for the select box that reads Select. The reason we do this is that if the select box were to list an actual node as the first choice, we would not be able to display it, since with the node already appearing, there would be no way to change to that value in the select box. [ 217 ]

Control Panel

9. We also need to alter the format of the each row. Copy the unformatted template file from /sites/all/modules/views/theme and name it: views-view-fields--control-panel--attachment.tpl.php

10. We'll gut the contents of this file, and replace them with: 3. The method to our solution is to display a title, and when the title is clicked, toggle between showing the block and hiding it. The title itself will be static, always being visible. Add that above the current line. Subcontractor Login

The onclick="showhideBlock()" is JavaScript that calls a function when the title is clicked. Let's create that function. 4. JavaScript can be confusing if it's not your forte, however, the function we need is just a few lines. Here's the code: function showhideBlock() { x=document.getElementById(“user-login"); if(x.style.display=="block") x.style.display="none"; else x.style.display="block"; }

The first line within the function looks for an element with the ID user-login and assigns the element to the variable x. We will create a wrapper div with that ID in the next step. The nomenclature x.style. display in the next three lines refers to the same setting as if we were doing the following with CSS: #user-login { display: value }

[ 223 ]

Front (Home) Page

If the display setting for the element is currently block, which means it's visible, we change it to none, which makes it hidden, and vice-versa. 5. We could insert the JavaScript directly into our template, but we'll be good Drupal citizens and use an API call to have the script inserted for us: API (Application Programming Interface) is a collection of entry

points, typically functions or object members, which provide developers access to an application's functionality. The Drupal API is documented at api.drupal.org.

So we have set $js equal to a string containing our script. It can get confusing quite quickly with quotes. JavaScript wants some, and PHP wants some, and never the two should meet, so copy carefully. We've delimited the PHP string with single quotes, and within the JavaScript we've used double quotes. The format of the API call is drupal_add_js($data,$type,$scope). This call can also be used to insert the contents of a JavaScript file into our code, but we're using it for inline code. The $data parameter is our script, the $type parameter, in our case, will be inline, and we will ask for the script to be inserted into the head section of our page via the $scope parameter. 6. We need to wrap our contents inside an element that has the ID of user-login, since that's the name we chose in our JavaScript. Use a division. Having done that, the code now looks like this: Subcontractor Login

The reason for the style entry in our div wrapper is to hide the login block initially. We could move that style rule to a CSS file, but since it's unique and unlikely to need overriding, leave it inline.

[ 224 ]

Chapter 9

7. That's all there is to it. Save the template and clear the cache so that Drupal finds it. In the following images you can see the box in both the peekaboo and I-see-you states.

[ 225 ]

Front (Home) Page

Activity 9-3–Adding a Theme region

We're going to be creating a view in the next activity to display a news item on our front page. The location for that view needs to be in a location that is currently not addressable in our theme. What to do, what to do? Simple. We'll create a new region in our theme, and add it to our template. 1. We need to edit our theme info file. In this case, the theme is Acquia Slate. First, let's look at the handy view the block page gives us of our regions. Focus on the upper ones.

2. Open acquia_slate.info, and look at the regions entries: regions[sidebar_first] = sidebar first regions[sidebar_last] = sidebar last regions[banner] = banner regions[header_top] = header top regions[header_first] = header first regions[header_middle] = header middle regions[preface_sidebar] = front preface sidebar regions[content_top] = inner content top regions[content] = content regions[content_bottom] = content bottom regions[postscript_first] = postscript first regions[postscript_middle] = postscript middle regions[postscript_last] = postscript last regions[footer] = footer regions[node_bottom] = node bottom

Our region needs to be below the header_middle region, but above the content regions. When it contains something, it will appear as a full-width banner just below the bottom of the concrete logo banner. Insert the following line: regions[header_middle] = header middle regions[header_bottom] = header bottom regions[preface_sidebar] = front preface sidebar

[ 226 ]

Chapter 9

3. Now, save the file, and open page.tpl.php. 4. We created the region, but it won't show in the preview on the block page unless we actually reference it in the page template file. So, insert the following lines:

5. Save the file, clear the cache, and check the Block page to see if it's shown. The following image shows that it is.

6. Also check the Region dropdown for any of the blocks.

7. Since we're going to be using this region on the front page as well, add the lines above to the same location in the file page-front.tpl.php, and then all we need is something to display there—our next activity.

[ 227 ]

Front (Home) Page

Activity 9-4–Creating a News block

We're going to create a Block display in our jobs view that will show the newest job open for bidding. The block will be assigned to our new region, and only be visible to Authenticated users (subcontractors). 1. Edit the existing jobs view, and create a Block display.

2. Name the display Latest Job Block.

3. Also make the Block title the same.

4. We're only going to show one job, so set the Items to display to 1.

[ 228 ]

Chapter 9

5. The Access will be for subcontractors only, so change it to role-based.

6. Select authenticated user for the role.

7. We'll be using two fields, the Node title, and the job address (field_address in the Content section). Remove the label text for Node: Title.

[ 229 ]

Front (Home) Page

8. Remove the label from the Content: Address field as well.

9. Sort the selected rows on Node: Post date.

[ 230 ]

Chapter 9

10. Sort Descending, this way, our limit of one will give us the most recent.

11. Add a few filters, to ensure we get the correct node: Content: Bidding open, Node: Published, and Node: Type. 12. The node records should only be selected if the Open for bidding field is set as such, so select that as the value to test for.

[ 231 ]

Front (Home) Page

13. The Node: Published test will be that the node has been published.

14. Set the Node: Type filter to test for a node type of Job.

15. Performing a live preview on the block display shows that it's working correctly.

[ 232 ]

Chapter 9

16. Let's head over to the Block page, find our block and assign it to our new region.

17. Configure the block with a title, to be accessible only to authenticated users, and to appear on every page.

18. The following image shows the block on the front page prior to whatever theming it will undergo.

[ 233 ]

Front (Home) Page

Activity 9-5–Creating an RSS Feed

While we're looking at the job view, we should create an RSS feed, so that the subcontractors can subscribe. 1. First we'll create a feed display.

2. We'll specify that the site title be used as the display title.

3. RSS Feeds are usually offered in node format, so specify that the Row style is Node.

4. We only want to provide the node title in the feed.

[ 234 ]

Chapter 9

5. We need to create a path for the feed, the page that will serve it to the user.

6. We'll only be sending out the most recent job title, so change the Items to display setting.

7. Next, set the sort criteria, just as in the Block display.

[ 235 ]

Front (Home) Page

8. Sort in descending order.

9. Add the same filters as the Block display. 10. Specify that the value be present for Content: Bidding open.

[ 236 ]

Chapter 9

11. Have the Node: Type filter check for a Job node.

12. Ensure that the node has been published.

13. Previewing our Feed display shows us the XML that will be output.

[ 237 ]

Front (Home) Page

Your browser might actually interpret the XML instead of displaying it, but it's still there!

14. Finally, let's navigate to the page and make sure it works.

Summary

We did a lot in a short time in this chapter. We made a role-specific menu, a peek-aboo login box, a new region for our theme, a news block for the home page, and an RSS feed. In our final chapter, we'll wind down and handle some punch list items—the things that are left when everything else is done—or at least, seems to be done. We'll define roles, users and permissions, and configure the site.

[ 238 ]

Punch List In our final chapter, we'll handle some punch list items—the things that are left when everything else seems to be done. We'll define roles, users, and permissions and configure the site. We'll take each of the settings in order for any that need to be customized.

Administrative Theme

It's much easier to work in the backend of Drupal when the layout is clean, in terms of all the administrative options and fields being easily visible. All too often a theme that hasn't given consideration to the admin pages will cause layout issues. I will typically set the Administrative theme (admin/settings/admin) to be Garland, as seen here.

Punch List

Clean URLs

Enabling this option will remove the ?q= ugliness from the site URLs, so we'll do that (admin/settings/clean-urls). The original URLs can still be used, such as q=user when there's no admin link available. The ability to use clean URL's is not available on every site, and is dependent on the Drupal.htaccess file being present in the domain root directory, as well as Apache allowing mod_rewrite on your server.

Error reporting

The Error reporting page allows us to specify custom pages for reporting HTTP 403 (Access Denied) and 404 (Page Not Found). We'll be using the standard pages, but we will be making one setting change here (admin/settings/error-reporting). While developing, we want errors reported to the screen, because we want to know right away that an error occurred. When deploying, we no longer want errors to be presented to the user. Instead, we want them to be logged only.

[ 240 ]

Chapter 10

File system

There are only three settings on the File system page, but are incredibly important. An incorrect setting here is a likely point of failure, and this page, sometimes forgotten, is often a point requiring updating when moving a site from one server to another, like the settings file. All too often the new site location does not have the same directory structure as the old, so the location settings here (admin/settings/ file-system) may be invalid until changed. We'll leave the location of uploaded files in the default location of sites/default/files, and the download method as public, but will set the location for temporary files.

[ 241 ]

Punch List

Input formats

Input formats come into play wherever there is a text box used for entering content. The default format is Filtered HTML, which unaltered, offers a set of tags too limited for our needs. We have the options of editing the input format to bring it in line with what we need, add a new format, or specify Full HTML, which allows all HTML tags, and that's what we'll select, since there will be only one trusted person creating content.

Logging and alerts

It has been mentioned above that errors will be logged, and so will alerts. The logging will be to the database, and it is from this page (admin/settings/logging) that we can configure this. There are two subsections here: Database logging and Syslog. The latter is of importance to mid-to-large sites, but with this being a small site both in physical size and anticipated traffic, we'll leave that alone. The Syslog option may not be present on your administrative page, depending on which modules have been activated.

[ 242 ]

Chapter 10

Database logging

This site will be managed fairly actively, so we're going to change the entry level to 100, so the database has less bulk between cleanups.

Performance

The performance page offers a number of ways to cache and/or compress data in order to provide content to users more quickly. Our site is going to be low-traffic, so at this point we don't need to consider many of the methods offered. We will, however, take advantage of normal caching.

[ 243 ]

Punch List

Search settings

On the Search settings page (admin/settings/search), we don't need to change the settings, but we see that our site needs to be indexed. If this option does not appear on your site, it's likely that the module has not been enabled. I'm a proponent of putting all such controls in one place, in addition to segregating them by function, things such as re-indexing, clearing cache, running cron, and so on.

We'll click the button to re-index, verify that we're certain, and schedule the site for indexing.

Drupal will make doubly sure that we want to re-index.

[ 244 ]

Chapter 10

User management

The way that Drupal allows us to differentiate the site capabilities of one person from another is by using roles. Let's take a look at how they are defined on this site.

Roles

On sites, where there will not be user accounts, the authenticated user role can be used to differentiate logged in users from site visitors. On a site with user accounts, the site visitor who creates an account and logs in will be the authenticated user, so an additional role is needed to differentiate any users who are supposed to have a greater level of privileges, such as company staff. The same is true with our site. The subcontractors will be the authenticated users and we'll create a single role for company staff, management.

Permissions

We'll cover the permissions for a core Drupal install here, and for the add-on modules in the appendix.

[ 245 ]

Punch List

Block module

The block module is for creating the blocks that can be placed in various regions on the site. The permissions settings will depend on who will be administering them—these particular permissions don't affect their viewing. With this site, the site owners will not be performing site administration themselves, so we will leave those permissions to User 1 (the super admin) and not assign them to any of the roles.

Comment module

At this point, the site is not making use of comments, but we will set permissions in an anticipatory fashion. We'll allow all users to read comments. Anonymous users have no standing to post comments, so we'll limit that capability to subcontractors (authenticated) and management, and allow management to do so without approval. Administering comments is a content administration ability rather than site administration, so we'll give management permission to do that.

Contact module

The contact module has two parts; contacting other users and giving feedback to a central user or users, who will receive the messages. The site will not enable user-touser contact, so we will assign permissions in the context of providing site feedback. To that end, all roles will be given the permission to access the feedback form, but administration of that form will be retained for User 1.

[ 246 ]

Chapter 10

Content module

The sole permission under the content module is the ability to use PHP input for field settings. There is a warning shown regarding this ability, which should read 'Really Really Really Dangerous' instead of simply 'dangerous.' We'll retain this capability for User 1.

Node module

The node module permissions affect the creation, editing, deletion, and administering of content. The list of permissions is long, particularly because we have a number of custom content types. They provide not only the ability to create, each individual content type, but also the ability to edit and delete them, to segregate performing that action on the user's own content, and content without regard to its creator. We're going to allow all users to view (access) content. The administering of content types we will reserve for User 1, but the administering of the content itself, nodes, we will grant to management. With regards to individual content types, there is no reason for management to be creating new Page or Story content, since Story content isn't being used, and the Page content to be used has already been created. Also, there only needs to be one About_us content entry, and creating another could lead to issues if both are published, so we'll not grant creation permissions for any of the three. Other than those, we'll allow management to create content. Subcontractors need to be able to create Sub content, as well as Profile content, so we'll grant authenticated users those permissions. Keeping in mind that subcontractors are not yet registered at the point that they complete registration, we will also permit the creation of Sub content by anonymous users.

[ 247 ]

Punch List

We'll allow management to delete any content that they have the ability to create. We'll also allow them to edit all content, and allow subcontractors to edit their own Sub entry. Finally, we'll grant management the permission to view and administer revisions.

Path module

The path module permissions control the administering of the path names, which are the URL's. This is one of the things that can break a site quickly if done wrong, and accordingly, we'll reserve these permissions for User 1.

Search module

The search module permissions are for administering and using the search facility, and we'll retain the permissions for User 1, and assign them to all users respectively.

[ 248 ]

Chapter 10

Statistics module

The statistics module is used for gathering information about site usage, such as the number of times a node has been viewed. Only management requires the ability to view these statistics.

System module

The system module permissions are like a list of 'other' core capabilities. There are two that we need to grant to management. One is the ability to access site reports, and the other, access administration pages, is needed lest the admin menu not be accessible at all.

Taxonomy module

The taxonomy module permissions are for the administration of taxonomy vocabularies and their entries. There are no functions that the users need access to here.

[ 249 ]

Punch List

Upload module

The permissions in the upload module section control the ability to upload files and view them. Subcontractors need the ability to upload a file with their registration, if desired, but only management need to be able to access the files, once uploaded. If the upload module has not been activated, this section will not be displayed.

User module

The user module settings control actions that affect user settings. We'll retain the ability to change permissions for User 1, but the ability to access profiles and administer users we'll grant to management, along with the ability to change their own usernames.

Summary

In this chapter, we configured the standard portions of our site, making it ready for use. The configuration of the add-on modules and custom content types used in the site is covered in the appendices. This brings us to the completion of our site and the end of the book. We've accomplished quite a lot in a relatively small number of pages. I hope you enjoyed the ride. You will find useful supplementary information in the appendices, including information about a version of our project website which we have made available for your use.

[ 250 ]

Add-On Modules We have made use of many contributed modules in our site. This Appendix contains information about each, and screenshots of the configuration settings where applicable. A few modules were used in the site, but not in the book. Such modules are included in this Appendix. Drupal 7 will have a module installer, much like the one found in Joomla!. However, in Drupal 6, you must do the following: •

Download the compressed file from the module page

•

Uncompress it

•

Drop the module folder into the sites/all/modules folder in your site (the modules folder is not present in a new installation, it needs to be added to sites/all)

•

Navigate to admin/build/modules (Admin | Site Building | Modules)

•

Enable the module

Sometimes modules depend on other modules. If the module you are installing depends on a module that is not present, the name will appear in small print below your module name, with a notation indicating that it is missing, and Drupal will not allow you to enable your module until the other module is present. If the required module is present, but not enabled, Drupal will ask you if it is alright to enable it. It's always, always a good idea to back up your database prior to installing new modules. Sometimes they add information to the database, and despite the fact that they have been tested prior to your being able to download them, errors do happen. Module descriptions are provided by their authors.

Add-On Modules

The screenshots regarding settings are current as of the time of this writing, which was when Drupal 6.13 was the current version. Note that module updates occur often, so there could very well be minor differences between the information contained herein and what you see at the time of installation.

Captcha

Location: http://drupal.org/project/captcha A CAPTCHA is a challenge-response test most often placed within web forms to determine whether the user is human. The purpose of CAPTCHA is to block form submissions by spambots, which are automated scripts that post spam content everywhere they can. The CAPTCHA module provides this feature to virtually any user facing web form on a Drupal site.

[ 252 ]

Appendix A

The next screen allows you to define challenges for known forms.

You can define the default CAPTCHA behavior.

[ 253 ]

Add-On Modules

If you are going to use 'Image CAPTCHAs', there is another menu choice to configure them.

You can define the characters to use in the code (such as avoiding the problems of O versus 0-zero) and the length of the string.

[ 254 ]

Appendix A

You can also make choices regarding the appearance of the image, such as the font characteristics.

The distortion level will make the characters even more difficult for a non-human to identify.

[ 255 ]

Add-On Modules

And finally, the permissions can be set to allow certain roles to avoid using CAPTCHA altogether.

CCK

Location: http://drupal.org/project/cck The Content Construction Kit (CCK) allows you to add custom fields to (content types) using a web browser. The CCK module doesn't have an explicit settings page or permission of its own. The fields are defined as part of a content type, and that content type creation is covered in Appendix B.

Contact form blocks

Location: http://drupal.org/project/contact_form_blocks The Contact form blocks module makes your site-wide contact forms available as Drupal Blocks.

Content profile

Location: http://drupal.org/project/content_profile

This module builds user profiles as content (also known as nodes), which opens the opportunity to use all the powerful modules for content for user profiles too, for example, the Content Construction Kit (CCK). It's intended to be simple and useful, but extensible by further modules. [ 256 ]

Appendix A

The setting for Content Profile is an extra pane in the content type settings. If checked, that content type is used as the user profile. If unchecked, as shown next, that particular content type will not be used for profiles.

Custom (form) destination

Location: http://drupal.org/project/customdestination Custom (form) destination provides a way to define where a form should redirect the user upon submission.

Date

Location: http://drupal.org/project/date The date module is a flexible date/time field type for the CCk content module which requires the CCK content.module and the Date API module. The Date API module is included in the Date module package—no need to go looking for it.

Embed Google Maps field

Location: http://drupal.org/project/embed_gmap

The Embed Google Maps module provides a CCK field for embedding Google Maps into nodes. You can embed any kind of Google Maps including driving directions and personal maps. You can also type a search query into the field and display the search results in the field. [ 257 ]

Add-On Modules

There is no settings page or permissions for this module. A new field type is created, the details of which will be shown in Appendix B.

File field

Location: http://drupal.org/project/filefield FileField provides a universal file upload field for CCK. It is a robust alternative to core's Upload module and an absolute must for users uploading a large number of files, because it allows for the creation of custom folders for different upload types. It's great for managing video and audio files for podcasts on your own site. There is no settings page or permissions for this module. A new field type is created, the details of which will be shown in Appendix B.

Form markup

Location: http://drupal.org/project/form_markup This module allows you to add surrounding HTML values to any CCK field by determining prefix and suffix values. (This module allows label text to be added to a Drupal form. There is no 'label' field in CCK, they're all meant to be content.) There is no settings page or permissions for this module. The ability to add prefix and suffix text to CCK fields is given, and will be shown in Appendix B.

ImageAPI

Location: http://drupal.org/project/imageapi This API is required by the ImageCache module.

[ 258 ]

Appendix A

Set the quality setting for the image, or leave the setting at the default.

Set the permissions for administering the module. In our case, only User 1 will be able to administer it, so none of the roles need to receive the permission.

ImageCache

Location: http://drupal.org/project/imagecache ImageCache allows you to set up presets for image processing. If an ImageCache derivative doesn't exist, the web server's rewrite rules will pass the request to Drupal which in turn hands it off to ImageCache to dynamically generate the file. The following image shows the presets that are in use on the project site. Full and thumbnail are created by the module, and will be used for job photos. The bio type was created for use with the biography photograph. These presets are selectable as format options from within Views.

[ 259 ]

Add-On Modules

Here are the specifics for the bio preset.

Here are the specifics for the full preset. Even though this preset is created by the module, the specifics of its configuration can be altered to meet your needs, or it can be deleted entirely.

[ 260 ]

Appendix A

Here are the permissions for this module. The administer and flush permissions will be retained for User 1.

Image field

Location: http://drupal.org/project/imagefield ImageField provides an image upload field for CCK. ImageField is a CCK-based alternative to the legacy Image project. It boasts features such as multiple images per node, resolution restrictions, default images, and extensive Views support. ImageField does not provide a built-in thumbnail solution, but complements the incredibly powerful thumbnail generation module ImageCache. [ 261 ]

Add-On Modules

There is no settings page or permissions for this module. A new field type is created, the details of which will be shown in Appendix B.

Menu per role

Location: http://drupal.org/project/menu_per_role This module allows you to restrict access to menu items per roles. It depends on the Drupal core menu.module—just activate both modules and edit a menu item as usual. There will be a new fieldset that allows you to restrict access by role. There is no settings page for this module. When it is active, a new panel will appear, as in the following image, when editing menu entries.

Rules

Location: http://drupal.org/project/rules The rules modules allows site administrators to define conditionally executed actions based on occurring events (known as reactive or ECA rules). Other modules use Rules. There are three permission settings pages for Rules, but we have not made entries on any of them, as it is only being used internally by User 1.

[ 262 ]

Appendix A

Token

Location: http://drupal.org/project/token Tokens are small bits of text that can be placed into larger documents via simple placeholders, like %site-name or [user]. The Token module provides a central API for modules to use these tokens, and expose their own token values. (Other modules use Token). The Token module has no settings page. It provides an API for other modules to use to define tokens.

Utility

Location: http://drupal.org/project/util The Utility module is a grouping of commonly-needed utilities that are simple to code, and that everyone wants, but nobody actually codes them: Collapse the module page's fieldsets, Module Weight (we use this function to ensure that our custom module is invoked in the proper order in comparison with other modules), Permissions Fieldset, Type Defaults, Log_Clear and Logged_in_as. The Utility module has a number of modules included in it, as listed above. We used the Module Weight feature. It has no settings page in admin, but once installed, creates a settings field next to each module name, as shown in the following image. The higher the number, the later the module registers itself with Drupal. So, if you have a module that needs something available to it that is provided by another module, this is the way to make sure the order is correct.

[ 263 ]

Add-On Modules

Views

Location: http://drupal.org/project/views The Views module provides a flexible method for Drupal site designers to control how lists and tables of content (nodes in Views 1 and almost anything in Views 2) are presented. Traditionally, Drupal has hard-coded most of this, particularly in how taxonomy and tracker lists are formatted. This tool is essentially a smart query builder that, given enough information, can build the proper query, execute it, and display the results. It has four modes, plus a special mode, and provides an impressive amount of functionality from these modes. Among other things, Views can be used to generate reports, create summaries, and display collections of images and other content. We've seen the View pages throughout the book. The following are the permissions settings. We have withheld the ability to administer Views, because management will not be performing this function.

[ 264 ]

Custom Content Types We have used several content types in our site. Introductory information regarding the creation of a content type is presented here, followed by information about each content type that was created for this site.

CCK

Drupal is a Content Management System. As such, it is content-centric. That is, instead of being business-function centric, where various tables in a database holding business-function data are gathered together dynamically to form a piece of content, in Drupal the focus is the content. Following a new install of D6 (Drupal version 6.x), Drupal contains two content types; Story and Page. However, there is a menu choice (admin/content/types) to create a new content type. So, for example, if you are reviewing books on your site, you might want a book to be a content type unto itself. You can create a content type and name it book, but there is very little you can do, initially, to make your new content type look any different from the other two. Enter the CCK module. CCK (see more information in Appendix A) is a module originally written by Yves Chedemois (yched at drupal.org). It offers so much functionality that there are web pages, web instructions, training courses, and books just on this topic. In a nutshell, CCK gives you the ability to add fields to your content types via a simple user interface, and once added, these fields are available throughout most of Drupal, and especially, given our context, within Views.

Custom Content Types

Adding fields to a content type is as simple as giving the field a name, choosing the field type, and adding it. Field types are provided through submodules and other add-on modules, and include text fields, select lists, checkboxes, radio buttons, dates, files, and images. You can provide option lists for select lists, default values for text fields, and other configuration data. You can even define field sets, and whether a field set is viewable initially, and whether it's collapsible. The best part is that, once you have defined the fields for a content type, they appear automatically on the node create form for that content type.

Content types in the Guild Builders site

Let's take a look at the content types that were created for use in our site, and the fields in each.

About-Us Info

The About-Us Info content type is used on the About-Us page, because a view is used to present that page, and filtering a view by content type is simple. Another option would have been to set the View filter to a specific node, but this way, the node can be unpublished and another easily put in its place. Name: About-Us Info Type: about_us Description: The node that will be used on the About Us page to describe the company Submission settings: Unchanged Workflow settings: Published CCK Fields: None

Bio

The Bio content type is used to create employee biographies. Name: Bio Type: bio Description: Employee biography Submission settings: [ 266 ]

Appendix B

Title field label: Name Body field label: Bio Workflow settings: Published CCK Fields:

Job Title (field_job_title) Text field

Settings: Default Photo

(field_bio_photo) File field (image)

Settings: Default

Job

The Job content type is dual-use. Prior to a job beginning, it is used to supply prebid information to the subcontractors. Following the job's completion, it is used to provide prior work information to any potential clients. Name: Job Type: job Description:Description of a current (for bidding) or past (for displaying information) job Submission settings: Title field label:

Project name

Project description:

Project description

Workflow settings: Published CCK Fields:

Project address

(field_project_address) Text area

Settings:

Rows: 5

Bid phase

(group_bid)

Standard group

Union

(field_union)

Check boxes / radio buttons

Settings: Bidding Open

Values: Union, Non-union, N/A (field_bidding_open) Single on/off checkbox

Settings:

Values: false, Open for bidding [ 267 ]


Bid due

(field_bid_due) Text field with date popup

Settings: Site visit

Default: now (field_site_visit) Text field with date popup

Settings: Special instructions

default (field_special_instructions)

Settings:

Text area

Rows: 5

Post completion

group_completed

Standard group

Display completed job (field_display_job) Single on/off checkbox Settings: Job photo

Values: false, Display completed job (field_job_photo)

Settings:

File field (image)

Default

Project manager (field_project_manager) Node reference Settings:

(check box)

Content types- Bio

Location The location content type is used to hold a Google map identifying the location of the office. Name: Location Type: location Submission settings: Default Workflow settings: Published CCK Fields: Map (field_map)

Embedded Google Map

Settings: Default

[ 268 ]

Appendix B

Subcontractor

The subcontractor content type is used to hold profile details about a subcontractor. Name: Subcontractors Type: subcontractors Description: Subcontractor details Submission settings: Title field label: Name Body field label: Bio Workflow settings: Published CCK Fields:

Contact name

(field_contact)

Settings:

Required

Address

Text

(field_address)

Settings:

Text area

Rows: 5

Phone

(field_ phone) Settings:

Text

Size: 20, Required

Fax

(field_fax) Settings:

Text

Size: 20, Required

Cellular

(field_cellular)

Settings:

Text

Size: 20

Web site

(field_web_site)

Settings:

Text

Default

Union

(field_union) Settings:

check boxes / radio buttons

Required, Values: Union, Non-union, N/A

Bondable

(field_bondable) check boxes / radio buttons [ 269 ]


Settings: Specialties

Required, Values: Yes, No (field_specialties) check boxes / radio buttons

Settings:

Multiple selections allowed

Values: Dumpster Supplier, Rental Equipment (tools, machinery, fencing, trailers etc), Cleaning, Surveyor, Sign Company, Architect Engineer, Civil Engineer, Testing, Demolition Contractor, Concrete Cutting, Coring, Surfacing, Removal, Hazardous Waste Removal, Site Demolition, Tree Clearing and Grubbing, Erosion Control, Earth Work, Paving, Sealing Striping, Storm Piping, Water and Sewer Piping, Septic Construction, Landscaping and Irrigation Fencing, Concrete Curbs, Concrete Footers, Slabs, Sidewalks, Concrete Structural, Concrete Material Supplier, Masonry Block, Brick, Stucco, Dryvit, Decorative and Applied Stone, Marble, Granite, Masonry Material Supplier, Structural Steel Supplier, Miscellaneous Steel Supplier, Steel Erector, Railing Fabrication, Welder, Wood Framer, Light Gauge Steel Framer, Timber Framer, Finish Carpentry, Interior Trim Carpentry, Exterior Trim Carpentry, Carpentry Material Supplier, Millwork Supplier, Millwork Installer, Drywall – Install and Finish, Drywall Material Supplier, Insulation Supply and Installation, Fireproofing, Roofing – Shingle, Roofing – Membrane and Built up, Roofing – Metal, Siding, Soffit and Facia, Gutters and Downspouts, Caulking, Architectural Door and Hardware Supplier, Door Installation, Storefront Aluminum, Glass Supply and Installation, Overhead Door Supplier and Installation, Window and Skylight Supplier, Ceramic Tile Supplier, Ceramic Tile Installation, Marble and Stone Flooring, Terrazzo Flooring, Suspended Ceiling Supplier, Suspended Ceiling Installer, Flooring Installer, Flooring Supplier, Specialty Flooring (poured, heat welded, epoxy), Painting, Wallpaper Supplier, Wallpaper Installation, Specialty Wall Coverings, Bathroom Accessory Supply and Installation, Window Blind Supply and Installation, Fire Control Specialties, Miscellaneous Specialties, Loading Sock Equipment Supplier and Installation, Kitchen Equipment Supplier and Installation, Appliance Supplier, Athletic Equipment Supplier and Installation, Furniture Supplier, Laboratory Equipment Supplier, Elevator / Lift Supply and Installation, Escalator Supply and Installation, Plumbing, Gas Piping, Medical Gas Piping, Sprinklers, HVAC, HVAC Equipment Supplier, Refrigeration, Kitchen and Hood Installation, Electrical, Alarm and Security

[ 270 ]

Index Symbols tag 217 tag 217 tag 217 <select> tag 217

A About Us page 173 About Us Page display adding 185 filter Node, published 188, 189 Items to display setting, modifying 187 naming 185 previewing 189 preview post information, removing 189 row style, options 186 About Us view creating 174 add-on modules CAPTCHA module 252 CCK module 256 Contact form blocks module 256 content profile module 256 Custom (form) destination module 257 date module 257 Embed Google Maps module 257 FileField module 258 Form markup module 258 ImageAPI 258 ImageCache 259-261 ImageField 261 menu per role module 262 rules module 262 Token module 263

Utility module 263 Views module 264 Administrative theme setting 239 Analyze button 40 API 224 Application Programming Interface. See API Attachment display arguments, adding 118, 119 arguments, inheriting 88 Attach to setting, modifying 117 attaching, to Page display 207 body label values, removing 123 creating 87-94, 115, 207 Empty text entry, creating 87, 116 field content, configuring 120, 121 fields, adding 119, 208 filter content, configuring 92-94 inherit argument setting, modifying 207 item numbering, modifying 116 name, editing 116 naming 207 Node ID, adding 89 other attachment displays, creating 210 previewing 209 title, adding 87 title, modifying 91 title label values, removing 122 theming 216-218 Attachment view about 30 accomplishing 31 example 30, 31 requirements, reviewing 32 template file, creating 52

Attachment view, requirements content_profile module 32 menu 32 reviewing 32, 33 Subcontractors 32

B bio Attachment display, creating 115 view 107 view page, creating 111 Bio Attachment display adding 190 arguments, disabling 190 attach to 191 fields, adding 192 name, altering 190 node selections, filtering 194 previewing 195, 198 title, sorting 193 bio page display adding 175 arguments, adding 177 Body field 180 fields, adding 177, 178 Items to display setting, modifying 176 job title field, adding 178, 182 naming 175 Node type filter, adding 182 path 176 photo field 179 previewing 183 Title field 180, 181 bio view created view, panel 108 creating 107 filters, adding 109, 110 sort criteria, adding 110, 111 theming 130-137 bio view, theming adding, to CSS file 137 display arrangement 134, 135 sections 130 Block adding 95

basic settings 96 creating 95, 96

C CAPTCHA adding, to contact form 71, 72 CAPTCHA module about 252 challenges, defining 253 color, setting 255 default behavior, defining 253, 254 font, setting 255 images, styling 255 permission, setting 256 CCK module 256, 266 clean URLs enabling 240 CMS 7, 8 contact form CAPTCHA, adding 71, 72 Contact form blocks module 256 contact subsystem configuring 58-61 contact us page attachment display, adding 73 attachment view content, creating 73-78 contact-us view creating 62, 64 Content Construction Kit. See CCK module Content Management System. See CMS Content profile module about 256 settings 257 content types, Guild Builders site About-Us Info 266 Bio 266, 267 Job 267 location 268 subcontractor 269, 270 control panel view Attachment display, creating 206 creating 202 control panel view, creating default display, settings 202 Nid field label, removing 204 Node title field, configuring 205 [ 272 ]

sort criteria, adding 205, 206 starting with 202 custom content types titles 42 Custom (form) destination module 257

H

D

ImageAPI module about 258 image quality, setting 259 ImageCache about 259 administer permission 261 bio type 259, 260 flush permission 261 full preset 260 preset bio, editing 260 ImageField 261 input formats about 242 Full HTML, specifying 242 Internet Relay Chat. See IRC IRC 29

date module 257 Drupal CMS 8 contact subsystem 57 content types 265 User 0 223 Drupal 6 tasks 251

E Embed Google Maps module 258 Error reporting about 240 setting, changes 240

F FileField module about 258 uses 258 File system about 241 settings 241 filtering 142 front page news block, creating 228 peekaboo login box, creating 222 role-specific menu, making 219 RSS Feed, creating 234 theme region, adding 226

G Guild Builders module .module file, creating 66-71 about 65, 66

home page. See front page

I

J Job Attachment display, creating about 160 argument, adding 161, 162 attaching 160, 161 empty text 163 field content, configuring 165 fields, adding 164 Items to display setting, modifying 160 output, theming 166 settings, summary 167 job selection display, creating default settings, modifying 141 default settings, summary 146 filters, adding 143, 144 filters settings 142 Node: Published field 144 Node: Type field 145 sort criteria, adding 141, 142 Job view Block 94 management display page 97 Page display 80 [ 273 ]

K

P

key # weight key 6, 7 key 0 42 key 1 42

Page display adding 81 arguments, adding 83 creating 80-86 fields, rearranging 85 Items to display value 82 Node view, creating 80 previewing 86 title, entering for page 82 title, setting 81 Page display, control panel view configured Page display, previewing 215 configuring 206-214 path, naming 206 peekaboo login box about 222 creating 223-225 need for 222 performance page about 243 normal caching 243 permissions block module 246 comment module 246 contact module 246, 247 content module 247 node module 247, 248 path module 248 search module 248 statistics module 249 system module 249 taxonomy module 249 upload module 250 user module 250 Prior Jobs Attachment display attach to 126 creating 124, 125 fields, rearranging 129 Inherit arguments 124 position 125 relationship content, configuring 127, 129 relationships, adding 126

L logging about 242 database logging 242, 243 Syslog 242, 243

M management page display access, options 101 access, restricting 100, 101 creating 98, 101- 106 field Node, configuring 102 fields, adding 102-104 Page display, adding 97 Page display, naming 97 previewing 106 sort criteria, adding 104, 105 view, styling 99 view title, adding 97 module about 65 embed_gmap module 73 Guild Builders module 65

N news block assigning, to region 233 authenticated user, selecting 229 configuring 233 display, adding 228 fields, configuring 229, 230 filters, adding 231, 232 previewing 232 sort criteria, adding 230, 231 title, adding 228, 229

[ 274 ]

prior-work Attachment display comparing, with Bio Attachment display 196 previewing 197, 198 prior-work Bio Attachment display, creating arguments, adding 155 attached to 153 display, adding 152 display name, editing 152 field content, configuring 157 fields, adding 157 fields, rearranging 158 Node title field, editing 156 Photo field 156 relationship content, configuring 154 testing 158 prior-work Page display, creating about 146, 184 field node, configuring 149-151 fields, adding 148, 149 pager, using 147, 148 path, setting 147 settings 151 view tittle, adding 147 prior-work view, creating Bio Attachment display used 152 Job Attachment display used 159 job selection display used 139 Page display used 146 prior-work view, theming about 168 display arrangement, previewing 170 final version, previewing 172 Job display, coding 169 Job display, theming 168 output, styling 170 template files, saving 171 project website 25, 26

R roles about 245 creating 245 role-specific menu, making block page 222 Guild Builders menu 220

menu choices, creating 220, 221 Role specific visibility settings, modifying 222 steps 219 RSS Feed display, creating 234 filters, adding 236, 237 Node title, providing 234 path, creating 235 previewing 237, 238 sort criteria, adding 235, 236 title, adding 234 rules module about 262 permission settings 262

S search settings page index, adjusting 244 re-index site button 244 Subcontractor Attachment view arguments, adding 42, 43 Attachment setting pane 44 field_website 45 fields, arranging 46 Live preview 47 Override button 41 previewing 47 Subcontractor page Analyze button 40 fields, adding 38, 39 Live preview section 40 path, defining 40 Sort criteria, adding 36, 37 View analysis 40 view, creating 34-36 subcontractor view, theming components 48 template file, selecting 48-52

T taxonomy vocabulary, creating about 9 front page changes 10

[ 275 ]

tag, adding 10 view, creating 11 template file creating 52 creating, steps 52-55 theme region adding 227 editing, into file 226 Token module 263

U User 0 223 Utility module about 263 Module Weight feature 263

V view about 11, 30 creating 12, 13 filters, creating 13-18 menu choice, creating 23-25 nodes, selecting 13 previewing 20 row style options 19 selection, narrowing 20-23 view page, creating display, creating 111 fields, adding 113-115 title 112 Views module about 264 permission settings 264 uses 264

[ 276 ]

Thank you for buying

Drupal 6 Attachment Views Packt Open Source Project Royalties

When we sell a book written on an Open Source project, we pay a royalty directly to that project. Therefore by purchasing Drupal 6 Attachment Views, Packt will have given some of the money received to the Drupal project. In the long term, we see ourselves and you—customers and readers of our books—as part of the Open Source ecosystem, providing sustainable revenue for the projects we publish on. Our aim at Packt is to establish publishing royalties as an essential part of the service and support a business model that sustains Open Source. If you're working with an Open Source project that you would like us to publish on, and subsequently pay royalties to, please get in touch with us.

Writing for Packt

We welcome all inquiries from people who are interested in authoring. Book proposals should be sent to [email protected]. If your book idea is still at an early stage and you would like to discuss it first before writing a formal book proposal, contact us; one of our commissioning editors will get in touch with you. We're not just looking for published authors; if you have strong technical skills but no writing experience, our experienced editors can help you develop a writing career, or simply get some additional reward for your expertise.

About Packt Publishing

Packt, pronounced 'packed', published its first book "Mastering phpMyAdmin for Effective MySQL Management" in April 2004 and subsequently continued to specialize in publishing highly focused books on specific technologies and solutions. Our books and publications share the experiences of your fellow IT professionals in adapting and customizing today's systems, applications, and frameworks. Our solution-based books give you the knowledge and power to customize the software and technologies you're using to get the job done. Packt books are more specific and less general than the IT books you have seen in the past. Our unique business model allows us to bring you more focused information, giving you more of what you need to know, and less of what you don't. Packt is a modern, yet unique publishing company, which focuses on producing quality, cutting-edge books for communities of developers, administrators, and newbies alike. For more information, please visit our website: www.PacktPub.com.

Drupal 6 Themes ISBN: 978-1-847195-66-1

Paperback: 312 pages

Create new themes for your Drupal 6 site with clean layout and powerful CSS styling. 1.

Learn to create new Drupal 6 themes

2.

No experience of Drupal theming required

3.

Techniques and tools for creating and modifying themes

4.

A complete guide to the system's themable elements

Learning Drupal 6 Module Development ISBN: 978-1-847194-44-2


A practical tutorial for creating your first Drupal 6 modules with PH 1.

Specifically written for Drupal 6 development t

2.

Program your own Drupal modules

3.

No experience of Drupal development required

4.

Know Drupal 5? Learn what's new in Drupal 6

5.

Integrate AJAX functionality with the jQuery library

Please check www.PacktPub.com for information on our titles

Drupal 5 Views Recipes ISBN: 978-1-847196-96-5


94 recipes to develop custom content displays for your Drupal web site I 1.

Display particular types of content in unique and compelling ways on your Drupal web site

2.

Enhance your web site with calendars, timelines, galleries, maps, podcasts, Views Fusion, and more

3.

Indispensable resources for Drupal 5 Administrators – Drupal Administration Menu, Views Bulk Operations, ModuleInfo, and Editable Fields modules

Drupal 6 Search Engine Optimization ISBN: 978-1-847198-22-8


Rank high in search engines with professional SEO tips, modules, and best practices for Drupal web sites 1.

Concise, actionable steps for increasing traffic to your Drupal site

2.

Learn which modules to install and how to configure them for maximum SEO results

3.

Create search engine friendly and optimized title tags, paths, sitemaps, headings, navigation, and more


Drupal 6 Performance Tips ISBN: 978-1-847195-84-5


Learn how to maximize and optimize your Drupal framework using Drupal 6 best practice performance solutions and tools 1.

Monitor the performance of your Drupal website and improve it

2.

Configure a Drupal multisite environment for best performance

3.

Lot of examples with clear explanations

Drupal 6 Site Builder Solutions ISBN: 978-1-847196-40-8


Build powerful website features for your business and connect to your customers through blogs, product catalogs, newsletters, and maps 1.

Implement the essential features of a business or non-profit website using Drupal

2.

Integrate with other "web 2.0" sites such as Google Maps, Digg, Flickr, and YouTube to drive traffic, build a community, and increase your website's effectiveness

3.

No website development knowledge required

4.

Complete example of a real world site with clear explanation


Drupal for Education and E-Learning ISBN: 978-1-847195-02-9


Teaching and learning in the classroom using the Drupal CMS 1.

Use Drupal in the classroom to enhance teaching and engage students with a range of learning activities

2.

Create blogs, online discussions, groups, and a community website using Drupal.

3.

Clear step-by-step instructions throughout the book

Drupal Multimedia ISBN: 978-1-847194-60-2


Create media-rich Drupal sites by learning to embed and manipulate images, video, and audio 1.

Learn to integrate multimedia in your Drupal websites

2.

Find your way round contributed modules for adding media to Drupal sites

3.

Tackle media problems from all points of views: content editors, administrators, and developers


Drupal 6 Attachment Views

Drupal 5 Views Recipes

Drupal 5 Views Recipes

Drupal 7 Views Cookbook

Drupal 7 Views Cookbook

Drupal 5 Views Recipes

Drupal 7 Views Cookbook

Drupal 6 Content Administration

Drupal 6 Content Administration

Drupal 6 Social Networking

Drupal 6 Social Networking

Drupal 6 Social Networking

Drupal 6 Content Administration

Drupal 6 Site Blueprints

Drupal 6 Panels Cookbook

Drupal 6 Performance Tips

Drupal 6 Performance Tips

Drupal 6 Theming Cookbook

Drupal 6 Social Networking

Drupal 6 Performance Tips

Drupal 6 Social Networking

Drupal 6 Content Administration

Village Views (Book 6)

Learning Drupal 6 Module Development

Drupal 6 JavaScript and jQuery

Drupal 6 JavaScript and jQuery

Drupal 6 JavaScript and jQuery

Drupal 6 JavaScript and Jquery

Drupal 6 Site Builder Solutions

Drupal 6 JavaScript and jQuery

Drupal 6 Search Engine Optimization

Drupal 6 Attachment Views

Drupal 5 Views Recipes

Drupal 5 Views Recipes

Drupal 7 Views Cookbook

Drupal 7 Views Cookbook

Drupal 5 Views Recipes

Drupal 7 Views Cookbook

Drupal 6 Content Administration

Drupal 6 Content Administration

Drupal 6 Social Networking

Drupal 6 Social Networking

Drupal 6 Social Networking

Drupal 6 Content Administration

Drupal 6 Site Blueprints

Drupal 6 Panels Cookbook

Drupal 6 Performance Tips

Drupal 6 Performance Tips

Drupal 6 Theming Cookbook

Drupal 6 Social Networking

Drupal 6 Performance Tips

Drupal 6 Social Networking

Drupal 6 Content Administration

Village Views (Book 6)

Learning Drupal 6 Module Development

Drupal 6 JavaScript and jQuery

Drupal 6 JavaScript and jQuery

Drupal 6 JavaScript and jQuery

Drupal 6 JavaScript and Jquery

Drupal 6 Site Builder Solutions

Drupal 6 JavaScript and jQuery

Drupal 6 Search Engine Optimization

Recommend Documents