Skip to Content

Planet Drupal

Syndicate content - aggregated feeds in category Planet Drupal
Updated: 8 hours 38 min ago

Acquia: Drupal for Digital Commerce – Bojan Živanović

16 July 2014 - 5:49am

Bojan and I chatted at Drupal Dev Days 2014 about one of the newest and most important weapons available in Drupal's eCommerce arsenal: recurring billing for digital commerce in Drupal Commerce.

Categories: Drupal

IXIS: Nippy EdgeCast Purging

16 July 2014 - 2:27am

Since we integrated the EdgeCast CDN for one of our clients, and released a related EdgeCast Drupal module we have been encouraging more and more clients to consider a CDN layer to accelerate performance to multiple geographic locations and maintain an excellent uptime even during site maintenance periods.

A recent international client who is running many domains with federated content using the Domain module needed to make use of the content delivery network to improve performance and resiliance for their sites.

read more

Categories: Drupal

Acquia: Deliver digital faster with Drupal – Part 2

15 July 2014 - 6:45am

In Deliver digital faster with Drupal Part 1, I showed you some of the many examples of successful sites built rapidly thanks to Drupal’s modularity. To stay ahead of your competition, you need to be nimble and agile; Drupal helps you do this with reusable, transferable digital experiences that can be customised to suit various niches even within a single business enterprise. All, of course, without paying additional license fees or mandated limits on developers, environments, or copies.

Categories: Drupal

Liran Tal's Enginx: Migrate Drupal 7 to WordPress 3.9 – The Conclusion

15 July 2014 - 6:35am
This entry is part 2 of 2 in the series Drupal 7 to Wordpress 3.9 Migration

Migrate Drupal 7 to WordPress 3.9  - To recap, in a previous post on this series, I’ve set the background for my action to migrate  from Drupal 7 to WordPress 3.9. In this post, we will explore the process of making this migration happen.

If you’ve been on this search before to migrate from Drupal to WordPress, then you’ve realized that there aren’t a lot of resources, and that you may have some preferences in regards to the migration process. Some solutions that popped required to have both instances of Drupal and WordPress up and running for some reason, but that didn’t fit my requirements as I wanted to use the same domain and not needing to setup another one just for the migration process. Other solutions are of course professional support services which will perform the migration for you, but you’d have to say goodbye to a few hundred dollars to begin with (prices range from $750 to $3500 for a website migration)

Finding Drupal2Worpdress provided me a good start to get things rolling. As with most things on Github for me, I usually begin by forking a repository and Drupal2Wordpress was no exception. Quickly after I reviewed the code in the original repository I found out that the script is very small and focused, without requiring any special dependencies or extra configuration which was my primary goal – finding the most simple solution as possible. Now I’m ready to take a stub at it.


My Video Course - Step by Step Drupal 7 to WordPress 3.9 Migration

I created a Video course on to teach you the skills of migrating Drupal 7 to WordPress 3.9.

I’d appreciate if you leave a review after taking the quick course

Step-by-Step Drupal 7 to WordPress 3.9 Migration Learn how to migrate your content, users, and more from a Drupal 7 website to WordPress 3.9.




Getting to Business with Drupal2Wordpress

Drupal2Wordpress is essentially very simple. It only requires to edit the PHP code at the beginning, and set the connection information correctly for both WordPress and Drupal database. That already implies on the characteristics of this migration tool – it expects that both instances of Drupal and WordPress are available through a database connection and since this tool has to be accessible and run on the hosting account service  and be triggered from the web or from a cron job (because hosting accounts do not open their database servers to the public).

Some of my fixes to this tool began with importing any content type from Drupal, yet making sure they are imported into WordPress as eligble posts content type (as opposed to pages for example, which aren’t blog related). URL aliasing has also been fixed so that imported posts in the new WordPress install are just working good, as well as another fix to migrate only approved comments. New additions to the tool included the support for migrating users, and adding a default ‘Blog’ category on WordPress and relating all posts to it (as otherwise they are not displayed).

The tool has been tested and it only requires to get a fresh installation of WordPress 3.9 to migrate any Drupal 7 site to it. You’re welcome to fork out the repository or test it and comment so we can further improve upon it.

Drupal2Wordpress – the Github repository.


(adsbygoogle = window.adsbygoogle || []).push({});

The post Migrate Drupal 7 to WordPress 3.9 – The Conclusion appeared first on Liran Tal's Enginx.

Categories: Drupal

Drupalize.Me: Drupal 8 Plugins Explained

15 July 2014 - 6:00am

As you start down the road of learning Drupal 8 module development, one of the first new Drupalisms that you're likely to encounter are plugins. After writing a blog post about creating blocks, which uses the new plugin architecture, I thought it might be interesting to take a step back and talk a little bit more about plugins at a higher level. This blog post contains an introduction to the what and why of plugins to help Drupal 7 developers make the transition to Drupal 8.

Categories: Drupal

Nuvole: Packaging and reusing configuration in Drupal 8

15 July 2014 - 6:00am
Bringing "reusable features" to Drupal 8.

This is a preview of Nuvole's training at DrupalCon Amsterdam: An Effective Development Workflow in Drupal 8.

Configuration Management in Drupal 8 elegantly solves staging configuration between different environments addressing an issue that is still haunting even the most experienced Drupal 7 developer. In earlier posts we covered the new Configuration Management in Drupal 8, seeing how it compares to Drupal 7 and Features, and even investigated how to manually simulate Features in Drupal 8 last year. Recent developments and contrib modules can take us several steps closer.

Configuration Management can get quite streamlined when using Git and Drush 7 as explained below.

Step 1: Move staging configuration directory into a versionable location

By default Drupal 8 will place the staging directory under sites/default/files and it is considered a good practice to not version that location, but an alternative location can easily be specified in our settings.php:

$config_directories['staging'] = 'config/staging';

Done that, we must rebuild the Drupal cache:

$ drush cache-rebuild

Step 2: Export active configuration into staging directory via Drush

The Configuration Management system exposes a set of very handy Drush commands: in order to “dump” all active configuration into our newly set staging directory we can just run:

$ drush config-export
The current contents of your export directory (config/staging) will be deleted. (y/n): y
Configuration successfully exported to config/staging.                                                    

Step 3: Push configuration changes and import it on the staging environment

Since the staging directory is under version control we can simply git-add all its content and push it to the remote repository. After having set-up the staging environment as an exact replica of our development environment (this is actually required for the configuration staging to work) we can start profiting from the new Drupal 8 CM system. Imagine we have changed the site name on dev, after having exported, committed and pushed that change, on the staging site we will simply run:

$ git pull

$ drush config-import

Config               Operation                update
Import the listed configuration changes? (y/n): y
The configuration was imported successfully.

For a more comprehensive overview of the Configuration Management system please refer to our previous blog post Configuration Management: Drupal 7 to Drupal 8.

Packaging configuration

For those developers familiar with code-driven development practices the three steps above might resemble what the Features module does in Drupal 7 with its features-update and features-revert Drush commands.

While Drupal 8 configuration staging capabilities are far more advanced than what Features could possibly provide, what the new Configuration Management system really lacks is the ability to package configuration.

Enter the Configuration development module

The Configuration development module, currently maintained by chx, serves two main purposes:

  • It automates the import of specified configuration files into the active storage.
  • It automates the export of specified configuration objects into files.

The module offers a simple, global UI interface where a Drupal developer can set which configuration is automatically exported and imported any time they hit the “Save” button on a configuration setting page.

In order to achieve a more modular configuration packaging it would be enough to set a specific module’s config/install directory as the actual export destination.

Nuvole contributed a patch to make that possible: instead of firing an auto-export every time a “Save” button is clicked the developer can, instead, specify in the module’s info file which configuration needs to be written back to that module’s install directory and run a simple Drush command to do that.

Reusable “features” in Drupal 8

One of the main advantages of having a standardized way of dealing with configuration means that modules can now stage configuration at installation time. In a way that’s something very close to what Features allowed us to do in Drupal 7.

Say we have our news section up and running on the site we are currently working on and we would like to package it into a custom module, together with some other custom code, and ship it over a new project. The patched Config development module will help us to do just that! Here it is how:

Step 1: Download, patch and enable Configuration development module

We need to download and enable the Configuration development module version 8.x-1.x-dev and apply the patch attached to this issue.

After rebuilding the cache, we will have the config-writeback Drush command available. Let's have a closer look at what it is meant to do:

$ drush help config-writeback

Write back configuration to a module's config/install directory. State which configuration settings you want to export in the module's info file by listing them under 'config_devel', as shown below:

  - entity.view_display.node.article.default
  - entity.view_display.node.article.teaser
  - field.instance.node.article.body

drush config-writeback MODULE_NAME        Write back configuration to the specified module, based on .info file.

module                                    Module machine name.

Aliases: cwb

Step 2: Find what configuration needs to be packaged

We now look for all configuration related to our site’s news section. In Drupal 8 most of the site configuration is namespaced with related components so, if we keep on using consistent naming conventions, we can easily list all news-related configuration by simply running:

$ drush config-list | grep news

Step 3: Package configuration

To package all the settings above we will create a module called custom_news and, in its info file, we will specify all the settings we want to export, listing them under the config_devel: directive, as follows:

$ cat modules/custom_news/

name: Custom News
type: module
description: 'Custom news module.'
package: Custom
core: 8.x

After enabling the module we will run:

$ drush config-writeback custom_news

And we will have all our settings exported into the module’s install directory:

$ tree -L 3 modules/custom_news/

├── config
│   └── install
│       ├──
│       ├──
│       ├──
│       ├──
│       ├──
│       └──

The Drush command above takes care of clearing all sensitive UUID values making sure that the module will stage the exported configuration cleanly, once enabled on a new Drupal 8 site.

To get the news section on another site we will just copy the module to the new site's ./modules/ directory and enable it:

$ drush en custom_news

The following extensions will be enabled: custom_news
Do you really want to continue? (y/n): y
custom_news was enabled successfully.      Final evaluation: Drupal 7 versus Drupal 8

One of the main differences between working in Drupal 7 and in Drupal 8 is represented by the new Configuration Management system.

While Features was proposing a one-stop solution for both configuration staging and packaging, Drupal 8 CM does a better job in keeping them separate, allowing developers in taking a greater control over these two different and, at the same time, complementary aspect of a solid Drupal development workflow.

By using the method described above we can upgrade our comparison table between Drupal 7 and Drupal 8 introduced in one of our previous posts as follows:

Functionality D7 Core D7 Core + Features D8 Core (current) D8 Core (current) + Patched Config Devel Export full site config (no content) NO NO YES YES Export selected config items NO YES YES YES Track config changes (full site) NO NO YES YES Track config changes (selected items) NO YES YES YES Stage configuration NO YES YES YES Package configuration NO YES NO YES Reuse configuration in other projects NO YES NO YES Collaborate on the same project NO YES NO NO

The last "NO" deserves a brief explanation: Configuration Management allows two developers to work simultaneously on different parts of the same project if they are very careful: but "merging" the work would have to be done by version control (GIT or similar), that doesn't know about YAML or Drupal.

Some open issues

Contributed modules seem to be the best way to enhance the core Configuration Management system, much like what happened with Drupal 7 and Features. There are still several issues that should be considered for an optimal workflow, to match and improve what we already have in Drupal 7:

  • Piping: the ability to relate configuration components based on both hard and logic dependencies, for example: I export a content type and, automatically, I get also its fields. If piping might have been too rigid, at times, it would be still useful to have in some configurable form.
  • Enhanced configuration diff: it might be useful to have the possibility to review what configuration is going to be installed before enabling a module, like it is now when importing staged configuration to the active storage.
  • Granularity: it is still impossible to export part of a configuration file, so we still depend on the core conventions for grouping configuration into files, and we can't export a single permission for example.
  • Ownership: we can't know if another module (or "feature") is tracking a component we wish to track; this could be useful in the perspective of maintaining several "modular" features.
  • Updates: we can reuse configuration by simply enabling a module, but this holds only for the initial installation; after a module is enabled, we don't have a clean way to import changes (say, to "upgrade" to a newer version of the feature) outside the standard workflow foreseen in Configuration Management.
Tags: Drupal 8, Drupal Planet, DrupalCon, Drush, Code Driven DevelopmentImage: 
Categories: Drupal

Kristian Polso: Password protect your Drupal site with Shield-module

15 July 2014 - 12:26am
From time to time, there might arise a situation where you want to password protect your Drupal site. Maybe the site is under development, or you just want it to be available to a selection of users. This is usually done with something called "HTTP Basic Auth", which allows you to password protect a site. This can be done in Apache by modifying the .htaccess file.  There are some great tutorials on how to do this, but this is not the correct way of doing it for couple of reasons.
Categories: Drupal

DrupalCon Amsterdam: Come for the Con, stay for the sprints! Plan your travel for weekend and Friday sprints in Amsterdam

14 July 2014 - 11:10pm

Sprints are an important part of DrupalCon you will want to experience. Arrange your travel and hotel to take advantage of the extended sprints before DrupalCon on 27-28 September, the big sprint day on Friday, 3 October, and the extended sprints after DrupalCon on 4-5 October.

Stay for the sprints on Friday

Every DrupalCon, we cap off the week with a full day of Drupal sprints. DrupalCon Amsterdam's sprint day is Friday, 3 October, starting at 9:00 and going until 18:00. You will not want to leave early and miss any of it. So, book your departure very very late Friday, or even better, Saturday or Sunday!

Whether you are a site builder, designer, programmer, themer, technical writer, project manager, or usability specialist, if you have Drupal experience, this is your chance to contribute back to the Drupal community, meet other Drupal enthusiasts and interact with them building the future of Drupal.

Something for everyone

The sprint on Friday will include three separate events:

1. First-Time Sprinter Workshop
If you're new to Drupal contribution, you can attend the FREE mentored workshop on Friday from 9-noon. The hands-on workshop will cover the basics of contribution essentials like the issue queues, IRC, git, and optionally setting up Drupal 8 on your laptop.

2. Mentored Core Sprint
If you are already have all the tools, have used the issue queue, have a working Drupal 8 development environment on your laptop, would like to work with a mentor to contribute to Drupal core, and would like help finding an issue to work on, or if you're not quite sure where to start contributing, come to the Mentored Core Sprint. This sprint will run all day, with First-Time sprinter workshop attendees joining in the afternoon.

Sprint mentors will help you find a task for a Drupal core issue and then help you work on it. You can create patches for bugs, add documentation to issues, test patches, and more!

To get a head start, set up your Drupal 8 development environment before Friday. Attend the core office hours from home. Or, at the conference, we will have plenty of opportunities to help get you set up at any of our Get Involved BOFs (times and locations TBD), or you can come to the First-Time Sprinter Workshop Friday morning.

3. All the Sprints!
If you're an experienced Drupal contributor, you can head straight to one of the many other share your sprint initiative to do focused work on one particular area of Drupal, like Views, the Drupal 8 multilingual initiative, the Twig theming system, Migrate,, and more.

You will work directly with initiative leads and collaborate on issues. This is a great opportunity to make a difference for the Drupal project AND learn from peers how to solve problems!

Mentor new contributors

Are you already familiar with setting up a development environment or with the core contribution process? Want to help other contributors? We need about 35 mentors to work with our first-time contributors. Sign up early and secure your mentor t-shirt in the size of your choice.

Sign up to help mentor

Want to mentor, but also want to sprint yourself? Extended sprints to the rescue!

Extended Sprints are 27-28 September and 4-5 October

Take advantage of being able to work with others from around the world with extra days: extended sprint days! Read more details and sign up for extended sprints so we can make sure we have enough resources and room for you! We'll be sprinting around the clock at the Berlage in the heart of Amsterdam and seeing the sights and enjoying the city's great pubs and restaurants during breaks.

Make a difference

DrupalCon sprints are critically important to pushing the Drupal project forward, and are also a great opportunity to give back alongside the people who help bring the code to life. Join us DrupalCon Amsterdam and help make an impact!

Sponsor opportunities available

Friday sprints are sponsored by Werk21, extended sprint venue, coffee and catering thanks to the Drupal Association, Acquia Large Scale Drupal, Open8, and … YOU?

Contact us for more information or to sponsor.

Cathy Theys (YesCT)
DrupalCon Amsterdam sprint lead

Categories: Drupal

NEWMEDIA: Drupal PCI Compliance White Paper: Version 1.1 Released!

14 July 2014 - 8:20pm
Drupal PCI Compliance White Paper: Version 1.1 Released!Version 3.0 of the PCI compliance standard becomes mandatory on January 1st, 2015 and will be a complete game changer for most Drupal eCommerce sites.Are you ready to meet the challenge?

For those wanting to dive right in, simply click this link to download the white paper.

Matt Kleve was spot on in his DrupalCon Denver 2013 presentation title PCI: a Four-Letter Word of eCommerce. Whenever I present on or discuss the subject matter with other members of the community, there is usually some level of disdain for the payment card industry (PCI) for creating the data security standard (DSS) that we all commonly know as PCI compliance. The complaints are many:

  • It's too confusing.
  • It's too difficult.
  • It's too expensive to deal with.
  • It's security theater.
  • It doesn't guarantee you'll never get hacked.

Once everyone has finished airing their grievances, there is always the unspoken question that you can see on everyone's face... Can't we just ignore this little nuisance of a requirement and get back to processing credit card transactions?

The reality is that we cannot pretend PCI compliance doesn't exist. The growth of the eCommerce market can only continue as long as users trust the process, and that can only happen if the end-to-end process remains secure. Oh—and any merchant agreement you sign will stipulate PCI compliance as a requirement (make sure to read all that fine print!). Therefore, if you want to accept credit or debit cards payments online (even through 3rd party) then you really have no other choice. Compliance is mandatory.

That's the bad news. The good news is that understanding where and how to get started for a Drupal site is much easier as a result of the Drupal PCI Compliance White Paper that was initially published a year ago (and a HUGE thanks to the many sponsors that helped make that happen). It's readable within an hour and can help everyone involved on a Drupal project make informed decisions and reduce their risk as much as possible.

The Standard Gets Stronger

As the volume of eCommerce transactions continues to grows, it becomes even more important to protect every component in the entire system handling the transaction. After all, a single point of failure was responsible for Target debacle, where the credit card records of 40+ million customers were compromised. This resulted in a huge financial loss for the company as well as a PR nightmare to deal with.

To minimize these types of attacks from growing in size and frequency, the security standard must keep up. The latest update to the PCC-DSS (version 3.0) was published in November, 2013 and will become mandatory of all eCommerce sites on January 1st, 2015.

What PCI-DSS 3.0 Means for Drupal

It's hard to understate the impact this will have on the Drupal community. In version 1.0 of the standard, there was a there was a very easy way out. Simply redirect the user to a hosted payment page on PayPal or Authorize.Net and you could outsource almost all of your responsibilities. This became the goto solution for many budget conscious eCommerce websites.

Version 2.0 of the standard introduced a gray area. The PCI council created a supplemental guide that stated the hosted payment pages, direct post, and iframe solutions all had vulnerabilities. Despite disclosing these attack vectors, the PCI council didn't directly come out and state that they must now meet a larger set of security controls. This didn't stop certain vendors (notably Braintree) from promising compliance within 15 minutes. The dilemma for someone interpreting version 2.0 of the standard was obvious: if there were ways to break in and steal cards, wouldn't that require one to fully lock down the LAMP stack and Drupal application layer? This gray area only led to additional confusion among the Drupal community, who (as a whole) simply opted for the easy route interpretation of the standard.

Version 3.0 ended the confusion entirely. Now hosted payment pages and direct post solutions fall into a new category (SAQ A-EP), which includes over 139 security controls that cover everything from anti-virus to password policy requirements. What used to be trivial (SAQ A) for most websites to achieve has become very challenging. No longer are shared hosting solutions viable. No longer can a website lag behind on updating Drupal core and contrib modules when security updates are available. No longer is it acceptable to enable php filter, allow authenticated users to use the full HTML filter, or manage a site through a shared FTP login.

In short, this is a big damn deal for the Drupal eCommerce community. Without readily available "turnkey" solutions (such as PCI Level 1 managed hosting), many smaller eCommerce sites may not be able to meet the requirements and may be forced to seek non-Drupal based alternatives. In fact, the cost of achieving and maintaining SAQ A-EP could easily fall within the $10,000-$100,000 price range, which is likely to exceed the entire budget of most Drupal eCommerce sites!

Learning More

Covering all the ins and outs of PCI compliance is difficult to do in a single blog post (trust me, I tried with the excessively long article titled Let's Talk About PCI Compliance for Ubercart and Drupal Commerce. Therefore, I'll close with this final recommendation (or plea): if you build, maintain, operate, or own an eCommerce website, then you should absolutely read the new version of the Drupal PCI Compliance White Paper. And if you have any comments, questions, or concerns, please submit an issue in the github issue queue.

Categories: Drupal

PreviousNext: Using Mink for web testing

14 July 2014 - 4:00pm

PreviousNext have been using Behat to test Drupal 7 sites for some time now. More recently, there has been a big push to introduce Behat tests in Drupal 8. So what is it all about?

In this post, I'll be taking a look at the Mink layer behind Behat and using it for web scraping and functional testing and what this means for the future of Drupal testing.

Categories: Drupal

Károly Négyesi: Drupal 8 progress from my / MongoDB perspective: update #27

14 July 2014 - 3:53pm

There hasn't been an update for some time now; things have quieted down a bit, I am mostly just writing drivers now (and coach people on migrate). MongoDB module caught up with the latest config changes and so the module works again. Migrate bugfixing moves along steadily with more and more people actually trying it and fixing bugs, hurray! Blocks now get placed more sensibly, there's steady progress on D6->D8 CCK Single On/Off Checkbox, Checkboxes/Radio buttons, and Select formatters, also node authors in more interesting cases are broken (In Drupal 6, the node.uid and the node_revision.uid can be different). The first step for migration groups is ready. This is the stepping stone for Drupal 7 migrations because quite a few migration will need to be in both the Drupal 6 and the Drupal 7 group. It is also quite important for contrib -- now contrib will be able to just add in a migration YAML that this migration belongs to the Drupal 6 group and it'll run along with core, as easy as that.

Our favorite meta issue convert SQL queries to entitity queries issue is almost finished, opens the door for multilingual / performance enhancements and of course MongoDB :)

I have discussed with Crell how to define a standard mechanism for backend-aware service overrides. As usual, this is good for core because it allows MySQL and PostgreSQL specific drivers but also at the same time it will help MongoDB as well: currently the MongoDB module handles the service overrides but it's an all-or-nothing thing. With this issue, you'll be able to mix various storage backends as you want in a standard fashion.

Finally, even if it's not directly MongoDB related, the issue to switch on twig autoescape is almost done too -- this will make Drupal 8 more secure, even custom modules and custom themes will be easier to write in a secure fashion. Hopefully this will make Drupal 8 an even more appealing offer.

Categories: Drupal

Drupal Association News: Drupal Association Board Meeting Summary

14 July 2014 - 3:22pm

We held our July Drupal Association Board Meeting last Wednesday. Halfway through the year, we took the opportunity to review our metrics for the year thus far, discuss some possible changes to our governance model, and tackle a couple of housekeeping issues in executive session. If you somehow managed to miss us during the live session, never fear! We've got a recording, the meeting materials, and the minutes available for your perusal, as well as this summary:


DrupalCon Austin is now behind us, but it's not forgotten! We're thrilled to have helped host an event that was so successful in so many ways. We were able to beat our Portland attendance numbers, though we did fail to meet our stretch goal of 4,000 attendees. At this point, we are sifting through all the registration, financials, and evaluation data to pull together a summary report (with comparisons to Portland) for the August board meeting.

Next up is DrupalCon Amsterdam. Registration for Amsterdam is strong and we're particularly excited that we had a record number of session submission - over 500! The sessions are now set, and we have a great line up, covering some of the most relevant topics for our community. There will be fun as well, of course. What's more fun than a bicycle? Apparently nothing, because many of our attendees are purchasing the bike package as part of their registration! And of course, there's Tour de Drupal

DrupalCon Latin America is the first DrupalCon scheduled for 2015. The site is scheduled to be up in mid-August for session submissions. We are also working on determining how we will handle languge and translation at DrupalCon Latin America. Working with the local team, we are discussing options for content translation so that we can serve both English and Spanish speakers.

We were able to create a lot of momentum for at DrupalCon Austin. Staff and Working group members conducted several user research interviews for the User Research Project led by Whitney Hess. And, in the weeks following DrupalCon, our staff were able to deploy over 30 patches to that came out of the sprints in Austin. 

In addition, we also recently deployed a CDN service for The CDN allows us to reduce strain on our infrastructure, increase our security, and most importantly should increase performance for users, especially those outside of the United States. We want to thank Narayan Newton (nnewton) and the rest of the Infrastructure Working Group for their direction and help.

Finally, there is a new way for you to keep on top of change notifications for We've standardized the reporting and, in addition to posting them online at, you can now subscribe to an email list to receive notifications right in your inbox.

Board Governance

At the June board retreat in Austin, each of the board committees met to discuss current issues. The Governance Committee met with the aim of exploring ideas that would increase the diversity of candidates for our elected candidates, possible term limits for board members, and how to improve committee performance on the board. Based on that conversation, the committee presented several ideas for the board to discuss. No decisions were made at this time, but the Governence Committee did receive good feedback to incorporate into future proposals. 

Next Meeting

Want more board news? Get it live! Join us at one of our upcoming board meetings

Flickr photo: Kristen Pol

Categories: Drupal

Lullabot: Module Monday: Honeypot

14 July 2014 - 11:00am

Fighting spam is an ongoing cat and mouse game as site owners come up with protections against spam, and spammers come up with increasingly impressive ways to bypass those protections. Solutions like Mollom have been popular in recent years, however Mollom is tied to an external service and only works while that service is running smoothly. Additionally, it costs money if your site has a lot of traffic. CAPTCHA challenges are also a popular solution, but they have accessibility problems -- and automated tools are getting increasingly successful at bypassing them.

Categories: Drupal

Acquia: The Open Source Value Proposition

14 July 2014 - 7:36am

Every so often, advocates and vendors of proprietary/closed source software attempt a FUD (Fear, Uncertainty & Doubt) campaign of comment and link-baiting in order to reframe the conversation around Open Source. The arguments brought up in these discussions are predictable and generally straw man arguments that hold little water, so I wanted to take time to break these down and show the real value proposition of Open Source platforms, web content management systems generally, and Drupal specifically.

Categories: Drupal

Stanford Web Services Blog: Module of the Day: Path Redirect Import

14 July 2014 - 6:02am

Today we're going take a look at the Path Redirect Import module, which lets you import redirects in bulk into your Drupal site.

All of the modules described in this post are available on Stanford Sites.

Categories: Drupal Function scope & Drupal cache

14 July 2014 - 4:48am
Function scope & Drupal cache

When developing with caching in mind it's important to consider functionality scope. For example, writing code which is per visitor specific in PHP with caching support ahhh =O. While rewriting that same functionality in JavaScript offers us a quick and cache friendly solution. Consider the following examples.

/** * Implements hook_preprocess_TEMPLATE(). */ function THEME_preprocess_page(&$variables) { $detect = mobile_switch_mobile_detect(); if ($detect['ismobiledevice'] && !$detect['istablet']) { $variables['logo'] = url('sites/all/themes/THEME/images/logo_rev.png', array('absolute' => TRUE)); } } /** * Custom header block content. */ function _header_search_content_block() { $detect = mobile_switch_mobile_detect(); $form = drupal_get_form('search_form'); // Format search form. $form['basic']['keys']['#attributes']['placeholder'] = t('Search'); $form['basic']['keys']['#title_display'] = 'invisible'; $form['basic']['keys']['#size'] = 20; if ($detect['ismobiledevice'] || $detect['istablet']) { $form['basic']['keys']['#size'] = 15; } $items = array( render($form), l(t('another item'), 'link') ); return theme('item_list', array('items' => $items)); }

Clearly this code can be easily rewritten in JavaScript. However with caching enabled we'll need a method to pass our device detection variables. The only function which is exempt from Drupal cache is boot(). Calling drupal_add_js() directly from hook_boot() fails; the following example is using Mobile Switch and illustrates a work around.

/** * This is an example of how to manipulate site elements with page * caching enabled. We pass our detection variables to js settings * which we can then act on. */ function MODULE_boot() { $detect = mobile_switch_mobile_detect(); // Whatami. $_SESSION['detect'] = array( 'ismobile' => $detect['ismobiledevice'], 'istablet' => $detect['istablet'] ); } /** * Implements hook_init(). */ function MODULE_init() { drupal_add_js(array('detect' => $_SESSION['detect']), 'setting'); } /** * @file * MODULE.theme.js */ (function($) { Drupal.behaviors.MODULE = { attach: function(context, settings) { // Swap logo for mobile. if (settings.detect.ismobile && !settings.detect.istablet) { $('.site-branding__logo img').attr('src', Drupal.settings.basePath + 'sites/all/themes/THEME/images/logo_rev.png'); } // Search box size. if (settings.detect.ismobile || settings.detect.istablet) { $('.l-region--header .search-form input.form-text').attr('size', 15); } } }; }(jQuery));

These flags can of course be used for more fruitful purposes =)... Note, this sort of consideration is most likely second nature to most Xd.

Categories: Drupal

CTI Digital: Installing Drush using Composer on Mac OS X 10.9 Mavericks

14 July 2014 - 3:46am
Following on from our previous guide “Creating and using an public/private SSH key-pair in Mac OS X 10.9 Mavericks” in which we walked you through the process of setting up Git on Max OS X 10.9 Mavericks, we’re now going to look at installing Drush using Composer. If you’re never heard of Drush before, the description provided on the  Drush GitHub repository offers a succinct and accurate explanation of what Drush is and the tools it makes available to you: Drush is a command line shell and Unix scripting interface for Drupal. If you are unfamiliar with shell scripting, reviewing the documentation for your shell (e.g. man bash) or reading an online tutorial (e.g. search for "bash tutorial") will help you get the most out of Drush. Drush core ships with lots of useful commands for interacting with code like modules/themes/profiles. Similarly, it runs update.php, executes sql queries and DB migrations, and misc utilities like run cron or clear cache. Ultimately our goal in these series of guides is to give anyone both experienced and inexperienced alike the knowledge and skills required to configure their system so that an installation of Drupal can be run from it with a suite of tools available for them to use from the get-go. Let’s begin. Installing Composer Rather than installing Drush manually, we’re going to let a tool called Composer do all the hard work for us. Composer is a tool for handing dependency management the full description for which can be found on the Composer site. In a nutshell though, the following sums up Composer well: Composer is a tool for dependency management in PHP. It allows you to declare the dependent libraries your project needs and it will install them in your project for you. Let’s install Composer. Open a new instance of the Terminal by either navigating to the Applications folder within the finder followed by the Utilities sub-folder, or alternatively by pressing “Cmd+Space” and typing “Terminal” followed by the “Enter” key. Once open, type the following command to ensure you’re in your home directory: cd ~/ To download composer, type the following command into the Terminal and hit enter: curl -sS| php At this point you could type “~/composer.phar --help” into the command line and you’ll most likely get a list Composer help documentation, but we want to be able to access Composer simply by typing the command “composer”, so let’s move the *.phar file into our “/user/local/bin” directory. Note: On a fresh installation of OS X 10.9, the “/usr” directory will very likely be empty. If this is the case, to enable us to successfully move Composer to “/usr/local/bin/composer” you’ll need to type the following two commands “sudo mkdir /usr/local” and “sudo mkdir /user/local/bin”. After typing the first command, you may be prompted for your system password. Simply enter it to continue. Now we’re all set to move Composer. To do this, type the following command into the Terminal: mv composer.phar /usr/local/bin/composer Note: If you get an error trying to move the file, prefix the command above with “sudo” and try again. We should now be able to type “composer” into the terminal and get something other than an error returned. Try this out by typing “composer” and hitting enter. Adding the Composer “bin” directory to our path Once Drush is installed, we will be able to type “~/.composer/vendor/bin/drush” followed by the Drush command of our choice, but who wants to do that every time?  To be enable the ability to type “drush” followed by our command we need to add Composer’s bin directory to our path. In your home directory “~/“ type the command “nano ~/.bash_profile” and add the following line to the file that opens up: export PATH="$HOME/.composer/vendor/bin:$PATH" Quit Nano, by pressing “Ctrl+X” and when asked if you wish to save the document type “Y” and hit “Enter”. Finally we need to re-source our “.bash_profile” file by typing “source ~/.bash_profile” into the Terminal (alternatively you can quit and re-open the Terminal). Installing Drush At this point, installing Drush is a piece of cake. Simply type the following into the Terminal and hit “Enter” composer global require drush/drush:dev-master Drush should now be installed. To ensure it is, type “drush” into the command line and you should see a series of Drush help documentation. If you had any problems following this guide feel free to get in touch with me on Twitter at @craigperks
Categories: Drupal

Wunderkraut blog: Configuration Entities in Drupal 8

14 July 2014 - 2:10am

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.


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?


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

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

13 July 2014 - 7: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

about seo