When the GRAMMYs wanted to rebuild their members-only professional networking site they turned to the experts at Metal Toad. Together with Lullabot and the Drupal Commons team at Acquia, we created GRAMMY Pro. A brand new site built in Drupal 7 that addressed all the concerns of the predecessor GRAMMY 365 - taking the networking opportunities of the membership to a whole new level.Summary: .Objective:
Build a new professional networking site for the music industry.Industry: EntertainmentFiled under drupal, cms.Show in grid: 1Active: inactive
Taking over an existing site from a contract developer or company that doesn't primarily build Drupal sites (or even some that do) can often be a daunting task.
Often we find our clients assume that all Drupal sites are created equal, and as we're taking it over we can just dive right in and start developing. Unfortunately that's not always the case so we end up doing a site audit.
A site audit accomplishes a couple things:
Many organizations adopt Open Source for reasons like flexibility and agility. Everyone needs to do more with less. But in government, Open Source drives both civic engagement and government participation like never before. Because of digital, the world feels much smaller and more connected. And Open Source gives people the opportunity to rally around a cause, no matter where they live.
Think about how we petitioned our government before we had the We The People website. I bet you have to think pretty hard about how it was done (I do!). Now, a website has brought to life the First Amendment rights of U.S. citizens. Millions of people's voices are heard. People pull together based on common concerns. The White House built We The People using Drupal and shared the code on GitHub, opening up the opportunity for other governments to easily create their own online petitioning systems.
Now, all kinds of open government data made available through the Data.gov project makes it possible for any developer, anywhere, to create a civic app. These apps have made us see our cities and towns in a different light.
Open City is one example of a group of local volunteers who create Open Source apps using government data. While the group is based in Chicago, the idea is that any city can grab code from an Open City app and make it their own.
Here are a few interesting examples: Clear Streets tracks a city's plows in real time. Living outside of Boston, I know we could use an app like that! Crime in Chicago lets citizens compare crime statistics in certain areas of town, which could be useful for people making decisions about where to move their families.
What is perhaps the most gratifying is that as open-source developers, we can collaborate on projects and help people around the world. It's part of what gets us out of bed in the morning. Earlier this year, participants in DrupalCon Portland launched a website in 24 hours to help people in Moore, Oklahoma, find transportation and housing after the tornado. Two weeks later, the site was discovered on Twitter in Germany and was repurposed to help people affected by the flooding in northern Europe. This type of project inspires us all to see how technology can make an immediate difference.
Other events, such as the National Day for Civic Hacking, encourage developers to use open government data to "collaboratively create, build, and invent". The idea that hackathons can help build and create a healthy, citizen-powered technology ecosystem within government is relatively new, and full of promise. Tim O'Reilly believes that government can escape the "vending machine" mentality (citizens put in tax dollars and get out services) by thinking of "Government as a Platform" for participation. I couldn't agree more.
Open Source ideals are already spreading in governments throughout the world, with good reason. A global network of developers is motivated to help. It's one of the best examples of civic engagement. As digital citizens, we all now have the power to contribute. One person's time and talent can make a huge difference. That is a movement I'm proud to be a part of.
(I originally wrote this blog post as a guest article for VentureBeat. I'm cross-posting it to my blog.)
Stein Setvik is a Technical Consultant with Forum One. This blog post originally appeared on the Forum One blog.Personal blog tags: DrupalmigrationSEO
Metal Toad worked with the design and marketing team at Puppet Labs to create an amazing new Drupal website that allows inline GUI editing of of not only their desktop website, but also all of their responsive versions (tablet, phone, etc.). The website leverages the full power of Drupal, Panopoly and Panels Everywhere to create an admin experience that would make any power user giddy.Summary: .Objective:
Create a Drupal-powered marketing website to showcase Puppet Labs amazing DevOps software.Industry: TechnologyFiled under drupal, development, cms.
Do you have questions about the upcoming Drupal 8 release? On Thursday, September 26 at DrupalCon Prague, I'll be moderating a question-and-answer core conversation with a panel of Drupal 8 leaders, including core committers and initiative leads. Questions are submitted in advance online, and anyone can submit a question. I will curate the submissions to ask the panel the most interesting and relevant questions. We'll also publish the full list of submissions after DrupalCon (with personal information removed) so that the community has a chance to get answers for questions we don't have time for during the session.
This is a rare opportunity for the community to communicate directly with the decision-makers who are shaping Drupal 8 into the best release of Drupal yet. Help us make the most of of it -- submit your questions now!
Panels and Display Suite are two very popular Drupal modules.
Both Panels and Display Suite allow you to control the layout of your Drupal content without any code.
Last month we did a 2 part video series with Acquia, introducing both Panels and Display Suite.
If you're new to these modules, watch the videos below to learn how to re-design your homepages, content, landing pages and much more.
Multistep forms are a great improvement to the user experience, especially if a form has a lot of fields. The problem is, when you have required fields on a particular step, and the field is not filled in, the user will get a validation error when hitting back. But fear not. You can still have your nice multistep form and get rid of these pesky errors when hitting a back button. The problem is solved by adding the #limit_validation_errors property to the back button.Tags: Drupal Module DevelopmentPlanet Drupal
Now's the time! As we announced on August 16, we're looking to fill the two At-Large Director positions that are opening. The At-large Director position is specifically designed to ensure community representation on the Drupal Association board and we strongly encourage anyone with an interest to take part in the process.
The Board of Directors of the Drupal Association are responsible for financial oversight and setting the strategic direction of the Drupal Association. New board members will contribute to the strategic direction of the Drupal Association. Board members are advised of, but not responsible for matters related to the day to day operations of the Drupal Association, including program execution, staffing, etc.
Directors are expected to contribute around five hours per month and attend three in-person meetings per year (financial assistance is available if required). You can learn more about what’s expected of board members by reviewing the board member agreement.
Today we are opening the self-nomination form that will allow you to throw your hat in the ring.Nominate Yourself for the Drupal Association Board
To nominate yourself, you should be prepared to answer a few questions:
- About Me: Tell us about yourself! Your background, how you got into Drupal, etc.
- Motivation: Why are you applying for a board position? What initiatives do you hope to help drive, or what perspectives are you going to try and represent?
- Experience: What Drupal community contributions have you taken part in (code, camps, etc.)? Do you have experience in financial oversight, developing business strategies, or organization governance?
- Availability: I am able to travel to three in-person board meetings per year (either self-funded, or with financial sponsorship)
- IRC Handle
- Twitter Handle
We will also need to know that you are available for the next step in the process, meet the candidate sessions. We are hosting 2 sessions:Session One
- Wednesday, Sept. 11th 2013 at 01:00 UTC
- 5 PM PST Tuesday Sept. 10th in the US and Canada
- 8 PM EST Tuesday Sept. 10th in the US and Canada
- 11 PM Tuesday Sept. 10th in Sao Paulo Brasil
- 1 AM Wednesday, Sept. 11th in London
- 9 AM Wednesday, Sept. 11th in Beijing
- 2 noon Wednesday, Sept. 11th in Sydney Australia
- Thursday, September 12 2013 at 17:00 UTC
- 9 AM PST Thursday, September 12 in the US and Canada
- 12 noon EST Thursday, September 12 in the US and Canada
- 3 PM Thursday, September 12 in Sao Paulo Brasil
- 5 PM Thursday, September 12 in London
- 1 AM Friday, September 13 in Beijing
- 4 AM Friday, September 13 in Sydney Australia
The nomination form will be open September 1, 2013 through September 6, 2013 at midnight UTC. For a thorough review of the process, please see our announcement blog post.
This holiday season rather than giving another box of chocolates or a bottle of wine, consider giving a gift that can change lives. Metal Toad worked with MercyCorps to create gifts.mercycorps.org, an ecommerce websites build on Drupal & Ubercart that allows people to shop for gifts like clean water, education for girls in a third-world country or even vaccinating a village. As one of the highest rated charitable organizations in terms of transparency and efficacy, we are very proud to have worked with MercyCorps on this project.Summary: .Objective:
Create an ecommerce platform capable of handling multiple gifts in particular around the holidays.Industry: Non-ProfitFiled under ecommerce, drupal, ubercart.
We have always told attendees of our Drupal 7 "Code-driven development" trainings that embracing the idea that configuration must be stored in files and not in the database would make their Drupal development future-ready: the specific processes would necessarily change but the concept would stay and be reinforced in Drupal 8, thanks to the nice work being done in the Configuration Management Initiative.
And this was right. The progress done in CMI is very good, to the point that in our coming DrupalCon training in Prague, Code-Driven Development: an Effective Drupal Workflow, from D7 to D8 we will explore in detail how things work in Drupal 7, but for each topic we'll also describe what is going to improve/change in Drupal 8.Configuration Management in a nutshell
From a site builder's point of view, Configuration Management in Drupal 8 is visible as two items in admin/config/development: "Configuration Export" and "Configuration Import".
The Export functionality has no further options, and it provides you with a config.tar.gz file containing hundreds (180+ on a clean installation, many more on a feature-rich test site) of files in YAML format, human- and machine-readable. All the site configuration is there: node types, their fields, permissions, Views, theme settings, variables...
The Import functionality, on the converse, will import a config.tar.gz file (or a subset: you can remove files from the archive), show you any configuration changes between the currently active configuration and the one you are trying to import and allow you to (partially) replace the current configuration with the one in the provided files.
For many developers, this is a dream come true: with D8, Drupal Core will support a file-based configuration, allowing developers to track changes, put configuration under version control, update a production site cleanly... basically, all the advantages that we have described as selling points for the Features module in the last several years.The Future of Features
So, if the major selling points of the Features module are now in core, does Features have a future in Drupal 8?
It still does, but it needs to be repurposed. So far, it had a dual functionality, serving as:
A machinery to export/import configuration from database to code. This will no longer be necessary in Drupal 8. Configuration lives in files and the database is used only for caching. For the same reason, an important problem in Drupal 7 development ("How do I make configuration exportable when there is no native support for Features?") is now solved for good.
A convenient way to package and reuse configuration across multiple sites. This is extremely useful to developers and not completely covered by Configuration Management in Drupal 8, even though the basic components are there.
Let's see how it is possible to package configuration and emulate, manually, what Features and Drupal 7 allow today.
As an example use case, we will package a "Blog Feature".1: Create and export configuration
Create the Blog content type, configure its fields (use proper naming for fields: field_blog_image and so on) and a classic view with a block and page display. Then go to admin/config/development and export your configuration into the config.tar.gz file.2: Package relevant configuration into a module
Create a simple feature_blog module containing:
- feature_blog.info.yml: a basic .info file in the Drupal 8 format.
description: 'A Blog content type and related configuration.'
- feature_blog.module: an empty module file, needed for correct Drupal operations.
// Drupal needs this empty file.
- a config subdirectory: copy to this folder all relevant files from config.tar.gz; filenames are quite helpful here, as it will be enough to copy all files that have "blog" in their name.
| |-- entity.display.comment.comment_node_blog.default.yml
| |-- entity.display.node.blog.default.yml
| |-- entity.display.node.blog.teaser.yml
| |-- entity.form_display.comment.comment_node_blog.default.yml
| |-- entity.form_display.node.blog.default.yml
| |-- field.field.field_blog_image.yml
| |-- field.instance.comment.comment_node_blog.comment_body.yml
| |-- field.instance.node.blog.body.yml
| |-- field.instance.node.blog.field_blog_image.yml
| |-- node.type.blog.yml
| `-- views.view.blog.yml
`-- feature_blog.module 3: Make the exported files portable (remove UUIDs)
The feature is ready, but it will only work if imported in the same Drupal 8 site. We need to make it portable to other sites.
The main problem here is that Drupal assigns UUIDs (Universally Unique Identifiers) to each component. When you add, say, an "image" field to a content type, you create an instance of the "image" field, and to describe this relationship Drupal will rely on the UUID of the "image" field. Since UUIDs are site-specific, trying to import this configuration on another site would result in an error message like:Drupal\field\FieldException: Attempt to create an instance of
unknown field 84e904df-2f14-46e8-9700-e00c5ca3f7d3
(line 252 of .../core/modules/field/lib/Drupal/field/Entity/FieldInstance.php).
Fortunately, in this case configuration import is designed to accept either names or UUIDs for describing the field this is an instance of. So it is enough to edit all files containing field.instance in their name and manually replace UUIDs with machine names (or just add machine names), something like the following:-field_uuid: d38ea114-e6dd-442c-9a56-86943affcc0e
Note that this relies on the specific handling of the FieldInstance class and may not be a general solution.4: Import the feature on another site
Our module/feature is now ready to be imported. Just copy it to the /modules folder on another site, or a subfolder of it (this is now the recommended location to add modules) and enable it.
Your content type and configuration will be immediately available.Possible improvements
The Configuration Management in Drupal 8 will bring to Drupal Core a clean, unified, professional way to deal with configuration. There will still be the need for a module like Features for packaging and reusing configuration.
Some implementation details of Configuration Management do not behave well in this respect: for example, UUIDs are problematic and user permissions are stored in a packaging-unfriendly way (one file per each user role, with roles identified by UUID).
But, overall, the future looks bright and code-driven! And, as we have seen, it is already entirely possible to manually create basic "Features" (i.e., modules with configuration) that will work in Drupal 8.Tags: Drupal Planet, DrupalCon, Training, Code Driven Development
While Drupal 8 has been been under development for two and a half years, I haven't talked much about it. I learned long ago that it doesn't do much good to talk about an upcoming release of a CMS until the software crosses over from what most of us would consider "vaporware."
The software needs to be close to beta, allowing for normal folks to actually be able install for testing purposes with a reasonable amount of certainty we don't need to be a developer. If you're a loyal reader of Planet Drupal, by now you should be getting a sense that the time has come to finally talk about Drupal 8.
There are a great number of changes coming with Drupal 8. So many, that I'm bound not to understand them all at this point. However, if you take a look at the core initiatives you can see where the core developers are working their hardest in improving Drupal 8.
Some of the great things planned for Drupal 8 include better HTML5 and mobile support, improved multilingual features, and setting up Drupal 8 on a modern web development framework (Symfony). Additional focus includes configuration management improvements and support for Views in the Drupal 8 core. While there is still work to be done, the core developers are starting to see the finish line in their sight.
As I mentioned, there are some headlines within the Drupal community that tells me from the user point of view it's time to show some interest in the upcoming Drupal 8. Some of the recent blog posts within the Drupal community I see worthy of mentioning can be found below.
Microserve is proud to announce the submission of another Drupal contrib module – TTR Configurable Widget. The module extends upon the Taxonomy Term Reference field by adding further customisable options to use rather than the default ‘Checkboxes’ and ‘Select List’.
Use Case Scenario
To explain a suitable use case scenario, it would be a good idea to start with our own. We had a design which required us to list a bunch of configurable taxonomy terms in an unusual way, which was dubbed by the designer as ‘The Word Wall’. It was obvious that it was a taxonomy term reference field; however it didn’t appear to be a Select list or Checkboxes. We decided the best route to take was to create a module which adds to the core functionality, and then create any new interfaces as sub-modules.
How to use
What the module does is adds all the additional configurations - such as ordering and limiting - and then allows the user to choose a new widget type to display the terms. The Module comes pre-packaged with the Word Wall sub-module, however TTR Configurable Widget has been designed in a way which makes it easy for other developers to build their own extensions and contribute them back to the module.
To get started you need to first download and enable both the TTR Configurable Widget and Wall modules.
Once that's done you need to configure the fields of a content type to use the widget. To do this navigate to Structure >> Content types >> YOUR-CONTENT-TYPE >> Manage fields.
Then create a new Term reference field and choose TTR Configurable Widget as the Widget. Or if you already have Term reference field that you would like to use TTR Configurable Widget with, simply click on it's currently used widget in the "WIDGET" column then choose TTR Configurable Widget in the select list on the next page then continue (you will need to click on "Edit" on return to the Manage Fields page to configure the widget).
On the Edit Field page you will be able to configure the widget through a set of options listed in the "TTR CONFIGURATION SETTINGS" fieldset. Here you can choose the number of terms to display on the form, the order of these terms and the View type which controls how the terms are displayed on the form. For this example we've selected Wordwall as the View type. The Wordwall view also relies on the "Number of values" option in the "FIELD SETTINGS" fieldset to limit the number of choosable terms on the node form. We've set the number of selectable terms to 3.
Once the configuration has been saved you will be able to see TTR Configurable Widget in action on the node form. The Wordwall view offers a clear and user-friendly way to select terms. Try it out!
(Maximum number of items selected)
Adding additional widget interfaces
We would love to hear any ideas for new interfaces to add to the module, just leave us a comment below and we will take it into consideration. If any developers have built anything themselves then feel free to open a ticket in the issue queue and we can get any contributions submitted to the next release.
See how we use it in one of our own projects below:
In a recent article on some issues we've encountered with Drupal, Behat and pathauto, we were asked to provide some examples of custom step definitions.
In this article we'll dive into how to create your own step definitions and the kind of thing you can do.
The monthly Drupal core bug fix release window is scheduled for this Wednesday. However, since the last Drupal 7 bug fix release was only one month ago and there haven't been many changes added to the 7.x development version since then, there won't be a release this week.
Upcoming release windows include:
- Wednesday, September 18 (security release window)
- Wednesday, October 2 (bug fix release window)
5 Rings: Every feature a branch, every branch a dev environment... without breaking the bank! The perfect git-flow dev environment for small shops
Everyone loves the git flow method for managing branches in development projects. If you've been living under a rock and don't know what git flow is, here's the original blog post that brought order to branching chaos. Honestly you can get a really good idea just by looking at the diagram:
Git-flow is a great branching methodology. It leverages git's merge strength to the max, and lets you focus on the important things. The only problem is: it requires a lot of development environments.
On Wednesday of last week, we spent the afternoon on another monthly Last Call code sprint as part of the Drupal Give initiative.
With beers and mimosas, BBQ and several extra-long extension cords, the afternoon passed in a flurry of laughs and bug fixes.
We’re also pleased to say that we have a new core contributor to the community: Kelly McCabe! Congratulations, Kelly.
At our last two sessions, Tom and Jeff spent time collaborating on which included porting over the settings from the Commerce Authorize.Net module and swipe detection settings for uberPOS transactions where the credit card is not present.
Rob worked on an internal feature that would allow a user to receive emails from whitelisted email addresses, as the site is being tested. All other emails never leave the development server but can be viewed through a web interface.
Here are some other things we’ve been working on:
- Justin B:
- Change EntityInterface type hints to NodeInterface where appropriate
- Password reset token is never deleted from the user's session after the password is changed
I've used both Features and Drush for a few years but until recently didn't know you can create, update and manage your features all with Drush. I can thank the good folks on a new dev team I'm working with who pointed me in the right direction for this method and I ran with it from there; I thought I'd share my early experience with these methods.Time Saver
If you've got a legacy Drupal 6 site to manage, creating and managing Features with Drush is good news as Features UI in D6 can sometimes be unwieldy and almost unusable.
Whether it's Drupal 6 or 7, this method is a huge timesaver and you'll work much smarter and faster as a developer, in this case Drush plus Features.Getting Started
It's pretty easy to get up and running once you get the hang of the syntax and terminology. Of course you'll need Drush, Features and Chaos tool suite (ctools) installed on your site along with any other contrib modules from which your Feature will be created such as Views.
Approaching Feature creation with Drush is similar to the UI method in the sense that you'll be adding components to the Feature but I'll also show you a few shortcuts along the way. To start, as an example I want to incorporate a View into my Feature so I'll invoke a basic Drush command in Terminal:
drush fe --d events_feature views:latest_events
The above string says to create a new feature, fe, short for features-export, using debug (--d), and then name it "events_feature" and use a view called latest_events. We use the debug function as it provides useful information if something goes wrong and as you'll see later will exclude any bad code along the way.
After this command, you should see a return message in Terminal:Will create a new module in sites/all/modules/features/events_feature
Do you really want to continue? (y/n):
After confirming above, you'll now have a new folder that contains the Feature. I found that in my tests with Drupal 6, the default location is sites/all/modules whereas in Drupal 7, the default location is sites/all/modules/features/. Of course Drush has a means of specifying the location of your Feature by invoking the --destination command. It would look something like this:
drush fe --d --destination="sites/all/modules/custom" events_feature views:latest_events
Here we tell Drush to put the new feature in a modules custom folder.Adding and Updating
Until now, we've only covered creating a new Feature with Drush but what about updating and adding components? Well, there's plenty more we can do and here is where the fun starts. The first thing you'll want to do is drush cc all and then enable the feature so we can work with it -- drush en events_feature -- this is just like enabling a regular module. If we look in the new .info file that was created, we see some basic info:name = events_feature
core = 7.x
package = Features
dependencies = views
features[ctools] = views:views_default:3.0
features[features_api] = api:2
features[views_view] = latest_events
This all looks familiar but note that dependancies and other info was added automatically when Drush created this. The package indicates a grouping similar to module grouping only this would apply to the the Features UI main page. I usually add some useful additional info as well including a description, version number and module path.description = Latest Events Feature
version = 7.x-1.0
project path = sites/all/modules/custom I've Got the Power...
Let's say you create an image style called "adaptive" and you've updated your view to use that style. First we'd simply add this new component to the Feature's info file. The best way to determine what components are available on your site is to have Drush compile a components list:drush fc
You'll now get a nicely printed list in Terminal of available components. Choose an item from the list and you'll be presented with all sub-items within the component, where they are being used and which ones are free to use. I'd then choose image and see:Available sources
image:50x50_avatar Provided by: user_follow
image:35x35 Provided by: user_groups
image:50x50 Provided by: user_groups
From the list, I can now formulate my component syntax for the adaptive image stye ready to be put into the .info file.
features[image] = adaptive
Now we'll update the Feature via Drush usingdrush fu, short for drush features-update.drush --d fu events_feature
This is where the power of Drush and Features comes into its own. By simply adding a new component to the Feature's info file and updating via Drush, it now will find and add dependencies, variables, ctools instances and anything related to Features API. These all get added and Drush will create any new module files. In this case an events_feature.features.inc file which has the definition of the new image style we've added.
As another example, say you add a node type called Events that has custom fields, this gets added to your Feature automatically so in most cases, it's merely enough to simply add features[node] = events to your info file, run Features update and now you have all your events node related fields and definitions within the Feature as well as variables and other dependancies. You can also run drush --d fu-all to update all your Features within a site.
One interesting thing to do with all this is, if you are managing your local dev with Git, use Git Tower to visually see the diff changes after you run drush fu. It's a great visual learning tool and really gets you dialed in to the nuances of what goes into a Feature.
You can also use Drush to revert a Feature which comes in handy on a remote site. Once you've pulled from Git on your remote server, simply do this:drush --d fr events_feature
This will revert the remote Feature to your most recent version you had updated locally.Extra, Extra...
As a bonus, I'll cover how to export static blocks. You'll need the Features Extra module for this. With Features Extra, when adding a new static block, you'll see a new field within the block's edit page called "Machine name." Once you give the block a machine name and save it, the block will now be available for export via Features.
Let's say I've created a block called My Custom Block with a machine name of my_custom_block. You can add the new components using the Features Extra syntax to your .info file as we did above as such:features[fe_block_boxes] = my_custom_block
features[fe_block_settings] = block-my_custom_block
There are two parts to this, the actual block and content,fe_block_boxes and all the settings for the block itself, fe_block_settings. This might include permissions, content type, theme block region and more. Though the options are less so for Drupal 6, Drupal 7 brings a lot more settings into the block edit page itself and these are all available here for export. Now if you run drush --d fu events_feature, you'll magically see new files appear within your feature for the newly exported block.
If you get any of your syntax wrong for adding new components to the .info file, using debug mode, Drush will simply delete any bad code or syntax and you may even see some useful debug info in Terminal. If you're using Git Tower to visually track your changes, you'll immediately see where things went wrong in your diff files.
This is the tip of the iceberg with Drush and Features but it should get you thinking about how to approach this, and in the long run work smarter and faster as a Drupal Developer whether you are a Themer, Site Builder or Backend dev.Tags
- Drupal Planet
You've probably heard of this magical land of version control where you can undo bad things and start over and share your work effortlessly. It's a wonderful place that, let's face it, actually takes a bit of work to get to. It's a lot like Drupal: the more time you spend with version control, the more you forget how hard and complicated it was at the very beginning. And even when you do get really good you can still get yourself into a fuddle sometimes.
In this article I will show you how to programmatically create new taxonomy vocabularies and terms to go with them. Say the module you are building has some functionality that relies on the Drupal core Taxonomy module. Obviously you can’t expect people to create their own vocabularies to work with your module so upon enabling it these should already be there.