Planet Drupal

Syndicate content
Drupal.org - aggregated feeds in category Planet Drupal
Updated: 10 min 20 sec ago

Wunderkraut blog: Configuration Entities in Drupal 8

Mon, 14/07/2014 - 8:10pm

With the overhaul of many API's in Drupal 8, one of the new kids on the block is the configuration system with its integration with the entity API. This means that we can now define configuration entities (that work much like the regular content entities) for the purpose of managing more complex configuration. For example, a View is a configuration entity and so is a field or an image style.

In this article we will look at how to define a configuration entity type that will serve a simple purpose, describe dummy flower configuration entities. We will do so in a module called flower and will use the alpha13 release of Drupal 8 to do it.

Before we get started, let's define a practical goal for this tutorial. As I said, we will have a flower config entity type with a couple of properties: name, number of petals, color and season. And by the end, we will have a fully fledged UI to create and manage them. The final code you can also find in this repository.

So let's begin.

The configuration entity interface

The first thing we need to do is define an interface our Flower entity type class can implement and that extends the default ConfigEntityInterface. So inside of our module's src/ folder, create a file called FlowerInterface.php with the following interface:

/** * @file * Contains \Drupal\flower\FlowerInterface. */   namespace Drupal\flower;   use Drupal\Core\Config\Entity\ConfigEntityInterface;   /** * Provides an interface defining a flower entity type. */ interface FlowerInterface extends ConfigEntityInterface {   }

As you can see, we are just extending the default configuration entity interface without adding any methods to it (which is possible).

The configuration entity class

Next, we will focus on the crux of defining our own configuration entity class. Go ahead and create a folder inside the src/ directory called Entity, and within it, a file called FlowerEntity.php:

/** * @file * Contains \Drupal\flower\Entity\FlowerEntity. */   namespace Drupal\flower\Entity;   use Drupal\Core\Config\Entity\ConfigEntityBase; use Drupal\Core\Config\Entity\ConfigEntityInterface; use Drupal\flower\FlowerInterface;   /** * Defines a Flower configuration entity class. * * @ConfigEntityType( * id = "flower", * label = @Translation("Flower"), * fieldable = FALSE, * controllers = { * "list_builder" = "Drupal\flower\FlowerListBuilder", * "form" = { * "add" = "Drupal\flower\Form\FlowerForm", * "edit" = "Drupal\flower\Form\FlowerForm", * "delete" = "Drupal\flower\Form\FlowerDeleteForm" * } * }, * config_prefix = "flower", * admin_permission = "administer site configuration", * entity_keys = { * "id" = "id", * "label" = "name" * }, * links = { * "edit-form" = "flower.edit", * "delete-form" = "flower.delete" * } * ) */ class FlowerEntity extends ConfigEntityBase implements FlowerInterface {   /** * The ID of the flower. * * @var string */ public $id;   /** * The flower name. * * @var string */ public $name;   /** * The flower color. * * @var string */ public $color;   /** * The number of petals. * * @var int */ public $petals;   /** * The season in which this flower can be found. * * @var string */ public $season;   }

What we have here is a simple class defining the entity properties we want (name, id, color, number of petals and season). This class extends the default ConfigEntityBase class and implements our interface. What happens above the class definition is what's interesting though.

Using annotations, we are basically telling Drupal about our Flower entity type.

The @ConfigEntityType tells Drupal that this is a configuration entity type (as opposed to a plugin or something else). Within its definition, we have an array-like structure with the following information (I will only mention the keys that are not super obvious):

  • label - the label of the entity type passed through the translation system.
  • fieldable - the configuration entities are not fieldable, but the content entities are. Since we are using the same entity API, we can specify this.
  • controllers - all the classes needed to manage these entities. The list_builder class will provide an admin overview interface of the entities, whereas the form classes are used to perform the CRUD operations through the UI.
  • config_prefix - a configuration identifier
  • entity keys - mapping of the main entity keys to the entity properties we defined. For instance, when we call the label() method on the entity object, it will return the flower name.
  • links - administration links for editing and deleting entities with values referencing routes. Specifying them here will make Drupal add them automatically to the operations column on the entity overview page (we'll see this in a minute).

For more information about the structure of an entity class annotation, follow this documentation page.

The entity forms

The next thing we need to do is create the forms we referenced in the annotations above: for adding, editing and deleting flower entities. The cool thing is that the form for adding can be reused for editing as well. For delete, we extend a special class that gives us all we need for a confirmation form. But first, the add/edit form (FlowerForm.php) inside of the src/Form/ folder:

/** * @file * Contains \Drupal\flower\Form\FlowerForm. */   namespace Drupal\flower\Form;   use Drupal\Core\Entity\EntityForm; use Drupal\Core\Entity\EntityInterface; use Drupal\Core\Entity\EntityTypeInterface; use Drupal\Core\Url;   /** * Class FlowerForm * * Form class for adding/editing flower config entities. */ class FlowerForm extends EntityForm {   /** * {@inheritdoc} */ public function form(array $form, array &$form_state) {   $form = parent::form($form, $form_state);   $flower = $this->entity;   // Change page title for the edit operation if ($this->operation == 'edit') { $form['#title'] = $this->t('Edit flower: @name', array('@name' => $flower->name)); }   // The flower name. $form['name'] = array( '#type' => 'textfield', '#title' => $this->t('Name'), '#maxlength' => 255, '#default_value' => $flower->name, '#description' => $this->t("Flower name."), '#required' => TRUE, );   // The unique machine name of the flower. $form['id'] = array( '#type' => 'machine_name', '#maxlength' => EntityTypeInterface::BUNDLE_MAX_LENGTH, '#default_value' => $flower->id, '#disabled' => !$flower->isNew(), '#machine_name' => array( 'source' => array('name'), 'exists' => 'flower_load' ), );   // The flower color. $form['color'] = array( '#type' => 'textfield', '#title' => $this->t('Color'), '#maxlength' => 255, '#default_value' => $flower->color, '#description' => $this->t("Flower color."), '#required' => TRUE, );   // The number of petals. $form['petals'] = array( '#type' => 'textfield', '#title' => $this->t('Petals'), '#maxlength' => 255, '#default_value' => $flower->petals, '#description' => $this->t("The number of petals."), '#required' => TRUE, );   // The season. $form['season'] = array( '#type' => 'select', '#options' => array( 'Spring' => 'Spring', 'Summer' => 'Summer', 'Automn' => 'Automn', 'Witer' => 'Winter' ), '#title' => $this->t('Season'), '#maxlength' => 255, '#default_value' => $flower->season, '#description' => $this->t("The season in which this flower grows."), '#required' => TRUE, );   return $form; }   /** * {@inheritdoc} */ public function save(array $form, array &$form_state) {   $flower = $this->entity;   $status = $flower->save();   if ($status) { // Setting the success message. drupal_set_message($this->t('Saved the flower: @name.', array( '@name' => $flower->name, ))); } else { drupal_set_message($this->t('The @name flower was not saved.', array( '@name' => $flower->name, ))); } $url = new Url('flower.list'); $form_state['redirect'] = $url->toString();   }   }

In our FlowerForm class we are extending the Drupal EntityForm class and implementing 2 of its methods: form() and save(). In the first one, we define a regular Form API form very similar to what we do in Drupal 7. But there are a few cool new things happening there as well:

  • We extend the parent form and add our elements to that definition.
  • We get the configuration entity object from the entity property of the parent class.
  • We check the operation being performed on the entity and if the user is editing it, we change the title of the page to reflect this
  • Instead of using the procedural t() function, we access $this->t() on the parent class for best practice.
  • We access the config entity public properties and set them as the defaults in the form elements' definition.
  • For the machine_name, we use the flower_load() helper function (that we will need to define in our .module file) in order to automatically check whether an entity with that ID already exists.

In the save() method we perform the simple operation of saving the entity object to the configuration system. Couldn't get simpler than this. And after the save is performed, we redirect to the flower entity overview page. Here we use the Url class to build a url object based on a route (that we will define later).

Next, let's quickly create the delete form.

Inside the same src/Form/ folder, create a FlowerDeleteForm.php file with the following class:

/** * @file * Contains \Drupal\flower\Form\FlowerDeleteForm. */ namespace Drupal\flower\Form;   use Drupal\Core\Entity\EntityConfirmFormBase; use Drupal\Core\Url;   /** * Form that handles the removal of flower entities. */ class FlowerDeleteForm extends EntityConfirmFormBase {   /** * {@inheritdoc} */ public function getQuestion() { return $this->t('Are you sure you want to delete this flower: @name?', array('@name' => $this->entity->name)); } /** * {@inheritdoc} */ public function getCancelRoute() { return new Url('flower.list'); } /** * {@inheritdoc} */ public function getConfirmText() { return $this->t('Delete'); } /** * {@inheritdoc} */ public function submit(array $form, array &$form_state) {   // Delete and set message $this->entity->delete(); drupal_set_message($this->t('The flower @label has been deleted.', array('@label' => $this->entity->name))); $form_state['redirect_route'] = $this->getCancelRoute();   } }

With this form class we are extending the Drupal EntityConfirmFormBase that provides us with all we need for a delete confirmation form. By implementing these self-explanatory methods, we take care of the entity delete process. Finally, it's time to define the admin overview page.

The entity list builder

As we declared when defining the config entity class, we now need a class file responsible for building the overview page of our entities. So straight in the src/ folder of our module you can create a FlowerListBuilder.php class file with the following class:

/** * @file * * Contains Drupal\flower\FlowerListBuilder */   namespace Drupal\flower;   use Drupal\Core\Config\Entity\ConfigEntityListBuilder; use Drupal\Core\Entity\EntityInterface;     class FlowerListBuilder extends ConfigEntityListBuilder {   /** * {@inheritdoc} */ public function buildHeader() { $header['label'] = $this->t('Name'); $header['color'] = $this->t('Color'); $header['petals'] = $this->t('Number of petals'); $header['season'] = $this->t('Season'); return $header + parent::buildHeader(); }   /** * {@inheritdoc} */ public function buildRow(EntityInterface $entity) {   // Label $row['label'] = $this->getLabel($entity);   // Color $row['color'] = $entity->color;   // Petals $row['petals'] = $entity->petals;   // Season $row['season'] = $entity->season;   return $row + parent::buildRow($entity); }   /** * {@inheritdoc} */ public function render() {   $build = parent::render();   $build['#empty'] = $this->t('There are no flowers available.'); return $build; }   }

In this class that extends the ConfigEntityListBuilder, we implement three methods. The buildHeader() method is responsible for creating the table header of our overview page whereas buildRow() will create the rows based on the number of entities and their values. Lastly, we are overriding the render() method so that we can specify a custom message to display in case there are no entities to show (personal preference). And that's basically it with the list builder class.

Miscellaneous

There are a few more things we need to take care of in order to round up our configuration entity type. The first one has just became kind of mandatory so I'll start with that: the configuration schema. So let's quickly create the folder structure inside our module (config/schema/) and inside a file called flower.schema.yml we can have the following:

# Schema for the configuration files of the Flower module. flower.flower.*: type: mapping label: 'Flower' mapping: id: type: string label: 'Flower identifier' uuid: type: string label: 'UUID' name: type: label label: 'Name' color: type: string label: 'Color' translatable: true petals: type: integer label: 'Number of petals' season: type: string label: 'Season' translatable: true

On the first line (after the comment) we start defining the schema for the (flower module).(flower configuration entity type).(all flower configuration entities). And it follows to map all the entity properties and specify what data type they are. Although the uuid property was not defined by us, Drupal adds it by default and we can specify it here.

As far as I could tell, the label-typed properties become translatable automatically whereas for all the rest we want translatable we can specify translatable: true. Translation is one of the biggest reasons for which we use these schemas for configuration entities.

And now that the schema is taken care of, it's time for some finishing touches. First, let's create our routes so that we can access everything in the browser. Inside of a file called flower.routing.yml in the module root folder, add the following:

flower.list: path: '/admin/structure/flowers' defaults: _entity_list: 'flower' _title: 'Flowers' requirements: _permission: 'administer site configuration' flower.add: path: '/admin/structure/flowers/add' defaults: _entity_form: 'flower.add' _title: 'Add a new flower' requirements: _permission: 'administer site configuration' flower.edit: path: '/admin/structure/flowers/edit/{flower}' defaults: _entity_form: 'flower.edit' _title: 'Edit flower' requirements: _permission: 'administer site configuration' flower.delete: path: '/admin/structure/flowers/delete/{flower}' defaults: _entity_form: 'flower.delete' _title: 'Delete flower' requirements: _permission: 'administer site configuration'

For more information about the structure of a route file (and what the above keys actually mean), please consult this documentation page. But an important take-away are the paths we defined at admin/structure/flowers.

Second, on the flower overview page, we'd probably like a link to add new flowers to the site. So let's create another YML file in the root of our module called flower.local_actions.yml to define that link:

flower.add: route_name: 'flower.add' title: 'Add flower' appears_on: - flower.list

This is a simple local action link definition called flower.add that uses the flower.add route and appears on the page given by the route flower.list. For more information about defining local actions, consult this documentation page.

Third, we can create a menu link under the Structure admin menu that will take us to the flower overview page. So inside of a file called flower.menu_links.yml in the module root folder, add the following:

flower.list: title: Flowers description: 'Administer the flower entities' parent: system.admin_structure route_name: flower.list

Here we create a link called flower.list found under the system.admin_structure link and that uses the flower.list route name. Simple.

Finally, we need to create the auto loader function that will be used by the machine_name form element to check whether an entity with a given machine name already exists (on the flower add form). So inside the flower.module file, create this function:

/** * Menu argument loader. Returns a flower entity * * @param $id * @return \Drupal\Core\Entity\EntityInterface|static */ function flower_load($id) { return FlowerEntity::load($id); }

And don't forget to use the FlowerEntity class at the top of the file:

use \Drupal\flower\Entity\FlowerEntity;

And that should be about it. Clear the caches, make sure the module is enabled, and start poking at it. Navigate to /admin/structure/flowers and create, edit, delete flower entities. Additionally, you can turn on configuration translation and translate all your entities into multiple languages. Cool, no?

Conclusion

In this tutorial we've looked at how we can create our own simple configuration entity type in Drupal 8. The alpha13 version (latest at the time of writing) has been used for this, so make sure that if you are using a newer one you make the necessary code adaptations if needed.

In Drupal 7 we do not have configuration entities and we are left with creating custom tables that hold data meant as configuration. And obviously, integration with the modest D7 entity API is practically inexistent. This all changes in Drupal 8 with the development of a robust entity API - fully integrated with the multilingual and configuration systems. Because of this, we now have exportable and translatable configuration entities used to manage more complex data that is not content.

And with all these new developments, we are being introduced to a few new concepts that can scare us a bit (services, dependency injection, plugins, OOP and so on). However, once we get used to them a bit, they will become a friend rather than foe and open the door to more sane, performant and modern development within the Drupal framework.

Categories: Drupal News

Drupal core announcements: Drupal core security release window on Wednesday, July 16

Mon, 14/07/2014 - 1:45pm
Start:  2014-07-16 (All day) America/New_York Sprint Organizers:  David_Rothstein

The monthly security release window for Drupal 6 and Drupal 7 core will take place on Wednesday, July 16.

This does not mean that a Drupal core security release will necessarily take place on that date for either the Drupal 6 or Drupal 7 branches, only that you should prepare to look out for one (and be ready to update your Drupal sites in the event that the Drupal security team decides to make a release).

There will be no bug fix release on this date; the next window for a Drupal core bug fix release is Wednesday, August 6.

For more information on Drupal core release windows, see the documentation on release timing and security releases, and the discussion that led to this policy being implemented.

Categories: Drupal News

Miles Carter: Drupal views templating tutorial: Outputting the respective image fields of multiple associated taxonomy term references

Mon, 14/07/2014 - 10:50am

Courtesy of - Miles J Carter Photos on the Web Blog
Source URL : Drupal views templating tutorial: Outputting the respective image fields of multiple associated taxonomy term references

Using a custom field template to output taxonomy term references as their respective image fields, rather than as text or a link

The ingredient icons are term reference fields formatted to output as their respective image fields, rather than as a link or text

The example situation is where a view displays a list of nodes or fieldable entities, for our example items on a menu, and each of these has one or more taxonomy term references, in this example the main ingredients. While it’s simple to output the term references as plain text or a link, showing an image or other field attached to the term reference instead of this presents problems.

Using views relationships

The obvious solution is to create a relationship to the taxonomy in the view set up, and add the image field via the relationship. However, this currently presents issues with duplicate rows being output. If an item in the view has more than one term reference, it is displayed once for each term reference. Because of how views works, setting “distinct” and “pure distinct” in the query settings does nothing as they are technically distinct results (each has a different term reference).

The views_distinct module should offer a solution to this kind of problem, but currently it does not work in a way that can aggregate the required fields while filtering duplicates in this situation.

Creating the custom field template

In our example view, no relationship is used and the relevant term reference field is included in the field list

If you have never made a views template before, click the link “Information” in the Other section of the view:

 

This displays a list of possible templates to use in customising your view for each field in the view. The template names shown are ordered from least specific to most specific – the filename of the template determines which situtations it is used. The bolded template is the one currently being used. To make a new custom template, create a file in the theme’s templates directory with the name. Click the link next to it to get the default code which should go into the template. In this case we wish to control output in all situations the field appears, so the first custom template option (highlighted) is that used.

 

From the helpful comment at the top of the file, it can be seen that the contents of the view item can be found in the $row object. By debugging this object the location of the ingredients term references and their respective image fields can be found.

In this case the term reference field data is at:

$row->field_field_ingredients

and the image field at:

$row->field_field_ingredients[INDEX]['raw']['taxonomy_term']['field_image']

Where INDEX is the array index for multiple items.

The field_view_field() function is useful here to display the image field without needing to worry about URLs and allows control of formatting, e.g. image style presets. We also need to use an isset() condition to prevent warnings being thrown where rows don’t have any term references.

Putting this all together gives the example code:

if(isset($row->field_field_ingredients)) {
        $term = $row->field_field_ingredients;

        foreach($term as $ingredient){
                print render(field_view_field('taxonomy_term', $ingredient['raw']['taxonomy_term'], 'field_image',));
        }
}

This outputs the image, but at it’s original size and with an ugly label that says “Image:”. To fix this, we need to use the optional fourth parameter of the field_view_field() function to control display and formatting of the field. The line inside the foreach() loop becomes:

print render(field_view_field('taxonomy_term', $ingredient['raw']['taxonomy_term'], 'field_image',
array('label'=>'hidden', 'settings' => array('image_style' => 'thumbnail'))));

This hides the label and sets the image style preset for the output to ‘thumbnail’.

Final code:

if(isset($row->field_field_ingredients)) {
        $term = $row->field_field_ingredients;

        foreach($term as $ingredient){
                print render(field_view_field('taxonomy_term', $ingredient['raw']['taxonomy_term'], 'field_image',
                array('label'=>'hidden', 'settings' => array('image_style' => 'thumbnail'))));
        }
}

Source - Miles J Carter Photos on the Web Blog
Read the Original Article : Drupal views templating tutorial: Outputting the respective image fields of multiple associated taxonomy term references

Categories: Drupal News

PreviousNext: Writing a custom Drupal Search API processor

Mon, 14/07/2014 - 10:07am

When working with the Search API Drupal module, sometimes we need to programmatically add information that is not available for indexing as a field. Lucky we can write our own custom pre-processor to provide this information to the index.

Categories: Drupal News

Gizra.com: Headless Drupal - Inline edit

Mon, 14/07/2014 - 8:00am

In our last example we showed how to create node using an angular form served from Drupal itself. This time we are taking one big step further and create the node from a completely decoupled web app.
And if that's not enough for the readers excited by the idea of a decoupled Drupal, we've also added inline editing to the example!

Enjoy the live demo

If you know Form API's pains, you should be excited now

Continue reading…

Categories: Drupal News

Freelock : I've got a theory: The Scientific Method applied to web site performance

Mon, 14/07/2014 - 3:10am

What can you do about this page being so slow? That's a question we've been asked by half a dozen customers in the past 6 months, and as it turns out, we can do quite a lot.

One of my long-standing complaints about Drupal is that it's a resource hog. That's an issue we can generally help by throwing lots of hardware and caching systems at the problem -- but that's not the kind of performance issue these clients were having.

PerformanceScalingMonitoringDrupalDrupal PlanetTechnical
Categories: Drupal News

Mediacurrent: The Power of Giving

Sat, 12/07/2014 - 7:00am

Several years ago, a mentor told me to add computer tech services to my web design company’s services because “everyone’s a web designer.” His point: there’s a lot of competition in the web design and development market. With so much competition, why would web development shops like Mediacurrent place so much value in sharing industry knowledge and even custom code for free with the Drupal community? Why is it worthwhile for a for-profit company to share knowledge to a community that includes competitors?

Categories: Drupal News

Midwestern Mac, LLC: Multi-value spatial search with Solr 4.x and Drupal 7

Sat, 12/07/2014 - 6:59am

For some time, Solr 3.x and Drupal 7 have been able to do geospatial search (using the location module, geofield, or other modules that stored latitude and longitude coordinates in Drupal that could be indexed by Apache Solr). Life was good—as long as you only had one location per node!

Sometimes, you may have a node (say a product, or a personality) affiliated with multiple locations. Perhaps you have a hammer that's available in three of your company's stores, or a speaker who is available to speak in two locations. When solr 3.x and Drupal 7 encountered this situation, you would either use a single location value in the index (so the second, third, etc. fields weren't indexed or searched), or if you put multiple values into solr's search index using the LatLonType, solr could throw out unexpected results (sometimes combining the closest latitude and closest longitude to a given point, meaning you get strange search results).

Categories: Drupal News

Joachim's blog: The ripple effect

Sat, 12/07/2014 - 6:21am

Hello! I'm back. I've not made any blog posts in over a year and a half due to the site where my blog was before, drupaler.co.uk, closing down. And while it took me some time to get round to writing a Migrate script to import my posts from the old site's database, it was actually getting round to setting up this new domain that took the longest.

So what have I been doing all this time? Especially as I still don't have a single Drupal 7 site out there to my name? Well, these days I work on a humongous web application which has kept me busy for the last 18 months; it's a large Drupal site (we hit a million of one of its several custom entity types recently), but to the general public it's just a login page. I may talk more about the development challenges in future posts.

Prior to that, I was building what would have been one of the earliest big Drupal Commerce sites to launch... except that very shortly before launch in October 2012, the whole project got canned.

Tags: contributing codedrupal commercedevelopmentmaintaining projects
Categories: Drupal News

Lullabot: Front-end Rapport #3

Sat, 12/07/2014 - 5:00am
Current Trends in Browser Market Share

Topics: Browsers

Arstechnica does a visual deep-dive into browser market shares through multiple charts and graphs — breaking down worldwide browser trends and adoption rates.

Categories: Drupal News

Aten Design Group: Design4Drupal 2014

Sat, 12/07/2014 - 3:33am

Design4Drupal 2014 is almost here, and Aten couldn't be more excited. This year, along with being the Design Partner for the event, members of Aten's Design & UX team will be presenting four different sessions.

This year's Design4Drupal (August 1-3) has been structured to give each day a specific focus. Friday kicks things off with a business summit, Saturday is chock full of sessions and Sunday wraps things up with sprints and trainings. Make sure you catch as many of Aten's sessions on Saturday as you can:

Saturday, August 2, 10:15am Enhancing Design with Adaptive Content

Aten’s Joel Steidl, Lead Architect, and Christine Coughlan, Information Architect, will share practical tips for breaking down and organizing content for projects of any size. They’ll share case studies to reinforce the theory and practice behind adaptive content and best practices for implementing it in Drupal and other platforms.

Layout Design Patterns

John Ferris, Aten's Lead Front-end Developer, presents reusable solutions to common layout problems. He'll begin with foundation CSS layout concepts and then build up to specific techniques for implementing complex layouts in Drupal.

Saturday, August 2, 2:15pm Anti-Handoff: A better design & front-end relationship

Front-end Developers delivering on what's promised by Designers can make or break a project. Erin Holloway, Aten's Senior Designer, will walk through approaching this problem with clear communication, the right tools and mutual respect. If you're struggling with collaboration between your team members, this session can help.

Saturday, August 2, 3:30pm Giving and Getting Great Feedback

Great feedback can be the lifeblood of a successful project. However, setting aside personal preference and giving objective feedback can be challenging. Responding to that feedback can be even harder. Aten’s Designer, Roxy Koranda, will give you the tools to both give and get great feedback.

With just 3 weeks until the event, there isn't a ton of time left to register. If you use Drupal and want to learn more about how best to approach Design, UX and Front-end Development, Design4Drupal is the place to be. We hope to see you there!

Categories: Drupal News

Drupal Easy: Drupal Web Developer Career Series Part 3: Career Waypoints

Sat, 12/07/2014 - 3:08am

This is installment three of our four-part blog post series that encapsulates the advice, tips and must-do elements of career building in the Drupal Community from the panel of experts collected for DrupalEasy’s DrupalCon Austin session; Drupal Career Trailhead; Embark on a Path to Success.

-->

read more

Categories: Drupal News

Acquia: Brant Wynn: Demo Framework – How we pitch Drupal to potential clients

Sat, 12/07/2014 - 12:52am

Brant Wynn, Acquia Solutions Architect, and I covered some interesting ground in our conversation preceding his jam's Drupal Camp session on selling Drupal to potential clients via beautiful, out-of-the-box demos. Listen to hear about working as a professional open source software developer, the potential wins from having migration tools built into Drupal 8, how Drupal 8 is bringing so many open source technologies and communities together, and more.

Categories: Drupal News

Code Karate: Drupal 7 Mobile Friendly Navigation Toolbar module

Fri, 11/07/2014 - 10:12pm

The Mobile Friendly Navigation Toolbar is a replacement for the standard administration toolbar that comes with Drupal 7.

Categories: Drupal News

DrupalCon Amsterdam: Inside Drupalcon Amsterdam Frontend Session Selection

Fri, 11/07/2014 - 5:21pm

After attending and helping to organize several Drupal events in Europe I have met a lot people and also had the chance to listen to many good speakers. I am also an usual speaker in DrupalCamps. That brought me enough experience to know when a session was interesting for the audience and feedback from attendees and organizers helps improve my sessions in the future.

It’s important for the speaker to know how to engage and entertain attendees. People will learn more and will be more satisfied if the session is dynamic and, why not, funny.

A few weeks ago I had the opportunity to collaborate, together with Lewis Nyman, in the Frontend track session selection for DrupalCon Amsterdam. I have never spoken in a DrupalCon so it was a good chance to learn from the best.

Our role was to help guide those who proposed a session by better aligning proposals with the suggested topics. That was a really good experience because I had to contact speakers I met in previous conferences and others I wanted to meet but we didn’t coincide in any event. Also we tried to invite speakers from other communities to spread the word of Drupal in other horizons and also to have opportunity to learn from professionals that are working in different projects and environments than those we use to know.

The response was impressive: we had more than 50 proposed sessions only in our track, for a total of more than 500 submissions overall. That’s a really big number taking into account that the topics were related to theming and design and because we have other tracks that cover development and site-building topics. Sometimes we had to move sessions from one track to another because it was difficult to decide which track the session fit best in.

Session topics were diverse but fit well with our needs, what made it really hard to decide between them. We had a limited amount of sessions to accept so Lewis and I tried to estimate different factors in the valuation process. We took into account previous speaking experience, using speaker profiles and videos or slides from previous sessions in other events.

A session's description was one of the most important factors to evaluate. Tip for prospective speakers: you should be really careful with your session description if you decide someday to speak in any conference. We contacted a few speakers prior to and during session selection to suggest slight variations on their session content so they can fit better with track topics or differ from other proposed sessions.

We tried to have a diverse Frontend track with interesting sessions, not only for front-end developers but also for UX designers, site builders, graphic designers… and not only Drupal people will be interested in them. I think anyone dedicated to web will enjoy and learn new techniques and tools used by well-known professionals in high-end projects.

You can imagine all the amount of time invested to prepare and coach speakers and also to plan and organize. We meet weekly as a team to comment, discuss and make decisions (also have a good time with Drupal fellows). It was a really enjoyable opportunity for me to gain more experience organizing Drupal events.

--
Ruben Teijeiro (rteijeiro)
DrupalCon Amsterdam Frontend Co-Chair

Categories: Drupal News

godel.com.au: Ideas to help keep your Drupal project secure against the OWASP Top 10

Fri, 11/07/2014 - 4:24pm
Fri July 11, 2014 Ideas to help keep your Drupal project secure against the OWASP Top 10

I'm sure you've heard the phrase "Security is a process, not a product" before, or something along those lines. Drupal has a pretty good track record as far as Web-based CMS security goes, and there's a dedicated team of experts looking after Core and Contrib, but it's no secret that the most common vulnerabilities are those we accidentally introduce ourselves during our day-to-day tweaking (Drupal.org claims over 90%). The Drupal Security White Paper shows pretty clearly that the further we get away from the heavily peer-reviewed Core codebase, the more likely we are to unwittingly introduce something that's dangerous to our data.

In the case of what processes we can implement as individuals, self education and reflection is always important, so I figured that the present is as good a time as any to run through the OWASP Top 10 and present a few practical ideas and Drupal "Best Practices" to help mitigate the risks we inevitably expose ourselves to. I've added some quotes from the white paper to each section to put things into perspective.

#1 - Injection

Drupal contains a robust object-oriented database API that makes it difficult for developers to unknowingly create injection holes by automatically sanitizing query parameters and enforcing an interface. Drupal's file system interaction layer limits where files can be written and alters dangerous file extensions that the server could potentially execute.

In Drupal, injection attacks are generally going to be enabled by allowing unsafe data to sneak into SQL queries. In Drupal 7 we have two syntaxes for working with the database API, the classic Drupal 6 style db_query("SELECT * FROM foo f WHERE bar = 'baz'"); and the dynamic DBTNG style db_select('foo', 'f')->condition('bar', 'baz' , '=');.

For both syntaxes, there are two things I think are worth mentioning:

Make use of PHP's PDO and Prepared Statements

Drupal's database API wraps PHP's own PDO, which supports something called Prepared Statements that magically guarantee you won't suffer from an injection attack provided you actually use the API correctly.

So, if you're wondering how to use the API correctly, let's split all SQL queries we might want to use into two categories, those that could be considered hardcoded strings, and those that have one or more variable components. The examples above would be "hard coded", an example of something with variable components might look like this:

// Get the type of the node with the ID of the second URL component.
// WARNING: Don't actually do this! it is NOT secure.
$id = arg(1);
$query = db_query("SELECT type FROM node n WHERE n.nid = " . $id);

The issue here is that, unlike our hardcoded query, the value of $id can be set to anything at all by the end-user, most notably including strings that resemble fragments of SQL queries. We really don't want the end-user to discover one day that they can start executing their own queries against our database by carefully crafting URL components to exploit our PHP logic.

Here the fix is to either use PDO placeholders using Drupal's classic syntax, or leverage Drupal's internal query builder with the dynamic syntax. The following two examples (one for each syntax) are secure versions of the previous insecure example:

Drupal 6 syntax:

// Get the type of the node with the ID of the second URL component. // The important part here is that the second argument passed to db_query() // is an array of substitutions that will be sanitized internally. $id = arg(1); $query = db_query("SELECT type FROM node n WHERE n.nid = :nid", array(':nid' => $id));

Drupal 7 syntax:

// Get the type of the node with the ID of the second URL component. // The important part here is that we use the dynamic query builder to handle // the unsafe $id variable. $id = arg(1); $select = db_select('node', 'n') ->condition('n.nid', $id, '=') ->fields('n', array('type'));

The question now is, how do we know when a variable is "unsafe"?

The answer should really be, treat all variables as though they are unsafe by default and stop guessing. Be in the habit of using the more secure syntax by default, even when it is not strictly neccessary. This both reduces the risk of some edge-case creeping up on you that you hadn't considered, and makes your code more portable/standardised at the same time.

Make use of whitelists for tables/fields/operators

I think maybe this one is less obvious to many people than making use of PDO, but it is also important to consider.

As mentioned in a bunch of core issues, and elsewhere (read the comments) Drupal doesn't actually escape/sanitize everything that you pass the database API. The reason that those issues are still open and not flagged as "critical fix me NOW ZOMG" (In part), is because certain parts of our SQL queries are fundamentally unsafe to use user data for, even if they were being escaped by the system.

Imagine a query (presumably hooked up to a radio button or select element) like the following:

// Return the current user's username or email address to be displayed. // WARNING: Don't actually do this! it is NOT secure. global $user; $field_name = $form_state['values']['field']; $select = db_select('users', 'u') ->condition('u.uid', $user->uid, '=') ->fields('u', array($field_name));

In this case, the end-user can hack up the form you presented them however they like and submit something for the field form value like "password" to get a dump of what is stored in the password field for the current user account. It's not hard to imagine other, even more damaging scenarios.

Since Drupal knows that it is fundamentally insecure to be directly using user data for some things (e.g. table names, fields, operators in condition() and orderBy()) and assumes that you'll definitely be using whitelisted values only in these cases. There may well be a de-prioritised, outstanding Core bug that means your variables are not being sanitised/escaped at all, despite the fact that you're using the query builder. This means that, as well as the end-user getting at your user's passwords when you thought they could only see email addresses, they may also have a way to directly attempt an injection attack on your database.

The fix here is, make use of whitelists wherever you're dealing with variables for finite, pre-determined lists of valid options (like field names). For example, the above could be rewritten to be more secure like this:

// Return the current user's username or email address to be displayed. global $user; // Return the username by default. $field_name = 'username'; // Ony allow field names in our whitelist. $allowed_fields = array('username', 'mail'); if (in_array($allowed_fields, $form_state['values']['field'])) { $field_name = $form_state['values']['field']; } $select = db_select('users', 'u') ->condition('u.uid', $user->uid, '=') ->fields('u', array($field_name)); #2 - Broken authentication and session management

User accounts and authentication are managed by Drupal core. Authentication cookies and a user's name, ID, and password are managed on the server to prevent a user from easily escalating authorization. User passwords are salted and hashed using an algorithm based on the Portable PHP Password Hashing Framework and existing sessions are destroyed upon login and logout.

Drupal handles this well "out of the box" and most developers will be rarely doing anything that would break it. According to the white paper, there are very few Security Advisories being issued in this category, so I won't dwell on this.

#3 - Cross site scripting (XSS)

Drupal has a strong system for filtering user-generated content on display. Untrusted user's content is filtered to remove dangerous elements by default. For developers, Drupal has at least eight API functions for filtering output to prevent XSS attacks. When identified, common developer errors that lead to XSS vulnerabilities are mitigated by building safer defaults. For example, a page title function in Drupal 6 is the source of many XSS holes due to a lack of proper escaping. In Drupal 7 this function escapes output by default.

Hmmm, I think the words "by default" mean something different to the authors of the white paper than they do to me. If you do anything in the Drupal theme layer, and you don't explicitly, manually sanitise every single one of your variables as you render them, you have XSS holes in your theme.

In Drupal 8, there's a critical issue to try and get automatic escaping of markup into core by using the Twig rendering system which should dramatically increase security (in line with my intuitive definition of "by default") and improve performance as a nice bonus. That issue attempts to summarise the situation:

No-one can write XSS safe code. Nor core contributors, nor contrib developers, no-one.

and from a duplicate issue:

100% of all custom themes are insecure (the rest is rounding error). The reason is often that developers forget to escape their data in the templates.

By the white paper's own reported statistics, over 50% of reported security vulnerabilities in Drupal core and contributed community code are XSS issues.

In light of all this, between now and when Drupal 8 auto-escaping is released, even if you learn nothing else about Drupal security, you'll want to become familiar with a few of the API functions provided for string sanitisation.

For reference, the full list on api.drupal.org is:

Read up on all of the sanitisation functions, but the most commonly used (for general theming) are probably:

check_plain()

Use this when you have a string that is NOT supposed to be HTML, but you want to display it in an HTML context. It's really just a wrapper around htmlspecialchars(). Any characters in your non-HTML string that might be interpreted as HTML by the browser are converted into HTML entities so that they render as you would expect them to in a non-HTML context.

This means that your string that looks like X < Y & Y > Z becomes X &lt; Y &amp; Y &gt; Z.

A couple of things to keep in mind with this function:

  1. It's possible to accidentally double encode characters so that &amp; becomes &amp;amp;, which looks really bad when rendered. It is NOT a good idea to run check_plain() over everything without thinking, in case you run it on a string that has already had check_plain() run on it earlier.
  2. While check_plain() is an important function for security, "defusing" characters that could be interpreted as HTML, it's primary usage is for encoding/decoding characters, NOT guaranteeing that strings are "HTML safe" by stripping dangerous markup. For example, it's possible that a substring of a string that was previously run through check_plain() will have its encoding corrupted if an HTML entity is truncated before the closing ;.
check_markup()

Use this to apply input filters to a string that is intended to be used as HTML. In this case, we DO want HTML to be interpreted by the browser, but we also want to be careful not to open ourselves up to <script> elements or similar being executed maliciously. In the simplest usage, this function takes two arguments - the string and the machine name of the filter format to apply.

Filter formats themselves are an important part of core and too detailed a subject for me to go into here. Suffice to say that the "out of the box" formats set the tone for most custom filters created by developers:

  1. plain_text - Behaves as check_plain() does.
  2. filtered_html - Will strip any (customisable) HTML tags considered dangerous and leave the rest intact
  3. full_html - Will render any and all HTML tags in the string, even if they might be dangerous. (ab)Using this causes developers to grumble.

Avoid using the PHP input filter completely if you care at all about mitigating security risks.

t() and/or format_string()

Use this in situations where you want to perform simple string substitutions with variables (that might come from end-users data) and, in the case of t() also allow for the string to be translatable into other languages.

Since t() wraps format_string(), I encourage you to use the former as they behave the same way and you get the translatability "for free".

The advantage of using placeholders in strings, rather than concatenating variables, is twofold, format_string() will automatically apply check_plain() to substitutions that do NOT begin with ! and it makes the strings easier to contextualise for translaters.

// Here the translators can see a whole sentence and use the placeholders as clues. // We don't have to call check_plain() repeatedly because we're using @placeholder syntax. t('Yesterday I went to @place and brought home a @thing', array( '@place` => 'the park', '@thing' => 'frisbee', )); // Here translators only see two disjointed strings separately: // 'Yesterday I went to' and 'and brought home a'. t('Yesterday I went to ' . check_plain($place) . 'and brought home a ' . check_plain($thing)); #4 - Insecure direct object references

Drupal often provides direct object reference, such as unique numeric identifiers of user accounts or content available in the URL or form fields. While these identifiers disclose direct system information, Drupal's rich permissions and access control system prevent unauthorized requests. Methods for obfuscation are available through configuration and community-contributed code. Further, validation and protection against semantic forgery attacks is implemented in Drupal core via the Form API.

For Drupal, this largely comes down to making sure you have your server environment and Drupal site configured in a way that makes sense for your project, in the context of Drupal, I'm going to tie this into...

#5 - Security misconfiguration

Many critical risks, such as access to administrative site controls, text formats, and private information are restricted to a single admin account by default. Identified design inefficiencies that lead to misconfiguration are corrected often through usability testing and fixes are recommended for inclusion to core. Documentation of best practices for secure configuration and site building are provided for free on drupal.org and there are several contributed projects that conduct automated security review or implement further secure configurations.

In my experience, the two fastest ways to end up with hundreds of spambot accounts (or worse) on your account are:

  1. Servers configured in a way that is not Drupal friendly, lazily or by someone who isn't an experienced sysadmin.
  2. Developers building functionality as Drupal user 1 and never logging out or logging in as a user with a different role to test it.

For the first point. If you are not a sysadmin, you don't directly employ a sysadmin, or you don't have a friend who is a sysadmin who owes you a series of large favours, it is going to be much, much cheaper and less headache inducing to sign up with Acquia or Pantheon than to mess around with a shared hosting provider or to try and configure and maintain your own VM.

For the second point, the Drupal permissions grid is huge and tedious to manage as it involves a lot of user switching but there are a few things you can do for yourself to make maintaining complex permission sets easier.

Implement a simple, repeatable testing plan

In the Drupal community, SimpleTest and Behat are very popular testing tools. Both support simple assertions for the HTTP response code and the existence/absences of HTML elements on a rendered page. In fact, automated tests to check that a given user has permission to do something or visit certain pages are some of the easiest to write and can help you avoid those awkward conversations where we have to explain to someone that there was a regression in the site's fundamental security configuration.

Even if you don't have the time or resources to set up automated tests for a project, make step-by-step notes of critical functionality and user roles that can be tested as part of QA each release.

If you're using drush, you can generate a one time login for any user in the system with uli and their username:

$ drush @mysite.alias uli 'John Smith'

Have a deployment plan

People who don't know how to use the Drupal permissions grid just love to make changes to it, then immediately forget what changes they made, or tell anyone that they made the changes. That is, if you let them.

At the very minimum, you should be exporting your permissions into Features so that, should anything go wrong, you have some kind of "oh shit" button to get things back to working order, fast (without rolling back your database).

The Features approach is a little limiting for Permissions management though:

  • The permissions aren't actually locked. It's relatively easy for a permission to be changed on production and it won't be restored to the correct value until the Feature is next reverted.
  • It's not easy to toggle permissions on/off for different development environments. For most permissions you aren't going to want to do this anyway, but for those that you do, you really don't want the wrong permissions in the wrong environment.
  • There are a very large number of Permissions, and exporting them all to a Feature quickly bloats the Feature code and UI.
  • Adding a permission to a Feature artificially introduces a dependency of the Feature on that module.
  • Exporting permissions to Features is a tedious and error-prone manual process.
  • Permissions exported in Features are not very portable between projects.
  • The generated code in Features is difficult to read over quickly.
  • It's relatively difficult to manage permissions across multiple domains if you have a multisite setup.

There are various contrib modules that aim to make permissions management more secure and development friendly, to name a few:

Additionally, you might want to consider making permissions management part of your deploy/build scripts if you use such things to manage your environments.

#6 - Sensitive data exposure

Account passwords are salted and repeatedly hashed based on the Portable PHP Password Hashing Framework. Available Drupal community-contributed code offer solutions to encrypt sensitive data at rest or in transit.

This depends a lot on what your employer/client/government considers "sensitive" data. Where I live, in Australia, the government has published a convenient set of guidelides around sensitive and private data that can be used to gauge the level of risk if data were to be exposed. If you don't have any in your site, well that's great - although I still recommend implementing hook_menu() to unset the default node menu path if you haven't already, as it shows every node in the site by default, which can be awkward.

If you're working with Ubercart or Commerce, please, please triple check whether your payment gateway integration module sends user's credit card data through the Drupal Form API, to your server, before sending it to the payment gateway provider. This goes double (so sextuple check) for anything that claims to store credit card data for later use, even if it is "tokenized". If sensitive credit card (or similar) data touches your server even for a moment, you might be exposing yourself to fines if you haven't taken appropriate steps (PCI-DSS) to ensure encryption and security.

If you work with Drush, and multiple environments, you might want to consider implementing hook_drush_sql_sync_sanitize() for your project. This allows you to scrub out sensitive data from your production database as you pull it down, so that you don't accidently lose it to someone shady along with your laptop or not-so-trustworthy contractor. You don't need to use drush for this, there are lots of ways, including a simple shell script with SQL queries, to setup a decent database scrubbing script. Acquia have some documented examples of how to achieve this too, if you're interested.

#7 - Missing function level access control

Function level access in Drupal is protected by a powerful permissions-based system which checks for proper authorization before the action is taken. For the case of URL access, access checking is tightly integrated into the entire menu-rendering and routing system which means that visibility of navigation links and pages are protected by the same system that handles incoming requests.

Yes, menu-rendering uses access checking to ensure that navigation links are protected, but links generated by l() or #type => 'link' render arrays do not automatically run access checks. Function (and URL) level access control is very easy to implement in Drupal using hook_permission(), hook_menu() and user_access(). Creating new, custom permissions is very straightforward but it's also very easy to get wrong in subtle ways (especially if you're writing some new function that wraps another function with existing access checks) - as I mentioned above, make sure you have a solid testing plan in place for your new permissions scheme before you deploy it!

#8 - Cross-Site request forgery

Drupal validates user intention in actions using industry standard techniques. Typical actions with side- effects (such as actions that delete database objects) are generally conducted with the HTTP POST method. Drupal's Form API implements unique form tokens to protect against CSRF in POST requests. Less important actions can leverage the one-time token generation and validation functions of the Form API while still using an HTTP GET request.

Reviewing the security white paper, we can see that there's a relatively large incidence of contributed, non-core code that is not correctly implementing the Drupal Form API, leading to CSRF exploits.

Avoiding CSRF exploits in Drupal is relatively easy if you follow three simple rules:

  1. Whenever you expose an action to an end-user that modifies data in your site, implement it using a form (POST) rather than a link + menu callback (GET).
  2. Never try to build an HTML form manually, always use renderable form arrays and the Form API.
  3. Always use form validate/submit handlers and $form_state to access user submitted values rather than trying to extract information from $_POST directly.

If you need to quickly convert some GET based code you suspect might be at-risk to POST requests, the Drupal documentation suggests converting the page callback to a simple confirmation form using the confirm_form() core function as a base.

Another option, is to put a token in the URL that is unique for each page load and can't be easily forged, much like the Flag module does. Keep in mind though that this approach might not behave well in conjunction with cached markup containing links to URLs that rely on tokens like this.

#9 - Using components with known vulnerabilities

Included libraries and frameworks (of which there are few) in Drupal core are system-level, unsophisticated, and of low risk to full server or application compromise.

Unfortunately, this happens very, very frequently in Drupal as soon as you start counting contributed modules as "components". Ironically, the frequency of known security vulnerabilities showing up in installed modules is due in a large part to the security team doing a good job of reviewing and flagging community code. The difficult part here is being proactive about regularly deploying new module versions as security fixes are released.

It's a shame that the Droptor service was discontinued, as it provided a central dashboard for reviewing available security updates across multiple sites. Acquia and Pantheon both provide similar dashboards for sites hosted on their servers.

It's also a shame that the core Update module that "dials out" to Drupal.org to get the status of installed module versions is somewhat poorly optimised. It's very easy to configure a site (such as when using "poor man's cron") so that 20+ second page loads are experienced intermittently when using Update. If performance is important, I recommend enforcing the Update module to be enabled in a review environment, but not production or local development where slow page load times could become an issue.

There's little else to say here. Keeping your modules up-to-date is simply a matter of organisation/process and diligence and has little to do with development skills or further learning.

#10 - Unwanted redirects and forwards

Internal page redirects cannot be used to circumvent Drupal's integrated menu and access control system. Drupal protects against automatic redirection to off-site URLs which could be used in a phishing attack.

Drupal provides the drupal_goto() function for handling redirections correctly. This function will ignore absolute URLs in GET requests, but otherwise will always respect the destination parameter in the URL. This allows us to safely redirect/forward users by constructing our URLs correctly (with drupal_get_destination()), without opening ourselves up to phishing attacks.

The contrib External Links module also provides visual feedback for users, protecting them against unexpected offsite redirections, showing an icon on any link that will take the user to a new domain. The External Links Extra module takes this one step further and allows for a popup warning box, or even a dedicated intermediate page, to make it as clear as possible to users that they are about to be redirected offsite.

David Meister Director & Lead developer Using style-linking for sane @font-face declarations in a post-IE8 world Mon June 30, 2014 Say no to fake browser bold and fake browser italic, messy @font-face syntax and super-legacy browser bug support with the neat, logical style-linking @font-face syntax. Tags planet drupal
Categories: Drupal News

Drupal core announcements: Drupal core updates for July 10, 2014

Fri, 11/07/2014 - 9:53am
What's new with Drupal 8?

The past two weeks have seen steady progress on Drupal 8, with the release of drupal 8.0-alpha13, the Clearing of the RTBC Queue, the expected deployment of Semantic Versioning support on Drupal.org, the launch of the #D8CX initiative, and the announcement about the roadmap for Drupal Commerce for Drupal 8!

Updates to api.drupal.org

If you go to https://api.drupal.org/api/drupal/8 you'll notice a few updates:

  • A few months ago, we updated the landing page with a list of topics, which were mostly just stubs. Documentation has now been written for most of the topics that are linked from the landing page.
  • There's a list of Services on the right sidebar, which you can filter by tag and name keywords — and each service has its own page, with appropriate cross-linking (list of code that uses the service on the service page, and if a service name is used in code, it should link to the service page)
  • The Classes page now lists Traits as well as classes and interfaces
  • For hooks like hook_form_FORM_ID_alter(), you can now see a list of functions that implement it (previously this only worked for hooks like hook_form_alter() where the function name was modulename_hookname(), but now it works for ALL_CAPS replacements as well).
Where's Drupal 8 at in terms of release?

Last week, we fixed 1 critical issue and 5 major issues, and opened 2 criticals and 10 majors. That puts us overall at 97 release-blocking critical issues and 614 major issues.

Where can I help? Top criticals to hit this week

Each week, we check with core maintainers and contributors for the "extra critical" criticals that are blocking other work. These issues are often tough problems with a long history. If you're familiar with the problem-space of one of these issues, and have the time to dig in, help drive it forward by reviewing, improving, and testing its patch, and by making sure the issue's summary is up to date and any API changes are documented with a draft change record, we could use your help!

More ways to help

Issue #1679344: Race condition in node_save() when not using DB for cache_field recently caused a Drupal.org outage. The issue already has a proposed resolution recommended in comment #24 — help out by creating a patch for either D7 or D8.

Additionally, there are a bunch of easy documentation issues which need some help moving forward. For each of these, there is a "Child Issues" sidebar. Look there for issues that are "active", "needs work", or "needs review":

If you want to get started with the core development process, this is a great way to get your first commit in core!

You can also search the Drupal Core issue queue for issues tagged "Novice": the ones in the "documentation" component are especially good for new contributors.

As always, if you're new to contributing to core, check out Core contribution mentoring hours. Twice per week, you can log into IRC and helpful Drupal core mentors will get you set up with answers to any of your questions, plus provide some useful issues to work on.

You can also help by sponsoring Drupal core development.

Notable Commits

The best of git log --since "2014-06-25" --pretty=oneline (201 commits in total):

You can also always check the Change records for Drupal core for the full list of Drupal 8 API changes from Drupal 7.

Drupal 8 Around the Interwebs

Excited to learn more about the changes coming up in Drupal 8, but don't like reading patch files? Here are some of the best articles from the past two weeks:

Drupal 8 in "Real Life"

Want to meet up with other Drupal folks excited about moving Drupal 8 forward? Code sprints are an ideal way to meet new friends, contribute to Drupal core and/or contrib, learn, share tips/tricks and discover new talent.

Two big events, Twin Cities DrupalCamp (in Minnesota, USA) and Drupalaton (in Lake Balaton, Hungary), will be holding massive, 4-day Drupal 8 sprints on Aug 7-10. Help us make sure there is space for everyone by signing up ahead of time!

Here are some other upcoming events:

  • July 10: Forum One is hosting a Code Sprint at their offices in Washington DC.
  • July 12-13: Drupal 8 at the Jersey Shore in New Jersey, USA, has room for 40 Drupal 8 sprinters. @drupalcampnj
  • July 16: DesignHammer is hosting a Drupal Coder Lounge event in Durham, North Carolina, USA to help work on Drupal 8 core and update documentation and contribtued modules for Drupal 8.
  • July 17-20: DrupalCorn in Iowa, USA will have a Drupal 8 contributed module sprint. @drupalcorn
Whew! That's a wrap!

Do you follow Drupal Planet with devotion, or keep a close eye on the Drupal event calendar, or git pull origin 8.x every morning without fail before your coffee? We're looking for more contributors to help compile these posts. You could either take a few hours once every six weeks or so to put together a whole post, or help with one section more regularly. Contact xjm if you'd like to help communicate all the interesting happenings in Drupal 8!

Categories: Drupal News

Drupal core announcements: Drupal core updates for July 10, 2014

Fri, 11/07/2014 - 7:13am
What's new with Drupal 8?

The past two weeks have seen steady progress on Drupal 8, with the release of drupal 8.0-alpha13, the Clearing of the RTBC Queue, the expected deployment of Semanitc Versioning support on Drupal.org, the launch of the #D8CX initiative, and the announcement about the roadmap for Drupal Commerce for Drupal 8!

Updates to api.drupal.org

If you go to https://api.drupal.org/api/drupal/8 you'll notice a few updates:

  • A few months ago, we updated the landing page with a list of topics, which were mostly just stubs. Documentation has now been written for most of the topics that are linked from the landing page.
  • There's a list of Services on the right sidebar, which you can filter by tag and name keywords — and each service has its own page, with appropriate cross-linking (list of code that uses the service on the service page, and if a service name is used in code, it should link to the service page)
  • The Classes page now lists Traits as well as classes and interfaces
  • For hooks like hook_form_FORM_ID_alter(), you can now see a list of functions that implement it (previously this only worked for hooks like hook_form_alter() where the function name was modulename_hookname(), but now it works for ALL_CAPS replacements as well).
Where's Drupal 8 at in terms of release?

Last week, we fixed 1 critical issue and 5 major issues, and opened 2 criticals and 10 majors. That puts us overall at 97 release-blocking critical issues and 614 major issues.

Where can I help? Top criticals to hit this week

Each week, we check with core maintainers and contributors for the "extra critical" criticals that are blocking other work. These issues are often tough problems with a long history. If you're familiar with the problem-space of one of these issues, and have the time to dig in, help drive it forward by reviewing, improving, and testing its patch, and by making sure the issue's summary is up to date and any API changes are documented with a draft change record, we could use your help!

More ways to help

Issue #1679344: Race condition in node_save() when not using DB for cache_field recently caused a Drupal.org outage. The issue already has a proposed resolution recommended in comment #24 — help out by creating a patch for either D7 or D8.

Additionally, there are a bunch of easy documentation issues which need some help moving forward. For each of these, there is a "Child Issues" sidebar. Look there for issues that are "active", "needs work", or "needs review":

If you want to get started with the core development process, this is a great way to get your first commit in core!

You can also search the Drupal Core issue queue for issues tagged "Novice": the ones in the "documentation" component are especially good for new contributors.

As always, if you're new to contributing to core, check out Core contribution mentoring hours. Twice per week, you can log into IRC and helpful Drupal core mentors will get you set up with answers to any of your questions, plus provide some useful issues to work on.

You can also help by sponsoring Drupal core development.

Notable Commits

The best of git log --since "2014-06-25" --pretty=oneline (201 commits in total):

You can also always check the Change records for Drupal core for the full list of Drupal 8 API changes from Drupal 7.

Drupal 8 Around the Interwebs

Excited to learn more about the changes coming up in Drupal 8, but don't like reading patch files? Here are some of the best articles from the past two weeks:

Drupal 8 in "Real Life"

Want to meet up with other Drupal folks excited about moving Drupal 8 forward? Code sprints are an ideal way to meet new friends, contribute to Drupal core and/or contrib, learn, share tips/tricks and discover new talent.

Two big events, Twin Cities DrupalCamp (in Minnesota, USA) and Drupalaton (in Lake Balaton, Hungary), will be holding massive, 4-day Drupal 8 sprints on Aug 7-10. Help us make sure there is space for everyone by signing up ahead of time!

Here are some other upcoming events:

  • July 10: Forum One is hosting a Code Sprint at their offices in Washington DC.
  • July 12-13: Drupal 8 at the Jersey Shore in New Jersey, USA, has room for 40 Drupal 8 sprinters. @drupalcampnj
  • July 16: DesignHammer is hosting a Drupal Coder Lounge event in Durham, North Carolina, USA to help work on Drupal 8 core and update documentation and contribtued modules for Drupal 8.
  • July 17-20: DrupalCorn in Iowa, USA will have a Drupal 8 contributed module sprint. @drupalcorn
Whew! That's a wrap!

Do you follow Drupal Planet with devotion, or keep a close eye on the Drupal event calendar, or git pull origin 8.x every morning without fail before your coffee? We're looking for more contributors to help compile these posts. You could either take a few hours once every six weeks or so to put together a whole post, or help with one section more regularly. Contact xjm if you'd like to help communicate all the interesting happenings in Drupal 8!

Categories: Drupal News

LightSky: 14 Modules for Improving the Administrative Usability of your Drupal Site

Fri, 11/07/2014 - 6:57am

Often times, Drupal gets a bad rap for usability. That’s because out of the box Drupal isn’t very user friendly. As with everything Drupal, it requires a few contributed modules in order to really make it shine. Below are a list of fourteen modules that you can add to your Drupal site to increase its usability. Let’s begin!

Views Bulk Operations - VBO is a module that allows you to execute bulk actions on views rows. The actions it comes with are pretty standard, but you can extend it using the Rules module or even roll your own if that’s your thing. This module allows for your site admins to be able to do things like mass delete nodes, mass publish/unpublish nodes, or even mass change the nodes author.

Admin Views - Admin Views is a module that replaces the stock administration screens with views. Why is this neat? You can add additional exposed filters to your users administration screens, or change which columns appear in order to help your site admins easily find the information they are looking for.

Draggable Views - Draggable Views is a module that allows your rows in a view to be reordered using the same javascript implementation that you find scattered about the Drupal admin (blocks, menu, etc).

Module Filter - Module Filter is a module that seeks to garner control over the unwieldy module listing page. It does this by adding a tab on the left hand side for each package, as well as one for showing the modules alphabetically. It also adds a textbox that you can search to quickly filter the module listing.

Autocomplete Deluxe - The Autocomplete Deluxe module replaces the default autocomplete element with the jQuery UI version making it much more user friendly than the default implementation.

Pathologic - The Pathologic module is an input filter which fixes image and link paths that would otherwise cause them to break. This is useful in situations where your site admins have content on both staging and live sites. Gone are the days of the live site pointing to the test site by accident or vice versa.

Custom Contextual Links - Contextual links was one of the features that our D6 -> D7 clients really seemed to love. One great usability improvement that you can make is to add a contextual link to a view (for example) that would allow them to quickly add the piece of content that corresponds to that view. Normally you’d add these custom contextual links through a set of hooks, but this module provides a nice UI to make it simple. 

Conditional Fields - The Conditional Fields module allows you to create fields that are dependent upon one another in order to be shown. One example of this would be to show a textarea of an admin (or user) selected “Other”. I added this module because it can be go a long way towards cleaning up administration screens when adding content types with lots of information.

Linkit - The Linkit module replaces the default CKEditor link icon with an autocomplete field that allows admins to easily drill down to the content they are looking to link to. We have a great write up on this module that you can find here.

Edit - Drupal 8 will ship with inline editing, and if you are too excited to wait, check out the Edit module. Edit module allows you to do just that, edit content in place. Note that you’ll need to use the CKEditor WYSIWYG if you want this to work on WYSIWYG fields.

Select2 - Like the autocomplete deluxe module above, the Select2 module replaces the standard select box with one that supports searching, remote data sets and infinite scrolling of results.

References Dialog - The References Dialog replaces all the standard reference fields with a dialog that allows them to add, edit and search for references. This can go a long way towards simplifying the administration workflow.

Content Menu - The Content Menu module adds the ability for administrators to be able to create pieces of content straight from the menu administration pages. When creating a piece of content, you have the ability to add a menu item, so it only makes sense that you can add a piece a content when adding a menu item.

Navbar - The Navbar module adds a mobile friendly navigation bar to the administration section of your website replacing the default toolbar which is non-responsive.

There you go. Fourteen modules to improve the authoring experience of your Drupal site. What do you think of the list? Are there any modules you would like to see added? Feel free to discuss in the comments below.

For more tips like these, follow us on social media or subscribe for free to our RSS feed and newsletter. You can also contact us directly or request a consultation
Categories: Drupal News

Drupal.org Featured Case Studies: University of Oxford

Fri, 11/07/2014 - 2:28am
Completed Drupal site or project URL: http://www.ox.ac.uk

The previous version of the University of Oxford site, also designed by Torchbox, was the top rated University site in a Times Education Supplement survey and was much imitated, but after more than seven years of duty, it was a little dated and, critically, wasn’t responsive.

The University of Oxford and Torchbox were excited to have the opportunity to revisit the site, and to revitalise it for a more digitally advanced generation of visitors. At the same time, we took on the challenge of moving this high profile, high traffic site to the Drupal Content Management System.

Key modules/theme/distribution used: Custom BreadcrumbsDomain AccessDisplay SuiteFeaturesLinkitLeafletMediaMedia: YouTubeMedia: VimeoMenu blockMenu Trail By PathWorkbenchWorkbench ModerationWorkbench MediaViewsWysiwygmothership
Categories: Drupal News

Theme by Danetsoft and Danang Probo Sayekti inspired by Maksimer