Skip to Content

Planet Drupal

Syndicate content - aggregated feeds in category Planet Drupal
Updated: 1 day 10 hours ago

Acquia: Build Your Drupal 8 Team: The Forrester Digital Maturity Model

15 June 2015 - 7:46am

In business, technology is a means to an end, and using it effectively to achieve that end requires planning and strategy.

The Capability Maturity Model, designed for assessing the formality of a software development process, was initially described back in 1989. The Forrester Digital Maturity Model is one of several models that update the CMM for modern software development in the age of e-commerce and mobile development, when digital capability isn't an add-on but rather is fundamental to business success. The model emphasizes communicating strategy while putting management and control processes into place.

Organizations that are further along within the maturity model are more likely to repeatedly achieve successful completion of their projects.

Let's take a look at the stages of this model, as the final post in our Build Your Drupal 8 Team series.

Here are the four stages:

Stage 1 is ad hoc development. When companies begin e-commerce development, there is no defined strategy, and the companies' products are not integrated with other systems. Most products are released in isolation and managed independently.

Stage 2 organizations follow a defined process model. The company is still reactive and managing projects individually, but the desired digital strategy has been identified.

Stage 3 is when the digital strategy and implementation is managed. An overall environment supportive for web and e-commerce development exists, and products are created within the context of that environment.

In Stage 4, the digital business needs are integrated. Products aren't defined in isolation, but rather are part of an overall strategic approach to online business. The company has a process for planning and developing the products and is focused on both deployment and ongoing support.

The final capability level, Stage 5, is when digital development is optimized. Cross-channel products are developed and do more than integrate: they are optimized for performance. The company is able to focus on optimizing the development team as well, with continuous improvement and agile development providing a competitive advantage.

Understanding where your company currently finds itself on the maturity scale can help you plan how you will integrate and adapt the new functionality of Drupal 8 into your development organization.

If you are an ad hoc development shop, adopting Drupal 8 and achieving its benefits may be very challenging for you. You may need to work with your team to move up at least one maturity level before you try to bring in the new technology.

In contrast, if your team is at stage 5, you can work on understanding how Drupal 8 will benefit not just your specific upcoming project, but also everything else that is going on within your organization.


  • A comprehensive SlideShare presentation on Digital Maturity Models.
  • A blog post by Forrester's Martin Gill that mentions the Digital Maturity Model in the context of digital acceleration.
Tags:  acquia drupal planet
Categories: Drupal

Annertech: Web Development on Fire? Smoke testing a Drupal Website

15 June 2015 - 3:57am
Web Development on Fire? Smoke testing a Drupal Website

Documenting code 10 years ago was always something that I wanted to do, but, let's face it: clients didn't give a damn, so unless you did it for free, it rarely happened. And I felt very sorry for the developer that had to fix any bugs without documentation (yes, even my code contains bugs from time to time!).

Categories: Drupal

Drupal core announcements: Recording from June 12th 2015 Drupal 8 critical issues discussion

15 June 2015 - 2:56am

It came up multiple times at recent events that it would be very helpful for people significantly working on Drupal 8 critical issues to get together more often to talk about the issues and unblock each other on things where discussion is needed. While these do not by any means replace the issue queue discussions (much like in-person meetings at events are not), they do help to unblock things much more quickly. We also don't believe that the number of or the concrete people working on critical issues should be limited, so we did not want to keep the discussions closed. After our second meeting last week, here is the recording of the third meeting from today in the hope that it helps more than just those who were on the meeting:

Unfortunately not all people invited made it this time. If you also have significant time to work on critical issues in Drupal 8 and we did not include you, let me know as soon as possible.

The issues mentioned were as follows:

Alex Pott
Rebuilding service container results in endless stampede:
Twig placeholder filter should not map to raw filter:

Francesco Placella[]=Open&priorities[]=400&version[]=8.x&component[]=entity+system&component[]=field+system&component[]=language+system&component[]=content_translation.module&component[]=language.module&component[]=views.module&issue_tags_op=%3D
FieldItemInterface methods are only invoked for SQL storage and are inconsistent with hooks:

Lee Rowlands
Make block context faster by removing onBlock event and replace it with loading from a BlockContextManager:

Francesco Placella
FieldItemInterface methods are only invoked for SQL storage and are inconsistent with hooks:

Alex Pott
Rewrite \Drupal\file\Controller\FileWidgetAjaxController::upload() to not rely on form cache

Gábor Hojtsy
Twig placeholder filter should not map to raw filter:

Daniel Wehner
drupal_html_id() considered harmful; remove ajax_html_ids to use GET (not POST) AJAX requests:

Francesco Placella
Node revisions cannot be reverted per translation:[]=Open&priorities[]=400&version[]=8.x&issue_tags_op=%3D&issue_tags=D8+upgrade+path

Daniel Wehner
SA-CORE-2014-002 forward port only checks internal cache:

Francesco Placella
Nat: it would be good to have your feedback on the proposed solution the translation revisions issue aside from its criticality (see and following)

Fabian Franz
[PP-2] Remove support for #ajax['url'] and $form_state->setCached() for GET requests:
Condition plugins should provide cache contexts AND cacheability metadata needs to be exposed:
Make block context faster by removing onBlock event and replace it with loading from a BlockContextManager:

Alex Pott
[meta] Identify necessary performance optimizations for common profiling scenarios:

Nathaniel Catchpole
Core profiling scenarios:
Node::isPublished() and Node:getOwnerId() are expensive:
And User:getAnonymousUser() takes 13ms due to ContentEntityBase::setDefaultLangcode() ( is similar.

Categories: Drupal

Jim Birch: Using CKFinder to organize image uploads by Content type in Drupal 7

15 June 2015 - 2:00am

As you may have noticed, /sites/default/files can quickly become a pretty busy place in your Drupal installation.  When creating image or file fields, we can add folders in the Drupal UI to organize the uploads.  But when we allow users to upload using the CKEditor WYSIWYG Editor, we have to work a bit harder to organize those uploads.

I am currently working on a project where we want to organize the uploads by content type.  Certain users have access to certain content types.  We want to be able to keep the separation going with the files.  Our goal is to have the wysiwyg uploads in the same folder as the "featured image" field on each content type, which is in /sites/default/files/[content-type].

What I quickly learned, was that IMCE is great in so many ways, and part of our normal Drupal install, but there is no obvious way to do this.  You can use IMCE to organize in a variety of different ways, like php date based folders and user id folders.  You could even have a roles based system, by creating an IMCE profile per role.  But I couldn't figure out a way to organize by field, or Content Type.

CKFinder to the rescue.  CKFinder is a premium file manager plugin for CKEditor.  When integrated with the CKEditor Drupal Module, both can be customized right in the Drupal UI.

Read more

Categories: Drupal

PreviousNext: How to index panelizer node pages using Drupal Apache Solr module

15 June 2015 - 12:44am

Apache Solr Search is a great module for integrating your Drupal site with the powerful Apache Solr search tool. Out of the box it can index nodes and their fields, but Panelizer pages won't be indexed. In this post I show how you can get around this by indexing the rendered HTML of a panelizer node page.

Categories: Drupal

Web Omelette: Drupal 8: custom data on configuration entities using the ThirdPartySettingsInterface

15 June 2015 - 12:00am

In this article we are going to look at how to use the ThirdPartySettingsInterface to add some extra data to existing configuration entities. For example, if you ever need to store some config together with a node type or a taxonomy vocabulary, there is a great way to do so using this interface. Today we are going to see an example of this and add an extra field to the menu definition and store the value in this way.

There are a number of steps involved in this process. First, we need to alter the form with which the entity configuration data is added and saved. In the case of the menu entity there are two forms (one for adding and one for editing) so we need to alter them both. We can do something like this:

/** * Implements hook_form_alter(). */ function my_module_form_alter(&$form, \Drupal\Core\Form\FormStateInterface $form_state, $form_id) { if ($form_id === 'menu_add_form' || $form_id === 'menu_edit_form') { my_module_alter_menu_forms($form, $form_state, $form_id); } }

Inside this general hook_form_alter() implementation we delegate the logic to a custom function if the form is one of the two we need. Alternatively you can also implement hook_form_FORM_ID_alter() for both those forms and delegate from each. That would limit a bit on the function calls. But let's see our custom function:

/** * Handles the form alter for the menu_add_form and menu_edit_form forms. */ function my_module_alter_menu_forms(&$form, \Drupal\Core\Form\FormStateInterface $form_state, $form_id) { $menu = $form_state->getFormObject()->getEntity(); $form['my_text_field'] = array( '#type' => 'textfield', '#title' => t('My text field'), '#description' => t('This is some extra data'), '#default_value' => $menu->getThirdPartySetting('my_module', 'my_text_field'), '#weight' => 1 ); if (isset($form['links'])) { $form['links']['#weight'] = 2; } $form['#entity_builders'][] = 'my_module_form_menu_add_form_builder'; }

In here we do a couple of things. First, we retrieve the configuration entity object which the form is currently editing. Then, we define a new textfield and add it to the form. Next, we check if the form has menu links on it (meaning that it's probably the edit form) in which case we make its weight higher than one of our new field (just so that the form looks nicer). And last, we add a new #entity_builder to the form which will be triggered when the form is submitted.

The getThirdPartySetting() method on the entity object is provided by the ThirdPartySettingsInterface which all configuration entities have by default if they extend from the ConfigEntityBase class. With this method we simply retrieve a value that is stored as third party for a given module (my_module in this case). It will return NULL if none is set so we don't even need to provide a default in this case.

Let us now turn to our #entity_builder which gets called when the form is submitted and is responsible for mapping data to the entity:

/** * Entity builder for the menu configuration entity. */ function my_module_form_menu_add_form_builder($entity_type, \Drupal\system\Entity\Menu $menu, &$form, \Drupal\Core\Form\FormStateInterface $form_state) { if ($form_state->getValue('my_text_field')) { $menu->setThirdPartySetting('my_module', 'my_text_field', $form_state->getValue('my_text_field')); return; } $type->unsetThirdPartySetting('my_module', 'my_text_field'); }

Inside we check if our textfield was filled in and set it to the third party setting we can access from the config entity object that is passed as an argument. If the form value is empty we reset the third party setting to remove lingering data in case there is something there.

And that's pretty much it for the business logic. We can clear the cache and try this out by creating/editing a menu and storing new data with it. However, our job is not quite finished. We need to add our configuration schema so that it becomes translatable. Inside the /config/schema/my_module.schema.yml file of our module we need to add this:*.third_party.my_module: type: mapping label: 'My module textfield' mapping: my_text_field: type: text label: 'My textfield'

With this schema definition we are basically appending to the schema of the config entity by specifying some metadata about the third party settings our module provides. For more information on config schemas be sure to check out the docs on

Now if we reinstall our module and turn on configuration translation, we can translate the values users add to my_text_field. You go to admin/config/regional/config-translation/menu, select a menu and when translating in a different language you see a new Third Party Settings fieldset containing all the translatable values defined in the schema.

Hope this helps.

In Drupal 8 var switchTo5x = true;stLight.options({"publisher":"dr-8de6c3c4-3462-9715-caaf-ce2c161a50c"});
Categories: Drupal

about seo