HollyIT: Windows+Vagrant+WinNFSD Without File Update Problems

Planet Drupal - Thu, 2016/02/11 - 7:07pm
Categories: DrupalPlanet Drupal

I have used Windows to develop on for years. I have been through WAMP, XAMPP and EasyPHP, plus also going my own route to handle my web development. Last year I switched to Vagrant so that I could mimic the varying servers I work with from all my clients. Of course I was quickly plagued with the problem most Windows vagrant users face - extremely slow page loads.


Darren Mothersele: Build Your Own PHP Framework

Planet Drupal - Thu, 2016/02/11 - 6:00pm

I'm excited to announce that I'll be back running training at this year's Drupal Camp in London. This will be the 3rd year in a row that I've offered training at the camp. I'm doing something a bit different this time...

Build Your Own PHP Framework

In this training you will build your own PHP framework.

But, why reinvent the wheel?

Building your own framework is a great way to learn the fundamentals of modern PHP. Regardless of your choice of framework, this will make you a better developer. A similar foundation of components underlies Drupal, Symfony, Silex, and Lavavel.

If you are a developer going from Drupal 7 to Drupal 8 then you need to adopt an object-oriented mindset.

Drupal doesn't always get it right. If you understand the basic principles you know when and why you're breaking them. You can make pragmatic choices as a programmer, without embodying bad practices.

"Build Your Own Framework" is a fun training to learn modern PHP. You will learn the "SOLID" principles of PHP package design. The training will demystify dependency injection, hexagonal architecture and other design patterns. We will look at HTTP Foundation and the other Symfony components.

Come armed with a basic knowledge of PHP, a laptop that can run PHP, and an open mind. Leave with a better understanding of the principles behind modern PHP and Drupal 8.

Tickets available here.

The training will be held on Friday March 4, 2016 at City University London.


IXIS: Building websites for the blind

Planet Drupal - Thu, 2016/02/11 - 5:15pm

This months Northwest Drupal User Group (NWDUG) in Manchester had a lovely visit from a non developer to talk about how the Internet has changed his life and the challenges of using the Internet as a blind person.

Being blind since he was a child has meant that some activities weren't possible before the Internet became accessible to everyday people - such as reading the news or magazine articles. Now Sunil works with the Internet everyday at his job in the British Red Cross.

read more


Drupal Association News: Global Training Days - February 2016 Summary

Planet Drupal - Thu, 2016/02/11 - 4:05pm

We kicked off the 2016 Global Training Days on February 5th. Twenty-two sites held a training in 11 countries, making it a great start to all things training in 2016.

Training events were held all over the globe in a variety of spaces. From offices to the public library and spaces where public university and governmental institutions collaborated with private organizations, Drupal was brought to a wide audience. Trainers gave introductory lessons with demos and hands-on site building exercises to attendees. Thank you to everyone who participated!

Here are just a few of the tweets we received about the first of the 2016 Global Training Days.

#DrupalGTD #Drupal training in progress at @valuebound in association with @drupalbangalore @BangaloreDrupal pic.twitter.com/IbzpiOobJf

— Neeraj Kumar (@neerajskydiver) February 6, 2016

Awesome #DrupalGTD in #Lviv! Thanks everyone! https://t.co/O1eYCMN8Dg #learndrupal with @lemberg_co_uk pic.twitter.com/gkoDQRnGMe

— Lemberg Solutions (@lemberg_co_uk) February 8, 2016

And in the end...thank you for this beautiful #DrupalGTD !!!!@bonsaimeme @SparkFabrik @SapienzaRoma #Drupal pic.twitter.com/rA4RPkD86j

— Bmeme (@bonsaimeme) February 5, 2016

All smiles at our #Drupal Training Day @SunSoftCity w/ @consultndesign. #DrupalGTD pic.twitter.com/GCxA7VLzAw

— Drupal Hub (@thedrupalhub) February 5, 2016

See more photos and updates at #DrupalGTD on Twitter. The full list of participants is on the 2016 page.

Learn more about the program at drupal.org or sign up to provide training at the next event.

Personal blog tags: Drupal Global Training DayGTD

roomify.us: Manage meeting room availability and take bookings with BAT for Drupal

Planet Drupal - Thu, 2016/02/11 - 3:45pm
We put together extensive documentation on how to use BAT, using a meeting room availability and booking example throughout. This is one of the most often requested features - especially from libraries and educational institutions - so we hope you will find it useful. We hope this will help and would love to hear your thoughts - get in touch.

Pronovix: Publishing a code sample book from Stackoverflow to LeanPub using Drupal and GitLab

Planet Drupal - Thu, 2016/02/11 - 3:09pm

In this blogpost we want to share how Bruno Lowagie (the original developer of iText) designed a workflow that allows him to publish questions and answers from Stackoverflow on the iText Drupal site and then export them to LeanPub (utilizing a custom Drupal module).


drunken monkey: Create Git diffs with proper function context

Planet Drupal - Thu, 2016/02/11 - 1:37pm

For years I have been annoyed (slightly, but still) that Git diffs for PHP classes always just contained the class header instead of the method header as the function context. I finally got round to doing a bit of research and it turns out that the solution is astonishingly easy: just one small and simple config file and it will magically work.

The problem

You might have noticed it, and maybe been annoyed by it, too: when you create a diff file with Git and have changes inside PHP class files, you get hunks that look like the following:

@@ -40,6 +40,7 @@ class SearchApiViewsHandlerFilter extends views_handler_filter {
       '<=' => t('Is less than or equal to'),
       '=' => t('Is equal to'),
       '<>' => t('Is not equal to'),
+      '!=' => t('Is REALLY not equal to'),
       '>=' => t('Is greater than or equal to'),
       '>' => t('Is greater than'),
       'empty' => t('Is empty'),

So, where you would normally expect the function context, to quickly get an idea what that change means, the diff instead just contains the class name, which is much less helpful (especially if the file name already tells you the class).

Well, after years of being regularly (slightly) annoyed by this (more so in recent years, with the OOP shift in Drupal 8), I finally searched this new place called "the interwebs" and arrived at the very simple solution.

The solution

It turns out Git's diff functionality already has support for creating the right function context information for various file types – it just doesn't know which files correspond to which file type. (It seems not even the standard .php extension is recognized by default.)

To remedy this, simply create a file with the following contents:

*.engine   diff=php
*.inc      diff=php
*.install  diff=php
*.module   diff=php
*.php      diff=php
*.profile  diff=php
*.test     diff=php
*.theme    diff=php

Save the file either in .git/info/attributes or .gitattributes (for just the local project), or (to change this globally) in $HOME/.config/git/attributes (or $XDG_CONFIG_HOME/git/attributes, if that variable is set). That's it – testing again, we now see the proper function context in the diff:

@@ -40,6 +40,7 @@ public function operator_options() {
       '<=' => t('Is less than or equal to'),
       '=' => t('Is equal to'),
       '<>' => t('Is not equal to'),
+      '!=' => t('Is REALLY not equal to'),
       '>=' => t('Is greater than or equal to'),
       '>' => t('Is greater than'),
       'empty' => t('Is empty'),

Much better, right?

Note: I haven't yet found out where to put the global attributes file for Windows. If you know, please post a comment and tell me, and I'll include it here.

Background information

For more information on Git attributes, please see the documentation. I didn't know about this at all before, but it seems there's actually a lot you can configure per file type, so there might be other very practical tips for customization.
If you find or know of any, please post them so others can profit from them, too – just as I hope this post was useful to at least a few of you!

As an afterthought, I've also added this tip to the Git documentation in Drupal.org's handbook. Hopefully, more people will find it that way.


Pixelite: Estimating Drupal projects

Planet Drupal - Thu, 2016/02/11 - 12:00pm

Estimating Drupal projects can be tricky, and there are a number of tools and guides out there to help make your life easier in this topic. I thought it would be a great idea to aggregate this data, and present some of the best information out there. It is up to you to choose the best match for your team.

Resources palantir.net

Developing Drupal sites: Plan or Perish - by Larry Garfield (2013)

Even though this article is nearly 3 years old, it still is completely valid for Drupal. There is an included spreadsheet that you get the tech lead, product owner and another engineer to collaborate on prior to building.

What I like about this:

  • Emphasis on involving tech leads early to perform scoping and breaking up functionality into tangible Drupal elements. This allows you to have less experienced developers do the actual build, as largely everything has been speced out.
  • View modes are used extensively which is a great for re-usability of content and maintaining flexibility
  • Questions, or opportunities for simplification can come up before anything has been built

There are 3 articles on lullabot.com that are worth reading, they all follow on from one another, so it would pay to start at the beginning and work your way to the end.

In here they introduce a spreadsheet that attempts to combine 2 developers estimates into a single number with variance.

What I like about this:

  • It exposes the fact that all website builds have range to which it can be completed in
  • It helps to explain the ‘Wideband Delphi’ method of estimation
  • Excellent explanation on how to use the spreadsheet is provided

Resources for my session on early estimating by Jakob Persson (2010)

Included in the article here is the Drupal early estimation sheet v3.

What I like about this:

  • Walks you through an actual example on how an email was turned into a concrete estimate, and how that was analysed
  • Introduces often overlooked things such as:
    • migration of data
    • producing help or documentation
    • deployments
    • third party system integration
    • working with a third party (e.g. external design vendor)

There are several training videos on drupalize.me that would be worth checking out if you have some time:

If you have an existing Acquia subscription you might already have access to Drupalize.me, so this might be worth looking into.

Personal thoughts

Having been involved in doing a lot of this in my previous role, and one additional point I would like to make is to never start from a fresh Drupal install, it often makes sense to standardise on a Drupal technology suite, and installation profiles make this easy.

For instance, Acquia typically use an installation profile called lightning which provides built in ways to do lots of common tasks, e.g. layout, workflow, media management. This saves you having to re-invent the wheel on every project, and should help you provide more solid estimates when it comes to the base features of the site.

Another common theme across the different methods is to involve 1 or 2 tech leads early on to help break the requirements down into Drupal functionality. Having these early conversations with the product owner early on can often lead to a better solution not only in time to build, but feature set too.

Also remember, the above articles and spreadsheets may not work perfectly for you and your organsiation, so feel free to adapt them to suit your needs.


If you know of some other method to help here, please let me know in the comments. Especially keen to know of any other training content or spreadsheets which other companies use to help estimate Drupal projects.


Wellnet Blog: Logging in Drupal 8

Planet Drupal - Thu, 2016/02/11 - 11:48am

Many Drupal websites are not just simple websites but real applications, with many functionalities, integrations and logic. It’s often necessary to keep track of what is happening in the application to understand if something went wrong or even just to monitor the user activities.
It is...


DrupalCon News: User Experience Design with Drupal and Beyond

Planet Drupal - Thu, 2016/02/11 - 5:04am

Did you know you, yes YOU, could potentially provide the most valuable information at all of DrupalCon New Orleans?


Acquia Developer Center Blog: What We're Up To at DrupalCon Asia in Mumbai

Planet Drupal - Wed, 2016/02/10 - 9:07pm
Jeffrey A. "jam" McGuire

Acquia is once again a sponsor of DrupalCon, and those of us who have the chance to take part in DrupalCon Asia in Mumbai, India are getting excited. This post covers the sessions we'll be part of in Mumbai.

Tags: acquia drupal planetdrupalconMumbai

J-P Stacey: Building a Drupal site with Behaviour-Driven Development

Planet Drupal - Wed, 2016/02/10 - 9:03pm

(This article first appeared on the Agile Collective blog.)

The Global Canopy Programme (GCP) needed to retrieve news syndicated from many public sources, manage it via an internal application, then re-syndicate it reliably to several public-facing websites. This application—called Forest Desk—needed to be described and built “just in time”, both to fit the clear initial requirements but also to adapt to any discoveries made along the way.

Read more of "Building a Drupal site with Behaviour-Driven Development"


Drupal Association News: Membership Drive 2015 recap

Planet Drupal - Wed, 2016/02/10 - 8:44pm

From October 13 to December 30, 2015, we ran our biggest membership drive campaign ever. We did a lot of experimenting and I want to share some results and learnings with you.

But first, I'll tell you about our program. Drupal Association membership is for anyone who uses Drupal, and anyone who wants to support our community and the project through a donation of membership dues. Membership is one way to contribute to Drupal, but it is by no means the only way.

The biggest accomplishment in this campaign: 10% growth

During the campaign period, we saw 10% overall growth in our membership (3,266 to 3,590 members). For the last two years over this same period of time, we had seen 1% growth in membership. Last year’s growth is a huge win.

Goal vs actual

Our campaign goals were to raise $100,000 and to have 1,000 new members sign up.

The results looked more like this: $50,896 and 480 new members.

We also had 148 lapsed members return and our overall membership grew. Despite not hitting our goals, we are happy to have new and renewing members and some new knowledge about campaign content.

Testing content

When the campaign launched on October 13, we put our first banner ever on drupal.org to test whether an increased presence on the site would make a difference in membership sales. The answer is a big Yes. There were spikes in membership sales around the times we launched and changed the content of the banners. The biggest day of sales took place on the day after the launch, Oct. 14, when 74 members paid dues.

On December 14, we refreshed the banner to include a photo and quote from a member who gave us a testimonial. We rotated the banners and a separate block on the drupal.org homepage until the end of the campaign to highlight a few members.

This graph shows the results during our December banner rotation period. There was a trough around the Christmas holiday, so testing this at a non-holiday time of year will be beneficial in a future campaign.

What we learned

A greater drupal.org presence helps sell memberships, and being mindful about what content to show our active members is important for inspiring people to share the campaign. If members see a banner, they should easily be able to share it or hide it.

We need to keep telling your stories. I saw some of the members who gave testimonials were given kudos in the community. It feels good to see the faces of the community and to see just why you care. We have continued sharing stories, starting with DrupalCon Asia.

On days we launched banners or refreshed content, we saw the biggest sales spikes and flurries of social activity. The time of year when many people step away from their computers could impact campaign performance, so testing at another time of year should be done.

Thanks to everyone who participated in this campaign. From the 27 members who gave testimonials, to everyone who joined or renewed membership or encouraged the community to be a part of the drive, we appreciate your help.

See the full report at https://docs.google.com/presentation/d/1h0r32Tfw7TZ6osQbgtfMMJCZ3gjHMmwYlqOF8Xnmc80/edit#slide=id.g34532c755_069

Personal blog tags: Membership

OSTraining: Image Styles and Sizes in Drupal 8

Planet Drupal - Wed, 2016/02/10 - 7:50pm

One thing that all site builders need to think about is image size.

The size of your images can have an enormous impact on your site's speed and it's performance on mobile devices. Fortunately, the Drupal 8 core provides tools for controlling and optimizing the size of your images.

In these two videos, Robert shows you how to use Drupal 8 image styles and image settings.


Affinity Bridge: Ten Pointers for New Drupal 8 Developers

Planet Drupal - Wed, 2016/02/10 - 7:46pm
Ten Pointers for New Drupal 8 Developers 02/10/2016 - 10:46 drush drupal drupal8 twig planet drupal Floyd Mann

We've been experimenting with Drupal 8 for a while now, but this site is the first project we've put into production built on it.

For folks who've worked with Drupal 6 or 7 previously and are just getting started using 8, here are a few tidbits worth being aware of when getting started.

1. Sooo much contrib is bundled in core now.

Those who’ve been in the Drupal community for quite a while remember the "Small Core" initiative. The idea was to strip Drupal core down to a minimalist framework, then use distributions to provide bundles of modules and configuration that would make Drupal a useful application in a particular scenario. Drupal Core itself would not be a useable product.

Small Core lost. Drupal 8 core contains major functionality that previously was provided by contrib modules, including Views, Views Datasource, Services, Entity API, Image Cache, Responsive Images, Breakpoints, Migrate, and WYSIWYG. Drupal 8 is a much more complete product out of the box then any previous version of Drupal.

A few features were removed from Drupal 8, most noticeably the blog module. It is easy to reproduce the blog functionality with the blog contrib module or even just by using the core components to add a custom content type and views to display the content. The latter approach is what we decided to do here.

When Drupal 7 was released many developers got burned by how many contrib modules weren't ready yet. The inclusion of so many essential modules in core has significant mitigated that issue, but there are still a number of "essential" contrib modules that aren't stable yet, notably token, pathauto, rules, and webform. There are prerelease versions of most of these modules in varying degrees of stability, and certainly trying them out, and contributing feedback, patches, and bug reports is the best way to help them get to a stable release. But sitebuilders under tight deadlines should check their requirements carefully and verify that any contrib modules they need are stable enough to use before promising complex functionality in Drupal 8 right now.

2. The authoring environment is massively improved.

The lack of a consistent author environment and authoring tools has, for years, been one of Drupal's biggest weaknesses when compared to other CMSes like WordPress. Developers love Drupal, but authors usually prefer WordPress.

A major effort was put into Drupal 7 to improve the authoring experience (UX), which Drupal 8 builds on. The seven administration theme is responsive now. Dropbuttons have been introduced for more economical use of screen space and to prioritize primary actions.  The CKEditor WYSIWYG editor is tightly integrated with core, providing a huge gain in consistency between one Drupal 8 environment and another.

Quickedit in-page editing is a whiz-bang feature of Drupal 8.  

Using QuickEdit while writing about QuickEdit

Did I mention the improvements to preview? Node previews that actually preview as they will render reduce the guesswork previously required when authoring any content containing layout code or different typefaces from the admin interface.      

3. Drupal 8 is a Symfony application

Drupalcon Denver is where I first heard about the plan to build Drupal 8 with Symfony components. I’m not sure whether my recollection is flawed or if I just didn’t understand what I was hearing, but the move to Symfony didn’t sound like too big a deal: just few minor changes to the plumbing, the inclusion of a Kernel and  HTTPRequest and HTTPResponse classes that’d improve testablity. I recall a neighbour at one of the talks telling me it sounded like ASP to him.  

The move to Symfony is a very big deal.  Drupal 8 is near total rewrite of Drupal, with almost all core functionality now provided through services and dependency injection and thus overrideable.  Interfaces and routing, classes and annotation, all idioms common in the Symfony world have been adopted in Drupal 8.

What is familiar to a Drupal Developer who hasn't worked with Symfony?  Well, the core business objects like nodes, blocks, taxonomy terms, and fields still exist, though they are implemented quite differently. The hook system isn’t too different either, but be warned that what you receive in an array of parameters is quite different.  And the Form API, though not totally unchanged, is one place where the Symfony solution was rejected, though perhaps not outright: there is an active discussion on drupal.org right now about whether to integrate the Symfony form component into Drupal 9

4. API Docs and Change records are your friend

The documentation team has worked incredibly hard to keep the documentation up with the changes that have occurred. Api.drupal.org has fantastic information about the classes and concepts you’ll encounter now.

One big issue is that many things have new names now.  This is where the change records are essential.  Something like “menu_get_object” from Drupal 6 or 7 has been replaced.  Searching for a old command in the change records will often bring up the exact code snippet you need to update your code.

5. Config management

The configuration management inititiative is one of the biggest changes in Drupal 8. All configuration, whether it be a view, a content type, or the site title, can now be managed via importing and exporting yml files, either through a UI or via Drush. The Features module, which was the best method of synchronizing configuration across development and production sites in D6 and D7, is considerably less essential now

All the nitty gritty details of configuration management are beyond the scope of this introduction, but I will share a few useful tips that we learned in development.

  • Start your local dev site with a config export and settings file from your staging site. You need to make sure the hash salt in your settings.php and the UUIDs in your config files are in synch, otherwise you will not be able to synchronize the configuration accross sites.
  •  Move the config directory out of sites/default/files. Not absolutely necessary, but it is becoming a best practice to move the config out of the site directory. It is an easy enough change to make and increases site security considerably.
  • Only commit production config to master, merge dev config in from branches. Config management does not include a method of identifying and merging changes between two different config directories or changes that were made in one branch that are absent in another: it is up to your source control system to handle that. If you start committing development config to your master branch, then expect to export changes from production before importing the dev changes, you will be in trouble!  It doesn't work like that. The better method is commit to your dev branch, then export production config to master and commit. Next merge dev into master, and finally import the merged config into production. Confusing? It is a bit, and the diagram on this Pantheon blog post doesn't make it less so. The short version is just don't commit anything but production config to master and you'll usually be alright.
  • It isn't always obvious what will be considered config and what is content. This has been an on-going problem for Drupal Developers to wrap their head around. For example, block placement is  configuration and thus stored in yml but block content is not.  It mostly makes sense once you get in there, but undeniably there is a bit of a learning curve here. 

As I mentioned, the Features module is still available; it looks like it will come into play for bundles of configuration that need to be pushed live jointly but independent of an entire site's config. Configuration management best practices are still evolving, however, so it remains to be seen exactly how wide Features for D8 adoption is or if other tools emerge.

6. Drush and the Drupal Console

Drush is still around and as essential as ever.  A few key new command in Drush 8:

drush cr - Cache rebuild, the replacement for drush cc all in Drupal 7

drush cim - import config, similar to drush fra in 7

drush cex - export config, similar to drush fu in 7

drush cedit - edit the config yml in your editor. This can be really handy sometimes.

The Drupal Console is a new option for command line users. It is based on the Symfony Console and an extremely exciting new arrow to have in our quivers.

Drupal Console can do many of the things drush can, but the focus of this project is a bit difference than Drush's. Most significantly is the effort in making Drupal Console generate pristine boilerplate code. That may not sound like much, but given the adoption of OO, PSR-4 namespaces, and autoloading, being able in a few keystrokes to generate a block plugin with all of the correct annotation, namespacing, and file placement is a huge timesaver. It also makes becoming productive in Drupal 8 much less daunting: you don't initially need to understand all of the changes that have taken place. Instead, let Drupal Console take care of registering your new plugin so you can focus on just the logic you need to deliver. Later you can come back and learn about what the annotation means, what the parent class does, and so on. 

7. Managing your build

We usually use Drush Make files to manage our builds, including contrib modules, patches, and libraries.

Traditional Drush Makefiles still work in Drupal 8. They have also introduced a makefile in .yml format

Embracing a trend that has spread across the wider PHP work, Composer can also be used to manage your Drupal install, and already is being used by Drupal itself to manage dependencies. There is good documentation on how to use Composer to manage your install on Drupal.org, making use of the Drupal Composer/Drupal Project and Drupal's Packagist host.  

Whether this approach will take off or whether Drupallers will stick with Drush again remains to be seen.

8. The theme layer is now in twig.

Another element that comes to Drupal from Symfony, Twig has been adopted for templating.

Twig is easy to use and significantly more secure than PHPTemplate was. It also introduces a new template extension model to Drupal, which I'm quite excited about. I suspect it is going to take a while for existing Drupal themers to embrace this model, but folks who come to Drupal from Symfony or Django will be pleased to have extendable templates available to them. And there are promising signs that some contrib themes are starting to embrace it

9. Theme debugging tools now in core.

In Drupal 8 in your services.yml file, you can enable theme debugging. Once you do you'll see output like this:

with all the candidate templates listed. The template that was actually used is indicated with the x rather than the *.  

One thing to watch for is that with theme debugging enabled some JSON calls break.  

You know what is extra cool? Theme debugging was backported into Drupal 7 too. Try drush vset theme_debug true some time and you'll similar output there.

More advanced debugging still requires the devel module. {{ kint(var) }} is my favourite twig debugging snippet.  The arrays are much more deeply nested than what you are used to from previous Drupals, so be sure to give php enough memory! Also, enable autoreload and disable template caching in your settings.yml file before debugging front-end code. Otherwise you need to clear cache on every page load.

10. A new approach to release management promises more rapid improvements in the future.

No longer will we have to wait five years for any significant changes in core functionality!  As is explained in the release cycle overview on Drupal.org, "Starting with Drupal 8.0.0, Drupal core releases will move to a new release cycle schedule" with the intent being for minor releases to come out twice a year. Drupal 8.0 has been out since October, thus we are only about two months from the release of 8.1.0. A beta release of 8.1 will be available in less than a month!

8.1 is going to add, among other things, improvement to migration support from Drupal 7 and the migration UI. It appears BigPipe will also make it into 8.1. Will there be upgrade issues for site builders or compatibility issues for contrib modules moving from one minor release to the next? Will poorly maintained sites end up stranded on minor releases? Again, time will tell, but it is exciting to think there will be significant improvements to core available to us a couple of times a year.


Janez Urevc: A lot of exciting Drupal 8 media news!

Planet Drupal - Wed, 2016/02/10 - 5:10pm
A lot of exciting Drupal 8 media news!

Media made a big leap towards a first major milestone. It's time to test what we have and help stabilise it.

At the beginning of November 2015 MD Systems announced the Media initiative program that they initiated in cooperation with Ringier, Gassmann media and Südostschweiz. Initiative was kicked off with a week long sprint, which happened at first week of December in Zurich. Work didn't end when sprint was over. Together with the team at MD Systems I continued to work on most important tasks to achieve a major milestone.

Photo by Stefanie Gupta

Note nr. 1: MD Systems are funding part of my time to work on Drupal 8 media. They are constantly investing in Drupal core and many contrib modules. They are one of the greatest Drupal service providers and number 1 Drupal organizational contributor taking their size into consideration. You need a site built? You should definitely get in touch with them.

Note nr. 2: Examiner.com (my employer and very well know enterprise Drupal 7 site) gives every developer a so-called "Drupal day" every other week. This allows me to work on Drupal 8 media components. We have been working on a Drupal 8 project for a while now, which also allowed me to do a lot of contrib work during my work hours. Thank you! You are great!

Since my last post we did a ton of work in many areas. Let me quickly list most important ones:

  1. Image cropping: We added few more features to Crop API. Image widget crop used those to provide new features such as soft and hard crop size limits, handling of default crops and ability to use cropper tool outside of field widget context. This allowed us to add cropper tool to the file edit form that File entity provides. Image widget crop was also promoted to a full project on drupal.org. We also started working on Crop API integration for Focal point module, which is very close to be committed. This will bring even more standardization in this area, which is something we are very excited about.

  2. File entity: we managed to bring this important module to the level where we can confidently say that it has reached feature parity with Drupal 7 version. This allowed us to bring it back home (to drupal.org) and make -dev version available on the project page.

  3. Entity browser: we continued our work on the configuration UI. Patch is almost ready. We need few more people to help us with testing and reviews. I hope that we will be able to commit it in the next week or so. We also added new selection display plugin which supports multi-step workflow (upload few images, select few more from media library, import some more from a 3rd parts service, save everything in one step). This allows us to build content creation experiences that we never saw in Drupal core or contrib before. Plugin could use some visual improvements. This is great introductionary task for any themers and/or frontend develpers that would like to join us. Get in touch!

  4. Image effects: together with @mondrake we started new project that will become home for majority of image effects that didn't find it's way into core. We already ported most of effects from ImageCache actions and added few more that lived in other Drupal 7 modules. Effects that are currently available in Image effects module are: watermark, auto orientation, brightness, color shift, contrast, set canvas and strip metadata. There is also text overlay effect that is waiting to be reviewed and tested.

There are many other things in different areas of the ecosystem. We fixed bugs and added features in Media entity, Field formatter, Inline entity form, Entity embed, ...

What is next

In the course of the next few weeks we need to review and commit remaining patches. After that we'd like to tag new releases for most of the modules in the ecosystem. This will encourage people to start actively using and testing them.

Media ecosystem for Drupal 8 is not perfect yet, but we are able to support more and more use cases. Testing, finding bugs and fixing them in a timely manner should be our priority at this point. We want to stabilize the ecosystem to allow our users to rely on our components.

How to help?

Start contributing. You can write documentation, test modules in the ecosystem and report bugs, fixing bugs or work on new features, design UX, write automated tests, share ideas and much, much more. You have a skill, we have a task for you.

We are available on IRC. Join us on #drupal-media channel on Freenode.net and get involved. We always publish general announcements on groups.drupal.org/media.

If you prefer more personal communication you can always ping me on Twitter (@slashrsm) or use the contact form on my blog to get in touch.

About me

I (Janez Urevc - @slashrsm) am one of the architects and maintainers of the media ecosystem for Drupal 8. If you like what I am doing please consider donating to my Bitcoin address: 1Xqe6gYWEbF1iKsy3Mr5SbAyebNyucj5t.

Together with some colleagues I'm building a small team of professionals that will be providing top-level consulting, training and development related to media in Drupal 8. If you're interested or you'd like to work with us please get in touch.

slashrsm Wed, 10.02.2016 - 17:10 Tags Drupal Media Enjoyed this post? There is more! Zurich Drupal 8 media sprint was a success! When will media be ready for Drupal 8?

View the discussion thread.


Mediacurrent: Drupal Bits and Bytes: How to Add Content in an Update Hook

Planet Drupal - Wed, 2016/02/10 - 4:22pm
Why would I want to add content in an update hook?

Lullabot: The Uncomplicated Firewall

Planet Drupal - Wed, 2016/02/10 - 2:37pm

Firewalls are a tool that most web developers only deal with when sites are down or something is broken. Firewalls aren’t fun, and it’s easy to ignore them entirely on smaller projects.

Part of why firewalls are complicated is that what we think of as a "firewall" on a typical Linux or BSD server is responsible for much more than just blocking access to services. Firewalls (like iptables, nftables, or pf) manage filtering inbound and outbound traffic, network address translation (NAT), Quality of Service (QoS), and more. Most firewalls have an understandably complex configuration to support all of this functionality. Since firewalls are dealing with network traffic, it’s relatively easy to lock yourself out of a server by blocking SSH by mistake.

In the desktop operating system world, there has been great success in the "application" firewall paradigm. When I load a multiplayer game, I don’t care about the minutiae of ports and protocols - just that I want to allow that game to host a server. Windows, OS X, and Ubuntu all support application firewalls where applications describe what ports and protocols they need open. The user can then block access to those applications if they want.

Uncomplicated Firewall (ufw) is shipped by default with Ubuntu, but like OS X (and unlike Windows) it is not turned on automatically. With a few simple commands we can get it running, allow access to services like Apache, and even add custom services like MariaDB that don’t ship with a ufw profile. UFW is also available for other Linux distributions, though they may have their own preferred firewall tool.

Before you start

Locking yourself out of a system is a pain to deal with, whether it’s lugging a keyboard and monitor to your closet or opening a support ticket. Before testing out a firewall, make sure you have some way to get into the server should you lock yourself out. In my case, I’m using a LAMP vagrant box, so I can either attach the Virtualbox GUI with a console, or use vagrant destroy / vagrant up to start clean. With remote servers, console access is often available through a management web interface or a "recovery" SSH server like Linode’s Lish.

It’s good to run a scan on a server before you set up a firewall, so you know what is initially being exposed. Many services will bind to ‘localhost’ by default, so even though they are listening on a network port they can’t be accessed from external systems. I like to use nmap (which is available in every package manager) to run port scans.

$ nmap Starting Nmap 6.40 ( http://nmap.org ) at 2015-09-02 13:16 EDT Nmap scan report for trusty-lamp.lan ( Host is up (0.0045s latency). Not shown: 996 closed ports PORT STATE SERVICE 22/tcp open ssh 80/tcp open http 111/tcp open rpcbind 3306/tcp open mysql Nmap done: 1 IP address (1 host up) scanned in 0.23 seconds

Listening on for SSH and HTTP connections makes sense, but we probably don’t need rpcbind (for NFS) or MySQL to be exposed.

Turning on the firewall

The first step is to tell UFW to allow SSH access:

$ sudo ufw app list Available applications: Apache Apache Full Apache Secure OpenSSH $ sudo ufw allow openssh Rules updated Rules updated (v6) $ sudo ufw enable Command may disrupt existing ssh connections. Proceed with operation (y|n)? y Firewall is active and enabled on system startup $ sudo ufw status Status: active To Action From -- ------ ---- OpenSSH ALLOW Anywhere OpenSSH (v6) ALLOW Anywhere (v6)

Test to make sure the SSH rule is working by opening a new terminal window and ssh’ing to your server. If it doesn’t work, run sudo ufw disable and see if you have some other firewall configuration that’s conflicting with UFW. Let’s scan our server again now that the firewall is up:

$ nmap Starting Nmap 6.40 ( http://nmap.org ) at 2015-09-02 13:31 EDT Note: Host seems down. If it is really up, but blocking our ping probes, try -Pn Nmap done: 1 IP address (0 hosts up) scanned in 3.07 seconds

UFW is blocking pings by default. We need to run nmap with -Pn so it blindly checks ports.

$ nmap -Pn Starting Nmap 6.40 ( http://nmap.org ) at 2015-09-02 13:32 EDT Nmap scan report for trusty-lamp.lan ( Host is up (0.00070s latency). Not shown: 999 filtered ports PORT STATE SERVICE 22/tcp open ssh Nmap done: 1 IP address (1 host up) scanned in 6.59 seconds

Excellent! We’ve blocked access to everything but SSH. Now, let’s open up Apache.

$ sudo ufw allow apache Rule added Rule added (v6)

You should now be able to access Apache on port 80. If you need SSL, allow "apache secure" as well, or just use the “apache full” profile. You’ll need quotes around the application name because of the space.

To remove a rule, prefix the entire rule you created with "delete". To remove the Apache rule we just created, run sudo ufw delete allow apache.

Blocking services

UFW operates in a "default deny" mode, where incoming traffic is denied and outgoing traffic is allowed. To operate in a “default allow” mode, run sudo ufw default allow. After running this, perhaps you don’t want Apache to be able to listen for requests, and only want to allow access from localhost. Using ufw, we can deny access to the service:

$ sudo ufw deny apache Rule updated Rule updated (v6)

You can also use "reject" rules, which tell a client that the service is blocked. Deny forces the connection to timeout, not telling an attacker that a service exists. In general, you should always use deny rules over reject rules, and default deny over default allow.

Address and interface rules

UFW lets you add conditions to the application profiles it ships with. For example, say you are running Apache for an intranet, and have OpenVPN setup for employees to securely connect to the office network. If your office network is connected on eth1, and the VPN on tun0, you can grant access to both of those interfaces while denying access to the general public connected on eth0:

$ sudo ufw allow in on eth1 to any app apache $ sudo ufw allow in on tun0 to any app apache

Replace from <interface> with on <address> to use IP address ranges instead of interface names.

Custom applications

While UFW lets you work directly with ports and protocols, this can be complicated to read over time. Is it Varnish, Apache, or Nginx that’s running on port 8443? With custom application profiles, you can easily specify ports and protocols for your own custom applications, or those that don’t ship with UFW profiles.

Remember up above when we saw MySQL (well, MariaDB in this case) listening on port 3306? Let’s open that up for remote access.

Pull up a terminal and browse to /etc/ufw/applications.d. This directory contains simple INI files. For example, openssh-server contains:

[OpenSSH] title=Secure shell server, an rshd replacement description=OpenSSH is a free implementation of the Secure Shell protocol. ports=22/tcp

We can create a mariadb profile ourselves to work with the database port.

[MariaDB] title=MariaDB database server description=MariaDB is a MySQL-compatible database server. ports=3306/tcp $ sudo ufw app list Available applications: Apache Apache Full Apache Secure MariaDB OpenSSH $ sudo ufw allow from to any app mariadb

You should now be able to access the database from any address on your local network.

Debugging and backup

Debugging firewall problems can be very difficult, but UFW has a simple logging framework that makes it easy to see why traffic is blocked. To turn on logging, start with sudo ufw logging medium. Logs will be written to /var/log/ufw.log. Here’s a UFW BLOCK line where Apache has not been allowed through the firewall:

Jan 5 18:14:50 trusty-lamp kernel: [ 3165.091697] [UFW BLOCK] IN=eth2 OUT= MAC=08:00:27:a1:a3:c5:00:1e:8c:e3:b6:38:08:00 SRC= DST= LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=65499 DF PROTO=TCP SPT=41557 DPT=80 WINDOW=29200 RES=0x00 SYN URGP=0

From this, we can see all of the information about the source of the request as well as the destination. When you can’t access a service, this logging makes it easy to see if it’s the firewall or something else causing problems. High logging can use a large amount of disk space and IO, so when not debugging it’s recommended to set it to low or off.

Once you have everything configured to your liking, you might discover that there isn’t anything in /etc with your rules configured. That’s because ufw actually stores its rules in /lib/ufw. If you look at /lib/ufw/user.rules, you’ll see iptables configurations for everything you’ve set. In fact, UFW supports custom iptables rules too if you have one or two rules that are just too complex for UFW.

For server backups, make sure to include the /lib/ufw directory. I like to create a symlink from /etc/ufw/user-rules to /lib/ufw. That way, it’s easy to remember where on disk the rules are stored.

Next steps

Controlling inbound traffic is a great first step, but controlling outbound traffic is better. For example, if your server doesn’t send email, you could prevent some hacks from being able to reach mail servers on port 25. If your server has many shell users, you can prevent them from running servers without being approved first. What other security tools are good for individual and small server deployments? Let me know in the comments!


OpenLucius: 18 Drupal SEO modules - and tools for better findability in Google

Planet Drupal - Wed, 2016/02/10 - 2:32pm

Search engine optimization (SEO) has always been important, but in recent years its importance seems to have increased significantly. We were more often dealing with Drupal SEO implementations than in previous years. Many of the implementations contained overlapping components. Below we will discuss the most important ones:


Dries Buytaert: Turning Drupal outside-in

Planet Drupal - Wed, 2016/02/10 - 11:49am

There has been a lot of discussion around the future of the Drupal front end both on Drupal.org (#2645250, #2645666, #2651660, #2655556) and on my blog posts about the future of decoupled Drupal, why a standard framework in core is a good idea, and the process of evaluating frameworks. These all relate to my concept of "progressive decoupling", in which some portions of the page are handed over to client-side logic after Drupal renders the initial page (not to be confused with "full decoupling").

My blog posts have drawn a variety of reactions. Members of the Drupal community, including Lewis Nyman, Théodore Biadala and Campbell Vertesi, have written blog posts with their opinions, as well as Ed Faulkner of the Ember community. Last but not least, in response to my last blog post, Google changed Angular 2's license from Apache to MIT for better compatibility with Drupal. I read all the posts and comments with great interest and wanted to thank everyone for all the feedback; the open discussion around this is nothing short of amazing. This is exactly what I hoped for: community members from around the world brainstorming about the proposal based on their experience, because only with the combined constructive criticism will we arrive at the best solution possible.

Based on the discussion, rather than selecting a client-side JavaScript framework for progressive decoupling right now, I believe the overarching question the community wants to answer first is: How do we keep Drupal relevant and widen Drupal's adoption by improving the user experience (UX)?

Improving Drupal's user experience is a topic near and dear to my heart. Drupal's user experience challenges led to my invitation to Mark Boulton to redesign Drupal 7, the creation of the Spark initiative to improve the authoring experience for Drupal 8, and continued support for usability-related initiatives. In fact, the impetus behind progressive decoupling and adopting a client-side framework is the need to improve Drupal's user experience.

It took me a bit longer than planned, but I wanted to take the time to address some of the concerns and share more of my thoughts about improving Drupal's UX (and JavaScript frameworks).

To iterate or to disrupt?

In his post, Lewis writes that the issues facing Drupal's UX "go far deeper than code" and that many of the biggest problems found during the Drupal 8 usability study last year are not resolved with a JavaScript framework. This is true; the results of the Drupal 8 usability study show that Drupal can confuse users with its complex mental models and terminology, but it also shows how modern features like real-time previews and in-page block insertion are increasingly assumed to be available.

To date, much of our UX improvements have been based on an iterative process, meaning it converges on a more refined end state by removing problems in the current state. However, we also require disruptive thinking, which is about introducing entirely new ideas, for true innovation to happen. It's essentially removing all constraints and imagining what an ideal result would look like.

I think we need to recognize that while some of the documented usability problems coming out of the Drupal 8 usability study can be addressed by making incremental changes to Drupal's user experience (e.g. our terminology), other well-known usability problems most likely require a more disruptive approach (e.g. our complex mental model). I also believe that we must acknowledge that disruptive improvements are possibly more impactful in keeping Drupal relevant and widening Drupal's adoption.

At this point, to get ahead and lead, I believe we have to do both. We have to iterate and disrupt.

From inside-out to outside-in

Let's forget about Drupal for a second and observe the world around us. Think of all the web applications you use on a regular basis, and consider the interaction patterns you find in them. In popular applications like Slack, the user can perform any number of operations to edit preferences (such as color scheme) and modify content (such as in-place editing) without incurring a single full page refresh. Many elements of the page can be changed without the user's flow being interrupted. Another example is Trello, in which users can create new lists on the fly and then add cards to them without ever having to wait for a server response.

Contrast this with Drupal's approach, where any complex operation requires the user to have detailed prior knowledge about the system. In our current mental model, everything begins in the administration layer at the most granular level and requires an unmapped process of bottom-up assembly. A user has to make a content type, add fields, create some content, configure a view mode, build a view, and possibly make the view the front page. If each individual step is already this involved, consider how much more difficult it becomes to traverse them in the right order to finally see an end result. While very powerful, the problem is that Drupal's current model is "inside-out". This is why it would be disruptive to move Drupal towards an "outside-in" mental model. In this model, I should be able to start entering content, click anything on the page, seamlessly edit any aspect of its configuration in-place, and see the change take effect immediately.

Drupal 8's in-place editing feature is actually a good start at this; it enables the user to edit what they see without an interrupted workflow, with faster previews and without needing to find what thing it is before they can start editing.

Making it real with content modeling

Eight years ago in 2007, I wrote about a database product called DabbleDB. I shared my belief that it was important to move CCK and Views into Drupal's core and learn from DabbleDB's integrated approach. DabbleDB was acquired by Twitter in 2010 but you can still find an eight-year-old demo video on YouTube. While the focus of DabbleDB is different, and the UX is obsolete, there is still a lot we can learn from it today: (1) it shows a more integrated experience between content creation, content modeling, and creating views of content, (2) it takes more of an outside-in approach, (3) it uses a lot less intimidating terminology while offering very powerful capabilities, and (4) it uses a lot of in-place editing. At a minimum, DabbleDB could give us some inspiration for what a better, integrated content modeling experience could look like, with the caveat that the UX should be as effortless as possible to match modern standards.

Other new data modeling approaches with compelling user experiences have recently entered the landscape. These include back end-as-a-service (BEaaS) solutions such as Backand, which provides a visually clean drag-and-drop interface for data modeling and helpful features for JavaScript application developers. Our use cases are not quite the same, but Drupal would benefit immensely from a holistic experience for content modeling and content views that incorporates both the rich feature set of DabbleDB and the intuitive UX of Backand.

This sort of vision was not possible in 2007 when CCK was a contributed module for Drupal 6. It still wasn't possible in Drupal 7 when Views existed as a separate contributed module. But now that both CCK and Views are in Drupal 8 core, we can finally start to think about how we can more deeply integrate the two. This kind of integration would be nontrivial but could dramatically simplify Drupal's UX. This should be really exciting because so many people are attracted to Drupal exactly because of features like CCK and Views. Taking an integrated approach like DabbleDB, paired with a seamless and easy-to-use experience like Slack, Trello and Backand, is exactly the kind of disruptive thinking we should do.

What most of the examples above have in common are in-place editing, immediate previews, no page refreshes, and non-blocking workflows. The implications on our form and render systems of providing configuration changes directly on the rendered page are significant. To achieve this requires us to have robust state management and rendering on the client side as well as the server side. In my vision, Twig will provide structure for the overall page and non-interactive portions, but more JavaScript will more than likely be necessary for certain parts of the page in order to achieve the UX that all users of the web have come to expect.

We shouldn't limit ourselves to this one example, as there are a multitude of Drupal interfaces that could all benefit from both big and small changes. We all want to improve Drupal's user experience — and we have to. To do so, we have to constantly iterate and disrupt. I hope we can all collaborate on figuring out what that looks like.

Special thanks to Preston So and Kevin O'Leary for contributions to this blog post and to Wim Leers for feedback.