Planet Drupal

Subscribe to flux Planet Drupal - aggregated feeds in category Planet Drupal
Mis à jour : il y a 30 min 50 sec

Théodore 'nod_' Biadala: Progressive Web Apps for the masses

lun, 28/03/2016 - 20:42

Much like web components, progressive web apps (PWA) refers to a set of browser features designed to allow websites to behave more like native applications on mobile devices. As far as features are concerned we’re talking about: Offline, OS integration, push notifications, and background synchronization. To control those features the relatively new serviceworker API is provided, with which the addition of a manifest file will make the website installable on some devices.

HTTPS is required for serviceworker to be available, let's encrypt can help with that1

Offline & caching

Good rule of thumb: if the browser implement serviceworker it can do offline, and choose how it’s done, much better than the old ApplicationCache. This is possible because serviceworker acts as a proxy for all requests made from the website: requesting an image? a CSS file? some Ajax request? all going through the serviceworker. Controlling requests means controlling responses: their origin (cache or network) and their contents. Any request or response can be altered, redirected or replaced. One obvious benefit is that any response can be put in cache. When the user is offline and his request fails, he’ll see a fallback page instead.

Let’s take an example: You’re preparing for an event, browsing the conference website. The website uses a serviceworker that cache all visited pages as well as a few extra pages in the background, such as the schedule page and the homepage. When the network during the event inevitably goes down, the schedule can still be accessed. And when an unseen page is requested, the serviceworker can catch the failing request and serve a default offline page, which is better than a browser error.

Another issue that come up every once in a while is websites failing to load because one third party asset used for ads or analytics is down. Twitter down? page down. To prevent this all third party assets can be served from cache, or there can be a timeout after which a cached version of the asset — or nothing at all — will be served. The serviceworker can enforce a timeout for network events as short as needed regardless of browser or server settings. Want your page to load under 300ms? As long as it doesn’t matter what it looks like, it’s possible.

Another example is if your users are in an area where data is expensive, a very aggressive caching strategy can be put in place: fetching all required assets when the serviceworker is installed and only allowing document requests to hit the networks. Fonts, images, CSS and JS will always come from cache. There are many strategies on how to handle requests, I would point to the very well made offline cookbook for a good idea of what’s possible. In a follow-up post I’ll talk about a strategy that should suit CMSs, based around the type of resource requested.

OS integration

Creating a manifest file — a json file with a handful of keys — and linking to it through a meta tag is the only thing needed on top of a serviceworker to be able to install a website like an app on android and using chrome. Once the website is installed an icon is placed at the same level as the other apps and will open a standalone browser window — which can be configured to open fullscreen without the URL bar. For now it only works on Android using the Chrome browser but there is potential.

For our conference website what we want is a manifest file that will tell android to use the event logo as an icon and make the schedule page the default when opening the website from the new shortcut. The install bar shows up under certain conditions, these days a website needs to be opened twice in under 5 min for the install bar to show up. Chrome controls when it shows up, there is no API to force it to show, thankfully. There is one to prevent the install bar from appearing though.

Extras Push notifications

I won’t talk about the lifecycle of a serviceworker here, for now just keep in mind that once the browser is closed, the serviceworker is still active and can receive server events. With OS integration of push notifications it means messages can be sent to users even when the website is closed. On the user side the notification will appear like any other app notification.

This is still early days for this feature. For Chrome their push server has to be used to send messages, while Firefox has it’s own (and open) server implementation. Eventually once the W3C get a spec sorted out things should improve. To see it in action check out the push notification demo, and the more up to date push notification tutorial.

Background sync

Another exicing feature, even less ready than notifications, no demos are in working order yet. Now that the user can access our conference website offline, he might want to rate the sessions while taking the train home. With background sync all his ratings can be logged and once back online, the event queue can be replayed to save all his feedback.

Some technical details
  • To implement serviceworker a browser needs fetch and Promise APIs, and when they have it, they also have most ES6 features implemented as well. In the serviceworker scope, modern JS can be used without breaking anything, no build tool required.

  • On the implementation, Chrome is leading the charge followed closely by Firefox. The others are showing an interest with Edge having started implementation, Safari plans are unknown but at least they didn’t say no, and I couldn’t find infos on UC Browser plans. There are more details about which browser implement which subset on Is Serviceworker Ready?


The exicing part of PWAs for me is not the app part. I don’t care about the competition of native vs. web apps, it’s probably going to end up like flash, and I’m betting on the web however long it’ll take. What’s exciting is the amount of control we now have on page loading and the control we keep on our websites once users are out of reach.

Want to make a page that self-destruct after 5 min of a user being offline? It’s possible.


Being a Drupal developer and Drupal being a CMS that would hugely benefit from this kind of feature2, I wrote the Progressive web app module that currently implements the Offline and OS integration part of this blog post. The code is still rough but working. A demo of the Drupal PWA can be seen on the “conference website”, to fully appreciate it turn on airplaine mode once it’s been loaded.

A more technical post is coming, presenting code from the pwa module that is needed to make all this work in real life. Also some feedback and tips for developing with serviceworker since things gets very weird, very fast when your async javascript proxy is acting up.

  1. How funny would it be that let's encrypt is already compromised by the NSA? Anyone else thinking of The Wire and the police selling burner phones to suspects?

  2. I said on twitter that this was bigger than frontend frameworks for Drupal, and still think that. Using frameworks can help PWAs compete with native but it's not required and, to me, not even the point. PWAs are about mobile and offline, I like that it gets us back to the mobile-first mentality that was there for most of Drupal 8 development cycle. PWAs allows us to explore new grounds that are relevant for all types of users. It's not just one subset of the community that will eventually benefit.

Catégories: Elsewhere

FFW Agency: MidCamp Recap, the Future of Drupal’s Frontend, and the Importance of Events

lun, 28/03/2016 - 19:43
MidCamp Recap, the Future of Drupal’s Frontend, and the Importance of Events David Hernandez Mon, 03/28/2016 - 17:43

I’m often asked why we bother with Drupal camps, conferences, meetups, etc. Being the prime sponsor of every DrupalCamp New Jersey, a repeated DrupalCon Diamond sponsor, hosting monthly coworking events in our New Jersey office, and the countless free community trainings we provide, FFW has a solid history of supporting in-person events. But, what is the point?

After all, we live in the world of tomorrow, where the internet connects us all. Our code is online, email has replaced letters, I use my laptop to make phone calls, online forums have long-term discussions, chat programs have real-time discussions. We’ve surely evolved beyond needing physical space, and wasting time and money on transportation.

Well, a funny thing happened this year at MidCamp (which FFW sponsored.) In this person’s opinion, a bunch of people started feeling a lot less bad about Drupal’s future.


For the past couple years I’ve been heavily involved in Drupal 8’s theme system. Though I feel most of my contributions are small compared to the work done by some others, I try to stay involved and as informed as possible. It is hugely important to know where things are, and where they are going.

I can testify to the amount of energy and enthusiasm that existed in Drupal’s frontend community after Drupal 8’s release. Many of the problems that plagued Drupal themers were solved, and people were looking forward to this new world of sensible theming. Things were looking bright, for once. Until…


In December, not long after Drupal 8’s release, Dries Buytaert published a blog post about decoupling Drupal’s frontend and selecting a JavaScript framework to do it with. This was met with excitement by some, including absolutely no one actually involved in Drupal’s theme system. Saying this whole discussion was deflating invokes imagery of a gradually shrinking balloon. Instead, you need to imagine a pin involved.

I won’t get into the pros and cons of decoupling, various frameworks, and what I or other people think about it. Lots of that discussion is happening all over the Drupal internet. Instead, I'll to stick to my point about events.

At DrupalCampNJ I met Preston So, an Acquia employee who has been on a literal world tour discussing decoupling Drupal. A number of other frontend contributors were there and we had a good discussion about what this all means and the different problems we need to tackle. You can find a recording of that discussion online.

I mentioned that many of us will all be at MidCamp, including a number of theme system, and base theme, maintainers, (myself included.) Sounds like a perfect opportunity to meet. Indeed, it was.


Preston presented a session on decoupling, and organized a BoF to dicsuss matters further. Towards the end of the camp there were many one-on-one and large roundtable discussions about the problems we all see in Drupal’s theme system, and how we might re-imagine it.

Much of the trepidation began to subside, and we started coming up with ideas and plans to move things forward. By Saturday, user personas were being hashed out, roadmaps were in the works, and call it Pollyanna, but I felt a lot more enthusiasm leaving Chicago than arriving.

Peoples is Peoples

As Pete once said, peoples is peoples, and so is Drupal. Regardless of how you feel about the Drupal community, other open-source communities, or even corporations, every product contains the fingerprints of the people that make it.

While technology is amazing, and capable of so many things, we still haven’t replaced the value of face-to-face interaction. I’m not sure we ever will. Online we are confusing, dismissive, quick to judgement, and impatient. In person, we are remarkably capable of finding common ground. We slow down. We empathize. We listen. We are reminded once again that we’re dealing with real people.

We are reminded while having lunch. We are reminded while sipping coffee and chatting in the hallway. We are reminded while discussing ideas over dinner with friends. We are reminded in those moments not crammed into little one hour time slots, where we can relax and breathe. And that’s why these events matter. That’s the point.

For more on the future of Drupal's frontend

If you are curious about the future of Drupal’s frontend, and even want to help, you can do so online and in person. There is a new Slack channel for everything frontend Drupal, a Google doc that summaries some of these discussions (Thanks to Chris Weber and Marc Drummond,) and we’re looking to hold a couple of events during DrupalCon New Orleans. Keep a look out for that.

Also, take a look at Marc Drummond's post-MidCamp writeup for more on the technical details surrounding the future of Drupal's frontend.

Tagged with Comments
Catégories: Elsewhere

Acquia Developer Center Blog: Using Block Visibility Groups to Create Conditional Layouts in Drupal 8

lun, 28/03/2016 - 16:05

Recently I had a customer ask me how to tell Drupal 8 to display certain blocks conditionally, based on whether or not the node page being viewed referenced certain taxonomy terms. In Drupal 7 I would have recommended the Context module for this, but as it’s not yet ready for Drupal 8 I had to go looking for other options.

My search led me fairly quickly to the brand-new Block Visibility Groups module, which aims to provide the same sort of conditional block visibility functionality that Context provides, but in a manner that integrates more closely with the core Block UI. It works well, but doesn’t natively provide support for basing visibility off of node field data (such as taxonomy term references). However, since Block Visibility Groups uses the core D8 Condition plugin type to define its conditions, all that’s needed is to implement a custom plugin to get the desired behavior. Here’s how it works, from start to finish:

Tags: acquia drupal planetdrupal 8blockspluginsconditions
Catégories: Elsewhere

Evolving Web: Migrate for Site Builders: Getting Your Content into Drupal

lun, 28/03/2016 - 16:01
Migrate for Site Builders: Getting Your Content into Drupal Suzanne Kenned… Mon, 03/28/2016 - 10:01
Catégories: Elsewhere Simplify Drupal 8 field value calls

lun, 28/03/2016 - 06:00
Things change, it's a fact of life; even more so it's a fact of a web developer's life. In semantic versioned frameworks every new major version brings new api and discards the old apis. Like ripping off a band-aid, this is an excruciatingly painful experience that will eventually bring forward a less painful future. Thus, it has been with the change from Drupal 7 to Drupal 8.x. Get the title...
Catégories: Elsewhere

Danny Englander: Drupal 8 Theming: How to Set Custom HTML Classes in a Block Region

dim, 27/03/2016 - 19:27

Now that I'm digging into Drupal 8 theming and its awesomeness, I'm discovering some really useful methods and functions. At the same time, I'm learning a lot and having fun.

In this post I'll show you how you can set a custom HTML class within a block region. I'll be doing this in a sub-theme that uses Drupal 8's Classy as a base-theme.

Our use case is that there are three "preface" block regions defined in a Classy sub-theme, "First", "Second", and "Third." When these regions render as HTML, Classy gives them one common class called region. We'd like to have something more specific such as region-preface that can be used as a class for theming any of these preface regions.

Getting started, examine the array

The first thing to do is enable Devel Kint to examine the block region array. Kint is part of the Devel module and you can either download it from or use Drush. Right now, Devel for Drupal 8 is available as a dev release; using drush we can download and enable it using these commands.

drush dl devel-8.x-1.x-dev -y drush en kint -y

Next, I'll add a template_preprocess_region in my sub-theme's .theme file and kint() the vars to see what's going on. In some cases, using kint right in a Twig template works well but in this case, you'll get much more info by using it as we do below in our .theme file.

function mysubtheme_preprocess_region(&$vars) { kint($vars); }

Once I do this, I run a drush cr and reload the page that has one of my preface regions on it. Here I see the array path to the region name and it's elements > #region.

So now in our preprocess region I can define that array path.

function mysubtheme_preprocess_region(&$vars) { $region = $vars['elements']['#region']; }

Note, you can also look in core's file to see how the region variables are defined and when I do that, I see something pretty similar to the above:

$variables['region'] = $variables['elements']['#region'];

The next thing I am going to do is create an array of my three preface regions that have already been defined in the theme:

$region_preface = array ( 'preface_first', 'preface_second', 'preface_third', );

Now that I define the array, I will set a common class for these three regions:

if (in_array($region, $region_preface)) { $vars['attributes']['class'][] = 'region--preface'; } Putting it all together function mysubtheme_preprocess_region(&$vars) { $region = $vars['elements']['#region']; $region_preface = array ( 'preface_first', 'preface_second', 'preface_third', ); if (in_array($region, $region_preface)) { $vars['attributes']['class'][] = 'region--preface'; } } Alternate Method using Twig set classes = []

One other way to set a custom class is to use the new set classes = [] method in a Twig template. So instead of setting the class in the .theme file, we'll create a variable for use in Twig.

if (in_array($region, $region_preface)) { $vars['region_preface'] = 'region--preface'; }

To make use of this variable, I've already gone ahead and copied Classy's region.html.twig into my sub-theme's template folder. I generally keep the same template folder structure in my sub-theme that classy gives you which looks something like this:

|____templates | |____block | |____content | |____content-edit | |____dataset | |____field | |____form | |____layout | |____misc | |____navigation | |____user | |____views

Now in my region.html.twig, I look for this existing code:

{% set classes = [ 'region', 'region-' ~ region|clean_class, ] %}

Now I'll add my variable in that we .

{% set classes = [ 'region', 'region-' ~ region|clean_class, region_preface|clean_class, ] %}

Of note above is clean_class which "prepares a string for use as a valid HTML class name." In other words, it removes invalid characters from our HTML classes so they render in a nice manner. We don't really need it here but it's nice to have and get used to using.

With either method above, be sure to run a drush cr and reload your page. The HTML output should look something like this.

<div class="region region-preface-first region--preface">

Now we can utilize the new common class region--preface for theming all preface regions with common attributes.


The above tutorial starts to give us a little insight into Drupal 8 theming. As with all things Drupal, there are often several ways to do the same task so by no means are the methods above definitive. In a future post, I'll expand on this a bit and add a class based on a variable value.

  • Drupal 8
  • Twig
  • Theming
  • Drupal Planet
Catégories: Elsewhere

Another Drop in the Drupal Sea: Drupal Chat: Is the Drupal project a meritocracy?

dim, 27/03/2016 - 15:56

On more than one occasion I've heard a person (such as Angie Byron) say that Drupal is a meritocracy. I've also heard Drupal described as a "do-it-ocracy." What do these things mean? Are they true?

Join me live this Monday at 1PM (GMT -0600) to share your questions and thoughts. As always, it's totally free to attend. You can participate by signing in with your twitter account or you can watch anonymously without signing in at all.

Catégories: Elsewhere

DrupalEasy: Florida DrupalCamp 2016 Wins and Losses

sam, 26/03/2016 - 21:56

A few weeks ago, the Florida Drupal community (and more than a few honored out-of-town guests) gathered together for our annual event. This was the 8th Florida DrupalCamp, so the camp definitely had a familiar feel. As we normally do, we like to take a close look back and discuss what worked, what didn't, and how we can improve future events. 

This year's event was smaller than previous years - we had approximately 40 fewer attendees (216 total) that last year. The general feeling is that this was due to a few factors, including our own laziness (we didn't get the camp site up until after the new year), our lack to marketing outside of the Drupal community, and (most worrisome) perhaps the fact that Drupal 8 has the perception of being more for larger organizations than for sites of all sizes.

After the conclusion of the event, we sent out an email to our entire email list - not just those that attended, asking them to complete a post-camp survey. We did this so that we could find out why people didn't attend, as well as get feedback from those that did attend. We had about a 25% response rate on the survey. 

For those that didn't attend, we were relieved to find out that no one who completed a survey indicated that the cost of the camp ($35) was a deciding factor. 

For those that did attend, curiously, the vast majority who completed the survey were already established in the Drupal community (more than 2 years experience, had attended a previous Drupal event, used Drupal daily, did not attend the beginner track) - very few beginners completed the survey, and we're not exactly sure why, considering that our beginner track was overflowing.


Getting back to our laziness, for the most part, it was the same set of organizers (minus a few) who organized this year's edition of the camp. It was the same venue, the same caterer, the same web site; most everything was a carbon copy of our (highly regarded) 2015 camp. Perhaps a bit of overconfidence set in, and we didn't really get things rolling until after the new year. We learned our lesson, and have set a goal of a having next year's site ready to accept registrations four months prior to the event.

Additionally, we've already begun the process of securing a venue for next year's event. By locking it in early, some of the pressure will be off the organizers as we get closer to next year's event.


Overall, the survey and anecdotal evidence indicate that the camp was a success. Sessions were strong, lunch was (again) a hit, the price was right, and our swag is second to none. It wasn't perfect (see the next section below), but our focus on the fundamentals (good people, good sessions, good food) has served us well. 

We do things a little differently than most camps when it comes to a keynote speaker. We have three. Rather than call them keynote speakers, we call them "featured speakers" and ask them to give double-length sessions so that our attendees can dive deep. This year's featured speakers were clearly well-received, as the top two "most favorite" sessions (according to the survey) were both featured speakers. Even more encouraging was that fact that no single session received more than one "least favorite" session vote on the survey. Overall 90% of the survey respondents rated the sessions "very good" or "excellent". 


With all the love for the sessions, swag, and food, we definitely have some things to work on for next year. 

While we made a mention of our Code of Conduct in the opening session, we had feedback that we didn't provide enough information on the process. We were a little too informal with how we mentioned it - in the future, we will be much more proactive and process-oriented in letting everyone know what to do if they see inappropriate behavior. 

As mentioned above, we didn't do a very good job this year marketing the camp outside of the Drupal community. With fewer organizers this year, everyone was stretched a little farther, and this task fell through the cracks. We discussed finding a new volunteer dedicated to helping us focus on reaching folks outside of our community. 

It took us more than a week to get our survey out. That is too long, and may be a contributing factor as to why our results are skewed towards experienced Drupalists. Next year, our goal is to have the survey ready to be announced at the closing session. 

We are extremely lucky to have such a great venue partner in Florida Technical College. They make it very easy for us to have our event there, but unfortunately, there are also some challenges. We only have access to two rooms that hold more than 25 people, and those rooms have, in the past, been used by featured speakers and our (very popular) beginner track. That means that some popular sessions end up being packed (overflowing), which leads to some complaints. We're working on a plan to mitigate this in future camps. 

Perhaps nothing has been communicated to us more in the past few years that the need to record and post session videos. Unfortunately, we have been unable to find a volunteer to help organize and lead this effort. We are dedicated to making this happen. We have a plan to use Google Hangouts to minimize the process overhead, but we still need volunteers to help make it happen. 

Finally, while the number of sponsors was roughly the same as the 2015 camp, we were unable to secure a top-level sponsor. This resulted in us having our first-ever budget shortfall. Luckily, we've built up a nice nest egg, so it wasn't an issue, but we're curious if this is the start of a trend that we need to account for in future events. I'd love to hear some feedback from other camp organizers on this topic.

Things to consider for next year

So, with all this knowledge, how is it affecting our thinking/planning for our 2017 event? Each year, we ask ourselves if we should find a new venue. As I mentioned previously, our venue partner couldn't be easier to work with. They open up their facility to us, give us the run of the building, and attempt to meet our every request. The cost for this is virtually nothing other than paying for some extra security and custodial services. But, the facility has some inherent challenges for us, specifically in the size of the classrooms. Each year we discuss finding a new location, and each year it comes down to the same thing - all of the organizers are too busy to do the legwork of finding and securing a new venue that provides what we need without an outrageous increase in cost and/or hassle. So, until we find someone willing to do the legwork, or one of the existing organizers creates a time machine, it doesn't look like we're going anywhere. 

That doesn't mean that we're not looking to address some of the issues. For starters, we're looking at the possibility of moving to a two-day camp format. This will allow us to spread sessions out more, make better use of the available space, and provide flexible session lengths for presenters. These facts, combined with session recordings will hopefully move things in the right direction. 

Want to help?

Interested in getting involved in next year's event? Feel free to contact me directly, or check out our "lessons learned" wiki page and leave a comment there. We're committed to making this the best DrupalCamp anywhere, so join us for the ride!

Catégories: Elsewhere

Acquia Developer Center Blog: So how was it? Recent graduates talk about Acquia U

sam, 26/03/2016 - 12:56

I spoke with Matt Dooley and Colin Packenham at Acquia headquarters in downtown Boston about Acquia's tech bootcamp program, Acquia U. Both are career changers and were more or less new to Drupal when they got started with the program and I was interested to see what motivated them to make the change and dive into Drupal headfirst.

"Acquia U opened a very large door to a whole new career." - Matt Dooley.

Interview video - 17 min.

What were your expectations going in?

Colin: I do know how I felt when I accepted, which was vaguely numb and extremely excited. I was on a job beforehand that didn’t have any growth. It was very comfortable and very stable and I was very good at it, but it wasn’t something that was engaging me. At that point, I had stopped learning. That was something that I’m very interested in for my career: just being able to do more, to learn more, to experience more, to be challenged more, rather than just sort of the day-to-day-finish-my-work-go-home. So, getting into Acquia U was--I thought--one of the best possible steps I could have taken at that stage in my career.

Matt: Expectations were pretty well-laid out by Amy at that time. She had an initial call with me saying, "Don’t expect a job. Don’t expect to come and sit next to Dries and be buddies." When I found out I was accepted, I was crazy excited. I couldn’t believe ... I didn’t know what the level of competition was. So I was surprised, excited. And even if I wasn’t guaranteed at Acquia, I knew that just going through this training is gonna be a step to something else.

So how was it?

Colin: Overwhelming at first and then amazing. Thankfully, due to nature of it, how everyone was brought into Acquia U, we were all sort of overwhelmed together and were able to bond and grow out and experience the rest of the company. And then Acquia is such a collaborative arena where you can talk to anybody about more or less anything and you’ll get an answer or a redirection to somebody who does know the answer. And that helped immensely and it made a welcoming place and the place where, "Oh you don’t know the answer? Here, we’ll help you learn the answer and then you can tell somebody else who also doesn’t know it."

Matt: It was awesome. It was way better than I thought it was gonna be. Day one was, "What is Drupal?" and then day two was like, "Here’s how you build a module." It was fast paced but it was great. We had an awesome instructor and an awesome group of people that were in the program with me and awesome resources within the company itself.

Run us through a day at Acquia U.

Matt: Most of the days were--from about nine to 'lunchish'--straight up classroom training with the instructor going over whatever the topic was of the day. Then typically we had lab hours in the afternoon. It’s where we worked on our personal sites or the Acquia U website. Sometimes we’d have some assignments that we would try to complete, if we were in need of extra help somewhere.

Colin: The average day at Acquia U ... there’s two big average days. During the beginning we did a lot of study under Mike Anello, who runs the Drupal Easy Program. He was a big believer in having us learn for ourselves after he gave the explanation. So it was two to three hours of going through well thought-out – sort of a lecture setting and then we will be run off the range to learn more things. So we would spend the day [,for example,] learning about Views in Drupal and then the rest of the day we will be learning on Drupal with Views. We’d sort of the experimenting for ourselves. Usually, we would end up having one of the different – one of the various "Ubies" [ed: our affectionate, internal nickname for Acquia U students] do some sort presentation on it and then everyone would learn from each other rather than just straight through Mike.

The other average day was more during the second half, which is when we were actually building the u.acquia site. It was less lecture at that point and more ... everyone was working together as a team to produce this neat website together. There were bumps because there’s bumps in every project. We learned how to work together as a team; we learned how to reach out to other people.

What's the most important thing you got out of Acquia U?

Matt: Surprisingly, I think it’s not Drupal-related. I think it’s more being able to work with a team better. Understanding different roles and responsibilities and how to function as a member of a team better.

Colin: I never actually worked in a situation like this before. I was always very "lone wolf-y" at a lot of other things; college encourages sort of the mindset that you’re going to work on your own, you have to depend on yourself. Coming to Acquia, I think the biggest thing was how much better teams can be when everyone is working together. I refer to this ... a lot of Support, they won’t say it in these words usually, but they’ll say something to the effect of "it’s lightning in a bottle almost", how the team could come together and do far more than they probably should be able to given the individuals. People are better when they work together than they are separately. You’ll have one genius person and then you got somebody who works very well with that genius person and then they have three times the output of amazing work. It’s "No person is an isl"and basically and learning how to work with other people made life a lot better - a lot more fun and a lot better.

What is one piece of advice that you would give someone looking for a new career?

Matt: Just start. It doesn’t matter where. I know for me, I had for a long time thought about switching careers from a design-based career to a more technical web development-based career and I dragged my feet in it for a while. So just to start, just to take the first step whatever it is.

Colin: Don’t be afraid to change. I definitely came from designing computer cases to doing a lot more things in Drupal and you’d be surprised how much of the mindset will apply from one thing to another even though what you’re actually doing is completely different.

More on Acquia U
  1. Visit the Acquia University website:
  2. Podcast: Acquia U: "Making the world a better place, one Drupalist at a time." - with Amy Parker
  3. Podcast: Acquia U: "Jump in and own it. Kickstart your career." - meet Amy Parker
  4. Podcast Meet Erica Ligeski: Drupal training means jobs (2013)
Guest dossiers
Skill Level: Beginner
Catégories: Elsewhere

Four Kitchens: Launch announcement: Successful Farming at

ven, 25/03/2016 - 22:16

We are proud to announce the launch of Successful Farming at Working with Meredith Agrimedia’s Successful Farming magazine and’s digital content, Four Kitchens helped unify the brands and provided a transition strategy to integrate the two identities …

Catégories: Elsewhere

Wuinfo: Does Design Pattern Really Matter?

ven, 25/03/2016 - 21:42

I am not against design patterns. I am just not its devoted follower. I think design pattern to a programming language is like grammar to the English language. I believe it is not the right tool to begin with software designing.

It said a design pattern is a general repeatable solution to a commonly occurring problem in software design. It is not accurate. Why not just make it a standard API function. A pattern should come with our solution in a natural way. To cope with a real life problem, we need to be agile and flexible. Design patterns may not be the best way. We just can not generalize solutions for various problems.

Someone said that we need design pattern. It is because issues may not become visible until later in the implementation. That is a big problem for me. As a system architect, I design software to deal with issues. If we can't see all of them before the implementation. It is a failure. Or at least, a certain percent of discount on the perfection of software quality.

It said that patterns allowed developers to communicate using well-known, well-understood names for software interactions, which might be true. We might discover patterns in a well-written system. Those patterns should not be created intentionally. Otherwise, it can make the code difficult to understand. Mostly, it happened when design pattern ideology dominated the process of business request analyze and technical design.

How does design pattern work? It is like how the grammar is working. We did not check grammar every time we speak? So, forget about patterns. Like we learned our mother tongue, just go practice and use it. Forget about the grammar. Let your innovation and creativity find the way to your code. Just design the system to handle issues, no worry about patterns.

Design patterns should come to our code naturally. After finishing our programming designing, revisit it a few weeks later. We may have "invented" a new one. As the matter of the fact, I might get one in my next article.

Catégories: Elsewhere

DrupalEasy: Enabling "development mode" on a local Drupal 8 site

ven, 25/03/2016 - 20:36

Drupal 8 includes some great debugging tools built-in, but it isn't always super-obvious how to access them. Luckily, the Drupal Console "site:mode" command helps out quite a bit, but it also requires the site to be configured properly before it can be successfully used. I find that having access to the Twig template name suggestions is invaluable when theming a Drupal 8 site:

Enabling development mode on a Drupal 8 site gives site building access to debugging functionality including:

  • Enables Twig debugging - template override filename suggestions right in the HTML source.  
  • Enables Twig auto-reload - Twig templates are automatically recompiled when they are changed (instead of having to wait for a cache rebuild).  
  • Disables Twig caching and Drupal's render cache - because caching is annoying when you're developing, right?  

Using Drupal 8's development "mode" simply involves tweaking your local site's settings.php and services.yml files. Drupal Console's "site:mode" command will do most of the work for you.

Here's the steps I normally take to enable Drupal 8's development mode:

  1. Ensure the local copy is using a sites/default/settings.local.php, and that it is being included by the sites/default/settings.php file.  
  2. Copy /sites/ to sites/default/services.yml. The services.yml file is ignored by Git by default, and contains environment-specific services settings.  
  3. Ensure the permissions of the sites/default/services.yml file allow you to read/write, as when you run Drupal Console's "site:mode" command, the file will be modified. This is a common issue when first setting this stuff up.  
  4. Run Drupal Console's "site:mode" command to put the site in development mode: drupal site:mode dev.  

If all goes well, then Drupal Console will output a summary of the changes it made, with no errors.

You can then flip-flop between development mode and production mode using:

drupal site:mode dev
drupal site:mode prod

Catégories: Elsewhere

Acquia Developer Center Blog: Multisite Governance, Site Delivery, and Other Issues Related to Managing Many Sites: Part 2

ven, 25/03/2016 - 16:02

This is Part 2 of an interview with Will Eisner, Senior Director, Product at Acquia. Will’s primary focus is on Acquia Cloud Site Factory, which helps organizations create and manage many sites, from a dozen to thousands.

In Part 1, Will discussed how companies often discover, to their dismay, that they are running hundreds of Web sites, on many different platforms. In this section of the interview, Will describes how Site Factory addresses that problem.  

The interview was conducted by DC Denison, Senior Editor, Technology, at Acquia, who is represented by the letter “Q.”

Tags: acquia drupal planet
Catégories: Elsewhere

Zivtech: Webinar: Does My Drupal Backend Look Weird to You?

ven, 25/03/2016 - 14:27

Stop hiding it! Take a good look at your website’s backend. Get answers to all your embarrassing questions in a safe place.

It’s actually pretty easy to massage your backend into better shape. Join us for a lively webinar on April 5, 2016 with Zivtech co-founder and CTO Jody Hamilton.

Date: Tuesday, April 5, 2016
Time: 01:00 pm ET / 10:00 am PT
Speaker: Jody Hamilton, CTO of Zivtech​

Sign up for the webinar!

  • Is everyone’s WYSIWYG this difficult to use?
  • Is it normal for Drupal sites that content editors require training or documentation?
  • Do I have an appropriate content publishing workflow?
  • Where do I look in the backend to see whether my site is configured securely?
  • Do I have the best forms for adding content to my site?
  • Is it normal to have little tricks for featuring content to the homepage?
  • Is my image and video handling as easy as it should be?
  • Is everyone else also afraid to edit certain parts of their site because doing so risks badly breaking something?

Discover how you measure up with your content management experience. Find out what you can do to make your work easier during this eye opening 60 minute webinar.

Sign up today!

If you can’t attend at the scheduled time, sign up and receive a recording after the webinar's over.

Catégories: Elsewhere

Valuebound: How to reduce the risk of your Drupal 8 application using Backup & Restore?

ven, 25/03/2016 - 10:07

Imagine this! You are typing hundred lines of code, fixing bugs after bugs and finally after countless efforts the program successfully runs. Uff!! What a feel when you finally crack the code! But wait, what if in a blink of an eye everything vanishes off? What if, your site which was running properly suddenly stumbles a minute later?
Isn’t it any coder’s nightmare? You curse yourself for not taking backup. This article will save you from that dreadful situation.
Not only is creating and storing site backup a good practise, but it also ensures site stability and helps in further updation.
In order to backup a Drupal site you need to take care of code and database.

  • The first problem we came across is placing the Drupal directory trees under…
Catégories: Elsewhere

Drupal Console: Drupal Console and Beer - Pilot Episode

ven, 25/03/2016 - 09:31
We are starting a weekly hangout “Drupal Console and Beer” our goal is to keep you informed about changes on Drupal Console project. In this article, we will provide you some of the content that we discuss during the video.
Catégories: Elsewhere Security Review 1.3 released for Drupal 6!

jeu, 24/03/2016 - 23:03

If you're running a Drupal site of any version (6, 7 or 8), I highly recommend installing the Security Review module and following its recommendations!

What many people don't realize, is that even if you've applied every security update that affects your site, it's possible to introduce vulnerabilities (or make it super easy to escalate a minor vulnerability to a highly critical one) by configuring your Drupal site insecurely.

The Security Review module can identify the most common insecure configurations on your site and tell you how to fix them!

However, if you're planning on keeping your Drupal 6 site running after its End-of-Life (EOL), it's doubly important that you install the Security Review module and harden your site's configuration.

And, yesterday, we released Security Review 1.3 for Drupal 6!

This release is basically the same as 6.x-1.x-dev release has been for a year, but we've been using it successfully with our customers for quite awhile. So, we figured it was time to make a proper release. :-)

However, we intend to continue maintaining the Drupal 6 version of the module and hope to fix (or otherwise close) the last 20 open issues and make more releases.

While most other modules are discontinuing maintenance on their Drupal 6 versions because of the EOL, I think this is one module that needs increased maintenance because of it. :-)

Catégories: Elsewhere

Zivtech: Edit Your Own Help Text With New Drupal 7 and Drupal 8 Module

jeu, 24/03/2016 - 21:15

Help text on form fields is an intrinsic component for web applications that contain forms for content creation, user accounts or data entry. Writing help text and labeling fields is typically left up to developers, rather than to the site owners and editors who best know their users' needs. In order for an editor to change the help text on a typical Drupal project, there's the effort and expense of writing up changes, sending them to developers, and then waiting for the changes to be deployed. This is because Drupal's settings for the field help text and field label are mixed in with more developer-oriented settings. It becomes tricky for site owners to learn to make these changes on their own without introducing the risk that they mistakenly break the site.

There is the Better Field Descriptions module for Drupal 7, which allows a separate permission to let editors override field help text and labels, but its user interface wasn't simple and intuitive enough to really meet the need. Looking ahead to our new Drupal 8 projects, I thought it would be great to solve this problem in a simpler way as a Drupal 8 module.

Module development hero Jonathan DeLaigle hooked us up and created the Field Help Helper module (with front-end help from Alban Bailly). Simply assign the permission to a user role and your editors will see an edit icon for each field description, letting them change the field label and help text right in the form itself.

Edit field help text and labels The form for changing a field's label and help text

We immediately loved it so much that we wanted to implement this module in our Drupal 7 projects, so Jonathan made a Drupal 7 version as well.

We're including this module in our starter-kit distribution, Bear, to make sure it is included on all our future projects. I look forward to not only our clients but also our non-coding staff (project managers, QA, documentation, design, etc.) efficiently improving the user experience of all our Drupal 7 and 8 forms with this tool.

Catégories: Elsewhere

Lullabot: Drupalcon: A Look Ahead to ‘Nawlins

jeu, 24/03/2016 - 21:00
Matt and Mike talk with Drupalcon organizers Rachel Friesen, Amanda Gonser, and Tina Krauss, alongside NOLA natives Eric and Sabrina Schmidt. We talk session and site submission criteria, and where the next Drupalcon will be! We also talk a lot about 'Nawlins including what and where to eat, where to listen to music, museums, what's within walking distance, and lots more!
Catégories: Elsewhere