Planet Drupal

In this episode, Addison Berry is joined by Holly Ross, the Executive Director of the Drupal Association (DA). We talk about who Holly is, where she's come from, and here role in the DA. There is some timely discussion about transparency and communication for the DA and the community, and how Holly looks to address these concerns.

Podcast notes

Module Monday videos
Drupal Global Sprint Weekend, March 9-10

Holly's DA blog

Contact Holly
Email: holly@association.drupal.org
Twitter: @drupalhross

Release Date: March 8, 2013 - 10:00am Album: Lullabot Podcast Length: 41:48 minutes (24.1 MB) Format: mono 44kHz 80Kbps (vbr)

On March 15, the PHP version requirement for Drupal 8 will be increased to 5.3.10. (We are giving developers a week's advance notice so that they can update their Drupal 8 development environments.)

For background information on this change, see the Drupal 8 issue: http://drupal.org/node/1800122

Looking back over my blog it's made me realise how much Drupal has pushed the company forward and how at the same time we've been able to help the community along the way. I thought I'd put this post together as a bit of a retrospective and a starting point for how the blog is going to change in the coming months.

We're riding the crest of the wave that is Drupal's burgeoning popularity amongst the masses, not just the few and in sharing our most popular recent Drupal related posts it will help those recent adopters at the same time.

So here's our most popular recent Drupal posts and do look out for a further post on how the blog will shape up in future, more posts for beginners coming soon.

The Ultimate Resource For Drupal Beginners

After responding to a question on Linked In I'm a Drupal newbie, do you know of a free online course that can help me understand better how to use and manage Drupal? I thought I'd take the answers and then develop them further into this guide.

read more

Views block area is a simple module that allows you to insert a custom block into the header or footer of your View. Blocks generated by Views will not work in here but don’t worry, that’s taken care of by the default View Area provided by Views.

Panels is the kind of module that people usually either love or hate. In case you didn't guess from the title, I'm part of the first group and it is one of my must-install modules[1].
However, like many others, the first time I gave it a try, I just overlooked and gave up on it quickly. While it is now far more widespread than it was back then, there's still a lot of misunderstanding going on, more or less for the same reasons I had overlooked it myself, and with the same arguments against it coming back over and over.
I won't try to cover all pros and cons, but will attempt to clarify a bit what benefits you can expect and the most common misconceptions.

So, lets start with what I believe is the main source of misunderstanding, and the source of most other arguments against it: Panels' purpose, what it is and it is not.

"Panels module is a UI to place content on my site's pages"

That's too often the way people define it, and that's exactly where the trouble begins [2]. While not enterly false, this assertion misses the whole "bigger picture" and leads to two reactions:

1. "How will my content producers understand how to use this overcomplicated UI"
   Let's get this straight out off the way:Panels is not made for end user content producers. It's for devs and site builders, and requires a good knowledge of how Drupal works.  Whoever told you differently has been misleading you [3].
2. "I can code, I'd rather place content myself using template files, that's so much neater and lean than this bloated interface"
   Let's try to get what Panels is about: it is not about content placement, at least this is only a tiny part of it. To truly understand what Panels is at heart and its benefits, you need to picture it as a global, unified way to make various and heterogeneous Drupal "objects/thingies/concepts" interact smoothly together: menu router paths, entities, theme layer, views, …
   In practice, it means Panels loads what it calls "contexts", most commonly entities like users, nodes, taxonomy terms, and makes every element on the page content aware of these contexts. This allow for infinite flexibility in the display of elements on the page, such as changing the whole layout, displaying (or not displaying) a given element, replacing an element with another, etc. according to any properties of the loaded contexts. Typically, this means you can build a page without any hacky coding that would display:
   • an article node's body in its center column;
   • a separate "block" on the right column that contains the node's file attachments, available to certain user roles only, replaced with custom text for other authenticated users, and with the login block for anonymous users;
   • another "block" underneath with a view of the 5 last nodes in the same category taxonomy as the viewed node;
   • Use another layout for article nodes that have a "main picture" field filled up.

   You can do that, obviously, by other means than Panels, loading global $user, call drupal_render a couple of times and have a go at taxonomy_term_load and views_embed_view, get a bunch of checks in preprocess functions, maybe implementing hook_menu_alter to take over node's path, etc. [4] Results can range from the hackiest "stuff it all in template files" to more sophisticated and clean solutions, but in the end, you'll face the same problems: no reusability, plenty of code replicated all other the place as every different page will need some different checks, and a whole bunch of template files to maintain. The more complex your site gets, the more unsustainable this becomes.

   Think of it like Views. You could query the db yourself, render the results in various ways, here again with a range of solutions going from hardcoded html to proper calls to Drupal's rendering system, but only the foolish would do so. So much is provided by Views that you just go to the UI, build your view, export it and forget about it. Same goes with Panels: yes, you'll have to use the UI at some point, but don't you see the endless possibilities its flexibility provides?

   Well, I hope you do. So let's have a look at a few other common assumptions.

"Panels module is heavy, slow and suffers performance issues"

The answer is simply No. It's true that it will load what looks at first sight like a giant spaghetti of php objects, that will end up in memory. Beside the fact than most of these are already loaded by Drupal itself anyway, try to imagine the actual process: Panels loading all the contexts just once, passing them to each page element ready to use on one hand, versus on the other, each element on the page making its own computation to retrieve and load the same information everytime. Result seems pretty obvious, no? [5]

As a bonus, Panels ships with an efficient and granular cache system. For each path and variants, you can set cache settings for each individual element on the page: set it well and your page will be blazing fast.

"Panels module is redoing/taking you away from Drupal's core"

A more conceptual argument you sometimes hear. Panels unarguably adds some layers over some concepts, like menu router or content display, and drops some others, like blocks or regions. Truth is there's no choice but doing so, to be able to overcome the inner limitations of core. How do you expect to build something a system can't do itself without extending and overriding it? That is exactly what hooks are intented for. 
Now, what do you prefer: let Panels do this for you in a clean and unified way that retains Drupal's standards, or reinvent the wheel everytime in a way that will most certainly be clunky and difficult to maintain, that no one but you can understand and that you yourself probably won't understand anymore in 6 months? I've made my choice.

If the scope of Panels is becoming a bit more clear for you, let's see a few more cool things it provides. There's much more, but these seem key to me:

• Exportable in code:if you use the "zero-touch" approach, everything's exportable using CTools, hence Features, even custom content. Compare to core's blocks!
• Tight views integration:Panels is able, when set on the view, to override some of the view's settings. This means you can do any crazy thing you might want: changing the number of results, altering arguments, pagers, whatever, based on context.
• Extendable:You can write your own plugins or handlers for anything Panels doesn't provide out of the box: contexts, displays, variant types, … To be honest, it means you'll have to learn a bit there, and depending on what you're trying to do, documentation might be "light" on certain subjects.
  However, in 99.9 % of the cases, the only things you will ever need to code are: 
  1. layout template files (Oh, back are our beloved template files, yay, known territory!)
  2. content type plugins, for custom "panes" which are the equivalent of creating a custom block type using hook_block_info, and quite trivial to create.

 

I shall try to sum-it up. Tricky. Probably the main thing to keep in mind is this: If you consider Panels as a UI to do your theming job, you'll be disapointed and frustrated. If you take it as a powerful new way of architecting and building your site, you'll be delighted. 

So yes, you will need to learn a few things and new concepts, but believe me, it's worth it.

Footnotes

1. Lot of this is in reality about ctools' « page manager » module and not panels per-se. Given the common confusion between both and for clarity, I've chosen to make no distinction and used the name « Panels » everywhere, although it renders this whole post technically innacurate. However, my point here is that if you're able to tell the difference, you probably don't need to read it! Please forgive me.

2. That's also more or less the way it is defined in the first paragraph of the project page, « Panels overview », which is sadly probably all most people will read from the entire description.

3. Yeah, there's panelizer and IPE. I know. Just trying to keep it simple.

4. You could also use a combination of other modules (context, boxes, display suite, themekey, beans,…). This is perfectly valid in certain cases, and you can combine most of them with Panels, see James talk on DS for example. But out of scope here.

5. Performance of Panels

Related Service Areas: DevelopmentTeaser: On why Panels module is one of the greatest tools around and why you should really consider using it.Categories: DevelopmentDrupal PlanetPrimary Category: DevelopmentTags: Drupal 7D7Panels

Episode Number:  123 Post Topics:  Drupal Contrib Drupal 7 Image Handling Drupal Planet

The Drupal 7 Cloud Zoom module makes it easy to zoom in on a Drupal image. The Cloud Zoom module creates an image display formatter that can be used for various types of images including image galleries, product images, and more.

In this episode you will learn:

• How to use the Cloud Zoom display formatter on a content type image
• How to use the Cloud Zoom display formatter to create a simple image gallery

DDoD Video: 

read more

 

I recently ran into an issue on one of our projects with a Git repository that stumped me for a few days. It was a small project: only three developers committing to a single repository hosted on Pantheon. I kept on running into an issue where I (or any of the other developers) could ever get my local repository to a “clean” state.

-->

read more

Drupal 8 comes with a new guided help API in the form of the Tour module. PreviousNext put a lot of effort into getting this module into Drupal 8 core prior to feature freeze and are excited by the possibilities it presents to ease the learning curve for new Drupal site-builders.

In part 1 of this post - we told the tale of how this module came to fruition. In this post, part 2, we provide examples of how you can add tour module support to your modules and talk about some of the advanced features of the API.

As I was writing the Last minute Sprint Weekend post, I was thinking, uh, worrying:

What have I done? Will people show up in irc and expect mentors to be there? Sprint Weekend started off as local sprints, and now it is online too. I cannot ask the regular crew of Core Office Hours mentors to be on irc for a whole weekend (Sprint Weekend is global and so practically around the clock) for an event they did not propose or plan. What will happen? How will this thing scale?

And then I thought, uh, had a hope:

We are all mentors.

It will be OK. Someone will be on irc, and they will know more than someone else who is asking how to contribute. Even new people know more about how to work on Drupal than other really new people.

Things regular people can do

• Welcome people. When you see someone who does not know how to use irc. Welcome them. Ask if they are new. Then, use the the irc? factoid to point people to the instructions for how the Drupal community uses irc.
• If someone asks a vague question, help them ask a more specific one. Even if you do not know the subject matter, getting people to be specific opens the opportunity for someone else to chime in with information. Also, sometimes talking out loud (typing out loud) leads the person asking the question to realize something for themselves.
• If someone asks a question and you have had that same question, respond: I was wondering that too. When you do this, it helps because the person asking does not feel alone.
• Answer questions if you know something while you wait for an answer to your question. Sometimes it pays to wait 20 minutes or so after asking a question. During that time, don't be bored. Help someone.
• If you get pm'd, redirect back to the channel. Sometimes, new folks click on a name in their irc client and do no realize what that might do. It's rare to need to private message. If someone pm's you, let them know the benefits of keeping the conversation in the general channel. The pm-ask? factoid has a good explanation.
• Encourage people to open an issue. Sure it might be a duplicate, but at least there will be an issue to mark duplicate later. Often, new people think that if they ask in irc, there is no need to also open an issue. Let them know that it helps to put details in an issue, and then paste a link to their issue into irc.

To do these things, one does not need to know symfony, or plugins, or how to write tests, etc. But, by being a mentor in this way, by being engaging and welcoming, anyone can grow the community.

We are all mentors.

ps. Brainstorming help from xjm and ZenDoodles.

Weiterlesen

By Heather James

If you're responsible for building and skilling up a team to develop Drupal sites, I'm going to introduce you to three inspiring internship programs you should know about. I'm also going to show you what is working in those programs to give you some ideas of how you can build your own team and give someone a great chance to change their lives.

My previous post, Preparations for Sprint Weekend, has some good resources and information (like what to bring with you to a sprint). Also, check the g.d.o page that lists locations and Dries's blog about the weekend.

In this update, are some last minute things.

On the day, locally or remotely:

• Be really nice to new folks.
• Get people on irc in #drupal and #drupal-contribute Because, even when working in-person, irc is handy to share links and use the bot. And remotely, well, you get to coordinate, get help, and get to joke with Drupalers.
• When working on issues, make a comment on the issue saying what you are about to do. This helps to avoid duplicate work.
• Reload issue pages before making a comment to see if someone else has commented since the last time you loaded the page.
• It's encouraged make comments on Drupal.org issues to: ask questions, give intermediate results, etc.
• Check twitter #SprintWeekend for announcements and chit-chat.
• Share photos.

Countdown to March 9!

Weiterlesen

Stanford University is home to a large and growing number of Drupal sites. Drupal’s qualities as a platform – flexibility, extensibility, and speed of development, to name a few – are part of this equation, of course. The other, vital component of this success is the efforts of a grassroots community of Drupal users at Stanford over the last few years. They have not only created great websites for the university, they’ve also dedicated time and effort to helping others succeed with Drupal and spread the word.

Twitter Timeline module released back to the Drupal community

Often times, a client will come to us asking how to embed some random script into one of their pages. One simple answer that we could give them is that they can copy and paste the embed code directly from the widget providers website into their page content. However, whislt it sounds nice and easy, it's actually not such a great idea. What happens when the widget provider changes their API or widget code? You'll end up with lots of broken widgets scattered throughout your site. How do keep track of all of the different widgets that have been embeded throughout your site? You can't!

I was sitting at home recently thinking "I wonder how life is going to change when Drupal 8 is released for production websites". So when I arrived at the office the following morning, I was determined to investigate that question. I cut my teeth on Drupal development with version 6, and since then I've developed a fair number of Drupal 7 sites. The features and advancements between those versions was exciting, and the features planned for Drupal 8 just continue to fire my enthusiasm for the product. I'm well aware that Drupal 8 isn't ready for prime time yet. But I'm sure there a large population of Drupal developers wondering, like me, what to expect when version 8 is finalized.

It didn't take long to run into a fairly substantial hurdle. I found a page to download the Drupal 8 development release package directly, as I've done with previous versions. But acolleaguehad tried that recently and ran into a critical bootstrap error. In reading through several forum posts, the community suggests getting the code from Drupal's GIT repository. I'm new to GIT, but the Drupal community makes heavy use of the tool, and it only makes sense to tie into the versioning and contribution features that it provides. I suspect that as Drupal evolves, we'll all be moving away from downloading compressed archives in favor of interacting with these GIT repositories.

Once I figured out GIT well enough to clone the Drupal.org repository for version 8.x, I configured a local install of XAMPP to point at the directory where I had stored my files. I created a local database to use in the install script and proceeded through the typical setup wizard for a Drupal site. I didn't notice many differences about the install scripts compared to Drupal 7, although it was quite exciting to see that it was installing the views modules as part of the core.

Admin Bar Improvements

Finally, I had a working Drupal 8 site at my disposal. The first thing that I noticed was updated styling/layout for the admin bar. That bar was new for the Drupal 7 core, and available as an add-on module for Drupal 6. I've found it to be quite indispensablefor navigating the admin pages of the site. The pill shaped menu items are gone now, and they've been replaced with rectangular buttons with an associated icon for each. I wasn't terribly thrilled with the extra 'flash' that those icons provide until I realized that they have a very real purpose when the admin bar responds to narrow screen widths. Basically, the text labels go away and you only have buttons with icons. All of the items that we were familiar with in Drupal 7 have been compressed into a single 'Menu' button for the Drupal 8 admin bar. Clicking this button displays another menu bar below the main one, and you now have the option of docking the menu horizontally under the main bar (default), or vertically at the left side of the page. For narrower screen widths, this secondary menu switches to the vertical layout automatically, although you still have the capability to change it back to horizontal.

BUG NOTE: There's a mysterious pencil icon at the left side of the admin menu. Clicking it causes toggles the background color of the button either blue or black, but doesn't seem to affect anything else. I'll be interested to see what they have planned for that.

Appearances

The Drupal 8 development release comes packaged with 'Bartik 8.0' as the default site theme and interestingly enough, 'Seven 8.0' as the admin theme. 'Stark 8.0' is also included, but disabled by default. The settings pages for these themes haven't changed much from Drupal 7, so I don't have much to comment on. I changed the default colors for Bartik to represent my Alma Mater, Oklahoma State University, and I moved on to more interesting things. The overall user interface has a couple notable updates though, particularly when you are logged in. The gear icons for block settings that we saw in Drupal 7 have been replaced with a Pencil icon. Several of the inline admin links in Drupal 7 have been styled as buttons in Drupal 8, and they remind me of the styling seen in the Twitter Bootstrap library. The Bartik theme now behaves responsive depending on the overall screen width.

New and Exciting Core Modules

First off, the menu item previously titled 'Modules' is now called 'Extend'. Luckily, it falls in the same position relative to the other links in the admin menu, so there was no doubt about where that link was going to take me. This is by no means a comprehensive list of the new modules for Drupal 8, but these are the ones that I'm most excited about:

• CKEditor - One of my biggest complaints about Drupal 7 is that it's not packaged by default with a good WYSIWYG. The CKEditor modules is disabled by default, but it's in the core. There's a requirement to enable the 'Text Editor' module, but that's provided in the core as well. BONUS: You don't need to download the CKEditor library manually anymore. It's included as well.
• Email Field - Automatically validates the format of provided email addresses, and generates a 'mailto:' link when displayed.
• Entity Reference Field - This CCK field type is key to creating relationships between content types. I've watched it grow from 'Node Reference' in Drupal 6 to 'Reference' in Drupal 7 before being included in the core for Drupal 8. As the name implies, it's useful for linking to much more than just nodes and users now. If you can define an entity in Drupal, this field will link to items of that type.
• Picture - I had never heard of this module prior to writing this post, but it's presence and description caught my eye immediately. It claims to resize images toaccommodatechanges in HTML5 responsive designs.
• Telephone Field - Generates a 'tel:' link when displayed. Useful for telephony apps like Skype and corporate phone systems that include desktop clients for making calls.
• Views - It only makes sense for this to be in the core. When they added CCK to the core in Drupal 7 I was surprised that views wasn't included as well. CCK and Views go hand-in-hand like french fries and ketchup. My thoughts on this one: It's about dang time.

Join me next week for Part 2 of this series. I'll be investigating Drupal 8's changes in content editing, including updates to the node form and block settings.

Category:  Drupal Best Practices Drupal Planet Drupal Training Watch our webinar on how we created a Drupal API portal for New York City's subways that uses Varnish caching, Edge Side Includes and custom bootstraps to deliver up to 5,000 hits per second.

There are many metrics for measuring a Drupal project's success. Matching budget estimates, minimizing scope creep, and hitting a launch date are vital goals for any project. However, the key factor for success is good communication throughout the project.

In the 9 video of this 10 part Drupal video tutorial series, I walk you through cloning, exporting and importing views. In doing so, I explain common use cases for each and show you how to take exported views and incorporate them in your custom module so that users are provided with a default view when they enable your module.

As an added bonus, I even introduce you to Susie at the end of the video tutorial... though she looks very unhappy about being picked up, trust me, she's not.

In part 1 of this series, we created a basic "complaints" form using Entityforms and attached a few fields to the form. We also setup email notifications for when a form is submitted using "Entityforms Notifications" module.

In this final part, we'll look into the Rules integration with Entityforms. We'll learn about and create an access, submission and validation rule. After we've played around with the different types of rules you should have a better understanding of how they work.

Drupal 8 comes with a new guided help API in the form of the Tour module.

Here at PreviousNext we were instrumental in getting this module in prior to feature freeze and are excited by the possibilities it presents to ease the learning curve for new Drupal site-builders.

In this post we discuss how the module came about, how we went about building support for the idea and the way the API works.

In part two we will go on to show some examples of how you can add tour module support to your modules and talk about some of the advanced features of the API.

Drupal 7.21, a maintenance release which fixes incompatibilities introduced in the Drupal 7.20 security release, is now available for download. See the Drupal 7.21 release notes for further information.

Download Drupal 7.21

Upgrading your existing Drupal 7 sites is strongly recommended, especially if you encountered problems with Drupal 7.20. There are no new features in this release. For more information about the Drupal 7.x release series, consult the Drupal 7.0 release announcement.

Security information

We have a security announcement mailing list and a history of all security advisories, as well as an RSS feed with the most recent security advisories. We strongly advise Drupal administrators to sign up for the list.

Drupal 7 includes the built-in Update Manager module, which informs you about important updates to your modules and themes.

There are no security fixes in this release of Drupal core; however, sites which were unable to upgrade to Drupal 7.20 (or upgraded but made modifications to disable the security fixes included within it) should upgrade to Drupal 7.21 to obtain additional security protection. See the Drupal 7.21 release notes for further information.

Bug reports

Drupal 7.x is being maintained, so given enough bug fixes (not just bug reports), more maintenance releases will be made available, according to our monthly release cycle.

Changelog

Drupal 7.21 is a bug fix only release. The full list of changes between the 7.20 and 7.21 releases can be found by reading the 7.21 release notes. A complete list of all bug fixes in the stable 7.x branch can be found in the git commit log.

Update notes

See the 7.21 release notes for details on important changes in this release.

Known issues

None.