Planet Drupal

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

DrupalCon News: 10 Things You Must Not Miss When You Come for DrupalCon Asia 2016

mar, 22/09/2015 - 17:14

Mumbai, earlier known as Bombay, offers up an interesting mix of history and modernity that cannot be  explained in words. You simply have to experience this city.

Here are 10 places and things you must not miss visiting when you come for DrupalCon Asia 2016.

Catégories: Elsewhere

Wim Leers: Caching at the Edge: CDNs for everyone

mar, 22/09/2015 - 13:15

Drupal 8 has comprehensive knowledge about the cacheability of the things it renders. This opens new doors. Did you know Drupal 8 will be able to cache everything at the edge?

For sites with many mobile users (high latency due to network), global audiences (high latency due to distance) and performance-sensitive sites (e-commerce), Drupal 8 will be a huge leap forward.

We’ll be showing how easy and powerful it is using the CloudFlare and Fastly CDNs.

Cache tags

Instantaneous purging of all (and only!) the affected pages when an article is updated. No more manual purging by content editors. No more fiddling with URLs to purge. It all just works. Optimally.

Cache anonymous pages without any effort. On your own reverse proxy, and on many CDNs — thanks to standardized configuration.

This sounds nice, but that’s just the anonymous user case. What about authenticated users?

Cache contexts

The typical example: a shopping site, users categorized in groups according to interests, and a shopping cart.

Automatic caching of the entire page, minus the shopping cart, on the edge. Reused across all users in the same group. And, if the CDN supports it, even the shopping cart can be cached on the edge (and be kept up-to-date thanks to cache tags). Otherwise only thatneeds to talk to the origin (via AJAX, for example).

Cache authenticated pages without any effort.  On your own reverse proxy, and on some CDNs — thanks to standardized configuration.

  • The caching concepts
  • Demos
  • BigPipe, ESI, hybrid rendering strategies
  • A peek at the future: ServiceWorker
Slides: Caching at the Edge: CDNs for everyoneConference: DrupalCon Barcelona Location: BarcelonaDate: Sep 22 2015 - 17:00Duration: 60 minutesExtra information: 


Catégories: Elsewhere

OpenLucius: Headless Drupal & Node.js | Part 1/3: Drupal 8 RESTful

mar, 22/09/2015 - 12:07
Recently we launched our new corporate website, built with a ‘headless’ Drupal cms as backend and Node.js & Express JS deployed at the frontend. The system is ‘decoupled’. Why and how decoupled? Read this blog. In these series of blogs I will explain how we implemented Node.js and Express JS as frontend framework, linked to a Drupal cms via a RESTful API. I am not discussing the design and development of the HTML, CSS and client-side Javascripts, which have already been developed and delivered.
Catégories: Elsewhere

Dries Buytaert: Always be shippable

mar, 22/09/2015 - 10:26

Drupal will soon be 15 years old, and 5 of that will be spent on building Drupal 8 -- a third of Drupal's life. We started work on Drupal early in 2011 and targeted December 1, 2012 as the original code freeze date. Now almost three years later, we still haven't released Drupal 8. While we are close to the release of Drupal 8, I'm sure many many of you are wondering why it took 3 years to stabilize. It is not like we didn't work hard or that we aren't smart people. Quite the contrary, the Drupal community has some of the most dedicated, hardest working and smartest people I know. Many spent evenings and weekends pushing to get Drupal 8 across the finish line. No one individual or group is to blame for the delay -- except maybe me as the project lead for not having learned fast enough from previous release cycles.

Trunk-based development

The past 15 years we used "trunk-based development"; we built new features in incremental steps, maintained in a single branch called "trunk". We'd receive the feature's first patch, commit it to our main branch, put it behind us, and move on to the next patch. Trunk-based development requires a lot of discipline and as a community we have mostly mastered this style of development. We invested heavily in our testing infrastructure and established a lot of processes. For all patches, we had various people reviewing the work to make sure it was solid. We also had different people figure out and review all the required follow-up work to complete the feature. The next steps are carefully planned and laid out for everyone to see in what we call "meta" issues. The idea of splitting one large feature into smaller tasks is not a bad idea; it helps to make things manageable for everyone involved.

Given all this rigor, how do you explain the delays then? The problem is that once these features and plans meet reality, they fall apart. Some features such as Drupal 8's configuration management system had to be rewritten multiple times based on our experience using it despite passing a rigorous review process. Other features such as our work on URL routing, entity base fields and Twig templating required much more follow-up work compared to what was initially estimated. It turns out that breaking up a large task into smaller ones requires a lot of knowledge and vision. It's often impossible to estimate the total impact of a larger feature on other subsystems, overall performance, etc. In other cases, the people working on the feature lacked time or interest to do the follow-up work, leaving it to others to complete. We should realize is that this is how things work in a complex world and not something we are likely to change.

The real problem is the fact that our main branch isn't kept in a shippable state. A lot of patches get committed that require follow-up work, and until that follow-up work is completed, we can't release a new version of Drupal. We can only release as fast as the slowest feature, and this is the key reason why the Drupal 8 release is delayed by years.

Trunk-based development; all development is done on a single main branch and as a result we can only release as fast as the slowest feature.

We need a better way of working -- one that conforms to the realities of the world we live in -- and we need to start using it the day Drupal 8.0.0 is released. Instead of ignoring reality and killing ourselves trying to meet unrealistic release goals, we need to change the process.

Feature branch workflow

The most important thing we have to do is keep our main branch in a shippable state. In an ideal world, each commit or merge into the main branch gives birth to a release candidate — it should be safe to release after each commit. This means we have to stop committing patches that put our main branch in an unshippable state.

While this can be achieved using a trunk-based workflow, a newer and better workflow called "feature branch workflows" has become popular. The idea is that (1) each new feature is developed in its own branch instead of the main branch and that (2) the main branch only contains shippable code.

Keeping the main branch shippable at all times enables us to do frequent date-based releases. If a specific feature takes too long, development can continue in the feature branch, and we can release without it. Or when we are uncertain about a feature's robustness or performance, rather than delaying the release, it will simply have to wait until the next release. The maintainers decide to merge in a feature branch based on objective and subjective criteria. Objectively, the test suite must pass, the git history must be clean, etc. Subjectively, the feature must deliver value to the users while maintaining desirable characteristics like consistency (code, API, UX), high performance, etc.

Feature branching; each feature is developed in a dedicated branch. A feature branch is only merged into the main branch when it is "shippable". We no longer have to wait for the slowest feature before we can create a new release.

Date-based releases are widely adopted in the Open Source community (Ubuntu, OpenStack, Android) and are healthy for Open Source projects; they reduce the time it takes for a given feature to become available to the public. This encourages contribution and is in line with the "release early, release often" mantra. We agreed on the benefits and committed to date-based releases following 8.0.0, so this simply aligns the tooling to make it happen.

Feature branch workflows have challenges. Reviewing a feature branch late in its development cycle can be challenging. There is a lot of change and discussion already incorporated. When a feature does finally integrate into main, a lot of change hits all at once. This can be psychologically uncomfortable. In addition, this can be disruptive to the other feature branches in progress. There is no way to avoid this disruption - someone has to integrate first. Release managers minimize the disruption by prioritizing high priority or low disruption feature branches over others.

Here is a workflow that could give us the best of both worlds. We create a feature branch for each major feature and only core committers can commit to feature branches. A team working on a feature would work in a sandbox or submit patches like we do today. Instead of committing patches to the main branch, core committers would commit patches to the corresponding feature branch. This ensures that we maintain our code review process with smaller changes that might not be shippable in isolation. Once we believe a feature branch to be in a shippable state, and it has received sufficient testing, we merge the feature branch into the main branch. A merge like this wouldn't require detailed code review.

Feature branches are also not the silver bullet to all problems we encountered with the Drupal 8 release cycle. We should keep looking for improvements and build them into our workflows to make life easier for ourselves and those we are implementing Drupal for. More on those in future posts.

Catégories: Elsewhere

Matt Glaman: Using Features Override to manage changes to a distribution

mar, 22/09/2015 - 06:14

The module has become a de facto tool in configuration management in Drupal 7. In fact, most Drupal distributions now utilize Features to export configuration and handle updates to the configuration. There is one pitfall - Features was  meant to be a way to export a feature set. Features takes a set of configurations and its job is to ensure those are in place. That means customizations to defaults are at risk of preventing incoming changes or loss when updating. That’s not good! You’re using a Drupal distribution so you save time, but now you have headaches because customizations disappear.

What is Features Override, then?

That’s where comes in and allows you to revert your feature modules and ensure configuration sticks. The name of the module speaks to its purpose. It allows you to override a feature and export those changes. But, how? Chaos Tools provides its own alter hooks for its object CRUD API. That means Views, Page Manager, Panels, and any item implementing this CRUD can be exported as a glob of PHP code representing an associative array of objects. Entity API  has its own CRUD, too; without knowing much of the history I’d assume Entity API’s implementation was modeled after Chaos Tools.  The biggest difference is the Entity API utilizes JSON for moving items around. Features, itself, provides its own alters for items that don’t have an import/export definition - such as field bases, field instances, etc. Features Override is a UI for writing alters in your feature module.

Let’s Do This!

We’ll run through customizing - the most download distribution which gets pretty customized. As a disclaimer, I am a maintainer of the project. If you were to install Commerce Kickstart 2 and navigate to Structure -> Features (admin/structure/features) you’d see something like the following:

“Default” means the Features is in its expected state. If we added a new config export or tweaked something, you’d receive it on update. Let’s change that because we want the Blog Post content type to hide the category and tag fields when we’re displaying them as a teaser.

In the above we’ve marked Category and Tags as hidden. In fact, since CK 2.27 there has been an automated test checking this change and Features Override. That’s right - we have automated testing to ensure your changes live on using Features Override (.) Let’s look back at our Features.

Now we’re going to create a new Feature called “CK2 Overrides” that will contain our specific changes. That will allow us to upgrade Commerce Kickstart 2 and revert its feature modules and keep our own changes. From the Manage Features page, we will select “Create Feature.” The next step is to pick your “Feature Overrides” component.

So this is where it can get confusing. As you can see there are two component types: “Feature Overrides” and “Feature Overrides (individual — advanced)” Unless you know what you’re doing - just pick the former. Feature’s magic will auto-populate what specific individual overrides are required to be exported. Think of it as nitpicking what specific keys in an array export it needs to alter (because that’s what it is!) Generate or download your feature and enable it!

And now we have nothing overridden!

Tips and Tricks

It’s not perfect - nothing is. So here’s a few tips and tricks I’ve learned

  • Not all overrides are caught, not all overrides want to stick.
  • Enabling an overrides feature sometimes needs caches cleared to kick off a new features component rebuild. Manually reverting won’t kick over the “overridden status."
  • An override feature will show up as overridden if the base feature is overridden - sometimes you just need to revert that one.
Catégories: Elsewhere

OSTraining: How to Find Your Site's .htaccess File in cPanel

mar, 22/09/2015 - 02:16

"Where is my .htaccess file?"

This is a problem that we've helped resolve over and over again at OSTraining.

The .htaccess file is absolutely crucial for the correct operation of many sites, whether they're running WordPress, Drupal, Joomla or similar platforms. The .htaccess files controls the URLs for sites and also adds many important security features.

Today, one more user was having trouble finding their .htaccess file, so we created this tutorial for her.

Catégories: Elsewhere Modern Drupal7 Site Building Tools

mar, 22/09/2015 - 02:00
Why build a site with Drupal 7 Drupal8 is nearly out making Drupal 7 look like it isn't an appealing choice. However, Drupal 7 is still a contender. The module ecosystem for Drupal 7 is mature and, specifically for site...
Catégories: Elsewhere

Red Crackle: Traits

lun, 21/09/2015 - 21:51
In this blog post, you'll learn what traits are in the PHP language. You will also learn when to use them and how they can help in code reuse?
Catégories: Elsewhere

Daniel Pocock: Skype outage? reSIProcate to the rescue!

lun, 21/09/2015 - 19:19

On Friday, the reSIProcate community released the latest beta of reSIProcate 1.10.0. One of the key features of the 1.10.x release series is support for presence (buddy/status lists) over SIP, the very thing that is currently out of action in Skype. This is just more proof that free software developers are always anticipating users' needs in advance.

reSIProcate 1.10.x also includes other cool things like support for PostgreSQL databases and Perfect Forward Secrecy on TLS.

Real free software has real answers

Unlike Skype, reSIProcate is genuine free software. You are free to run it yourself, on your own domain or corporate network, using the same service levels and support strategies that are important for you. That is real freedom.

Not sure where to start?

If you have deployed web servers and mail servers but you are not quite sure where to start deploying your own real-time communications system, please check out the RTC Quick Start Guide. You can read it online or download the PDF e-book.

Is your community SIP and XMPP enabled?

The Debian community has a federated SIP service, supporting standard SIP and WebRTC at for all Debian Developers. XMPP support was tested at DebConf15 and will be officially announced very soon now.

A similar service has been developed for the Fedora community and it is under evaluation at

Would you like to extend this concept to other free software and non-profit communities that you are involved in? If so, please feel free to contact me personally for advice about how you can replicate these successful initiatives. If your community has a Drupal web site, then you can install everything using packages and the DruCall module.

Comment and discuss

Please join the Free-RTC mailing list to discuss or comment

Catégories: Elsewhere Featured Case Studies: SooperThemes Drupal Themes

lun, 21/09/2015 - 18:01
Completed Drupal site or project URL:

SooperThemes is a theme shop, selling premium Drupal themes. SooperThemes developed their sixth Drupal re-design to go with a completely new product line, based on our Glazed Drag and Drop theme.

As the oldest active Drupal themes shop, SooperThemes has been selling designs and contributing code to the community since 2007. We have used Drupal 6 with Ubercart and Drupal 7 with Commerce. For our newest website, we started with a clean slate and browsed the Drupal ecosystem for the most effective and maintainable tools to build the home for our new themes.

Traditionally, we have always used custom themes for our own website. This time, we built our website entirely with our own product. Our new theme is as much about its Drag and Drop site-building tools as it is about design. We could create a unique design by editing the many settings in the Glazed theme. Thereafter, we could design pages with the integrated visual drag and drop page builder. At no point did we miss Photoshop or our favorite code editor. Photography, text, and responsive design combine intuitively in the page builder, and everything is mobile-friendly out of the box.

Key modules/theme/distribution used: Drupal CMS Bootstrap 3 ProfileBootstrapModel EntitiesRecurlyOrganizations involved: SooperThemesTeam members: JurriaanRoelofs
Catégories: Elsewhere

Microserve: Responsive Design: Media Queries And How To Make Them More Friendly

lun, 21/09/2015 - 17:33
Responsive Design: Media Queries And How To Make Them More FriendlySep 21st 2015

In building responsive websites, whether Drupal or otherwise, we all need to harness the power of media queries. 
Here is a brief overview of media queries, breakpoints and the basics of the ‘Mobile First’ approach and also some simple tricks for making media queries more friendly, semantic and easier to remember and use with LESS and SASS variables. 

Media queries - The basics

A CSS Media Query (originally ‘media rule’ in CSS2, renamed ‘media query’ in CSS3) is a CSS statement which targets a specific media type and/or size/size range. Inside a media query statement we can nest a collection of CSS declarations which will style content only when the conditions of that parent media query statement are true.

So, if a media query targets a media type of ‘screen’ with a min-width of 320px, it’s nested CSS declarations will only have effect on screens (smartphones/tablets/computers etc) but only if the device has a screen with a display larger than 320px wide.


In responsive design, a ‘breakpoint’ is a declared pixel width at which the layout of a web page or entire site should adjust (respond) to better display its content on the screen size of the device it is being viewed on. Commonly designers and developers set breakpoints at 2 or 3 size ranges to separately target mobile, tablet and larger desktop/laptop computers.

There’s no actual limit (other than common sense) to the amount of breakpoints you could add, but these 3 are a pretty good rule of thumb and cover most needs.

The beauty of the system is that it encourages us to target screen size ranges (all screens between ‘these sizes’) and not specific device types, so when a new model of smartphone comes out (for instance), we can be pretty sure the site will appear correctly as the device’s screen will be of a size that falls within an existing range that we are already targeting.

Mobile First? (min vs max)

First thing to decide is in which direction you want to media queries to work.

By this I mean whether you want to set max-width or min-width breakpoints. 

You can of course use a mixture of both, but here we’re all about making things more straightforward, so I would avoid ‘crossing the streams’ and stick to one strategy.

Max Width breakpoints:

Everything from zero or the last, narrower breakpoint,  up to ‘this width’ .
Used mostly in ‘Desktop First’ and ‘Retro Fitted Mobile’ builds.

Min Width breakpoints:

Everything above ‘this width’ to infinity, or until overridden by another, wider breakpoint.
Used mostly in modern ‘Mobile First’ builds.

‘Mobile First’ is widely accepted as the best way to approach responsive design, so I would advise the use of Min Width breakpoints.

You can find much more in-depth information about Mobile First from the person regarded as its original architect Luke Wroblewski.

In Mobile First theory we start without any breakpoints or media queries (in essence targeting all screen sizes of 1px wide to infinity) and here set all default, site-wide styles as well as any mobile specific styles for (so that we know all screens no matter how small will be covered) and then we create media query breakpoints at which we override the default styles for layout or elements which need to appear differently on larger screens. (As opposed to styling the whole site for desktop and then overriding for smaller screens.) 
This can take a little getting used to and feel a bit ‘backwards’ for developers used to building desktop sites, who may still consider mobile a ‘bolt on’, secondary consideration, but it’s surprising how easy the switch in thinking can be.

Example of a Mobile First media query body{ background: white; } @media screen and (min-width:768px) { body{ background: black; } }

In this example, the body of the document will have a white background on all screens smaller than 768px - This is it’s default ‘Mobile First’ setting.
Then on all screens larger than 768px the body will have a black background.

Which and how many breakpoints to choose?

You could in theory, create a mobile first website without any media queries or breakpoints.

You could serve the same mobile layout to all screen sizes. But because in most cases mobile layout consists of 100% width single column elements, it would start to become very difficult to use and read on larger screens. So the bare minimum we would usually consider using is one breakpoint to distinguish between mobile and more traditional desktop layouts.

The size of 768px used in the example above would work well for this, as our site would show mobile layout on mobiles and many tablets in portrait orientation, then on tablets in landscape orientation, laptops and desktops, another layout could be displayed.

I use Bootstrap 3 as my main front-end framework and ‘out of the box’ Bootstrap 3 has 3 defined breakpoints:

sm - 768px and up to...
md - 992px  and up to...
lg - 1200px  and up to infinity

This covers our Mobile First defaults up to 767px, a tablet aimed size range of 768px-991px, a traditional desktop width of 992px-1199px and a more modern, wider desktop width of 1200px and above.
*Personally, I usually add a smaller, custom breakpoint of around 480px, because I find in practice the range of 0-767px, before the first ‘sm’ breakpoint kicks in can sometimes be a bit wide for every part of my layout. Interestingly, one of the promised updates in the imminent release of Bootstrap 4 is that it will come with a similar ‘extra small’ breakpoint as standard.

Media queries can become surprisingly complicated to keep track of. This is where LESS and SASS variables can be a godsend.

LESS and SASS Variables - Making media queries more user friendly

Although not the most complicated coding syntax in the world, media queries can be hard to keep track of, once you’ve got 3 or 4 different sizes to contend with. Having to remember the precise pixel width you are targeting and in which direction can become surprisingly complicated, especially when we start using inline queries (more coming on that later.) This is where LESS and SASS variables can be a godsend.

Here’s a LESS example:

In our variables.less (or similar) create a variable called ‘@tablet’. *Notice we use a tilde (~) in front of our value string, so that the quote marks are not included when processed into CSS. - We need to use quotes around our variable value as LESS syntax requires this if a value contains a string of different tokens, but once compiled to CSS, these are not needed.

@tablet: ~“screen and (min-width: 768px)”;

Now instead of using

@media screen and (min-width:768px) { body{ background: black; } }

We can use the variable to target 768px and above.

@media @tablet { body{ background: black; } }

In SASS, the same principle applies, but our syntax is slightly different. Our variable is denoted by ‘$’ as opposed to ‘@’ and instead of adding a tilde to interpolate our value string and remove the quotes at the point at which our variable is declared, we use #{} around our variable name at the point at which it’s referenced in our code to do the same thing.:

$tablet: “only screen and (min-width: 768px)”;

We can then use:

@media #{$tablet} { body{ background: black; } } ‘Nested media queries’

So that’s given us a method of creating more memorably named variables to use in place or full hand media queries in our code, but it can still feel a bit disjointed and counter intuitive to set initial global declarations in one point of a file and then keep jumping to another point in a file or to another file altogether to set our media query overrides.  Also imagine if you only want to override an attribute value which was a few levels down within a LESS or SASS nest. For our media query override to work we would have to include the entire nest up to the point at which the value we want to change appears.

Say we want to change the color of all links on screens above 768px wide, but only if they are inside paragraphs, which are inside a div with the class of ‘thisdiv’, which are in turn inside a div with an ID of ‘container’.

The original global code might look like this:

#container{ .thisdiv{ p{ a{ color: red; } } } }

Our media query override would need to include this whole list (LESS version shown):

@media @tablet{ #container{ .thisdiv{ p{ a{ color: blue; } } } } }

That’s a heck of a lot of nesting to keep on top of and if we add a new nest level in our original declaration between say '#container' and '.thisdiv', we would also have to update the nesting in our media query.
Luckily current versions of both LESS and SASS allow for the nesting of media queries so that they can essentially be used inline within existing declarations.

So with the above example instead of having to re-write the entire nest in a separated part of our file or in a separate file, we can just specify the exact element we want to override from within the original global declaration.

So instead of having to write:

#container{ .thisdiv{ p{ a{ color: red; } } } } @media @tablet{ #container{ .thisdiv{ p{ a{ color: blue; } } } } }

We can just write:

#container{ .thisdiv{ p{ a{ color: red; @media @tablet{ color:blue; } } } } }

*Notice the media query is nested inside the ‘a’ attribute itself, after its initial, global value.

Bootstrap 3 specific queries

In Bootstrap 3 we can go a little further to make sure we fully integrate our media query variables into the framework. Bootstrap depends on a grid system which is based around a collection of pre existing breakpoints.

Although most users leave these existing breakpoints where they are, if you do need or want to changes these to custom values of your own choice, this can be done by identifying and changing the values of the corresponding variables in variables.less. For this reason it makes sense that our media queries use these existing variables as their values.

Why? Because if we (or anyone else) updates the value of the grid breakpoint widths, our media query variables will then in turn automatically receive these new values.

Here is our friendly name Bootstrap LESS variables:

@mobile-lg: ~"screen and (min-width: @{screen-xs-min})"; @tablet: ~"screen and (min-width: @{screen-sm-min})"; @normal: ~"screen and (min-width: @{screen-md-min})"; @wide: ~"screen and (min-width: @{screen-lg-min})";

I usually place these at the top of variables.less for easy reference.

So to re-iterate; instead of explicitly stating ‘768px’ as the value for min-width in the @tablet variable, we instead reference the existing Bootstrap variable ‘@{screen-sm-min}’. This means if the integral Bootstrap grid variable is updated, our media query variable and all dependant references will use this new value automatically.

Other Front End Frameworks Are Available!

There are of course other front-end frameworks available other than Bootstrap such as Foundation by Zurb as well as some Drupal specific responsive grid-based systems like AdaptiveTheme and Omega. I only cover Bootstrap here as an example and also because it is currently the most popular framework around also but not least because it's what I personally use most and know most about. All of the principles up to the Bootstrap specific queries should still be just as relevant, no matter which framework you use or whether you indeed use one at all.

Further reading

The above is intended as quite a top level, overview of media queries and their application. For more in-depth information on the technologies and concepts used I’d recommend the following further reading:

W3C Schools: Media Queries
Luke Wroblewski - Architect Of Mobile First
Bootstrap 3

Written by: Martin White, Drupal Themer

Microserve is a Drupal Agency based in Bristol, UK. We specialise in Drupal Development, Drupal Site Audits and Health Checks, and Drupal Support and Maintenance. Contact us for for further information.

Catégories: Elsewhere

Drupalize.Me: Meet Front-end Developer Kris Bulman

lun, 21/09/2015 - 15:00

We interview Kris Bulman about what it means to be a front-end developer and share advice from his experience. Kris has been theming Drupal sites and working on the front-end since 2007. He's done a lot of work in the open source world including being a co-maintainer of Drupal’s Zen theme and building his own Sass grid system.

Catégories: Elsewhere

Wunderkraut blog: How to make DrupalCon even better?

lun, 21/09/2015 - 11:46

You may have noticed that after three years of being the primary sponsor for DrupalCon Europe we've chosen to skip the traditional sponsorship this year. Many people have asked why, so here’s the answer.

For a long time we treated DrupalCon in Europe as a marketing investment. We did this even though it didn't create even nearly enough leads to justify the investment of time and money. In real life it was an HR investment, our staff liked it and it helped in our hiring. And DrupalCon is an awesome event that we are proud to support, could we support it in a better way? There is a real difference between DrupalCons, and in fact technical conferences in general, between Europe and the US. Customers don't go to technical events in Europe. The participant profile is much more technical in Europe. This makes DrupalCon in Europe a very attractive marketing opportunity for hosting providers, ISVs and other parties who target to developers and Drupal shops, less so for Drupal shops. After DrupalCon Amsterdam we sat down with the DA in order to come up with a better way to support the event. Traditional sponsorship wasn't working for us and we wanted to help improve the event. Our own staff is a big part of the Drupal community, so naturally we asked them what would make the DrupalCon even better. After considering quite a few different ideas, and learning a lot on the strange limitations conference venues have in the process, we decided to make contributing to Drupal more comfy. We do this by bringing loads of beanbag chairs to the venue. Naturally we paid the DA for the privilege, and in order to keep our financial support on the same level as before we also decided to be the first company to sign up for the new signature level supporting partnership. We have more ideas in store for the future years and I would also like to hear your take on how to make DrupaCon even better. Is there something we could do to help?
Catégories: Elsewhere

DrupalCon News: Registration is Open! Come on By!

dim, 20/09/2015 - 15:18

We are set up and handing out badges here at the CCIB!  Come on over to door A of the Convention Center, step through the doors and get your DrupalCon kicked off!

When you arrive to the CCIB, go in this door:

And grab your badge:

Then take a pic with Dries!

Catégories: Elsewhere

DrupalCon News: Come Run with Us

dim, 20/09/2015 - 11:10

If you like Drupal and being in shape, Barcelona offers a lot of options for running. There are many routes to follow, each one with its own charms.

Remember, in Google Maps, the venue of DrupalCon 2015 is next to Auditori Forum.

If you are staying in the Hotel Princess or near the CCIB, you can follow these directions:

Catégories: Elsewhere

Gábor Hojtsy: Multilingual happenings at DrupalCon Barcelona

sam, 19/09/2015 - 13:39

If you are interested in to learn about, solve your problems with and/or contribute to multilingual Drupal, DrupalCon Barcelona is the place to be. Here is a quick summary of things happening so you don't miss what is going on.

Catégories: Elsewhere

DrupalCon News: The Local Community Invites you to Celebrate DrupalCon!

sam, 19/09/2015 - 11:00

It's here! DrupalCon is in a few days and the local community has been working really hard to bring back the traditional welcome evening from past DrupalCons. On Tuesday 22nd starting at 8pm we will have an amazing time with the best company, the Drupal community!

We want to give the best welcome possible at our reach to all DrupalCon attendees, so no matter if it's your first or your fifteen DrupalCon, come and have fun with us the first evening of the conference!

Catégories: Elsewhere

DrupalCon News: Come to Extended Sprints This Weekend!

sam, 19/09/2015 - 09:23

We are excited to welcome you to the Extended Sprints at the Makers of Barcelona co-working space this weekend.

We will see you at Carrer de Bailèn, 11. The exterior of the building looks like this:

And when you come in you pass a small cafe and see this:

Catégories: Elsewhere

DrupalCon News: Come to Extended Sprints This Weekend!

sam, 19/09/2015 - 09:14

We are excited to welcome you to the Extended Sprints at the Makers of Barcelona co-working space this weekend.

We will see you at Carrer de Bailèn, 11. The exterior of the building looks like this:

And when you come in you pass a small cafe and see this:

Catégories: Elsewhere

OSTraining: Automatically Populate Drupal Fields From Other Content

sam, 19/09/2015 - 00:32

One of our members wanted to automatically fill in Drupal fields from another node.

It took a little experimentation, but we managed to make it work using the Token, Token Filter and Entity Reference modules.

This technique works for nodes, but it should allow you to automatically popular field using data from any entity.

Before you begin, follow this tutorial on using tokens in Drupal fields. That will give you set up you need to complete these next steps.

Catégories: Elsewhere