Drupal aggregator

bertboerland posted a photo:

bertboerland posted a photo:

bertboerland posted a photo:

bertboerland posted a photo:

bertboerland posted a photo:

Once/if you have multiple languages configured on your website, selecting from them for the page becomes an important question. The Drupal 8 language detection and selection options are located the same place they were in Drupal 7 but almost all options got some improvement.

Useful out of the box

Drupal 7 only had the default language detection method turned on, so even if you kept adding in more and more languages (and even if you enabled the language switcher block), the URLs did not work. You still needed to get here and configure the URL detection method. Now this is built-in, so adding languages and placing a selector block would in itself make multiple languages accessible.

Query coder allows you to convert SQL queries into dynamic queries. The module offers a simple UI where you can paste in a SQL query, press submit and then you're presented with a dynamic query code example.

In Drupal 7, you can query the database in two ways; using a static or a dynamic query. Static queries are the simplest to write and the fastest from a performance stand point. A static query will suffice for general SELECT queries.

Dynamic queries on the other hand can be tricky and takes some getting used to. One benefit of using it is that other modules can modify the query by implementing hook_query_alter.

In my new position at Drupalize.Me I have the luxury of helping a lot of projects in little ways. Being able to context switch quickly helps a lot. This means I've put a lot of time into how my workstation is setup so that I can easily move from one project to another. With the new job I also decided to add OSX to the mix of computers that I use on a daily basis.

read more

While working for Acquia in the last few months – helping them maintain Drupal Gardens – I had two tasks that required to write small modules. In this blog post, I would like to introduce these modules.

Safer Permissions

The first one is Safer Permissions.

Written on June 18, 2013 - 11:27

First of all: I'm a featured speaker. I'll be hosting a session called 'Drupal 8 for Site Builders'. Come and watch to get an overview of all the wonders and power Drupal 8 has for creating a site. However, there are other reasons to attend DrupalCon Prague, and they are not Drupal related at all.

Kutná Hora

Kutná Hora is a little town, about 80 kilometers away from Prague, world known for its Sedlec ossuary which contains a lot of human bones, used for decorating the inside. While this may sound luguber, a visit to this small chapel is not something you will ever forget. And if you don't go inside, the top of the chapel has a skull, they really thought about everything. The easiest way to get there is by train and even arriving in the small station is worth travelling. I have seen it already, but will be going again, so feel free to join me.

CERN opendays

CERN, the European Organization for Nuclear Research, is opening its doors on 28th and 29th of september for the public for it so called CERN opendays. CERN lies in Geneva, Switserland, about 8 hours driving from Prague, or maybe 1 hour flying by plane. You'll be able to go down 100 meters underground and look at the Large Hadron collider and all other amazingly cool experiments scientists and engineers perform. Unless you are Daniel "dawehner" Wehner, you don't get that many chances to visit this place in your lifetime, especially since they only open it up publicly every 4 years. Tickets are for sale starting August, so keep an eye on the website if you want to go. That means I won't be attending the post-sprints, but honestly, I can live with that.

The DrupalCon Prague team welcomes you to submit to our call for content for our September conference.

Why content, not papers? Well, the DrupalCon program has changed since we last did the call. We've listened to feedback from DrupalCon attendees, and we're hoping our new direction will really resonate with our audience. In addition to our regular great offerings of Sessions, BoFs, CXO, Keynotes and Training, we're excited to roll out a few new initiatives.

Recently, I had a need to be able to backup a Drupal database but to skip a number of tables that I didn’t care about; mostly tables related to caching. Given most of these tables are prefixed with cache*, I was hoping for a way to specify tables to ignore using a wildcard character like ‘%’ or ‘*’.

A discussion on responsive Sass strategy and how to solve the common problem of numerous grids needing varying numbers of columns across many breakpoints. Can we accomplish this with one mixin?

ESDevelopment posted a photo:

Desarrollo de Web Dinámica con CMS Drupal
dsh.mx

Building sites using Drupal Commerce is something we often do at Marzee Labs, but when EnjoyThis approached us to build an e-commerce site for The London Distillery Company featuring a “design your own whisky cask” part, we immediately seized that opportunity to do something different. In this post, I’ll review the architecture of the project.

Challenges

The new site for The London Distillery Company had to appeal to a young urban crowd. EnjoyThis took on the challenge of creating a visually appealing design using big images, bold typography & plenty of videos (which they shot themselves).

Drupal Commerce was chosen to build the site, which needed a lot of customization that would have been beyond most open-source ecommerce platforms. We needed multi-country & multi-continent shipping which influences shipping costs, delivery times & taxes. We also needed to offer customers the possibility to use coupons, so they’d get free shipping, receive a percentage off their purchase, or get a free bottle for every three bottles they buy.

The most challenging part of the project was to allow visitors to design their own bespoke casks, choosing from options such as barrel size (40 liters, 180 liters, or 220 liters, for the very thirsty ones!), wood type and barley. Every one of these options has a different price and attributes, and some of the options would in turn enable more options. For example, if you pick the Maris Otter barley type, you might want to take the peated or the non-peated version.

After the user has customized his or her own cask, we allow them to share their configuration via mail, Twitter or Facebook, so we needed unique URLs for every cask combination.

The first step in the “design your own whisky cask” process. Selecting a different option triggers an AJAX request that loads a different product combination. Try it out yourself.

UX and Front-end

The secret of marrying a good UX implementation to the one-pager “design your own cask” is very simple: relying on what Drupal Commerce gives us. The danger would be to sink in heavy template usage to accommodate the markup. Instead we used a couple of preprocess functions, as well as the standard and almost untouched commerce HTML.

Javascript-wise, we pass very limited amount of variables from Drupal PHP to Drupal behaviours, and hook our code to rely on what Drupal Commerce gives us. This means that we don’t have to hack our way around, and can keep the custom code down to a fairly human, understandable level. That said, we did hit a few walls, and butted our heads against the desk a couple of times, especially in some event bubbling that commerce was “offering” us.

All in all, the best decision we made for this uncommon commerce page was to keep most of what Drupal Commerce would give us out of the box and do a make up with jQuery rather than reinventing the wheel.

Under the hood

To build out the “design your own cask” tool, we started from a description and a price for each of the attributes that would made up the final cask: a 20-liter barrel costs that much, adding the peated option would add that much, etc.

We made the maths and found that a user can chose between roughly 200 different cask combinations. Each combination is built out as a separate product and bundled in one single product display (see the bespoke page), taking advantage of Drupal Commerce’s flexible product / product display separation. We built a script to generate the different combinations, and used Commerce Feeds to get that data into Drupal. Future price changes are then easily synced using the built-in synchronization of Commerce Feeds.

Each combination also shows a breakdown of the costs of each selected attribute. Selecting the “peated” option for the barley type would add an additional 200 pounds for example. We store that data in a separate node that is referenced from the product entity. Every time an attribute is selected by the user, we receive a correct reference to the price breakdown node of that particular combination and extract these components using jQuery.

The third step in the cask configuration. The visitor can choose the type of barley, which in turn triggers new choices.

We are very happy with the final site, especially the "Bespoke Tool" which we recommend you try out. Drupal Commerce proved to be a very flexible framework, even for a use case that requires more than just the typical product pages.

Disclaimer: our friends at EnjoyThis designed the whole site, including beautifully shot images and videos to promote the whisky distillery. Marzee Labs architected and implemented the e-commerce part using Drupal Commerce and implemented the User Experience of the “design your own cask” part.

Drupal makes it easy to add fields to your site, which you can use to trigger custom functionality in your modules and themes. It's nice, but there's also a dark side. As sites grow more complex, these fields can get out of hand, resulting in one or more of these outcomes:

• An utterly exhausting number of fields, without any way to see which ones are important
• Fields without any logical grouping 
• Fields that do nothing
• Fields where certain combinations of choices result in poorly displayed content or broken functionality
• Fields more suitable for admins than content creators

These problems grow out of fairly innocuous roots. Let me use a simple example:

You've added a field to your page content type called "layout" which lets you choose between two options: a page layout that prominently displays the image you've uploaded to the image field, and one that emphasizes text without displaying any image (you use some CSS being the scenes to do this magic).

Naturally, choosing the "Strong Text w/out Image" option, turns the image field into a "field that does nothing." It's easy to justify, but the more you let this, and other field mismanagement creep into your UI's, the more frustrated your new users will become.

Fortunately, we have some options for managing these kinds of issues:

• The Conditional Fields module provides an admin UI for letting you set up dependencies and conditions for fields without any programming. One great use is to hide "fields that do nothing" based on the contents of previous fields. It's like usability gold.
• The Field Permissions module lets you hide fields on a user permissions basis, which is great if you've got advanced functionality in fields, and you really want to simplify things for content creators.
• The Field Group module lets you combine fields into groups with a variety of UI options, like collapsible containers, vertical tabs, horizontal tabs, and others. This is great for providing whatever form interface is most intuitive for your users. You can also look into the Field Collection module for a additional options.
• The Computed Field module lets you dynamically pre-populate fields with whatever values make sense. Smart default values = big win for users.

If you'd rather make changes in the code than the UI, the Form API in Drupal 7 has a lot of the features that these modules provide. Form states allow developers to programmatically trigger behaviors like hiding, showing, or populating fields based on the states of other fields. Collapsible fieldsets allow for logical grouping of fields and you can set whether their collapsed by default or not.

And being sensitive to the default state of fields makes a huge difference. Here's my usability rule of thumb, regardless of whether I'm using contributed modules with admin UI's or the Form API that comes with Drupal:

Required fields (or those of major importance): Expanded by default
Optional fields (or those of minor importance): Collapsed by default
Fields that do nothing: Hidden

What advice do you have for managing fields in Drupal?

We have rolled out an experimental feature to export tours (in Inline Manual terminology Topics) that are compatible with Drupal 8 tour module. You can now use the Authoring tool and Inline Manual infrastructure to manage your tours. These exported tours you can play out of the box in Drupal 8. If you are after more advanced solution, that can be used for your clients, check out the Inline Manual module.

Currently I am developing a module for our own issue tracker. Of course our issue tracker is build in Drupal; so it is a Drupal module. The development started, after I tried the Dashboard module in core, and some contrib modules. I will leave those unnamed. Not that there is something wrong with the modules, they all have their audience, but I want to take it a step further.

First I must admit: I am a big fan of Panels. I know, I know... something must be wrong with me; It is slow, it is for site builders, not for real programmers, and all kinds of other arguments... I say: blah, blah, blah. I am not here to argue about Blocks vs Panes or Display Suite and Context. Been there, done that (And believe me, we do a lot of Drupal module development)... I just prefer Panels and Panelizer for most use cases; period.

With that out of the way, I can come to the point; Why develop a new module, when there are already good Dashboard modules? The reason is simple. It is not 'only' a dashboard module, users can change the way they see a page. They don't have to be owner of the content, they just drag-n-drop the order in the display and show or hide stuff to their liking. Another user can drag-n-drop the order of the same content to his or her liking. So... how to use it, and what is so cool?

How I came to development of this module.

First forget Panelizer for a moment. We start with Panels and the Page manager of ctools. It is standard behaviour of Panels that you can override a node view page, so that you can use Panels to construct the node page.
Suppose there is a node type called 'issue'. That node type holds all issues (dûh). The node type has a lot of fields like detailed description, assignee, project, status, attachments and more... We need all those fields.. they have a purpose, but it also gives us a display nightmare. Different users find different stuff important. Account management only cares about the hours and how fast things are picked up, project leads want a decent way to estimate and relate stuff and the developer need to access all the fine details, including the attachments.
So what I did was overriding the default node view with a Panel and started playing around. Assignee at the top, description lower.. etc, etc. It took me a while to figure out a way to display everything and to have a display that I liked. First my buddy from account management showed up in my office... "Listen, I realy like your hard work (typically a sales guy), but I want to see also all previous issues for this project, or maybe even every issue from the same client, and can client name go on top, together with the reporter?". Luckely I did build it all with Panels, so 15 minutes and some Views magic later, I did my job... Happy sales guy!
Next in line was the Project lead. "Can't we show related issues? Issues might have something in common because of a particular modules or so.." No, is not an answer for a devoted developer, so again some views, search api thingies... and woot! I did have a cool pane with related stuff. Then a developer showed up. "What is all this stuff on my issue pages? It is way to crowded... Just give me clear instructions, don't bother me!" Woops... developers... they have their own way of saying things.. All I understood that something was completely wrong.

How to fix this with a custom module?

It was clear that there never could be an agreement on what field on top, what is important and what not to display on that page. So I developed a module called Panels User Override. The administrator provides a 'sane' layout of the page. He even provides some extra stuff that is not in the normal display. A user then can drag-n-drop the way he/she sees the page. So every user can have the issues his or her way, without me doing anything... fantastic! This module also opend the way for a new frontpage of our issue tracker. It will be (in the near feature) a Panel page, with way more possibilities then our friend 'Dashboard', that only works with 'Blocks'.

What this module is not.

It is not Panelizer. It cannot be compared to Panelizer. I see no reason why it cannot work together with Panelizer from a technical perspective, but I cannot come up with a use case. I think you will create a nightmare for your users. You then can override displays that are already overriden per node... See a whole thread on this topic in the issue tracker of this module.
I already did make the module available it in my sandbox on drupal.org, but it is not ready to promote it to a full project. It might never see the full project status. One of the main problems is the way it does access checks now... it simply doesn't do any access checks. So you can also override Panels, that you have no access to, and drag-n-drop panes that are not available for you. Not a real problem... it does no harm that you can change the order on things you will never see, but it is weird for the user. I do have some ideas how to fix that.
Problem is that I don't have a context on edit. Possible ways to solve this are:

1. The edit/override can only be started from a context (e.g. edit THIS layout). Thing is that this doesn't make it clear that you also edit the same display for all other contexts (nodes).
2. Leave all intact as it is now and load a default context on edit. But I simply cannot figure out a way... how to do this? I see that the developers of Panels have the same issue with this, because the preview is also loaded without a default context....

Well.. test it, review it, patch it and come with better ideas! But don't depend on it. It might change, dissapear or never be touched again, without notice. So use this custom developed module at your own risk!

Adding color support to a Drupal theme allows site owners/administrators to modify the theme's color scheme directly from a settings page, rather than having to edit any CSS.

I'm currently assessing color integration options for Neptune and have found DesignKit to be a quick, easy, and flexible alternative to direct color module itegration (as used by Garland and Bartik). On the flip side, there are a couple of caveats (see below).

This tutorial will focus on implementing basic color configuration, although DesignKit also supports image configuration and more advanced color configuration (including color blending/shifting).

On Tuesday, June 18, at one o'clock EDT, I will be on a panel for an Ask Me Anything (AMA) on Reddit - http://www.reddit.com/r/IAmA/ - The topic will be ALS and Assistive Technology.

So why should you attend?

First, it's only an hour or so, and it'll look better if more than one or two people show up. Besides, it'll be a great opportunity to spend your lunch hour with me. Being online simply makes it that more simple.

Next, if you have any pressing questions, such as how do you manage to write awesome modules for Drupal when your hands are completely useless, then this is your opportunity!

My qualifications: I was diagnosed with Lou Gehrig's Disease about two years ago, just before my newborn's first birthday. At first, my arms and hands were weak, so I purchased a magic touch pad and keyboard for the mac. By September, I needed to supplement this with Dragon Dictate (Naturally Speaking on the PC). This combination served me well until last year, when my hands became too weak to control the touch pad, so I began looking at eye gaze solutions.

The first iteration was a custom built eye gaze tracking system built by my father, from an open source concept over at http://www.eyewriter.org/ . It was cumbersome and difficult to calibrate, however, so beyond a couple of proof of concept demonstrations, I didn't really use that much.

Then about July I got a head tracking piece of software for the Mac, which served me well for a few months. However, it was doomed from the start, as my neck strength was already failing.

So in September of last year, I finally got a Tobii PCEye, and used it to control the mouse, while I continued to use Dragon to dictate code and emails to the computer.

Finally, this January, my voice had degraded to such an extent that I gave up struggling to keep training and retraining Dragon, and now use the Tobii, in combination with Dasher, an open source word predictor for use with eye gaze systems, to control all aspects of the computer.

I'm planning to get a stand alone Tobii system next month, which will allow me to speak when I have lost that ability entirely, using my own voice banked with Model Talker, and have also begun a trial using a brain computer interface (BCI) for the possible loss of eye movement in the future.

By far the best thing I have done during the course of this debilitating illness has been to try to stay one step ahead, by training myself to use the next bit of software or hardware before I actually need it. I believe that where medicine has completely failed patients with ALS, technology has taken up the banner, and offers the only hope.

So join me Tuesday at 1:00 for an AMA on Reddit, to have a chance to chat with me live. I'll post the URL here and on Twitter: http://twitter.com/aaronwinborn soon before the session starts.

read more