Skip to Content

Planet Drupal

Syndicate content - aggregated feeds in category Planet Drupal
Updated: 4 hours 19 min ago

Dcycle: Catching watchdog errors in your Simpletests

6 July 2015 - 11:04am

If you are using a site deployment module, and running simpletests against it in your continuous integration server using drush test-run, you might come across Simpletest output like this in your Jenkins console output:

Starting test MyModuleTestCase. [ok] ... WD rules: Unable to get variable some_variable, it is not [error] defined. ... MyModuleTestCase 9 passes, 0 fails, 0 exceptions, and 7 debug messages [ok] No leftover tables to remove. [status] No temporary directories to remove. [status] Removed 1 test result. [status] Group Class Name

In the above example, the Rules module is complaining that it is misconfigured. You will probably be able to confirm this by installing a local version of your site along with rules_ui and visiting the rules admin page.

Here, it is rules which is logging a watchdog error, but it could by any module.

However, this will not necessarily cause your test to fail (see 0 fails), and more importantly, your continuous integration script will not fail either.

At first you might find it strange that your console output shows [error], but that your script is still passing. You script probably looks something like this:

set -e drush test-run MyModuleTestCase

So: drush test-run outputs an [error] message, but is still exiting with the normal exit code of 0. How can that be?

Well, your test is doing exactly what you are asking of it: it is asserting that certain conditions are met, but you have never explicitly asked it to fail when a watchdog error is logged within the temporary testing environment. This is normal: consider a case where you want to assert that a given piece of code logs an error. In your test, you will create the necessary conditions for the error to be logged, and then you will assert that the error has in fact been logged. In this case your test will fail if the error has not been logged, but will succeed if the error has been logged. This is why the test script should not fail every time there is an error.

But in our above example, we have no way of knowing when such an error is introduced; to ensure more robust testing, let's add a teardown function to our test which asserts that no errors were logged during any of our tests. To make sure that the tests don't fail when errors are expected, we will allow for that as well.

Add the following code to your Simpletest (if you have several tests, consider creating a base test for all of them to avoid reusing code):

/** * {inheritdoc} */ function tearDown() { // See $num_errors = $this->getNumWatchdogEntries(WATCHDOG_ERROR); $expected_errors = isset($this->expected_errors) ? $this->expected_errors : 0; $this->assertTrue($num_errors == $expected_errors, 'Expected ' . $expected_errors . ' watchdog errors and got ' . $num_errors . '.'); parent::tearDown(); } /** * Get the number of watchdog entries for a given severity or worse * * See * * @param $severity = WATCHDOG_ERROR * Severity codes are listed at * Lower numbers are worse severity messages, for example an emergency is 0, and an * error is 3. * Specify a threshold here, for example for the default WATCHDOG_ERROR, this function * will return the number of watchdog entries which are 0, 1, 2, or 3. * * @return * The number of watchdog errors logged during this test. */ function getNumWatchdogEntries($severity = WATCHDOG_ERROR) { $results = db_select('watchdog') ->fields(NULL, array('wid')) ->condition('severity', $severity, '<=') ->execute() ->fetchAll(); return count($results); }

Now, all your tests which have this code will fail if there are any watchdog errors in it. If you are actually expecting there to be errors, then at some point in your test you could use this code:

$this->expected_errors = 1; // for example Tags: blogplanet
Categories: Drupal

A Small Web Firm: Connecting Tableau to Drupal on Pantheon

6 July 2015 - 10:29am
Data-driven content management Although creating, searching for, updating, and publishing content in Drupal is a snap, understanding and making decisions based on that content can be challenging. Questions like, "What are the most viewed, untranslated case studies?" or "Does an accelerated blogging cadence increase page views?" are difficult or impossible to answer within Drupal alone. Though the data that could help answer those questions may live in Drupal, content editors or administrators are unlikely to find answers on their own because the information is made available, if at all, through complex UIs only understood by Drupal site builders, developers, or power users. This problem--where those most knowledgeable about some dataset are only able to ask questions of that data by proxy through a specialist--extends far beyond just content management in Drupal. Tableau (my employer) takes pride in helping solve this type of problem for organizations the world over, and because Drupal runs on pervasive database technologies like MySQL and PostgreSQL, we also happen to work well with Drupal: just add database credentials, connect, and go. Container cloud complications If you run Drupal on Pantheon, you may be familiar with (and likely benefit from) their container-based architecture. The efficiency and agility that containers provide are what allow Pantheon to offer development and test environments at scale. Containers also enable Pantheon to offer you highly available (distributed) and horizontally elastic applications by default. Although these features are a Drupal developer's dream, the underlying technology complicates things for data-driven content managers. When Pantheon updates servers, migrates endpoints, or does other maintenance work transparent to end-users, database connection details change, breaking Tableau's connection to the Drupal database. There are a few options for working around this problem, each with its drawbacks:
  • Send out updated credentials whenever they break: just instruct every Tableau user to e-mail you when the dashboard they built stops updating; you can find the new credentials and send them back. Rinse and repeat for every user with access and every site: welcome to your new full-time job.
  • Give content editors access to the Pantheon dashboard: train them to navigate to the specific environment you want them to connect to, suss out the MySQL details, and be sure not to hit that "delete live site" button you just gave them access to...
  • Use Pantheon's CLI to replicate the DB locally on a schedule: on the whole, not a bad option, but what happens when the DB server goes offline or your replication script starts failing? Didn't you go with Pantheon to get out of the infrastructure management and monitoring game in the first place?
Introducing the Pantheon Switchboard We, being a data-driven marketing organization who coincidentally has a large Tableau installation base, and one that happens to host many Drupal sites on Pantheon, know the struggle well. To that end, we've developed and open sourced the Pantheon Switchboard, a Docker image that mashes up the Pantheon command line interface and MySQL proxy, allowing Tableau users (both those connecting ad-hoc using the desktop client as well as those scheduling extracts with our cloud or on-premise servers) to reliably and seamlessly connect to MySQL databases hosted on Pantheon, despite those periodic database connection detail changes. The Switchboard's container approach attempts to strike the right balance between infrastructure requirements and the type of self-service simplicity that Tableau users expect. Complete details on installation and usage are available on the project's README. Deploying to Google Compute Engine For production use, we're enamored with the simplicity of deploying containers on GCE using their Container-Optimized VM images; feel free to use this as a recipe to get started: # switchboard-manifest.yml version: v1 kind: Pod spec: containers: - name: my-drupal-site-proxy image: tableaumkt/pantheon-mysql-proxy imagePullPolicy: Always ports: - name: mysql containerPort: 3306 hostPort: 11337 protocol: TCP env: - name: PROXY_DB_UN value: un_to_connect_to_drupal_proxy - name: PROXY_DB_PW value: pw_to_connect_to_proxy_here - name: PANTHEON_SITE value: my-drupal-site - name: PANTHEON_ENV value: test - name: PANTHEON_EMAIL value: - name: PANTHEON_PASS value: password_for_email_here - name: my-wp-site-proxy image: tableaumkt/pantheon-mysql-proxy imagePullPolicy: Always ports: - name: mysql containerPort: 3306 hostPort: 11338 protocol: TCP env: - name: PROXY_DB_UN value: un_to_connect_to_wp_proxy_here - name: PROXY_DB_PW value: pw_to_connect_to_proxy_here - name: PANTHEON_SITE value: my-wp-site - name: PANTHEON_ENV value: dev - name: PANTHEON_EMAIL value: - name: PANTHEON_PASS value: password_for_email_here # - Additional containers/proxies here. restartPolicy: Always dnsPolicy: Default Then spin up a VM in Google's Cloud with their CLI, using the above manifest as a template: gcloud compute instances create pantheon-switchboard-test \ --image container-vm \ --metadata-from-file google-container-manifest=switchboard-manifest.yml \ --zone us-central1-a \ --machine-type f1-micro After which you should:
  1. Provision a permanent IP and assign it to the VM (or use the VM's ephemeral IP for testing)
  2. Set up network rules to only allow connections from a specific range of IPs (like your corporate network or if you use Tableau Online, its IP), and to the ports you specified in your manifest, and optionally,
  3. Route a domain to the VM's IP.
Once wired up, you should be able to connect to your Pantheon databases using the PROXY_DB_UN, PROXY_DB_PW, and host port specified in your manifest, along with the IP (or domain) you configured in your Google Cloud console. Get Started
Categories: Drupal

Microserve: DrupalCamp Bristol 2015 Wrap-up

6 July 2015 - 9:40am

After nearly a year in the planning, Bristol's inaugural DrupalCamp has finally come and gone!

There have been murmors about a Bristol camp or event for a number of years and it's so rewarding to see the whole South West Drupal community coming together to make it a reality.

A few of my personal highlights were: Paul Johnson's Business day GOSH showcase; Matt Jukes recounting his numerous and often hilarious escapades trying to bring modern digital tools and techniques to ONS; and a very thought-provoking accessibility talk and demonstration by Léonie Watson.

There were also two very polished case studies to round-off the event, given by DrupalCamp Bristol committee chair Rick Donohoe and Ringo Moss.

We at Microserve have really relished the opportunity to help make DC Bristol a reality, and are very much looking forward to starting work on DrupalCamp Bristol 2016!

We will be following up with a detailed perspective on DrupalCamp Bristol from an organisers point of view, as well as a camp wash-up from the whole committee.

Images courtesy of DrupalCamp Bristol and Oliver Davies. DrupalCamp Bristol branding by Positive.

Mark Pavlitski
Categories: Drupal

SitePoint PHP Drupal: How to Build Multi-step Forms in Drupal 8

6 July 2015 - 9:00am

In this article, we are going to look at building a multistep form in Drupal 8. For brevity, the form will have only two steps in the shape of two completely separate forms. To persist values across these steps, we will use functionality provided by Drupal’s core for storing temporary and private data across multiple […]

Continue reading %How to Build Multi-step Forms in Drupal 8%

Categories: Drupal

Appnovation Technologies: Drupal North Regional Summit

6 July 2015 - 5:32am

Last weekend was the first annual Drupal North Summit held in Toronto, Ontario.

Categories: Drupal

Annertech: Your Connected Website

6 July 2015 - 5:07am
Your Connected Website

Modern websites talk. They talk through great content to the visitors who come to read them, but they also talk through APIs (Application Programming Interfaces) to other systems. Does yours? Should it? Could integrating your site with other systems bring you greater return on investment?

Categories: Drupal

LevelTen Interactive: How to display an RSS feed in a Drupal block

5 July 2015 - 10:00pm

If you have a standard RSS feed that you'd like to display in a block on your Drupal website, you've come to the right place. For this example, we will be using a sample feed at (excerpted here:). ... Read more

Categories: Drupal

KatteKrab: CCR at OSCON

4 July 2015 - 6:11pm
Sunday, July 5, 2015 - 11:11

I've given a "Constructive Conflict Resolution" talk twice now. First at DrupalCon Amsterdam, and again at DrupalCon Los Angeles. It's something I've been thinking about since joining the Drupal community working group a couple of years ago. I'm giving the talk again at OSCON in a couple of weeks. But this time, it will be different. Very different. Here's why.

After seeing tweets about Gina Likins keynote at ApacheCon earlier this year I reached out to her to ask if she'd be willing to collaborate with me about Conflict Resolution in open source, and ended up inviting her to co-present with me at OSCON. We've been working together over the past couple of weeks. It's been a joy, and a learning experience! I'm really excited about where the talk is heading now. If you're going to be at OSCON, please come along. If you're interested, please follow our tweets tagged #osconCCR.

Jen Krieger from interviewed Gina and I about our talk - here's the article: Teaching open source communities about conflict resolution

In the meantime, do you have stories of conflict in Open Source Communities to share?

  • How were they resolved?
  • Were they intractable?
  • Do the wounds still fester?
  • Was positive change an end result?
  • Do you have resources for dealing with conflict?

Tweet your thoughts to me @kattekrab

Categories: Drupal

Wuinfo: How we come with CYouTube Module

4 July 2015 - 5:07am

Recently, I was working with a team on the project for country music television (CMT) at Corus Entertainment. We need to synchronize videos from two different resources. One of them is Youtube. There are over 200 youtube channels on CMT. We need pull videos from all those channels regularly. By doing that, videos that published on Youtube will be available on CMT automatically. So, in-house editors do not need to spend time uploading the videos.

We store videos in file entities. Videos are from different sources. All imported videos act same across the site. Among the imported video, only their mime type is different if two videos are from the different source. Each imported video is a file entity on CMT. For the front end, we built views pages and blocks based on those video file entities.

We have some videos imported from another source: MPX thePlatform. We used "Media: thePlatform mpx" as main module to import and update those videos. To deal with customized video fields, we contributed a module "Media: thePlatform MPX entity fields sync" to work with the main module.

After we have done with MPX thePlatform videos, we have experience of handling videos import. How do we import YouTube videos now? We have over 200 channels on YouTube.

We gave up to make it work with Feeds module. At first, we planned to use feeds module. Since Google have just deprecated their YouTube API V2.0, Old RSS channels feed is no longer working. Thanks to the community, we found a module called feeds_youtube. The module's 7.x-3.x branch works with YouTube latest API V3.0. So, we have a feeds parser. We still need a feeds processor. Thanks to the community again, we found feeds_files module. We installed those modules and their dependent modules. We configure feeds module and spent couple days. It did work. At the end, we decide to build a lightweight custom module that can do everything from download YouTube JSON data to create local file entities. Each video imported from channels will have a uplink to an artist or a hosting show.

What do we want from the module? We want it to check multiple YouTube channels. If there is a new video uploaded in a channel, we create a associated file entity on CMT. In the created entity, we have some the metadata from YouTube saved to the entity fields. In that entity, we also save local metadata. Local metadata likes a show, artist information. We want the module to handle over 200 and maybe thousands of channels in the future. We want the module to handle the tasks gracefully and not burn out the system when importing thousands of videos. It sounds to be quite intimidating but not really.

We ended up building a module and contributed it to It is called Youtube Channel Videos Sync V3. Here is how we come up with the module.

First of all, we gathered a list of channels name. We also collected relevant local metadata like artist id or show id. Then, we send a request to YouTube and get a list of videos for each channel. Then, for each video, we create a system queue task with video's data and the local metadata. At last, we built queue processor and created the video file entity one by one. See the diagram below for the complete process.

A little more technical detail below:

How we get a list of YouTube channels name and the local metadata for the channels? In the module configuration page, we set the fields used to store the channel name. In CMT, we have the field in both show and artist nodes. The module went through the nodes and get an array of channel name and the node id with they content type. Array like this:

   'channel name' => array(
     'field_artist_referenced' => array('nid',...),

How to configure YouTube metadata fields into entity fields? On the module configuration page, we can set up mapping between the YouTube metadata field and local entity field.

In the imported videos, how to set the local artist and show information? The module has a hook where a custom module can implement to provide that information. Like the array above, "field_artist_referenced" is a field machine name of video entity. "array('nid')" is the value for that field. By doing that, the imported video has an entity reference pointing back to the artist or show node. One of the best ways to set up a relation is to have an entity reference in the video entity that point to the artist node or entity.

That is the overall process the module follow to import thousands of videos from YouTube.

Categories: Drupal

Ryan Szrama: Publishing Content on Relative Dates Using Rules in Drupal 7

3 July 2015 - 8:50pm

A friend of mine is a DUI lawyer who uses a Drupal site for content marketing and lead generation, managed by my friends at EverConvert. They quickly identified the weekend as the best time for the website to directly appeal to visitors who found the site after a Friday or Saturday night arrest. In addition to live chat, they decided to alter the site's appearance by publishing content only during these times that contains large, direct calls to action.

Fortunately, Drupal provides the tools to build this with nary a line of code.

Introducing the Rules Scheduler

The primary module you'll use to create something similar is Rules with its Rules Scheduler sub-module. Most purpose built content scheduling modules that I've seen allow you to set absolute dates for pieces of content to be published or unpublished. However, you wouldn't want to have to enter in every single weekend date to get that content published at the right times. Fortunately, Rules Scheduler allows you to schedule arbitrary actions using relative date strings (in addition to any other format supported by strtotime()).

Before we dive into the configuration I proposed to them, you should understand that the Rules module basically adds a GUI based scripting language to the back end of Drupal. In addition to configuring actions to be performed after certain events when a set of conditions are met, you can create Rules components that are essentially subroutines that can be directly invoked by Rules (or code) without being triggered by events.

To setup a Rules Scheduler based content publishing schedule, you have to create two Rules components: one will publish the piece of content and schedule it to be unpublished on a relative date (i.e. "next Monday"), while the other will unpublish the piece of content and schedule it to be published on a relative date (i.e. "next Friday"). Another Rule will need to react to content being created or updated to initiate the publishing schedule.

Using Fields to Avoid "Magic" Behavior

One of the keys to building a maintainable Drupal site (or module) is to ensure that every "automated" action is explicitly enabled. In the early days of Drupal Commerce development, I adopted an approach to some module behaviors where a feature just automatically worked if certain conditions were met (e.g. the representation of attribute fields on Add to Cart forms). "Neat!" I thought, until I realized that it was difficult to document and even more difficult to ensure users knew to look for said documentation. Much better to include explicit user interface components to enable functionality.

In the case of a scheduling system, you wouldn't want to build the site to just automatically enter every piece of content, or even every piece of content of a certain type, into the publishing pattern. Your client, a.k.a. the end user, really expects (and needs) to see an indicator on a form that submitting it will lead to a desired outcome.

For my friend's site, my recommendation was simply to add a Boolean field using a checkbox widget to the relevant content type reading, "Schedule this content to be published on Fridays and unpublished on Mondays." If the site required more publishing patterns than just the weekend pattern, I would've used a List (text) field with radio buttons or a select list identifying the different available publishing patterns.

Building the Scheduling System in Rules

Working with Rules is fairly simple if you can write out long hand what it is you're trying to accomplish. Considering all of our constraints here, we need a set of rules that accomplishes the following:

  1. When a call to action is created or saved with the scheduling checkbox checked, delete any scheduled tasks related to the content. (This is possible because Rules Scheduler lets you assign an identifier to scheduled rules, so identifying our scheduled tasks with the node ID will allow us to delete the tasks when needed in the future.)
  2. If the call to action that was just saved isn't published, schedule it to be published next Friday.
  3. If the call to action that was just saved is published, schedule it to be unpublished next Monday.
  4. When a call to action is automatically published on Friday, schedule it to be unpublished next Monday.
  5. When a call to action is automatically unpublished on Monday, schedule it to be published next Friday.

The first three items will be accomplished through a single rule reacting to two events, "After saving new content of type Call to action" and "After updating existing content of type Call to action." The rule will first delete any scheduled task for the piece of content and then it will invoke two rules components that will schedule the appropriate task based on whether or not the call to action was published.

The final two items will be accomplished through rules components that perform the necessary action and then schedule the appropriate task. As mentioned above, we'll use relative time strings ("next monday" and "next friday") and choose task identifiers that include the call to action node IDs ("unpublish-call-to-action-[node:nid]" and [publish-call-to-action-[node:nid]" respectively).

Give it a whirl!

It only took me about 10 minutes to create and test the rules based on the specification above, but if you aren't familiar with the Rules UI, it could take much longer. I believe Rules is worth learning (we built Drupal Commerce around it, after all), but there's something to be said for ready made examples.

I've attached to this post a Features export of the content type and related rules configurations for you to try on your own site. Give Scheduled Calls to Action a whirl and let me know how it works for you in the comments!

(Note: to see the rules configurations and scheduled tasks, enable the Rules UI, Views, and Views UI modules if they aren't already enabled on your site.)

Categories: Drupal

2bits: Presentation: Backdrop, and alernative Drupal fork

3 July 2015 - 8:25am
Last week, at the amazing Drupal North regional conference, I gave a talk on Backdrop: an alternative fork of Drupal. The slides from the talk are attached below, in PDF format.
Categories: Drupal

Chapter Three: Principles of Configuration Management - Part Three

3 July 2015 - 7:09am

This is the third in a series of posts about Drupal 8's configuration management system. The Configuration Management Initiative (CMI) was the first Drupal 8 initiative to be announced in 2011, and we've learned a lot during thousands of hours of work since then. These posts share what we've learned and provide background on the why and how. In case you missed them: here is part one and part two.

Categories: Drupal

Midwestern Mac, LLC: Major improvements to Drupal VM - PHP 7, MariaDB, Multi-OS

3 July 2015 - 6:17am

For the past couple years, I've been building Drupal VM to be an extremely-tunable, highly-performant, super-simple development environment. Since MidCamp earlier this year, the project has really taken off, with almost 200 stars on GitHub and a ton of great contributions and ideas for improvement (some implemented, others rejected).

Categories: Drupal

Drupal core announcements: Recording from July 3rd 2015 Drupal 8 critical issues discussion

3 July 2015 - 3:19am

This was our 6th critical issues discussion meeting to be publicly recorded in a row. (See all prior recordings). Here is the recording of the meeting video and chat from today in the hope that it helps more than just those who were on the meeting:

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 meeting log is as follows (all times are CEST real time at the meeting):

[11:06am] alexpott:
[11:06am] Druplicon: => [meta] Remove or document every SafeMarkup::set() call [#2280965] => 90 comments, 13 IRC mentions
[11:06am] alexpott:
[11:06am] Druplicon: => Remove SafeMarkup::set() from Renderer::doRender [#2506581] => 49 comments, 9 IRC mentions
[11:07am] alexpott:
[11:07am] Druplicon: => Remove SafeMarkup::set() from XSS::filter() [#2506195] => 40 comments, 3 IRC mentions
[11:09am] dawehner:
[11:09am] Druplicon: => Remove support for #ajax['url'] and $form_state->setCached() for GET requests [#2502785] => 51 comments, 18 IRC mentions
[11:09am] Druplicon: dawehner: 5 hours 36 sec ago tell dawehner you might already be following but I figure you would be in favor.
[11:10am] alexpott: GaborHojtsy: do you what the you link is for the live hangout?
[11:11am] GaborHojtsy: live hangout page:
[11:11am] GaborHojtsy: alexpott: ^^^
[11:11am] GaborHojtsy: to watch that is
[11:11am] alexpott: GaborHojtsy: thanks!
[11:12am] plach:
[11:12am] Druplicon: => Node revisions cannot be reverted per translation [#2453153] => 159 comments, 58 IRC mentions
[11:12am] plach:
[11:12am] Druplicon: => Remove EntityFormInterface::validate() and stop using button-level validation by default in entity forms [#2453175] => 79 comments, 9 IRC mentions
[11:14am] plach:
[11:14am] Druplicon: => FieldItemInterface methods are only invoked for SQL storage and are inconsistent with hooks [#2478459] => 112 comments, 29 IRC mentions
[11:14am] larowlan:
[11:14am] Druplicon: => Make block context faster by removing onBlock event and replace it with loading from a BlockContextManager [#2354889] => 100 comments, 19 IRC mentions
[11:15am] larowlan:
[11:16am] Druplicon: => SA-CORE-2014-002 forward port only checks internal cache [#2421503] => 46 comments, 11 IRC mentions
[11:16am] larowlan:
[11:16am] Druplicon: => "Translate user edited configuration" permission needs to be marked as restricted [#2512460] => 20 comments, 8 IRC mentions
[11:17am] WimLeers: catch: pfrenssen is likely gonna be working on the "numerous paramconverters" issue
[11:17am] WimLeers: the issue catch talked about:
[11:17am] Druplicon: => Numerous ParamConverters in core break the route / url cache context [#2512718] => 22 comments, 12 IRC mentions
[11:17am] catch: WimLeers: did you discuss last night's discussion with him already?
[11:18am] WimLeers:
[11:19am] WimLeers:
[11:19am] Druplicon: => Rendered Cache Metadata created during the main controller request gets lost [#2450993] => 132 comments, 27 IRC mentions
[11:20am] pfrenssen: catch: WimLeers: yes I'm working on that, for the moment just studying how it works
[11:20am] berdir: WimLeers: I think we can also demote it if all the other must issues are critical on their own
[11:20am] GaborHojtsy:
[11:20am] Druplicon: => "Translate user edited configuration" permission needs to be marked as restricted [#2512460] => 20 comments, 9 IRC mentions
[11:20am] catch: pfrenssen: cool. I'll be around most of today so just ping if you want to discuss.
[11:21am] GaborHojtsy:
[11:21am] Druplicon: => Config translation needs to be validated on input for XSS (like other t string input) [#2512466] => 34 comments, 3 IRC mentions
[11:21am] WimLeers: pfrenssen++
[11:21am] WimLeers: berdir: assuming you're talking about — then yes, that's exactly the plan :)
[11:21am] Druplicon: => [meta] Finalize the cache contexts API & DX/usage, enable a leap forward in performance [#2429287] => 112 comments, 10 IRC mentions
[11:21am] GaborHojtsy:
[11:21am] Druplicon: => Arbitrary code execution via 'trans' extension for dynamic twig templates (when debug output is on) [#2489024] => 43 comments, 12 IRC mentions
[11:22am] GaborHojtsy:
[11:22am] Druplicon: => Numerous ParamConverters in core break the route / url cache context [#2512718] => 22 comments, 13 IRC mentions
[11:22am] xjm: GaborHojtsy: I took care of updating the security polict with mlhess
[11:22am] xjm: GaborHojtsy: that's done
[11:23am] • xjm listening to the meeting but cannot join because of 10 person limit
[11:23am] GaborHojtsy: xjm: yay
[11:23am] GaborHojtsy: xjm++
[11:24am] WimLeers: Yes
[11:24am] WimLeers: I DO HAVE A MICROPHONE!!!
[11:24am] WimLeers: :P
[11:24am] xjm: GaborHojtsy: now restrict access is mentioned explicitly, so any perm that has it is covered
[11:24am] Druplicon: => Security advisories process and permissions policy => 0 comments, 1 IRC mention
[11:25am] larowlan:
[11:25am] Druplicon: => Additional uncaught exception thrown while handling exception after service changes [#2509898] => 22 comments, 5 IRC mentions
[11:25am] alexpott: WimLeers: a working microphone :)
[11:28am] WimLeers: alexpott: all of you guys are breaking up for me from time to time. It looks like it's something with Chrome/Hangouts :(
[11:28am] xjm: WimLeers: yeah I had to use FF
[11:28am] WimLeers: My mic *works* if I test it locally.
[11:28am] WimLeers: xjm: lol, the beautiful irony
[11:30am] WimLeers: berdir: alexpott: I checked and I agree with the change you guys just asked me feedback on:
[11:30am] Druplicon: => Condition plugins should provide cache contexts AND cacheability metadata needs to be exposed [#2375695] => 117 comments, 40 IRC mentions
[11:32am] alexpott:
[11:32am] Druplicon: => Rebuilding service container results in endless stampede [#2497243] => 97 comments, 22 IRC mentions
[11:33am] • larowlan using FF too, doesn't trust Google
[11:33am] alexpott: dawehner, catch: anyone got the nid of the chx container issue?
[11:33am] dawehner:
[11:33am] catch: alexpott:
[11:33am] Druplicon: => Performance: create a PHP storage backend directly backed by cache [#2513326] => 43 comments, 13 IRC mentions
[11:33am] Druplicon: => Performance: create a PHP storage backend directly backed by cache [#2513326] => 43 comments, 14 IRC mentions
[11:34am] catch: beat me.
[11:36am] larowlan: for the ctools issue I mentioned
[11:36am] Druplicon: => Create "context stack" service where available contexts can be registered [#2511568] => 0 comments, 3 IRC mentions
[11:41am] xjm: dropping off now to walk to the venue
[11:41am] alexpott: pfrenssen++
[11:50am] GaborHojtsy: for browser we are working on
[11:50am] Druplicon: => Browser language detection is not cache aware [#2430335] => 47 comments, 21 IRC mentions
[11:50am] GaborHojtsy: Fabianx-screen: see above
[11:51am] berdir: and it's not a blocker
[11:51am] berdir: because right now it just kills page/smart cache
[11:51am] berdir: so if you use that, you are not seeing a cached page anyway
[11:51am] berdir: Fabianx-screen: we have a cache context for the content language
[11:52am] xjm: the youtube video has like a 20 second delay
[11:53am] GaborHojtsy: xjm: we get what we pay for :D
[11:54am] xjm: now I am talking
[11:55am] plach:
[11:55am] Druplicon: => Remove EntityFormInterface::validate() and stop using button-level validation by default in entity forms [#2453175] => 79 comments, 10 IRC mentions
[11:55am] xjm: more like 60s
[11:55am] GaborHojtsy: xjm: well, you’ll be in the recording forver now :D
[11:55am] xjm: :P
[11:56am] xjm: GaborHojtsy: is there any way to increase the number of participants or to include the chat sidebar in the video?
[11:56am] WimLeers1: catch: Can you leave a comment on with your POV/conclusion — sounds like you have the clearest grasp on this/completest view on the likely solution.
[11:56am] Druplicon: => Numerous ParamConverters in core break the route / url cache context [#2512718] => 23 comments, 14 IRC mentions
[11:56am] WimLeers1: xjm: chat is here, we don't use Google Hangout's chat sidebar
[11:56am] GaborHojtsy: xjm: the chat window is THIS ONE
[11:57am] larowlan: xjm: the chat one is lost soon as the call ends
[11:57am] xjm: WimLeers: GaborHojtsy: so the thing is that listening to the video it's very hard to figure out which issues people are discussing, even with Gábor's notes
[11:57am] larowlan: xjm: you can get more than 10 in the call if you have a corporate account I think
[11:57am] WimLeers: larowlan: Gábor copy/pastes this chat to the g.d.o post with the link of the recording
[11:57am] • larowlan nods
[11:57am] WimLeers: that was meant for xjm, oops
[11:58am] GaborHojtsy: xjm: the trick is if we would start on time, then my chat log shows timestamps which are sync with the video
[11:58am] GaborHojtsy: xjm: we have a few minute delay between the video start and the top of the hour
[11:58am] catch: WimLeers: yep will do.
[11:59am] GaborHojtsy: xjm: because people arrive later basically :)
[11:59am] WimLeers: catch++
[12:01pm] GaborHojtsy: xjm: its also hard to get Druplicon in google hangouts — as in impossible ÉD
[12:01pm] GaborHojtsy: xjm: and there was some interest for people watching to be able to follow links WHILE the meeting was on
[12:02pm] xjm: GaborHojtsy: but it doesn't work -- I'm trying that right now -- the delay is too big
[12:02pm] WimLeers: alexpott: regarding in title:
[12:03pm] GaborHojtsy: xjm: well, then at least the Druplicon advantage is there :)
[12:03pm] GaborHojtsy: xjm: I am happy to use some way to get the comments in if there is one
[12:04pm] GaborHojtsy: xjm: I am not sure it helps if eg. someone shares their screen with an IRC client throughout the video
[12:04pm] GaborHojtsy: xjm: the links are not clickable either
[12:04pm] xjm: GaborHojtsy: shannon did that for the meeting we had 2y ago -- though the same problem with links not being clickable
[12:04pm] GaborHojtsy: xjm: but that may be a workaround

Categories: Drupal

DrupalCon News: We're making it easy to give back. Add a membership to your cart.

3 July 2015 - 2:00am

If you have been to a DrupalCon before, you will notice something new in the registration process. We've made it really easy for you to sign up for Drupal Association membership and bundle it into your overall DrupalCon purchase.

Categories: Drupal

InternetDevels: Drupal 7 application with PhoneGap: full tutorial

3 July 2015 - 12:06am

Mobile application development is a relatively new area of Drupal development services, but it is advancing rapidly, because mobile devices are used increasingly.

In terms of adapting websites for mobile platforms, PhoneGap and technologies built on it remain very popular. So let’s see what it is and how it works.

Read more
Categories: Drupal

2bits: Backdrop: an alternative Drupal fork

2 July 2015 - 8:16pm
Last week, at the amazing Drupal North regional conference, I gave a talk on Backdrop: an alternative fork of Drupal. The slides from the talk are attached below, in PDF format.
Categories: Drupal

Drupal core announcements: Portsmouth NH theme system critical sprint recap

2 July 2015 - 8:16pm

In early June a Drupal 8 theme system critical issues sprint was held in Portsmouth, New Hampshire as part of the D8 Accelerate program.

The sprint started the afternoon of June 5 and continued until midday June 7.

Sprint goals

We set out to move forward the two (at the time) theme system criticals, #2273925: Ensure #markup is XSS escaped in Renderer::doRender (created May 24, 2014) and #2280965: [meta] Remove or document every SafeMarkup::set() call (created June 6, 2014).


The Drupal Association provided the D8 Accelerate grant which covered travel costs for joelpittet and Cottser.

Bowst provided the sprint space.

As part of its NHDevDays series of contribution sprints, the New Hampshire Drupal Group provided snacks and refreshments during the sprint, lunch and even dinner on Saturday.

Digital Echidna provided time off for Cottser.


xjm committed #2273925: Ensure #markup is XSS escaped in Renderer::doRender Sunday afternoon! xjm’s tweet sums things up nicely.

As for the meta (which is comprised of about 50 sub-issues), by the end of the sprint we had patches on over 30 of them, 3 had been committed, and 7 were in the RTBC queue.

Thanks to the continued momentum provided by the New Jersey sprint, as of this writing approximately 20 issues from the meta issue have been resolved.

Friday afternoon

peezy kicked things off with a brief welcome and acknowledgements. joelpittet and Cottser gave an informal introduction to the concepts and tasks at hand for the sprinters attending.

After that, leslieg on-boarded our Friday sprinters (mostly new contributors), getting them set up with Drupal 8, IRC, Dreditor, and so on. leslieg and a few others then went to work reviewing documentation around #2494297: [no patch] Consolidate change records relating to safe markup and filtering/escaping to ensure cross references exist.

Meanwhile in "critical central" (what we called the meeting room where the work on the critical issues was happening)…

lokapujya and joelpittet got to work on the remaining tasks of #2273925: Ensure #markup is XSS escaped in Renderer::doRender.

cwells and Cottser started the work on removing calls to SafeMarkup::set() by working on #2501319: Remove SafeMarkup::set in _drupal_log_error, DefaultExceptionSubscriber::onHtml, Error::renderExceptionSafe.

Thai food was ordered in, and many of us continued working on issues late into the evening.


joelpittet and Cottser gave another brief introduction to keep new arrivals on the same page and reassert concepts from the day before.

leslieg did some more great on-boarding Saturday and worked with a handful of new contributors on implementing #2494297: [no patch] Consolidate change records relating to safe markup and filtering/escaping to ensure cross references exist. The idea was that by reviewing and working on this documentation the contributors would be better equipped to work directly on the issues in the SafeMarkup::set() meta.

Mid-morning Cottser led a participatory demo with the whole group of a dozen or so sprinters, going through one of the child issues of the meta and ending up with a patch. This allowed us to walk through the whole process and think out loud the whole time.

The Benjamin Melançon XSS attack in action. Having some fun while working on our demo issue.

By this time we had identified some common patterns after working on enough of these issues.

By the end of Saturday all of the sprinters including brand new contributors were collaborating on issues from the critical meta and the issue stickies were flying around the room with fervor (a photo of said issue stickies is below).

Then we had dinner :)

Sunday morning was down for a while.

We largely picked up where we left off Saturday, cranked out more patches, and joelpittet and Cottser started to review the work that had been done the day before that was in the “Needs Human” column.

Our sprint board looked something like this on the last day of the sprint.

Thank you

Thanks to the organizing committee (peezy, leslieg, cwells, and kbaringer), xjm, effulgentsia, New Hampshire DUG, Seacoast DUG, Bowst, Drupal Association, Digital Echidna, and all of our sprinters: cdulude, Cottser, cwells, Daniel_Rose, dtraft, jbradley428, joelpittet, kay_v, kbaringer, kfriend, leslieg, lokapujya, mlncn, peezy, sclapp, tetranz.

AttachmentSize 20150606_114556.jpg453.91 KB 20150606_184029.jpg549.46 KB 20150607_130317.jpg353.87 KB IMG_8589.JPG781.47 KB
Categories: Drupal

Acquia: Front End Performance Strategy: Styles

2 July 2015 - 11:38am

The quest for improved page-load speed and website performance is constant. And it should be. The speed and responsiveness of a website have a significant impact on conversion, search engine optimization, and the digital experience in general.

In part one of this series, we established the importance of front-end optimization on performance, and discussed how properly-handled images can provide a significant boost toward that goal. In this second installment, we’ll continue our enhancements, this time by tackling CSS optimization.

We’ll consider general best practices from both a front-end developer’s and a themer’s point of view. Remember, as architects and developers, it’s up to us to inform stakeholders of the impacts of their choices, offer compromises where we can, and implement in smart and responsible ways.


Before we dive into optimizing our CSS, we need to understand how Drupal’s performance settings for aggregation work. We see developers treating this feature like a black box, turning it on without fully grokking its voodoo. Doing so misses two important strategic opportunities: 1. Controlling where styles are added in the head of our document, and 2. Regulating how many different aggregates are created.

Styles can belong to one of three groups:

  • System - Drupal core
  • Default - Styles added by modules
  • Theme - Styles added in your theme

Drupal aggregates styles from each group into a single sheet for that group, meaning you’ll see at minimum three CSS files being used for your page. Style sheets added by inclusion in a theme’s ‘.info’ file or a module’s ‘.info’ file automatically receive a ‘true’ value for the every_page flag in the options array, which wraps them into our big three aggregates.

Styles added using drupal_add_css automatically have the every_page flag set to ‘false.’ These style sheets are then combined separately, by group, forming special one-off aggregate style sheets for each page.

When using drupal_add_css, you can use the optional ‘options’ array to explicitly set the every_page flag to ‘true.’ You can also set the group it belongs to and give it a weight to move it up or down within a group.

drupal_add_css(drupal_get_path('module', 'custom-module') . '/css/custom-module.css', array('group' => CSS_DEFAULT, 'every_page' => TRUE));

Style sheets added using Drupal’s attached property aren’t aggregated unless they have the every_page flag set to ‘true.’

Favoring every_page: true

Styles added with the every_page flag set to ‘false’ (CSS added via drupal_add_css without the true option, or without the option set at all, or added using the attached property) will only load on the pages that use the function that attaches, or adds, that style sheet to the page, so you have a smaller payload to build the page. However, on pages that do use the function that adds or attaches the style sheet with every_page: ‘false’, an additional HTTP request is required to build that page. The additional requests are for the one-off aggregates per group, per page.

In more cases than not, I prefer loading an additional 3kb of styling in my main aggregates that will be downloaded once and then cached locally, rather than create a new aggregate that triggers a separate HTTP request to make up for what’s not in the main aggregates.

Additionally, turning on aggregation causes Drupal to compress our style sheets, serving them Gzipped to the browser. Gzipped assets are 70%–90% smaller than their uncompressed counterparts. That’s a 500kb CSS file being transferred in a 100kb package to the browser.

Preprocessing isn’t a license for inefficiency

I love preprocessing my CSS. I use SASS, written in SCSS syntax, and often utilize Compass for its set of mixins and for compiling. But widespread adoption of preprocessing has led to compiled CSS files that tip the 1Mb limit (which is way over the average), or break the IE selector limit of 4095. Some of this can be attributed to Drupal’s notorious nesting of divs (ugly mark-up often leads to ugly CSS), but a lot of it is just really poor coding habits.

The number one culprit I’ve come across is over nesting of selectors in SASS files. People traverse the over nested DOM created by Drupal with SASS and spit out compiled CSS rules using descendant selectors that go five (sometimes even more) levels deep.

I took the above example from the SASS inception page, linked above, and cleaned it up to what it should probably be:

The result? It went from 755 bytes to 297 bytes, a 60% reduction in size. That came from just getting rid of the extra characters added by the excess selectors. Multiply the savings by the 30 partials or so, and it’s a pretty substantial savings in compiled CSS size.

Besides the size savings, the number and type of selectors directly impact the amount of time a browser takes to process your style rules. Browsers read styles from right to left, matching the rightmost “key” selector first, then working left, disqualifying items as it goes. Mozilla wrote a great efficient CSS reference years ago that is still relevant.


Once again we’ve demonstrated how sloppy front-end implementations can seriously hamper Drupal’s back-end magic. By favoring style sheet aggregation and reining in exuberant preprocessing, we can save the browser a lot of work.

In our next, and final, installment in this series, we’ll expand our front-end optimization strategies even further, to include scripts.

Tags:  acquia drupal planet
Categories: Drupal

Drupal Watchdog: Build it with Backdrop

2 July 2015 - 8:29am

Backdrop CMS is a fork of the Drupal project. Although Backdrop has different name, the 1.0 version is very similar to Drupal 7. Backdrop 1.0 provides an upgrade path from Drupal 7, and most modules or themes can be quickly ported to work on Backdrop.

Backdrop is focused on the needs of the small- to medium-sized businesses, non-profits, and those who may not be able to afford the jump from Drupal 7 to Drupal 8. Backdrop values backwards compatibility, and recognizes that the easier it is for developers to get things working, the less it will cost to build, maintain, and update comprehensive websites and web applications. By iterating code in incremental steps, innovation can happen more quickly in the areas that are most important.

The initial version of Backdrop provides major improvements over Drupal 7, including configuration management, a powerful new Layout system, and Views built-in.

What's Different From Drupal 7?

Backdrop CMS is, simply put: Drupal 7 plus built-in Configuration Management, Panels, and Views.

Solving the Deployment Dilemma

Database-driven systems have long suffered from the deployment dilemma: Once a site is live, how do you develop and deploy a new feature?

Sometimes there is only one copy of a site – the live site – and all development must be done on this live environment. But any mistakes made during the development of the new feature will be immediately experienced by visitors to the site.

It’s wiser to also have a separate development environment, which allows for creation of the new feature without putting the live site at risk. But what happens when that new feature has been completed, and needs to be deployed?

We already have a few great tools for solving this problem. When it comes to the code needed for the new feature we have great version control systems like Git. Commit all your work, merge if necessary, push when you’re happy, and then just pull from the live environment (and maybe clear some caches).

Categories: Drupal

about seo