Newsfeeds

Import or aggregate RedHen CRM data using Feeds.

There are currently 99 new Drupal contributors awaiting review of their first project. This is a great place to contribute to the community and learn about interesting upcoming projects, for example...

Module: Subscriptions by Reference What does it do?

The Subscriptions module allows you to subscribe directly to nodes, but what if you want to subscribe to one node referenced by another? Previously, you could do that with a moderate amount of custom code, maybe with the help of a blog post explaining the process. Now, the Subscriptions by Reference module promises to make that even easier. Just tell it which content types and field you want to use in the subscription and it does the rest.

Look Useful? Review it!

If you would like to see this module readily available on Drupal.org, you should review it and help make that happen.

Review It

Pro Tip: If you've never reviewed a project application before, you can find instructions for reviewers on Drupal.org and the Code Review group is happy to help more people get involved.

In this lesson we're going to talk about what is possibly the most useful Drupal site building module of them all - Views. If you're coming from a WordPress or Joomla background, you won't have experienced anything quite like it. Not only does Views allow you to easily build queries on your site's content, but it gives an amazing degree of control over the display of those query results.

We're going to begin by creating a very basic view just to get acquainted with the interface and some of the settings we'll be using the most often. If you've been following along and are using my free installation profile, then everything you'll need is ready to go. If you're using your own site, make sure you have Views installed along with some content you can work with. If you have a fresh install of Drupal, the Devel module is great for generating dummy content.

Once you're all set, let's get started creating our first view.

Creating a View

To begin, let's head to Structure > Views. You should see something like the screenshot below. At the upper left of the page is a link that says, "Add new view". Go ahead and click it.

You'll next be directed to the screen below. If you wanted to keep things super easy, you could just add a title and then save to have a view of all your site's content presented as teasers. We're going to do something a bit different, however. Take a look at the settings below.

You'll see that I've named the view "Blog grid" and set it to only show content of the Article type. Often you may want to create an additional display, such as a block, but in this example we're going to just stick with the default Page view.

The ability to create multiple displays is one of the really cool things about Views. We're building one query, but we have the option to display it in multiple ways - a page, a block or even a feed - and then tweak the display of each as needed.

We'll go with what we have here and click "Continue and edit". You'll next see the view edit form as in the screenshot below.

OK, there's a lot going on with this form, but we're only going to focus on a few of these settings to keep it simple this time around. Let's begin with two that we're not going to edit in this lesson, but that I'd like you to take a moment to check out. These are the Filter Criteria and the Sort Criteria settings.

You'll see that they determine the type of content we're working with, the publish status and how the results will be sorted (in our case, by date with the newest displayed first). These settings make it very easy to add criteria to further filter our results.

For example, one thing that is often useful to do is only include nodes in your view that have been promoted to the front page. This allows you to do something like publish a post but not include it in the main list of your blog articles. I do this occasionally when I don't want a post distributed to email subscribers, but do want it available through my Categories menu.

Take a look at these options, play around with them bit and see what changes you can come up with. Experimenting is a great way to figure out all the things Views is capable of doing.

Editing a Field Display

In our last tutorial, we talked about content types and the Fields UI. In this lesson we're circling back a bit on that subject by using fields to create our view. That's what a view mostly boils down to - a query where we ask Drupal to return certain fields so we can use them in a display we place on our site. You'll see that in this view all that we currently have being displayed are the titles of our articles. The preview (down at the bottom of the page) also shows us that our titles are being displayed as simple, unformatted links. 

Although it's a good idea to have the title as a link, we should probably change the display style to a heading. To do this, click on Content: Title under Fields. You'll see something like the screenshot below.

You'll notice that I've expanded the Style Settings tab and checked "Customize field HTML" and set it to display the title as an H2. I could have done a lot of other customizations, including adding a class, changing the field wrapper and more.

Farther down this screen you'll see the Rewrite Results tab and that is where things get really interesting. You can pretty much go nuts with how you want to customize a field's display. This is super powerful stuff! The only criticism I'll offer is that by default, Views generates markup that is quite bloated - it has a serious case of divitis. Fortunately, we have the Semantic Views module to tidy things up. We won't get into using that module in this lesson, but I recommend you take a look at it on your own.

I'm going apply these settings for all displays, but note that by using the drop down at the top of this screen you could choose to instead apply it to a specific display. This is very useful when you're using the query to create multiple displays (pages, blocks or feeds) and modifying how each one outputs the view.

After applying the changes, you should notice in the preview that the titles have been successfully changed to headings. So far, so good. But let's add another field to our display to make it a bit more useful. You'll see in the screenshot below there is an arrow pointing to the link that adds a new field to our view.

After clicking that button, you'll see a long list of options pop up. Let's select Content: Body and then continue by clicking the, "Apply (all displays)" button. You'll next see the same screen as when we edited the Title field. One difference this time is that "Create a label" is now checked. In most cases I uncheck that so that my views don't add labels, but you may find situations where it comes in handy.

Another difference this time is that we're going to make a change to the format of the field. We probably aren't going to want the entire Body field to be displayed in our view, so instead we'll set it to only display a summary. You'll see a drop down under Formatter. Go ahead and select, "Summary or trimmed". In this case the default settings are fine, but I encourage you to play around with some of these a bit and see what you come up with. Now we'll click, "Apply (all displays)" to continue.

After saving that, take a look at the preview - looking pretty good, huh? We've come far enough that we should see what this Page view we've created actually looks like on our site. First, however, make sure you save your view! That's an important thing to remember - none of your changes are applied until you save the view, so if you ever get off track, just click cancel and start over.

After saving, look for a small link at the upper right of the view edit screen that says, "view Page". Let's click that and take a look at the view we've created as it will appear on our site.

That was pretty easy, right? I'll bet that you can think of a lot applications just using what we learned today, but in future lessons we'll be coming back to the Views module and adding to our bag of tricks. In fact, our next lesson will cover some advanced features of views (contextual links and relationships) and in a few weeks we'll use Views and the Flex Slider module to add an image slider to our front page.

Until then, you can keep up with this series either via the RSS feed or subscribing to blog updates (at the top of the sidebar).

If you'd like to comment on this post, you can do so on this discussion forum.

Text Link Formatter allows you to link text fields in the field formatter settings with the link fields or with content. E.g. you have a content type teaser and a link field and you want to link the teaser to the entered link.
It is very similar to Linked Field module.

Also you can use other approaches:

• Custom Formatters
• Token formatters

This module adds new taxonomies tokens to use in your nodes, paths or breadcrumbs, for example, like [parent-term] and [parent-child]

Guest blogger Yvonne Chen of Dayvin Internet Solutions shares the results of the Shanghai Global Training Day event this past March.

Following-up with the Global Training Day series, we were glad to be able to organize the Drupal Training Day on March 15, 2013 in Shanghai.

Personal blog tags: Drupal Global Training DaycommunityChinaguest blog

Ah, base themes.

If there's an analogue to the Windows/Mac/Linux battle in Drupal land, it's probably Zen vs. Omega vs. AdaptiveTheme.

Garrett Dawson and John Ferris have a way out of that eternal struggle: Custom base themes. As they put it in their Drupalcon Portland session description:

"By necessity, base themes make assumptions about how teams and individuals work. By rolling your own, you’ll become much more comfortable and informed about the Drupal theming layer, and have a better launchpad for your front-end projects."

Here in Portland we take home gardening and permaculture seriously, so what better place to talk about "growing your own" custom base theme!

I spoke with John and Garrett about how creating your own base theme can make work for you and your team easier. Take a gander at their session, “Dapper Drupal: Custom Tailored Themes,” on Thursday at 2:15 PM for the full story!

IB: Base themes that are out there make some assumptions about how you want to theme. What's the advantage to rolling your own base theme rather than finding the theme that already makes the assumptions you do?

JF and GD: If you can find a base theme in contrib that fits perfectly into your workflow, by all means, use it. There's a lot of solid tools out there. We don't want to deter people from using and contributing to them. With that said, we feel it's unlikely a contributed base theme will be ticking all the boxes and making all the right assumptions about your workflow.

There's no one-size-fits-all approach. Your front-end process is heavily influenced by team dynamics, contrib module choices and a whole host of other considerations. The majority of base themes cannot account for those variables like you can. We want front-end developers to take a critical look at their tools to see where they can make improvements. That may mean creating a custom base theme; a custom starter theme for use with an existing base theme; or even a set of helper modules.

All the popular base themes started because someone wasn't happy with what was available at the time. The ultimate goal is increasing efficiency while improving the quality of the final HTML, CSS and JS.

IB: Do you recommend custom base themes for big shops? Small distributed teams? Freelancers? Everyone?

JF/GD: Yes, all of the above. At least consider it as an option. If you find yourself doing any kind of repetitive work, there's an opportunity for improvement. The only people who should steer clear of custom base themes are those new to Drupal. You need to be familiar with the tools that are available before setting out to create your own.

IB: Besides your the custom base themes you developed yourselves (Center and Prototype) what other custom base themes have you seen in the wild?

JF/GD: Yes! We've learned a lot working with and iterating on Center and Prototype. They work well for the structure of our team and the type of work we do at Aten. However, we realize every team is unique. We were really interested in seeing how other organizations were approaching the front-end problem space. We chatted with a range of teams of varying sizes working across different industries. Everyone has their own unique set of tools based on their own strengths and constraints. We're excited to share those with you, but you'll just have to come and see for yourself!

Images: National Archives and Flickr user McBeth.

Join Rootwork on Twitter, Facebook and SlideShare.

Learn about Rootwork's services for nonprofits and social change.

Field formatter to display image fields on referenced nodes.

Everyone planning and building Web solutions with Drupal benefits from understanding what a "hook" is—and why Drupal is not a CMS. more>>

Kraftwagen

• On the kraftwagen.org it says that Kraftwagen is “Drupal for large (distributed) development teams and staged deployments.” Can you elaborate on what exactly that means?
  • (Rolf) pain of configuration in DB. Everything in code is essential. Standardized workflow
• What do you mean when you say “Drupal for developers”?
• It states that everything is in code. Does that include info from the database, like configuration?
• How does this compare to the configuration management initiative in Drupal 8?
• How does it integrate with multiple deployment targets like local, staging and live environments?
• It mentions skeletons, what are those?
  • (Rolf) start points. mention scaffolding
• So, how does this all work? What are the components of Kraftwagen?
  • (Rolf) kraftwagen (drush extension) and 2 important modules (kw-manifests and kw-itemnames). explain the workflow of Kraftwagen (setup, build, init db, update)
• On the site is says something about Environment awareness, and mentions that the Devel module shouldn’t be enabled on a live server, but should on a development environment. I get around this by using a global git ignore file on my local machine that ignores the devel module. So, when I spin up a new site on my local machine, part of that process is to install the Devel module, but my system prevents it from ever being pushed anywhere automatically. How does Kraftwagen deal with that?
  • (Rolf) builds are not environment aware, but dependencies and manifests are.

Use Cases

• Are you familiar with Aegir? How would you compare the two?

TBD

A set of tools to integrate Drupal with Open Simulator servers.

Current features:

• Opensim core, featuring a preference panes to set access to Opensim database
• Alternative grid info block, showing hypergrid active users as well as usual data (login URL, local accounts, active local accounts, regions).

Future features

• Show user owned regions / simulators
• Link payments to activation / deactivations of regions / simulators

Useful modules

• d4os: integration with Opensim, including user creatioon

Defines a Map media type and enables the embedding of various map types. Currently supports ArcGIS out of the box, but it can easily handle other embeddable resources.

Requires Media 2.x or greater.

Allows viewing of Watchdog messages for events triggered by users that have since been deleted.

Without this module the detail screen of those message events will appear blank.

See: http://drupal.org/node/7428

Is there another module that handles this? I am going to promote this to a full project but thought I would wait to see if there is another module first.

What do you do in Traveller?

It's fair to say that in the last year, adopting the CSS preprocessor SASS has completely changed frontend development for me. That's a sentiment I've heard others express when they started using it — and I was pretty late to the party.

I got attracted to it initially through variables. We've all been there when a client or a designer wants to change a color and suddenly we have to change dozens or hundreds of values across CSS.

Dale Sande captures that kind of revolution in efficiency that SASS brings, as seen in a screenshot from his upcoming presentation at Drupalcon Portland.

But Dale, who's spoken plenty on SASS and organizes the Seattle SASS meetup, is taking us way past the SASS basics like variables, and that's why I'm excited to see his presentation next week.

Around the same time SASS came onto the scene, some thoughtful people were exploring more maintainable frontend development and CSS architecture through ideas/acronyms like OOCSS, SMACSS and BEM, and folks like Nicole Sullivan, Jonathan Snook (a Drupalcon featured speaker!), Nicolas Gallagher, and Harry Roberts.

I spoke with Dale about SASS, object-oriented CSS and some the things he'll be covering at Drupalcon. Be sure to join me at his session, "Sass: OO'S'CSS w/Extends and Silent Placeholders," on Wednesday at 2:15 PM!

IB: Some people argue SASS creates bloated code — do you see placeholders addressing that concern effectively?

DS: Sass doesn’t create bad code. Bad coders do.

The whole concept of placeholder selectors was designed to fight code bloat and be a more pragmatic solution to OOCSS. In my presentation, I illustrate how using the various techniques generate code.

The real "ah-ha" moment comes when we see how using placeholder selectors makes it easier to manage and literally re-use code — thus reducing dreaded CSS bloat.

IB: What's the advantage to using silent placeholders over mixins for a set of rules?

DS: Simply put, being able to re-use code without duplicating code. The use of mixins was the first part of being DRY with our code. Looking at the Sass it felt AWESOME! But when we looked at the output CSS, this is when we realized that we were all living a lie.

Our CSS rules were being duplicated tens, if not hundreds of times. We weren't being DRY, we simply put the onus of duplication on the machine.

Placeholder selectors embrace the one of the oldest concepts of CSS and that is to extend the CSS selector for reuse. But with traditional CSS this was difficult to do, especially when you were dealing with thousands of lines of code. Sass' @extend directive allows developers to create name-spaced reusable chunks of code that is portable, re-usable and extendable without duplicating anything.

IB: Do you see placeholders as helping to reduce the amount of tight coupling — scattering pieces of styles in multiple places?

DS: While Placeholder Selectors are a tool that can help with scattered code, it is not the only solution. Having a file/folder structure that embraces the different types of code, e.g. CSS selectors, placeholder selectors, mixins and functions, can assist in creating reusable modulare code and maintain a process of control over the many parts.

Images: Screenshot from Dale Sande's presentation.

Join Rootwork on Twitter, Facebook and SlideShare.

Learn about Rootwork's services for nonprofits and social change.

This will make your website pass gas when you scroll.
Just for novelty.

Imports properties from the Vebra Live estate agent software and converts them to nodes

Hey developers ~ new, experienced or otherwise, undecided!

DrupalCon Portland is just around the corner — have you thought about the week and what you want to accomplish? Keynotes, sessions, a new job, and "people to see" are certainly popular options. As one colleague put it, "Spending time with all the cool, smart people that I talk to online." Maybe just making sure you have some of these ten things to bring with you to Con is all you can muster right now.

Recently I had to create a custom field for a project I am working on. The field was not difficult to implement, it only had to store two values in the database, but I didn't found a sample tutorial for that so I want to share my experience with you.

If you take a look at the Examples module, you can find a sample field that stores one value in the database, but this sample will show you how to store more data. In fact this field will store two values retrieved from The Internet Chuck Norris Database. One numeric value that represents the joke identificatior and a text value that holds the joke itself, for example:

Chuck Norris once ordered a Big Mac at Burger King, and got one.

First step to create our custom field is to create the database structure to store the data. This can be done using the hook_field_schema in the .install file of your module.

/** * Implements hook_field_schema(). */ function field_chuck_field_schema($field) { $columns = array( 'id' => array( 'type' => 'int', 'unsigned' => TRUE, 'not null' => FALSE ), 'joke' => array( 'type' => 'varchar', 'length' => 2048, 'not null' => FALSE ), ); return array( 'columns' => $columns, ); }

You can create as many columns as you want to store your data. Just take into account the supported types.

Next step is to create a .module file to hold the field specifications starting with the hook_field_info:

/** * Implements hook_field_info(). * Provides the description of the field. */ function field_chuck_field_info() { return array( 'field_chuck' => array( 'label' => t('Chuck Norris Joke'), 'description' => t('Creates a field for Chuck Norris jokes.'), 'default_widget' => 'field_chuck', 'default_formatter' => 'chuck_norris_joke', ), ); }

In this hook we create our field name "field_chuck" and the default widget and formatter names. Then we describe the field widget with hook_field_widget_info telling Drupal the name of the widget, a label for it and for what field types it's designed:

/** * Implements hook_field_widget_info(). * Expose Field API widget types. */ function field_chuck_field_widget_info() { return array( 'field_chuck' => array( 'label' => t('Chuck Norris Joke'), 'field types' => array('field_chuck'), ), ); }

Also we must tell Drupal the field widget structure with hook_field_widget_form:

/** * Implements hook_field_widget_form(). * Return the form for a single field widget. */ function field_chuck_field_widget_form(&$form, &$form_state, $field, $instance, $langcode, $items, $delta, $element) { $element += array( '#type' => $instance['widget']['type'], '#default_value' => isset($items[$delta]) ? $items[$delta] : '', ); return $element; }

This hook implementation is different than the one in the Examples module but I guess this is more customizable because we can use hook_element_info to implement our own Form API element types with their values:

/** * Implements hook_element_info(). * Declare the field Form API element types and specify their default values. * @see field_chuck_field_process(). */ function field_chuck_element_info() { $elements = array(); $elements['field_chuck'] = array( '#input' => TRUE, '#process' => array('field_chuck_field_process'), ); return $elements; }

Now we can create the field Form API elements in the #process callback function:

function field_chuck_field_process($element, $form_state, $complete_form) { $element['submit'] = array( '#type' => 'markup', '#markup' => t('Go!'), '#prefix' => '<div id="field-chuck-submit"><h2>', '#suffix' => '</h2></div>', '#attached' => array( 'js' => array(drupal_get_path('module', 'field_chuck') . '/field_chuck.js'), ), ); $element['joke'] = array( '#type' => 'textfield', '#title' => t('Chuck Norris Joke'), '#default_value' => isset($element['#value']['joke']) ? $element['#value']['joke'] : '', '#prefix' => '<div id="field-chuck-joke">', '#suffix' => '</div>', '#maxlength' => 2048, '#size' => 100, ); $element['id'] = array( '#type' => 'textfield', '#title' => t('Joke ID'), '#default_value' => isset($element['#value']['id']) ? $element['#value']['id'] : '', '#prefix' => '<div id="field-chuck-id">', '#suffix' => '</div>', '#size' => 4, ); // To prevent an extra required indicator, disable the required flag on the // base element since all the sub-fields are already required if desired. $element['#required'] = FALSE; return $element; }  The final steps are:

• Create the implementation of hook_field_load if we want to process the data before loading it in the field widget.
• Don't forget that the implementation of hook_field_validate and hook_field_is_empty are required for a correct field validation.
• Also we can implement hook_field_presave if we want to alter the data before storing it in the database.
• Create the custom field formatter using hook_field_formater_info and hook_field_formatter_view as I explained in a previous post.

The full example code can be downloaded from my Drupal sandbox and includes the javascript to fetch the Chuck Norris jokes, so I hope you will enjoy it :)

Tags: drupal 7fieldwidgetformatterDrupal Planet