Planet Drupal

Subscribe to Planet Drupal feed
Drupal.org - aggregated feeds in category Planet Drupal
Updated: 25 min 12 sec ago

Drupal governance announcements: Evolving and documenting Drupal core's structure, responsibilities, and decision-making

Mon, 23/03/2015 - 17:41

The Drupal project just turned 14 years old. There are now over 1 million known installations of Drupal, and Drupal.org has over 1 million users. Drupal 8 has over 2,700 contributors (almost three times that of Drupal 7) and over 13,000 commits so far (50% more commits per day on average than Drupal 7). I wanted to take an opportunity to reflect on our current governance structure and try to evolve the Drupal leadership team and decision-making, enable better scaling, and document both the formal and informal processes we have currently in place.

Over in the Drupal core issue queue, I've proposed an evolution to Drupal core's structure and decision-making process which documents how things are currently done, and also proposes some incremental improvements:

  1. Defines roles and responsibilities that are currently carried out by individuals within the core committer team: product managers, framework managers, and release managers. This is done to provide transparency, to help expedite decision-making, and to ensure that these roles are easier to fill in the future, as we can eliminate the requirement for core committers to be “superhuman” contributors capable of doing anything and everything, at all times.
    • This document also adds the concept of “provisional” product, framework, and release managers, without actual commit access, who work alongside the core committers until they gain the necessary experience to play a full committer role.
    • In so doing, the document also appoints two additional core committers—Alex Bronstein (effulgentsia) and Jess (xjm)—who have been playing this "provisional" role for some time now, informally.
  2. Lays out an explicit decision-making framework to make it clear who needs to be involved in what types of changes, and to what degree. This documents the process we already use, but also introduces some changes. The added transparency should make it easier for contributors who are proposing changes to direct their questions to the right people.
  3. Clearly outlines the role of subsystem maintainer (formerly component maintainer) as an active “maintenance” role: performing or organizing regular maintenance tasks: triaging the subsystem's queue(s), reviewing patches in need of review, etc. These responsibilities also come with a more formal opportunity to sign off on proposed changes that significantly affect the subsystem. The advantages to this are additional transparency, delegating and scaling responsibilities, and reducing the workload that currently falls to core committers. Going forward, subsystem maintainers who are not currently active will no longer be listed in MAINTAINERS.txt.

This document builds on ideas that have been blogged about or presented at Drupal events by many people, including Randy Fay (rfay), Larry Garfield (Crell), Cathy Theys (YesCT), Gábor Hojsty, Greg Dunlap (heyrocker), Jess (xjm), Alex Pott (alexpott), Nat Catchpole (catch), Jennifer Hodgdon (jhodgdon) and others. It has been reviewed by numerous people, including the existing core committer team. Special thanks to Angie Byron who has spent weeks helping me co-author this proposal.

Categories: Elsewhere

Drupalpress, Drupal in the Health Sciences Library at UVA: equipment booking system — content types

Mon, 23/03/2015 - 16:16

For our equipment booking system we needed two kinds of content types: reservation and equipment. Patrons would create nodes of the reservation content type. Staff would create nodes of the equipment content type(s). Because our library circulates a lot of different equipment we need a bunch of content types — one for each: Apple TV, Laptop, iPad Air, Digital Video Camera, Projector, etc. The equiment content types all need the same field structure — title, description, image, accessories and equipment category. It’s tedious creating these individually, but once you get one fully fleshed out (and the skeletons of the rest in place) then the Field Sync module will finish the job with the push of a button.

The reservation content type would be canonical for each kind of equipment. In other words, we don’t have to create a Reservation_iPad and a Reservation_Laptop and a Reservation_Projector, etc. There’s just one: Reservation. The way we accomplish this is by using an entity reference field that looks for any nodes of equipment content types.

When a patron creates a node of the reservation content type, he/she will select the equipment to be reserved in the entity reference field. This entity reference structure allows us to offer a pretty helpful feature for patrons navigating from a specific equipment page to the reservation form. An Entity Reference Prepopulate and Display Suite combination gives us a “Reserve This Item” link on equipment pages (say Apple TV – Copy 1) that sends the patron to a node/add reservation page that has that piece of equipment (in this case Apple TV – Copy 1) selected in the equipment field.

There’s good documentation out there for Entity Reference Prepopulate — check out this video. But it might be worth explaining how we built the URL that prepoluates the entity reference field. With Display Suite you can create a custom code field — we hardcode a URL to the node/add reservation form, with a token for the id of the currently viewed entity appended onto it. When the user clicks the link, the Entity Reference Prepopulate module kicks off, sees the id and builds the form with that entity referenced.

Categories: Elsewhere

Chromatic: Through the Looking-Glass: MidCamp 2015

Mon, 23/03/2015 - 14:56


photograph taken for Aaron Winborn (aaron), a long-time member of the Drupal community.

This last weekend I was fortunate to attend and speak at the second MidCamp in Chicago. It was hosted within the University of Illinois at Chicago campus and was a very well organized Drupal Camp. MidCamp drew a very diverse crowd (around 350 attendees, I believe) and had a schedule packed with solid sessions.

MidCamp becomes MADCamp

Prior to the event, plenty of Alice in Wonderland references were thrown around and there was even a “MADCamp” track, but it wasn’t entirely clear why. It was then revealed that MidCamp – tired of being the middle child – was rebranding itself as MADCamp (Midwest Area Drupal Camp). This was a creative move that added an entertaining twist to the atmosphere.

Keynotes

The keynote speakers were Tiffany Farriss, the CEO of Palantir.net and Drupal Association Treasurer, and Jen Lampton, a Founding Forker of Backdrop CMS and a notable member of the Drupal community.

Tiffany’s keynote, The Economics of Drupal Contribution, discussed the changes needed to make core contribution more attractive for organizations and individuals. Depending heavily on a small number individuals and their spare time leads to burnout and is not a sustainable model, she says. She also referenced a number of moves made by the Linux Foundation as ideas for helping solve those problems; including significantly shorter release cycles and a higher percentage of development being funded. Drupal 8 Accelerate is an example of an existing attempt to rethink the economics of core contribution.

Jen Lampton (photo by Marty Vernon)

Jen’s keynote was titled PHP for Everyone and gave a great overview of what PHP is and why it doesn’t deserve the bad rap it’s been given in the past. She outlined the arguments against it and rebutted them with its strengths. As she pointed out, PHP is currently involved with 80% of the web and is used by a number of large organizations like Facebook. These organizations are working hard to improve the language and each version sees significant improvements, continuing to modernize an otherwise older language.

I also enjoyed having a discussion with Jen about their experiences with Backdrop CMS thus far. After receiving some initial friction, it seems that the Drupal community has accepted and is embracing Backdrop. It will be very interesting to see the role that Backdrop plays and the audience it attracts as Drupal 8 is released and adopted.

Sessions

As mentioned, the schedule was packed with great sessions. I’m thankful to have had the opportunity to present a session about organizing Features. As for those I attended, there were two themes that stuck out to me the most: automation tools and headless Drupal.

Automation Tools

Fredric Mitchell, VP of Engineering at Better Weekdays, presented on using Grunt with Drupal. Among the Drupal tasks that can be automated with Grunt, using it with Drush Make provides a very interesting build workflow. Phase2, Fredric’s previous employer, has shared their grunt-drupal-tasks tools, along with a blog post about using them.

Allan Chappell of Promet Source presented another interesting Drupal 7 build workflow using Composer, the dependency manager of choice in the PHP community. He also pointed to a number of related tools Promet has shared, such as Drupal Tangler, and demoed how Composer can be used to manage Drupal 7 core, contributed modules, their dependencies, libraries, and patches.

Jeff Geerling, a Technical Architect of Acquia, introduced everyone to Ansible, a tool we began using recently at CHROMATIC. He demonstrated Ansible using Dramble, his cluster of 6 Raspberry Pi 2 computers; a combination of web servers, a load balancer, a Redis cache server, and a MySQL server. He installed Drupal 8 on the web servers and used LEDs to help demonstrate just how easy it is to manage servers with Ansible. Impressive!

Headless Drupal Steve Persch (photo by Marty Vernon)

Off with Drupal’s Head was a panel discussion led by Steve Persch, a senior engineer at Palantir.net. The consensus of the panel was… well… that there is no consensus. While there is plenty of talk about Headless Drupal, many things remain unclear. Where to cut off the head (what Drupal should and shouldn’t be responsible for) and when to use the headless approach is still up for debate and the right answer may depend on the project. Some consider it only useful for web applications while others recommend it only when fighting Drupal to build beautiful pages or forms isn’t worth the trouble. Regardless, a key takeaway was that a headless project is no less work. While it does avoid wrestling with the Drupal theme system, introducing a JavaScript framework is no simple task.

Steve also later presented Rendering HTML with Drupal: Past, Present and Future. He anticipates that many Drupal 7 projects will undergo redesigns without a corresponding Drupal upgrade, two tasks that often currently happen at the same time. Headless Drupal makes that easier and he sees clear decoupling as the future of rendering HTML with Drupal. He doesn’t, however, anticipate that a particular JavaScript MVC framework will be permanently paired with Drupal because front-end technologies are currently evolving at a much faster rate than back-end technologies and Drupal’s release cycle.

Wrapping Up

After Steve’s session I headed to Saturday night’s social event at the Moxee Restaurant and Brewery. The night was filled with great company, food, drinks, and entertaining bouts of table shuffleboard. Getting away from our code and bright screens never fails to bring the community closer together.

MidCamp/MADCamp was another excellent opportunity to meet and catch up with the myriad of personalities and companies that comprise the Drupal community. It was also a humbling reminder of how fast things move and how much more there is to learn. I recommend attending camps to anyone that has the opportunity. Being smaller than DrupalCon (North America, at least) allows them to become a more personal experience. That being said, I hope to see everyone again at DrupalCon Los Angeles in May!

Categories: Elsewhere

undpaul: A book about Configuration Management in Drupal 8

Mon, 23/03/2015 - 13:54

In December 2013, Packt Publishing asked us to write a book about the upcoming Drupal 8. They had seen the Drupal Association survey that showed the new feature Configuration Management was the most popular topic they wanted to learn about in Drupal 8. Since we are long-time evangelists of tracking configuration changes in code, we were excited about having the opportunity to write this book, which is expected to be published in March 2015 (like this week!). It's even more exciting because Packt actually donates a portion of sales of Drupal-related books to the Drupal Association. For this to work, you need to order or pre-order directly at Packt.

Since we did so much testing with and writing about Drupal 8, we also wanted to build something with it. So we built a microsite for the book and we were surprised about how smooth this worked. It took 9 hours on a Sunday to find an appropriate HTML template, install and configure Drupal and make it look the way it does now. After the book is published, the site will get some more functionality so we can publish questions and answers as well as errata. Since it will be quite a while until Drupal 8 is actually released, we are expecting there will be a few changes and some of our code might become outdated.

You can read a sample chapter in an article on Packt's website.

What will be in the book?

Chapter 1, Understanding Configuration Management, will give you a quick overview of Configuration Management. You will learn what types of configuration exist, why managing configuration is a good idea, and how to get started with it. It will provide a look at the several ways in which configuration was managed in Drupal 7 and then show how Drupal 8 approaches the problem.

Chapter 2, Configuration Management for Administrators, provides an introduction on how to use Configuration Management for users who are not developers, but administrators of a Drupal website who want to make use of the advantages of this new feature. We will show you how to use the Configuration Management interface and how to create a copy of your website, and you will learn how to move a configuration made on one site to another site.

Chapter 3, Drupal 8's Take on Configuration Management, will show you the inner workings of the Configuration Management system in Drupal 8. You will learn about config and schema files, and read about the difference between simple configuration and configuration entities.

Chapter 4, Configuration Management API, will teach you how to get your hands dirty and learn about the Configuration Management API of Drupal 8. Here, you will dive into the Simple Configuration API and learn how configuration can be overridden. Later, you will take a closer look at how to create custom configuration entity types, and we'll also teach you about the configuration's context system.

Chapter 5, The Anatomy of Schema Files, covers schema files and explains how Drupal uses them for Configuration Management. You will learn about the structure of schema files used by Drupal and write your own schema for custom configuration.

Chapter 6, Adding Configuration Management to Your Module, will teach you how to access configuration objects and how schema files are structured in the previous chapters. (You will surely want to know how to get all this fancy stuff into your shiny new module for Drupal 8). You will learn how to include the default configuration in custom modules, how to define and use your own configuration, and how to create configuration forms.

Chapter 7, Upgrading Your Drupal 7 Variables to Drupal 8 Configuration, will show you ways to convert your Drupal 7 variables into Drupal 8 Configuration objects and how to provide an upgrade path in your modules.

Chapter 8, Managing Configuration for Multilingual Websites, allows you to build comprehensive multilingual websites in which you can display a site's content in different languages and translate the user interface. While many features were built into Drupal's core in previous versions, building multilingual sites remained a very painful task. In this chapter, we will take a look at how Drupal 7 deals with different languages on a site and how Drupal 8 is trying to fix weaknesses from previous versions.

Chapter 9, Useful Tools and Getting Help, provides a list of links and tools provided by the Drupal community; these will be useful if you reach a point where you need help when dealing with Configuration Management.

Like what you see?

Go pre-order the book directly on Packt's website, or follow us on Twitter.

drupal planet english

Categories: Elsewhere

Iztok Smolic: Fastest way to build a landing page on your Drupal site

Mon, 23/03/2015 - 13:53

Landing pages are a must-have for any web business. Every marketer will tell you that pointing ads to a home page is a waste of money. Actually, any campaign should have a dedicated landing page to maximise the the conversion. Here is the problem: setting-up landing pages in Drupal is not easy. Modules like Panels and Display Suite sure […]

The post Fastest way to build a landing page on your Drupal site appeared first on Iztok.

Categories: Elsewhere

Web Omelette: Custom access control for Drupal 7 entities

Mon, 23/03/2015 - 09:05

Have you ever used hook_node_access() to control access to various node operations on your site? Have you found this hook unbelievably awesome? Thought to yourself, boy, I'm unstoppable now? Well, I sure did.

The problem is that Drupal 7 entities do not start and end with nodes and you may want to control access to other entities in the same way. However, there is no hook_taxonomy_term_access() or hook_fieldable_panels_pane_access() that you can use to apply this tactic. So what can you do in these cases?

The first thing is to understand that each entity implementation is different. Some have a centralised access callback for all the operations while others simply define permissions or access callbacks to be used directly inside the hook_menu() definition. And I'm sure there are also other ways of handling this but these I think are the most common.

In this article we are going to look at two entity examples: taxonomy terms (from core) and fieldable panels panes (from contrib). We will trace the access pipeline from request to response and see what we can do to intervene in this process and add our own logic. So let's begin.

Taxonomy terms

The first entity type we are going to look at is the regular taxonomy term introduced by core. It's actually pretty easy to understand how this entity type is built and what we can do in order to hook into the access pipeline.

If we take a look at taxonomy_menu(), we can quickly figure out which paths it creates to add and edit terms and what access callback and arguments are defined:

Adding terms to a vocabulary

$items['admin/structure/taxonomy/%taxonomy_vocabulary_machine_name/add'] = array( 'title' => 'Add term', 'page callback' => 'drupal_get_form', 'page arguments' => array('taxonomy_form_term', array(), 3), 'access arguments' => array('administer taxonomy'), 'type' => MENU_LOCAL_ACTION, 'file' => 'taxonomy.admin.inc', );

Editing a particular term

$items['taxonomy/term/%taxonomy_term/edit'] = array( 'title' => 'Edit', 'page callback' => 'drupal_get_form', // Pass a NULL argument to ensure that additional path components are not // passed to taxonomy_form_term() as the vocabulary machine name argument. 'page arguments' => array('taxonomy_form_term', 2, NULL), 'access callback' => 'taxonomy_term_edit_access', 'access arguments' => array(2), 'type' => MENU_LOCAL_TASK, 'weight' => 10, 'file' => 'taxonomy.admin.inc', );

By nature, viewing taxonomy term pages has to do with node access since they show a list of nodes so we will skip this aspect here and stick with just the add/edit operations.

So let's change the access callbacks and potential passed arguments inside a hook_menu_alter() implementation.

/** * Implements hook_menu_alter(). */ function demo_menu_alter(&$items) { $items['admin/structure/taxonomy/%taxonomy_vocabulary_machine_name/add']['access callback'] = 'demo_taxonomy_term_access'; $items['admin/structure/taxonomy/%taxonomy_vocabulary_machine_name/add']['access arguments'] = array(3, 'add'); $items['taxonomy/term/%taxonomy_term/edit']['access callback'] = 'demo_taxonomy_term_access'; $items['taxonomy/term/%taxonomy_term/edit']['access arguments'][] = 'edit'; }

So what happens here? We are simply replacing the access callback definition for these two menu items with our own custom function demo_taxonomy_term_access(). Additionally, we standardise a bit the arguments this function gets: $entity (either term or vocabulary object) and $op (add or edit). This covers both cases.

Now let's write our callback function:

/** * Access callback for taxonomy term add/edit operations * * @param null $entity * @param null $op * @return bool */ function demo_taxonomy_term_access($entity = null, $op = null) { if ($op === 'add') { return user_access('administer taxonomy'); } if ($op === 'edit') { return taxonomy_term_edit_access($entity); } }

Inside the function we run a check on $op and perform the access logic we want. In doing so, we make use of the $entity object that can be either the term being edited or the vocabulary to which a new term is added. In this example we are replicating exactly the intended access checks of the Taxonomy module. To add a term, a user needs to have the administer taxonomy permission while to edit one it needs either the same permission or a vocabulary specific permission (as seen inside taxonomy_term_edit_access()). Now it's up to you to include inside this logic whatever else you need. And you end up with something not so dissimilar to hook_node_access() but for taxonomy terms.

Fieldable Panels Panes (FPP)

FPP is a contributed module that creates an entity type that is primarily used inside a Panels context. Regardless of any of this though, it too exposes CRUD operations on the entities of this type. And consequently, there are access implications. So let's see how we can hook into this pipeline by starting where we did with the Taxonomy module: at fieldable_panels_panes_menu().

By looking inside this hook implementation we can find many defined paths which relate to these CRUD operations. And we also see that many of them have fieldable_panels_panes_access() as the access callback with some specific arguments passed to it.

But what does this function actually do? Nothing but taking the parameters and deferring to the controller class responsible for this entity type and its access() method. And by checking fieldable_panels_panes_entity_info(), the principle function responsible for defining the entity type, we find that this is the PanelsPaneController class. In there, we find all the logic for determining access rights for various operations.

Now that we know all this, what can we do to hook into this pipeline? We could do like before and override the hook_menu() implementation. But since there are so many menu items and the FPP class controller is already doing such a nice job, that may be counter productive. So let's instead override the entity definition and replace the class controller with one of ours that extends PanelsPaneController. In there, we then do what we want.

First, we implement hook_entity_info_alter():

/** * Implements hook_entity_info_alter(). */ function demo_entity_info_alter(&$entity_info) { $entity_info['fieldable_panels_pane']['controller class'] = 'DemoPanelsPaneController'; }

Right after this, we create a file inside our module called DemoPanelsPaneController.inc which contains the following to start with:

<?php /** * Overrides fieldable panels panes controller functionality */ class DemoPanelsPaneController extends PanelsPaneController { }

Finally, we edit the module's .info file and make sure it loads this file:

files[] = DemoPanelsPaneController.inc

Then we clear the cache. If all went well, nothing really has changed on the site in terms of functionality. However, the DemoPanelsPaneController class is being used for controlling the fieldable_panels_pane entity type. And since this one extends PanelsPaneController, all previous functionality remains. It follows to now override the access() method and include our own logic to it:

public function access($op, $entity = NULL, $account = NULL) { // $account not always full (defaults to current user) return parent::access($op, $entity, $account); }

In the example above, nothing is really changed because the logic is deferred back to the parent class. But you could add some logic in addition or instead of that depending on various contextual factors.

However, I strongly recommend/warn you to stick to the minimum amount of deviation from default is needed, and for all rest, defer back to the original logic. This is to prevent the opening of any security holes. For example, if your access() method looks like this:

public function access($op, $entity = NULL, $account = NULL) { if ($op === 'update') { return false; } }

You are indeed denying access to the edit form but now anybody can create and delete entities because there is no more check on those operations. So make sure you understand this and do not leave any loopholes. The fix in this case would be:

public function access($op, $entity = NULL, $account = NULL) { if ($op === 'update') { return false; } return parent::access($op, $entity, $account); }

If the operation is edit, the access is denied for everybody (probably not a good idea but suitable for this demo purpose). However, if the operation is delete, create or view, we defer to the logic of the parent class to handle those cases. In which case the default FPP permissions will be used.

Conclusion

In this article we've seen two ways we can hook into the access checking pipeline of entities in Drupal 7. We've learned that there is more than just one way of going about it depending on how the entity type in question has been defined. The purpose was to illustrate how you can approach the matter and where you need to look in order to find a solution. Hope this helps.

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

Drupal core announcements: Plan to finalize the Migration system

Mon, 23/03/2015 - 05:56

If you move to Drupal 8 from Drupal 6/7, you'll be using the new core migration system.

Migrate team lead benjy has just posted a plan to finalize the migration system, a "meta" issue which outlines what work's already been completed, what's left to be done, what's blocking what, and how to get involved.

Migrations are an extremely high-impact place to throw time and energy, so if fixing Drupal 8 release blockers isn't your thing, but being able to actually move to Drupal 8 when it's ready is, please jump in and lend a hand! :D (Especially if you've worked with Migrate module in D7 contrib.)

Categories: Elsewhere

Chen Hui Jing: Drupal 101: Creating custom content with Panels

Mon, 23/03/2015 - 01:00

If you ever find yourself needing to create a static page in Drupal, perhaps for a temporary landing page or an under-construction page, while the site is being fleshed out behind the scenes, an option to consider is via Panels. I was in the process of building the DrupalCamp Singapore 2014 website and needed to put up a temporary home page. Using Panels gave me the option of hand-coding the HTML for the page. To do this, you will also need to install the Chaos tools suite (ctools).

  1. Enable the Panels, Chaos tools and Page manager (comes with ctools) modules.

    drush en panels ctools page_manager -y
  2. Once all the required modules are...
Categories: Elsewhere

groups.drupal.org frontpage posts: Registration is Live for Drupal Dev Day NYC 2015! (#D3nyc15)

Sun, 22/03/2015 - 20:20
Start:  2015-04-19 09:00 - 17:00 America/New_York Drupalcamp or Regional Summit Organizers:  joebachana richbaldwin mdorman amycham forestmars

Registration is now up for D3NYC15, to be held Sunday, April 19th at John Jay College in Midtown Manhattan. To reserve your seat, follow this link: http://goo.gl/22LnX5.

The camp website may be found at http://www.drupalcamp.nyc.

Drupal Dev Day NYC 2015 will be a free, full-day Drupal unconference and Drupal 8 sprint event. All skill levels are welcome at Drupal Dev Day NYC 2015. The content is determined by attendees at the beginning of the day, but you can expect to find sessions and conversations on topics ranging from the most basic to advanced.

Among the exciting details of the camp include:
• Morning coffee, bagels and a schmear (wouldn't be a NYC camp without 'em!)
• Beginning Drupal training presented by Bleen!
• A Drupal Ladder/mentoring room, where you can get your environment set up and learn to code for Drupal
• Drupal 8 codesprints
• Sessions all day, picked by us all and presented by drupalists among us or collaboratively in BoF format.

If you are an organization interested in helping to sponsor this event, please contact Matt Dorman (mdorman) for more details, or you can go to the registration page and select your level of sponsorship commitment. Thank you in advance!

For those people interested in volunteering on the day of the event, please ping Joe Bachana (joe@bachana) or post a comment to this event page.

Watch this Event page and follow @DrupalNYC (https://twitter.com/drupalnyc) on Twitter or our Facebook page (https://www.facebook.com/Drupalcampnyc) for the latest updates!

Categories: Elsewhere

DrupalOnWindows: Deploying changing module dependencies with Drupal

Sun, 22/03/2015 - 06:00
Language English

Deployments are often one of the most important aspects of the Drupal development cycle. But sometimes, due to time and/or budget constraints (or the maturity of your company) developers clone databases downstream, manually reproduce content on production environments, and rely on other bad practices on a regular basis.

Today we will show you how we manage small (but critical) changes in module dependencies for our custom modules here at www.DrupalOnWindows.com.

More articles...
Categories: Elsewhere

Midwestern Mac, LLC: Ansible + Drupal + Raspberry Pi Dramble - Presentation at MidCamp 2015

Sun, 22/03/2015 - 00:00

Earlier today, I gave a presentation on Ansible and Drupal 8 at MidCamp in Chicago. In the presentation, I introduced Ansible, then deployed and updated a Drupal 8 site on a cluster of 6 Raspberry Pi computers, nicknamed the Dramble.

My slides from the presentation are embedded below, and I'll be posting a video of the presentation as soon as it's available.

Categories: Elsewhere

KatteKrab: A more accessible online world will benefit everyone.

Sat, 21/03/2015 - 22:37
Sunday, March 22, 2015 - 08:37

PSA: If you are a web professional, work in a digital agency or build mobile apps, please read this article now: Taking the social model of disability online

Done? Great.

"The social model of disability reframes discussion of disability as a problem of the world, rather than of the individual. The stairs at the train station are the problem, rather than using a wheelchair."

El Gibbs has reminded me of question time during Gian Wild's keynote at Drupal Downunder in 2012. Gian asserts that accessibility guidelines are a legal requirement for everyone, not just Government. There was an audible gasp from the audience.

It's true that our physical environment needs to include ramps, lifts, accessible toilets, reserved parking spaces, etc in order to accommodate those with mobility needs. Multi-lingual societies require multi-lingual signage. There are hearing loops - but for some reason, this "social model" of accessibility doesn't seem to have extended online.

Making the digital world accessible, and counteracting the systemic discriminatory impact of failing to do so is something we must take seriously. We must build this in during planning and design, we must make it easy for content editors to maintain WCAG compliance AFTER a site or app is delivered.

Building accessibility features in from the beginning also means it costs less to implement, and delivers a double win of making the whole team more mindful of these issues to begin with. It should be part of the acceptance criteria, it should be part of the definition of done.

I'd like to see us tackle these issues directly in Drupal core. If you're interested in keeping track of accessibility issues in Drupal, you might like to follow drupala11y on twitter, and check out issues on drupal.org that have been tagged with "accessibility"

Accessibility traps might not affect you now, but they will. This is probably affecting people you know right now. People who silently struggle with small font sizes, poor contrast, cognitive load, keyboard traps, video without captions. 

My own eyesight and hearing is not what it was.  My once able parents now require mobility aids. My cousin requires an electric wheelchair. A friend uses a braille reader, and yet I still forget.  It's not front and centre for me, but it should be. Let's all take a moment to think about how we can focus on making our online and digital world more accessible for everyone. It really does benefit us all.

Categories: Elsewhere

Midwestern Mac, LLC: Camp Organizers BoF at MidCamp 2015

Sat, 21/03/2015 - 19:37

On March 21, 2015, there was a fairly well-attended Camp Organizers BoF at MidCamp in Chicago. I took notes during the BoF and am simply publishing them here for the benefit of camp organizers in the Drupal Community. They're fairly raw, but hopefully they'll be helpful for you!

Categories: Elsewhere

Red Crackle: Drupal Testing Methodologies Are Broken - Here&#039;s Why

Fri, 20/03/2015 - 18:01
Currently available Drupal testing methodologies are broken. They are nowhere close to being enterprise-ready. All Drupal developers who have worked on long-term projects have felt this pain. Yes, Drupal 7 ships with Simpletest module but it has two problems: (1) Drupal 7 is not unit-test friendly, and (2) Simpletest module requires reconfiguring the site from scratch. Any Drupal developer who wants to test Drupal today is using functional testing tools such as BDD, Sahi or Selenium. But because of the need to bootstrap Drupal, functional testing still takes a long time to complete. What is needed is an integration testing framework that doesn't bootstrap Drupal on every request and which makes it easy for developers to write and maintain tests. Red Crackle has developed such a framework specifically for testing Drupal. It understands Drupal so that all the mundane tasks of setting up test objects is done automatically in background and the developer just has to concentrate on writing business logic of the test.
Categories: Elsewhere

SitePoint PHP Drupal: First Look at Platform.sh – a Development and Deployment SaaS

Fri, 20/03/2015 - 17:00

Not so long ago, many of us were satisfied handling deployment of our projects by uploading files via FTP to a web server. I was doing it myself until relatively recently and still do on occasion (don’t tell anyone!). At some point in the past few years, demand for the services and features offered by web applications rose, team sizes grew and rapid iteration became the norm. The old methods for deploying became unstable, unreliable and (generally) untrusted.

So was born a new wave of tools, services and workflows designed to simplify the process of deploying complex web applications, along with a plethora of accompanying commercial services. Generally, they offer an integrated toolset for version control, hosting, performance and security at a competitive price.

Platform.sh is a newer player on the market, built by the team at Commerce Guys, who are better known for their Drupal eCommerce solutions. Initially, the service only supported Drupal based hosting and deployment, but it has rapidly added support for Symfony, Wordpress, Zend and ‘pure’ PHP, with node.js, Python and Ruby coming soon.

It follows the microservice architecture concept and offers an increasing amount of server, performance and profiling options to add and remove from your application stack with ease.

I tend to find these services make far more sense with a simple example. I will use a Drupal platform as it’s what I’m most familiar with.

Platform.sh has a couple of requirements that vary for each platform. In Drupal’s case they are:

  • An id_rsa public/private key pair
  • Git
  • Composer
  • The Platform.sh CLI
  • Drush

I won’t cover installing these here; more details can be found in the Platform.sh documentation section.

I had a couple of test platforms created for me by the Platform.sh team, and for the sake of this example, we can treat these as my workplace adding me to some new projects I need to work on. I can see these listed by issuing the platform project:list command inside my preferred working directory.

Continue reading %First Look at Platform.sh – a Development and Deployment SaaS%

Categories: Elsewhere

Victor Kane: Why won't anyone listen to Nedjo?

Fri, 20/03/2015 - 16:45
When he says the Drupal 8 Configuration Management system is only listening to one use case?

One reason no-one listens to Nedjo Rogers on this subject is that what he's saying is not that simple to understand. But I assure you it's well worth the effort. He's saying that the Drupal 8 Configuration Management system is built around a single use case that favors a certain enterprise need, namely that of single site configuration stabilization and propagation to other environments, principally live.

In his initial article on this subject (Bibliography #4, Nedjo Rogers) Nedjo wrote that the fact that “Sites own their configuration, not modules” (as stated in Bibliography #3, Alex Pott) constitutes nothing less than “a seismic shift in Drupal that's mostly slipped under the radar”. Nedjo first reviews the history of exportable configuration in Drupal, and correctly highlights the fact that there are two main use cases involved:

  • To share and distribute configuration among multiple sites.

  • To move configuration between multiple versions of a single site.

“By and large, the two use cases serve different types of users. Sharing configuration among multiple sites is of greatest benefit to smaller, lower resourced groups, who are happy to get the benefits of expertly developed configuration improvements, whether through individual modules or through Drupal distributions. Moving configuration between different instances of the same site fits the workflow of larger and enterprise users, where configuration changes are carefully planned, managed, and staged....”

“If anything, the multiple site use case was a driving force behind the development and management of configuration exports. The Features module and associated projects - Strongarm, Context, and so on - developed configuration exporting solutions specifically for supporting distributions, in which configuration would be shared and updated among tens or hundreds or thousands of sites.”

“For Drupal 8, however, the entire approach to configuration was rewritten with one use case primarily in mind: staging and deployment. The confiugration system "allows you to deploy a configuration from one environment to another, provided they are the same site."

If this is the case, then we really need to get to the bottom of this issue. The objective of this article is to briefly summarize the whole debate (see Bibliography), remove any items that are blurring or clouding the issue, and then underline three times those points that really deserve not being kept “off the radar” and which I hope others will delve into so that we can get a clear picture of perspectives and solutions (many of which Nedjo himself, and others, are spearheading already in third party modules; see below). It's an important question: what's in store for us in terms of industry-wide best practices for Configuration Management in Drupal 8, taking into account all important use cases? And it's a question that Nedjo took the trouble to raise in the Drupal Community as far back as January, 2012. But no-one listened.

read more

Categories: Elsewhere

Phase2: Accelerating with Drupal 8

Fri, 20/03/2015 - 16:09

Today is an exciting day for the Drupal community! Collectively, we’re all moving a few steps closer to a full release of Drupal 8 with the help of a program called Drupal 8 Accelerate. This is a pilot program from the Drupal Association designed to put $250,000 of community funds towards eliminating the last 50 critical issues between us and release.

The Drupal Association has been an incredible leader in the effort to release Drupal 8, pledging to set aside $62,500 to match every dollar donated to the provide Drupal 8 Acceleration Grants.

What’s the latest with Drupal 8 Accelerate?

But we knew we could do even more to turbocharge this project. Today we are announcing that D8 Accelerate is now getting a huge boost from seven anchor sponsors, who have pledged to “match the match,” amplifying every donation made and accelerating the community’s investment in Drupal 8.

Phase2, Acquia, Appnovation, Lullabot, Palantir, PreviousNext, and Wunderkraut have collectively pledged another $62,500 to match the Drupal Association’s matches of community donations. This is an all-out, everyone-in community effort to move D8 from beta to release. Our goal is to bring the total to $250,000 available for grants by September. We are now more than half way there.

Why should we all want Drupal 8 to succeed?

The answer is simple: D8 will empower us to use Drupal the way many of us have wanted to for a long time. D8 improves the API layer, multi-lingual capabilities, theming and the editor experience. It also makes is much more powerful for developers (which matters a lot to us at Phase2).

Historically, it has been a challenge to integrate new libraries or different front-end elements without a lot of leg work. Imagine, for example, how the availability of Twig theming will enhance your projects. Or how flexible implementations can be with dependencies on meaningful external software integrated through Symfony routing. We will even be able to more seamlessly incorporate mobile apps into the digital strategies we develop, correcting one of the main weak points of previous Drupal releases.

Put simply, Drupal 8 is a win for our collective clients, and therefore it is a win for all of us.

Phase2 & Drupal 8

At Phase2, we want Drupal 8 to succeed because our clients have increasingly big needs and major challenges, and we believe that Drupal 8 is moving in the direction to address those. For that reason, we’ve made investing in Drupal 8 a priority, not only by way of the Drupal 8 Accelerate program, but also in the form of contributed code and shared knowledge gleaned from major enterprise Drupal 8 implementations.

Taking on early Drupal 8 implementations enables us to commit our people to the D8 cause, while directly supporting our client’s mission. It also provides us with a group of advanced scouts to report back from the front lines and develop training for the rest of our team.

Principle among these scouts was Software Architect Jonathan Hedstrom, whose contributions to D8 include Drush support, core patch reviewing, testing and re-rolling, writing tests, modules upgrades (Redis), and more. In addition to Jonathan, Senior Developer Brad Wade made important front-end contributions, while Software Architect Mike Potter has been a significant part of Features development.

We’ll be sharing a lot of what we learned from our D8 work so far at DrupalCon Los Angeles, so stay tuned for our session announcements next!

 An all-out, everyone-in effort

It took the whole Drupal community – including individuals, companies, the Drupal Association – to get D8 to the place it is now. We are honored to have contributed alongside everyone involved. It has certainly been a heavy lift for many community members, so to each of these people and organizations, we say thank you. The success of Drupal 8 is the most important priority of our community.

However, Drupal 8 still needs a strong push to get over the finish line. So we must ask one more time for the support of our fellow Drupalers. We all have a major stake in the success of the project, and everyone can play an instrumental role getting it out the door. Even the smallest donation makes a difference when every dollar you donate is now matched, compounding your impact. You can read more about how the funds actually support the grant program to achieve the work on the Drupal Association D8 Accelerate page.

If you would like to donate, please visit the D8 Accelerate Fundraising site and please consider using my profile as a way to easily make your contribution so we can start enjoying those launch parties!

Categories: Elsewhere

Drupal Association News: Ready, Set, Drupal 8! D8 Accelerate Fundraiser

Fri, 20/03/2015 - 15:59

Last November we launched Drupal 8 Accelerate, a grant program designed to eliminate Drupal 8 release blockers. Through the progam, we’ve made a small number of grants that have had a huge impact. In fact, we only have about 50 release blockers left between us and release. So now the Association is going to take it to the next level. We've already pledged $62,500 of our general operating budget in 2015 as matching funds for you donations. Now we are announcing that the board has partnered with 7 outstanding community supporters to “match the match” and provide another $62,500 of the program, bringing us to $125,000 available for grants.

Now it's your turn! We're asking you to help us raise another $125,000 to make the total amount available for these grants $250,000. You can give knowing that every dollar you contribute is already matched by the Association and these anchor donors, doubling your impact. Your donations will allow us to make more grants, faster, increasing our impact and getting D8 out the door!

This is an all-out, everyone-in effort to raise $250,000 to kill the last release blockers in our way.This is our moment - together, we are going to move Drupal 8 from beta to release with the Drupal 8 Accelerate program. We already know it works. Drupal 8 Accelerate grants have already tackled release blockers issues related to menus, entity field validation, and caching. As a donor, you will always know exactly what you're funding because we're making it all public

Join us today and make your donation. The sooner we get this done, the sooner we can all enjoy those launch parties!

Special thanks to our anchor donors, Acquia, Appnovation, Lullabot, Palantir.net, Phase2, PreviousNext, and Wunderkraut, for making this matching campaign possible.  These seven organizations stepped up to the plate and made this entire campaign possible. Thank them on Twitter using the #D8Accelerate hashtag.

The D8 Accelerate project is designed to help move Drupal 8 from the initial beta to a full release. This directly relates to the Association's mission: uniting a global open source community to build and promote Drupal. This is a pilot program from the Drupal Association to put $250,000 of community funds toward accelerating the release of Drupal 8, due to the strategic impact this work has on the entire Drupal ecosystem.

Categories: Elsewhere

Darren Mothersele: Introducing Stylex: Atomic design, style guides, and prototyping with Silex and Twig

Fri, 20/03/2015 - 01:00

I've been working a lot with Atomic design (component-based design) with Drupal recently, and I've witnessed huge improvements on projects where it has been introduced. The main advantage being the decoupling of the development of the back-end from the development of the front-end code.

I've covered this in more detail previously, I'm running some workshops on Atomic Design in Drupal, and I have more to say on this in the future. Today I want to tell you about a simple tool I'm using to speed up the process.

The main purpose of this tool is to simplify the construction of prototype sites or style guides for front-end code. There are several tools already available, including the excellent Pattern Lab, but I wanted something incredibly simple.

I basically just wanted to make use of the power of Twig templates for mocking up front-end code, with an easy way to load in demo content (from yml files).

 Barebones project

I've created a barebones Stylex project on GitHub that demonstrates this, but you probably want to follow along in the setup, so you know what's going on...

Basic setup

I've packaged this for Composer so getting started is easy. Assuming you already have Composer installed globally all you need to do is create a folder for your project and run the following command:

composer require darrenmothersele/stylex dev-master

This will download Stylex from Github and all the dependencies. It creates the composer.json file for you and downloads all the code for the dependencies into a vendor folder.

As a bare minimum you will need to create a index.php to run the application, and a starter template templates/index.html.

Create a file in the project root (same location as the generated composer.json file) called index.php with the following code:

<?php require_once __DIR__ . '/vendor/autoload.php'; $app = new Stylex\Application(); $app->run();

Then create a templates folder and create the first page template, templates/index.html in this folder:

<html> <head> <title>Hello!</title> </head> <body> {% block content %} <h1>Hello, world!</h1> {% endblock %} </body> </html>

You can run the application with PHP's build in web server. Simply run the following command:

php -S localhost:8000

Now, browse to http://localhost:8000 to see the website.

Adding pages

You can add more pages, and make use of Twig's awesome template inheritance feature. For example, to create an 'About us' page, create a new file in the templates folder called about.html with the following content:

{% extends 'index.html' %} {% block content %} <h1>About us</h1> {% endblock %}

This inherits the whole template from index.html but replaces the content block with a new block of content specific to this page. Browse to http://localhost:8000/about to see the result (make sure PHP's web server is running - see above).

Using data

You can create YAML data files and then use them in your templates. Create a folder called data and then add *.yml files with your data. In any template these are then available using the filename. For example, to create a data file for your navigation links, create a file called data/main_menu.yml with the following content:

- title: Home path: / - title: About Us path: /about

Because the filename is main_menu.yml this data is now available to read in template files using {{ main_menu }}. Let's add a component template to style the menu. See my posts on Atomic design in Drupal to find out more about component templates. For now, just create a file in templates/components/menu.html with the following content:

<ul> {% for item in main_menu %} <li> <a href="{{ item.path }}">{{ item.title }}</a> </li> {% endfor %} </ul>

Now you can include the menu in your page template, by adding the following to your index.html file:

{% include 'components/menu.html' %} Using sample content

Stylex supports creating sample content using Markdown format with YAML front matter. This is a simple way to manage blobs of content with associated metadata. By using Markdown and YAML together to create sample content you can keep the sample content out of your front-end mockups and prototypes. This is another useful decoupling that makes life easier.

In this approach sample content is stored in subfolders under a content folder. You can have multiple types of content, and organise them into subfolders under a main content folder. Let's create a first article as an example. First create your content and then content/articles folder, then create a sample file called content/articles/first_post.md with the following content:

--- title: My First Post excerpt: Lorem ipsum dolor sit amet, consectetur adipisicing elit. image: http://placebee.co.uk/640x480/1 --- Lorem ipsum dolor sit amet, consectetur adipisicing elit. Voluptas ipsam veritatis officia unde incidunt doloribus veniam eligendi ea maiores delectus excepturi aspernatur illum, voluptates quas odit harum cupiditate cum maxime...

See the Stylex Barebones for the full example, I've abbreviated the content here. The main point is to show how you can include YAML metadata above the main Markdown formatted content.

You can then reference this content from your templates. For example, to print out the title of that first post you created, use the following in your Twig template:

{{ content.articles.first_post.title }}

Or, more useful, print out the titles of all articles:

{% for post in content.articles %} <h2>{{ post.title }}</h2> {% endfor %}

Or, yet even more useful (if you're building an atomic design), output all the articles using a component template:

{% for post in content.articles %} {% include 'components/teaser.html' with post only %} {% endfor %}

For this to work, create a component template for the teaser by creating a templates/components/teaser.html file with the following content:

<div class="teaser"> <h2 class="teaser-title"> {{ title }} </h2> <img src="{{ image }}" alt="" class="teaser-image"> {{ content|raw }} </div>

You can create subfolders to organise different types of sample content, for example, add an events folder content/events and they will be available in your templates as {{ content.events }}

 Debugging

If you're getting error messages, you can turn on debugging. In the index.php file that you created simple add the following line before $app->run();

$app['debug'] = TRUE; Conclusion

This just does the basics to allow you to use Twig templates to quickly build out front-end code. It reads in sample content and data from yml files and allows you to easily combine them with template files to create a prototype site.

The next step is to reset Drupal's markup and get it generating the exact same markup. This is covered more in my Atomic Design in Drupal workshops.

You'll probably want to add your favourite front-end tools into this. In particular, I like to add a Gruntfile to do less/sass compilation, etc.

Drop me a line if you find this useful, or have any ideas for how it can be improved.

Thanks!

Darren

Categories: Elsewhere

Code Karate: Creating a hierarchy of users with the Drupal Subuser module

Fri, 20/03/2015 - 00:57
Episode Number: 198

In this episode we cover the Drupal Subuser module. This module makes it easy to allow your users to manage other users on your site. This works great if you want to allow a site manager to be able to add in users of a specific role, but not have access to the full Drupal User Administration pages.

Tags: DrupalDrupal 7Site BuildingDrupal Planet
Categories: Elsewhere

Pages