Planet Drupal

Subscribe to Planet Drupal feed - aggregated feeds in category Planet Drupal
Updated: 15 min 4 sec ago

Drupal Association News: Putting Drupal on a Larger Stage in Germany and Beyond

Mon, 13/01/2014 - 17:46

Authored by Meike Jung and Stephan Luckow.

How can Drupal compete with the large budgets of proprietary software sales teams? It’s not just a question for Drupal. Other open source projects that largely depend on the work of volunteers have similar challenges. That’s why we decided it was worth a try to cooperate with other communities struggling with similar issues.

Categories: Elsewhere

Drupal Watchdog: Creating a Drupal 7 Distribution

Mon, 13/01/2014 - 16:41
Capturing Your Own Installation Profile and Settings

Prior to version 7, most Drupal users — and even administrators — had little need to be familiar with the inner workings of distributions and installation profiles. For versions 6 and earlier, when installing a fresh copy of Drupal core, one naturally would specify the minimum required information: database connection, website name, and superuser account. Yet one had no opportunity to affect the list of modules and themes initially enabled, the default content types, or any other configuration details. However, anyone installing Drupal 7 is presented with a choice of installation profiles: "Standard" (the default) and "Minimal".

An installation profile comprises a set of files that completely describe how to configure a new installation of Drupal core, and can be made part of a distribution.

Michael J. Ross

Michael J. Ross is a web developer who uses Drupal and other leading technologies to create custom websites for businesses and non-profits. He writes articles and book reviews, of which more than 500 have been published in print and online.

Categories: Elsewhere

Drupal Association News: Join the First Association Board Meeting of 2014

Mon, 13/01/2014 - 14:50

Join us on January 15 at Noon Pacific for our first board meeting of 2014. This meeting will be the first to use the metrics we developed in our 2014 Leadership Plan to tell the story of our progress. For 2014, each staff update will contain metrics through the prior month. For example, in February, we will be able to report the number of comments in issues on as of 31 January, 2014.

Categories: Elsewhere Place blocks inside your content with EBA

Mon, 13/01/2014 - 14:34

Previously on this website I have written about rendering blocks programmatically and adding things to content to be managed alongside fields. It's time to combine the two! On many projects, we find ourselves needing to render a block consistently across all content of a certain type. For example:

Categories: Elsewhere

Web Omelette: How to translate Drupal Commerce products

Mon, 13/01/2014 - 12:54

This is a short tutorial on enabling Drupal Commerce product entities to be translated using the Entity Translation module in Commerce Kickstart.

As you know, Drupal can be quite frustrating at times when it comes to translation. You have some core stuff available that if coupled with some contrib solutions will get you going but it will never be perfect. At least not so easy. And if you are working with something as complex and custom as Drupal Commerce, things get more difficult, fast.

Today I want to share with you my experience with enabling product entities to be translated with Entity Translation in the Commerce Kickstart distro. Let's say your Product Displays are translatable already (either using core and the i18n package or with Entity Translation) but the products are not. What do you do?

Well first you need to go to admin/config/regional/entity_translation and enable Commerce Product under the Translatable Entities list. Then - and if you've been searching the internets and reached here desperate for a solution - you have to edit the product type you want translatable (at admin/commerce/products/types) and check the radio Enabled via Entity translation. You know, like with regular content types.

But wait a minute. There is no such thing. You are seeing nowhere product types and this URL throws a 404 error. There are product variations, but no multilingual options when you edit product variation types. So wtf is going? You are using Commerce Kickstart - that's what's going on. And Commerce Kickstart comes with Commerce Backoffice that for ease of use and whatnot removes the product type UI and replaces it with product variations - among other things of course.

So what do you do? Go ahead and disable the module Commerce Backoffice Product. Clear the cache. Then go back to that URL (admin/commerce/products/types), edit the product type you want (remember, the product type is the variation you had before) and you will find upon that multilingual setting you couldn't find. Save the product type and your product entities of that type are now translatable.

You can then edit the individual fields on the product type/variation and enable translation. And this includes the title as well if you are using the Title module (which Commerce Kickstart should). This was in fact my need. The product displays where translated but the product entity titles were not. So in my cart, the line items were referencing the product entity title and not that of the display. Translating the product entity title therefore solved my problem.

Now if you want to go back to the way it was - using product variations and the old UI - which I prefered actually, re-enable the Commerce Backoffice Product module and clear the cache a couple of times. I had to wait a bit before everything reverted properly, but it did nonetheless. So if you don't get back your variations instantly, don't fret, they'll come soon.

OK, so hope this helps.

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

PreviousNext: Embedding Responsive iframes in your Drupal site

Mon, 13/01/2014 - 08:03

Implementing iframe elements can be troublesome for both content editors and developers, that's even before trying to make them responsive. After some recent project work I'm here to tell you there is an easy way to handle them.

Categories: Elsewhere

DrupalCon Austin News: Be the first to buy a ticket to DrupalCon Austin

Mon, 13/01/2014 - 07:08

We are excited to announce that tickets are now available at the earlybird rate on the DrupalCon Austin site.

Oh, and did we mention? You can now register on behalf of others!

View 2014 Ticket Prices

Categories: Elsewhere

Drupal core announcements: Drupal core security release window on Wednesday, January 15

Mon, 13/01/2014 - 04:53
Start:  2014-01-15 (All day) America/New_York Sprint Organizers:  David_Rothstein

The monthly security release window for Drupal 6 and Drupal 7 core will take place on Wednesday, January 15.

This does not mean that a Drupal core security release will necessarily take place on that date for either the Drupal 6 or Drupal 7 branches, only that you should prepare to look out for one (and be ready to update your Drupal sites in the event that the Drupal security team decides to make a release).

There will be no bug fix release on this date; the next window for a Drupal core bug fix release is Wednesday, February 5.

For more information on Drupal core release windows, see the documentation on release timing and security releases, and the discussion that led to this policy being implemented.

Categories: Elsewhere

Cheppers blog: January 15th we are going to PARTY! (Uh, work. Well it is a #DrupalWorkParty!) It is the 13th anniversary of the release of Drupal.

Mon, 13/01/2014 - 00:01

People are taking a few hours on Wednesday Jan 15 2014 to tackle a Drupal issue. We will be together on irc in #drupal and #drupal-contribute and also communicating on twitter #DrupalWorkParty


Because it is more *fun* when we work together. We get more *done* when we work together. Drupal needs our help.

Categories: Elsewhere

Théodore 'nod_' Biadala: Life of a JS maintainer

Sun, 12/01/2014 - 18:30

Back in Drupal 7 dev cycle, there was no single person that took ownership of Drupal JS as a whole, which lead to many inconsistencies in the code base or straight up syntax errors in point releases. It is not that nobody cared, it's that nobody cared enough to take ownership. We've been using JS for more than 8 years, there is a lot to do.

Do what exactly? Let's look at the list of responsibilities from the Drupal core maintainers page. I'll talk about how that applies to JS and what it's like day-to-day.

Maintainer tasks Queue monitoring

Monitoring their subsystem's issue queue (also known as "issue queue farming"). When a new issue is submitted, this involves verifying that it's a valid issue and taking appropriate action (tag as "Novice", change the status if more information is needed or if it's not really a bug, change other issue parameters, move it to a different issue queue, etc.).

Issues can be assigned to the javascript component and in real life, there are very few issues that you can assign to javascript. Usually it's an issue that needs to be assigned to CKEditor or Views UI or some other module. Hence there is a JavaScript tag for tracking JS-related issues.

When I started I would often read the core queue and tag whatever issue is related. I still do it from time to time though I don't need to anymore, most people working in the core queue know that any patch touching a JS file needs to have the JavaScript tag if they want a timely review from the JS team. Otherwise there is no way for us to find the issue.

Overall there isn't much trouble managing the JS issue queue. It's pretty clear when it's a JS issue since it usually ends up as an error in the browser console. The problem is getting people to tag their issues.

If your patch changes a JS file in any way, please tag it JavaScript, even if the change is trivial.

Contributor monitoring

Mentoring new contributors who are working on issues related to that subsystem.

There aren't many people so it's not too overwhelming. I'm really happy with the results I got while working with a couple of contributors. I don't think I'm doing a terrific job overall though. My current excuse is that the state of JS was so far from acceptable and I just wanted things fixed so I didn't take the time to mentor people. If you need something rationalized, let me know, I can be pretty good at it.

The mentoring is often about JS but sometime it's only about the core process. Maintainers exists to get stuff done — I'll get back to it a bit further. There are people who know JS and don't contribute to core. If you're in that position, reach out to me on IRC or by mail, I'm here to help out.

I'll start to make more time to take this part more seriously and hopefully increase the number of JS contributors. That's part of the reason why I started writing again.

Point of contact

Being the point of contact for that subsystem's contributors.

I'll take this one as point of contact […] with outside projects and it isn't always a lot of fun. Between Aloha, CreateJS it looks like Drupal is good at both bikeshedding and alienating outside projects.

I'm to blame for most of the friction with the jQuery and jQuery UI team. We cleared things up but the fact that it happened a couple of times is on me. I haven't been really good at making outside projects feel welcome in Drupal. That needs fixing. On of the challenge is the lack of structured decision making in the core process.

It's stupid to think I can get outside people interested in Drupal if I don't take care of outside projects.


Reviewing proposed patches to that subsystem.

For a long time most of the patches were mine so I had to find other people to review. It started to changed a few months ago, Now I have a backlog of other's people patches to review! Can't tell you how happy — and guilty — that made me feel the first time I realized I had several people waiting on me to review patches. It's taking a while for me to adjust since I still have big patches I want to work on and that takes time away from review.

Hopefully you guys don't get discouraged if I'm late in a review. Ping me on IRC if that's the case. Would hate to lose people because of that.

Acting expert

Acting as an expert on the workings of that subsystem (answering questions that come up, and being involved in discussions of major overhauls and re-architecting).

On one hand you just have to show up and/or trigger conversations and contribute to the extend of your knowledge. When the knowledge is not enough, learn things or get the relevant people in the conversation.

On the other hand, it's easy to get passionate and a bit crazy about some topics. It's good to be passionate and Drupal is important. Realistically though, chances are nobody is going to die because of a technological decision made in core.

You won't get everything you want, pick your battles.

Getting things done

Translating strategic thinking about their subsystem into actionable items and issues.

Early on I took that as "write patches" it works much better as "write issue summaries and get people to write patches". That way you can review and RTBC, ensuring you're addressing the real issue: getting patches in core.

Day to day

The end goal of maintainers is to get things done in core. Here is how that works for me.

Day Work

Fortunately, it has nothing to do with javascript. People in need of a Drupal consultant have performance, security, migration, training or process issues, not javascript issues. It means that most JS I do is on my free time and during downtime (doesn't happen anymore).

Acquia is very good to me, sponsoring almost all my trips to Drupal events so that I can talk to you guys about my hobby.

Community to maintainer

Outside events, the main feedback I get from the community are bugs. A good amount of features requests and a little bit of patches. I'm stalking those two JS component and JS related tags issue pages. They are always open on my main browser and refresh every 30 min (one of many awesome features of Opera that was dropped in the blink version). #drupal-contribute is opened in a tab next to it (IRC, another feature Opera dropped on their blink version). When I'm home I check that during the day to see if anything interesting came up.

I get the occasional email saying thank you about a particular issue, those are always nice to get.

Maintainer to community

I think it's the part that's the most fun for me: Talking about what we're doing in core for devs and users. Since my first talk at frontendunited amsterdam in 2012 I've been having sessions all over the place to talk about JS and Drupal, pretty much one every quarter. It's a lot of fun.

Now I'm starting this and hopefully get in on the Drupal planet to talk about really cool stuff we're doing in a format more readable than a bunch of 300+ comments issues. Like the back story of the overlayslayer. Hopefully getting people outside the core queue interested in core JS issues.

Maintainer to core committer

Getting things in core means getting the core committers to agree a change is valid and that a specific patch is good. Since none of them are hardcore JS dev sometime you have to convince them a change is needed. It's fairly easy since they are great and always ready to hear relevant arguments. I haven't run into any problems on issues that were properly explained. And sometimes you get the occasional break, one more hint that DRUPAL IS PEOPLE!

When I started I was surprised how fast that particular patch was committed. It took only 14 days for a massive JS patch changing a lot of files to get in (at that point I wasn't yet maintainer). It still took a couple more months to get the trust of all the committers, after that things were much easier.

I have to say that sometimes that process gets in the way. On the JS clean-up issues the overhead of the core process can be almost unbearable when you're lacking people to review patches.

At the end of the day

There are two things I'm really proud of:

  1. The visible existence of a JS community in Drupal core.
  2. The javascript (spring, summer, autumn, spring) winter clean-up.

Looking back at those two years, a few low points:

  • Relations with external projects.
  • DrupalCon Sydney, there was no javascript talk.
  • Drupal.ajax (horrible DX)
  • Drupal.tableDrag (too complicated and monolithic)

Of course, many more wins over those past two years:

  • The amazingly productive piggy back on the mobile initiative.
  • The slow but steady simplification of core JS. I know, but it's true.
  • Relations with external projects.
  • Getting people from the outside to care about our JS problems.

I'm missing a lot of highlights but you know what? Nobody is going to die if I don't list them all. Feel free to correct me in the comments if you feel it's very important to mention something and I'll add it.

If core JS doesn't get in your way, as far as I'm concerned, I did my job.

I guess I never really thought about it but what is your opinion of my work as maintainer? I get many thumbs up at events for the work I'm doing — I love it, keep them coming — but that's about the technical side of things ; I'm interested to know what are my shortcomings as a maintainer from your point of view.

Categories: Elsewhere

Open Source Training: Remove Duplicate Views Results

Sun, 12/01/2014 - 10:39

When you are building a Drupal site and creating views, it's not uncommon to find that your view is showing the same result multiple times.

Here are two common ways to remove duplicate views results.

Categories: Elsewhere

Pixeljets: Packt Publishing book - Premium Drupal themes

Sat, 11/01/2014 - 20:30

In 2013 I was invited by Packt Publishing to play a role of technical editor in one of their books.
Just got my sample of the book “Premium Drupal Themes” by mail.
It was an honor and nice experience for me, and now I hope to find time and become an author some day :)

Categories: Elsewhere

Lullabot: Insert Content Here, Episode 21: Karen McGrane's 2013 Year in Review

Fri, 10/01/2014 - 22:00

Jeff Eaton and Karen McGrane look back at the events and content strategy trends of 2013, and make their predictions for the coming year. Along the way, they discuss the challenge of content marketing overload, the future of WYSIWYG editors, the evolution of content migration tools, and more.

Categories: Elsewhere

Mediacurrent: Meet Albert Volkman

Fri, 10/01/2014 - 20:38

1. So Albert, what's your role at Mediacurrent, both internally and client-related?

I'm a Senior Drupal Developer at Mediacurrent. I take our client's dreams and aspirations, and make them into realities! I work alongside our team in architecting solutions, and then implementing them, utilizing Drupal's best practices.

2. We're so glad to have you!  Give us an idea of what professional path brought you here.

Categories: Elsewhere

Acquia: Looking for a Drupal job?

Fri, 10/01/2014 - 18:11

There are many great positions available for people who build Drupal sites. For anyone who knows PHP, Drupal is a great extension to your tool chain. Drupal’s unique site building model also allows for non-coding web development. Right now, the job market in Drupal is tipped in the favor of the job seeker. If you need help finding Drupal jobs, you’re in the right place.

Categories: Elsewhere

Drupal Watchdog: Drupl'Art

Fri, 10/01/2014 - 17:50
Sculpting Conditionals

At DrupalCon Paris, I attended a grid presentation by Mark Boulton, for designers. I didn’t get it. Recently I read the biography of Steve Jobs. Now I get it. Drupal designers like Mark focus on the art outside. For several issues, this column has focused on the art inside. At the risk of redundancy, let me state that when I talk about Drupl'Art I am talking mostly about the art within.

Aesthetic Minimalist

Like all artists, I navigate my craft through stylistic seas. Most recently, I sailed into an Extreme Minimalist Period: fewer lines of code mattered to me. Eventually, Charlie (chx) politely suggested that, if I insisted on charting that course, to at least comment it better. He was right, I was wrong; and I offer up a heart-felt mea culpa to the developers who followed in my turbulent wake and are now stuck with the flotsam and jetsam.

I am still a Minimalist, but now an aesthetically practical Minimalist; readability and maintainability carry the day. Farewell to saving opcodes!

Doug Green

Doug is a 25-year veteran of software development, inventor of the coder module, and core contributor. He specializes in creating interpretive language, development tools, and complex or high performance software. He believes software is functional art, and infuses that belief in everything he does.

Categories: Elsewhere

Théodore 'nod_' Biadala: Drupal core JS team

Fri, 10/01/2014 - 17:00

It took a little while but I'm really happy to be able to say that there is a set of very good JS people around in the core issue queue. I know there are some out there in contrib but unfortunately very few show up in the core issue queue. We're nice and we have cookies, don't be afraid!

The short story is that back in february 2012, after writing JavaScript clean-up patches for a few months, webchick told me on IRC that she wouldn't have a problem with me stepping up as JS maintainer, so I did. Lacking people to review JS patches I approached seutje on kristofvanroy's recommendation. It was at DrupalCon Munich — 3am, at the bar — that I conned talked seutje into being co-maintainer. Thanks to him, patches were reviewed, more patches were written and I stopped being down about the lack of progress in JS.

Few months later, with new and fancy functionalities piling up in core — edit module, the new toolbar, wysiwyg — and given my lack of interest for Backbone I coerced asked nicely jessebeach to be maintainer with us since she appreciates the library and can walk the walk. We're pretty much the three musketeers of core javascript. But we can't be the three musketeers without the forth one: Wim Leers. Over time he's been the one writing the most JS for core through his work on edit and wysiwyg.

I also want to give a shout out to droplet who's been reminding us that europe an north america are not the only Drupal users while sending out really good patches. Thanks to SebCorbin for working on a major and very important architectural change. Of course thanks to: mfer, ksenzee, JohnAlbin, attiks, rupl, sdboyer, rteijeiro and everyone else working for a better JS in Drupal.

Categories: Elsewhere

agoradesign: Drupal Commerce: building Commerce Discount rules based on node categories

Fri, 10/01/2014 - 15:59

Today I'll explain, how we've build our own Inline Conditions in order to support Commerce Discount rules based on taxonomy terms of product display nodes.

Categories: Elsewhere

OhTheHugeManatee: Drush Self Aliases

Fri, 10/01/2014 - 09:22

I ran into an interesting problem with the drush @self alias today. I wanted to pull a fresh copy of the DB down from a client’s live site to my local development copy. Should be as easy as drush sql-sync @self, right? I’ve done this a thousand times before.

And I’ve also ignored the warning message every time before, but today I thought I’d check it out:

WARNING: Using temporary files to store and transfer sql-dump. It is recommended that you specify —source-dump and —target-dump options on the command line, or set ‘%dump’ or ‘%dump-dir’ in the path-aliases section of your site alias records. This facilitates fast file transfer via rsync.

There are actually two possible solutions to this warning (that I can think of), and they illustrate some of the useful “power user” features of Drush that any frequent user should be aware of.

The warning is there because drush would prefer to rsync the DB dump from site1 to site2, rather than a one time copy. Rsync has lots of speed improvements, not the least being diff transfer. When transferring an updated copy of a file which already exists at the destination, rsync will only send over the changes rather than the whole file. This is pretty useful if you’re dealing with a large, text based file like an SQL dump – especially one that you’ll be transferring often. In order to use this efficient processing though, Drush needs to know a safe path where it can store the DB dump in each location.

First we’ll add the %dump-dir% attribute to our alias for clientsite:

~/.drush/clientsite.aliases.drush.php1 2 3 4 5 6 7 8 9 10 11 12 13 <?php // Site clientsite, environment live $aliases['live'] = array( 'parent' => '@parent', 'site' => 'clientsite', 'env' => 'live', 'root' => '/var/www/', 'remote-host' => '', 'remote-user' => 'cvertesi', 'path-aliases' => array( '%dump-dir' => '/home/cvertesi/.drush/db_dumps', ), );

Notice that %dump-dir actually goes in a special sub-array for path-aliases. This is very likely the only time you’ll need to use that section, since most everything else in there is auto-detected. This is the directory on the remote side where drush will store the dump.

Our options come in with the @self alias. In a local dev environment, the most common way to handle this is in your drushrc.php file:

~/.drush/drushrc.php1 $options['dump-dir'] = '~/.drush/db_dumps';

But this won’t work for all cases. You can also take advantage of Drush’s alias handling by creating a site alias with the settings you want, and letting Drush merge those settings into @self. When Drush builds its’ cache of path aliases, it uses the site path as the cache key (for local sites only). That means that if you have a local alias with the same path as whatever @self happens to resolve to, your alias options will make it into the definition for @self. So here’s the alternate solution:

~/.drush/clientsite.aliases.drush.php1 2 3 4 5 6 7 $aliases['localdev'] = array( 'root' => '/Users/cvertesi/Sites/clientsite', 'uri' => 'default', 'path-aliases' => array( '%dump-dir' => '/home/cvertesi/.drush/db_dumps', ), );

There’s just one, obscure caveat with the latter method: somewhere in the alias merging process, BASH aliases are lost. That means that ‘~’ stops resolving to your home directory, and you have to write it out (as I did above).

Have fun!

Categories: Elsewhere

PreviousNext: Come sprint with us on Drupal 8 Contrib at Drupal South

Thu, 09/01/2014 - 23:18

Friday February 14th is the DrupalSouth Code Sprint, and PreviousNext are decending en masse to Wellington, New Zealand, to participate.

As a team we've been discussing what we'd like to sprint on. We've collectively agreed that the sprint would be an opportune time to work on porting some of our favourite contrib modules to Drupal 8.

Read on to find out our plans and how you can get involved.

Categories: Elsewhere