Drupal News

Subscribe to Drupal News feed
Drupal.org - aggregated feeds in category Planet Drupal
Updated: 18 min 20 sec ago

Midwestern Mac, LLC: Honeypot for Drupal 8, 3 years in the making

6 hours 57 min ago

Almost three years ago, on Feb 19, 2013, I opened the 8.x-dev branch of the Honeypot module (which helps prevent form spam on thousands of Drupal sites). These were heady times in the lifetime of the then-Drupal 8.x branch; 8.0-alpha1 wasn't released until three months later, on May 19. I made the #D8CX pledge—when Drupal 8 was released, I'd make sure there was a full, stable Honeypot release ready to go.

Little did I know it would be more than 2.5 years—and counting—before I could see that promise through to fruition!

Advomatic: Automating Living Style Guides in a Drupal Theme

7 hours 42 min ago
Over the past year or so here, we’ve tried to make front-end development less painful by creating living style guides in our Drupal themes that we can use internally as a valuable resource during development, as well as externally as a client deliverable. They allow us to write consistent, reusable and efficient code that is easy to maintain over... Read more »

Drupal Watchdog: VIDEO: DrupalCon Amsterdam Interview: The Drupal 9 Question

9 hours 53 min ago

Taking advantage of the DrupalCon Amsterdam gathering of Drupal bigwigs – and in our eternal quest to quench our thirst for enlightenment, and thrust onwards into the future and deeper into the unknown – we corner some of those key Drupal players to ask the all-important question burning in everyone’s mind: When is Drupal 9 coming out?

Dries Buytaert (Drupal Creator and CTO & Co-Founder of Acquia): Nine?

MortenDK (Viking, geek Röyale): Oh! Ho-ho-ho!

Leslie Hawthorn (Director, Developer Relations, Elasticsearch): After Drupal 8.

Tom Erickson (CEO, Acquia): Drupal 9!

Michael Meyers (V.P. Large Scale Drupal, Acquia): I think that the real question is how fast can we accelerate the pace of innovation in the Drupal community and get to 8.1, 8.2, 8.3, and I’m a lot less interested in Drupal 9 right now.

Holly Ross (Executive Director, Drupal Association): How much time have you got?

Bastian Widmer (Development and Operations Engineer, Amazee Labs): Let’s first finish Drupal 8.

Robert Vandenburg (President and CEO, Lingotek): When is Drupal 9 coming out? Never! When pigs fly!

Fabian Franz (Senior Performance Engineer, Technical Lead, Tag1 Consulting): I’m still thinking about Drupal 7.

Kieran Lal (Technical Director, Corporate Development, Acquia): I actually know the exact time... When it’s ready.

Tags:  DrupalCon DrupalCon Amsterdam Video Video: 

NEWMEDIA: Improve your Frontend Toolset with Grunt and LibSass

10 hours 35 min ago
Improve your Frontend Toolset with Grunt and LibSassLearn how you can leverage Grunt and LibSass as groundwork to improve your Frontend Development process and deliver better optimized sites for clients.

At newmedia we've been utilizing Sass and Compass compiled with Ruby for CSS Preprocessing for quite some time now in our Drupal projects. While this toolset has served us well, the toolset for Frontend Developers has been growing and improving tremendously as time goes on. Thus, we want to leverage those tools not only to improve our day-to-day development tasks, but more importantly to better provide more optimized websites for our clients.

In this post we will walk through overhauling our Frontend tooling with Grunt and LibSass, what's involved, and what the benefits are for clients. For the purpose of this article, we're just going to focus on getting Grunt and LibSass up and running - from there the heavy lifting is done, and you're free to expand on your Grunt tasks as you see fit.

What's the client benefit?

Implementing these tools allows us to work faster and spend less time waiting for tools to run. The other key benefit is that, since Grunt runs arbitrary tasks, we can add more tools to ensure our end product is optimized - not just CSS, but also Javascript, images, and more, resulting in all-around faster-loading websites.

What are these Frontend tools & why are we using them?

Grunt is a task runner built in Javascript that leverages node.js. Currently, there are two popular task runner projects: Grunt and Gulp. While there are slight pros and cons between the two projects, we decided to implement Grunt for our Drupal projects, as our Wordpress team had already begun to use Grunt, and we wanted to converge some of our tooling and processes.

LibSass is an implementation of the Sass compiler written in C instead of Ruby. The primary benefit over the original Ruby compiler is a tremendous boost in speed resulting in much faster compile times.

Note on LibSass: Unfortunately LibSass does not yet have feature parity with Ruby Sass, but it's not too far off and continues to improve. This Sass Compatibility reference is handy for specific features that may be missing. Personally, I have yet to hit an issue with feature parity, but your mileage may vary.

Get the prerequisites in place

You will need node.js if you don't have it already. I suggest using the "n" version management tool to help manage your node install: https://github.com/tj/n

Once you have n installed, install the current stable version of node:

n stable

Next, you'll need to get a couple node modules installed globally: grunt-cli, the commandline interface for grunt, and bower, a dependency manager for web projects.

npm install -g grunt-cli npm install -g bower

From here, many of the node modules we'll need can be managed at a project level.

Setting up Grunt for your project

Now that we have our prerequisites in place, we need to set up three files within our project:

  1. package.json to manage our project-level node dependencies
  2. Gruntfile.js to define our tasks
  3. bower.json will be used to define our sass library dependencies (in our case, singularity and breakpoint).

Special note on Drupal projects: Currently, placing node_modules within Drupal's directory can potentially cause it to crash, and otherwise could negatively impact performance. We structure our repository so that we have the Drupal directory contained in a folder called docroot, so we handle node at the root level of our project repo above the Drupal directory, rather than at the theme level. See these Drupal Core issues for more information:

package.json

Here's our example package.json:

{ "name": "newmedia", "version": "0.0.1", "description": "newmedia grunt tools", "devDependencies": { "grunt": "^0.4.5", "grunt-contrib-watch": "^0.6.1", "grunt-sass": "^0.18.1", "load-grunt-tasks": "^3.1.0" } }

The devDependencies section defines the node modules we're using:

  • grunt (Grunt itself is installed on a per-project basis, only the commandline interface grunt-cli is installed globally),
  • "grunt-contrib-watch", which provides a watch tool (think sass watch or compass watch),
  • grunt-sass, which will bring in and manage libsass for us, and
  • load-grunt-tasks, which allows us to automatically load our grunt dependencies in, rather than manually specifying each one in our Gruntfile.js

As times goes on, you'll likely want to add dependencies to your toolset. Adding them with "npm install [name] --save-dev" will download the module for you and automatically add it to your package.json.

bower.json

Using the Ruby Sass compiler, you use Bundler to manage your Sass library dependencies. Bower will take the place of that in our Grunt/LibSass workflow:

{ "name": "newmedia", "version": "0.0.1", "description": "newmedia build dependencies", "authors": [ "NEWMEDIA!" ], "ignore": [ "**/.*", "node_modules", "bower_components", "test", "tests" ], "devDependencies": { "breakpoint-sass": "~2.5.0", "singularity": "~1.6.2" } } Gruntfile.js

Now that we have dependency management out of the way, we can setup our tasks. Here's our example Gruntfile:

module.exports = function(grunt) { // Load tasks automatically with 'load-grunt-tasks' plugin. require('load-grunt-tasks')(grunt); // Define our theme directory var themeDir = 'path/to /theme'; // Specify where to find dependencies we load in with Bower var sassLib = ['bower_components']; // Define the CSS files we want compiled from SCSS files var sassFiles = {}; sassFiles[themeDir + '/css/style.css'] = themeDir + '/scss/style.scss'; sassFiles[themeDir + '/css/print.css'] = themeDir + '/scss/print.scss'; // Project configuration. grunt.initConfig({ sass: { dev: { options: { sourceMap: true, outputStyle: 'expanded', includePaths: sassLib }, files: sassFiles, }, build: { options: { sourceMap: false, outputStyle: 'compressed', includePaths: sassLib }, files: sassFiles, } }, watch: { sass: { files: ['**/*.scss'], tasks: ['sass'], } }, }); // Default task(s). grunt.registerTask('default', ['sass:build']); grunt.registerTask('dev', ['sass:dev']); grunt.registerTask('build', ['sass:build']); }; Changes to your Sass

Now that we have the tools in place, we will need to update how we import our sass libraries. Fortunately this is a simple change. Here are our existing imports:

@import "breakpoint"; @import "singularitygs";

These imports get updated to:

@import 'breakpoint-sass/stylesheets/breakpoint'; @import 'singularity/stylesheets/singularitygs';

The exact change to your Sass imports may be different depending on the library. To determine the path you need to use, add the library to bower.json, and look inside bower_components to locate the library and determine the path to the main scss file to import.

Note on Compass

At the time of writing this post, Compass is still dependent on Ruby and can't be used with LibSass. Depending on your case, there are a couple options. If you are using Compass mixins and want to continue to use them, there is a compass-mixins library you can use with LibSass. If you primarily use Compass to handle vendor prefixes, you might want to look at adding Autoprefixer to your Grunt task instead.. If you're using other libraries that depend on Compass, it's likely that even using the compass-mixins library, you won't be able to use those libraries with LibSass.

Ready to Go!

At this point you should be in a good place to try running your grunt task. In our example, we have two defined tasks, build and dev, as well as our watch task. Try running "grunt dev" to do a one-time run. Once you are getting successful task runs, you are ready to start working on your project! You can now use "grunt watch" to detect changes and automatically run tasks.

You're also now at a good point to look at adding additional tasks to your workflow. Some suggestions would be to add tasks to handle optimizing your Javascript and image assets. You can find an expansive selection of tasks on the official Grunt Website’s plugin directory.

Nuvole: Drupal 8 Configuration Management with Features

12 hours 31 min ago
Use Features together with a configuration management workflow and get the best of both worlds.

This is a preview of Nuvole's training at DrupalCon Los Angeles: "An Effective Development Workflow in Drupal 8".

Features for Drupal 8 will exist and it is already in alpha state. This may be surprising to those who wrongly assumed that Configuration Management was going to supersede Features; but, as we explained before, it all comes down to understanding how to use Features the right way in Drupal 8.

If you are using Features in Drupal 8 for deployment of configuration, you are doing it wrong!™ The role of Features

While the configuration management was built to keep configuration consistent and enable deploying it between different environments of the same site it was not built for sharing configuration between different sites. This is where Features comes in. Features allows you to easily bundle related configuration and re-use it on another site.

For re-using configuration and building starter profiles the current alpha version is already great. It works just like the re-usable “feature” we were blogging about last year, except it comes with a familiar UI and lets you do everything as a site builder. It even comes with a smart system that auto detects configuration that belongs together.

Configuration changes are development

Developers and site builders working with configuration in Drupal 8 need to understand that changing configuration needs to be treated equally with development. While this may seem trivial at first, the consequences are a fundamental shift to the approach of building a Drupal 8 site.

Drupal 8 comes with the configuration management system that was built to deploy configuration between different environments of the same site. It allows the whole configuration of a site to be synchronized both through the UI for “site builders” and through drush and git for “developers”. While the system allows individual configuration objects to be exported and imported, deployment and synchronization is always done with the entire set to ensure it is consistent.

This means that when you change configuration on a production site you either opt out of using the configuration management to deploy configuration or you need to go through a more elaborate work flow to synchronize the configuration changes with the development environments similar to what you would need to do if you were to change code directly on the production server.

For the math-oriented,

Δ config ⊆ development

What if you want to be free of the temptation to edit configuration in production? Luckily there is a module for that! It is called Configuration read-only mode and allows to lock the forms where you change the configuration, thus enforcing its role as a "developers only" tool.

Of course some configuration will differ between environments. Just as the database credentials are kept separate from the rest of the code, specific configuration can be overridden in the instances’ settings.php or services.yml. The rest of the code is usually treated as a whole for consistency reasons, the same should be true for configuration.

What about not using configuration management?

Features and packaging related modules should not be regarded as a solution to deploy only partial configuration. Packaged configuration by definition is never aware of the whole site and the possible inter-dependencies of the site's particular configuration. Deploying only partial configuration circumvents the safeguards Drupal put in place to make the deployment more robust. Of course nobody is forced to use the new tools for configuration management and you can easily opt out of using it by just ignoring that option. It is also still possible to develop a Drupal 8 site by sharing a database dump just as with Drupal 5. But remember that a Drupal 7 approach will yield the Drupal 7 headaches. We would recommend re-evaluating the deployment strategies when starting to use Drupal 8.

Managing distributions in Drupal 8

The more complicated scenario which is yet to be tackled is a feature for a richer distribution which will update over time. For example a newer version of a feature could come with an updated view or additional or updated fields for a content type.

First steps in that direction have already been taken by Configuration Update Manager (a dependency of features) and Configuration Synchronizer (a sandbox module). Configuration Update Manager compares the configuration in use on the site with the configuration which was provided by a module or installation profile. Configuration Synchronizer goes a step further and keeps a snapshot of the configuration when it was installed in order to determine whether the configuration has been customized by an administrator or whether it can safely be updated to the one provided in the new version of the module/feature.

All the modules mentioned above are used in a development environment of a particular site. Or in other words in an environment where configuration changes are expected and part of the process of updating a site.

For more, see our presentation from the Drupal Developer Days (embedded below); thanks to all the people there for the fruitful discussions we had on this topic during the event.

Drupal 8 Configuration Management with Features from Nuvole Tags: Drupal PlanetDrupal 8DrupalConAttachments:  Presentation Slides - Drupal Developer Days 2015 Montpellier

Jim Birch: Drupal 7: Scheduling Posts with Scheduler

13 hours 1 min ago

The scheduling of posts was the first things I noticed that was missing from Drupal after moving over from Wordpress.  Thanks to the Scheduler Module, we have that functionality back, with more control over what and who can access it.

The Scheduler module allows for Publishing, and Unpublishing on a Content Type by Content Type basis.  You can set up Scheduled Publishing on the Blog Content Type.  Then, you can set up Scheduled Publish and Unpublishing on something like a Sale, or Contest Content Type.  You can also control which roles have access to the scheduling functionality, and the ability to see what content is currently scheduled.

You want to make sure you have an external Cron/crontab setup on your server, and make it run at the time that you schedule to ensure that your posts go out on time.  If no one is visiting your site it is going to sit idle and cached.  Cron sitting on the server, running on the server's clock, and the schedule you set up, will poke Drupal on that schedule just to say "Hey, How's it going over by there fella?  You need to be doing anything right now?"  Drupal is smart enough to say, "Yes, I need to do all of the things, thank you very much", and then does them.

Read more

Annertech: Annertech's talks at Drupal Open Days Ireland 2015

15 hours 18 min ago
Annertech's talks at Drupal Open Days Ireland 2015

We love to share our knowledge. At every Drupal camp and Drupal Open Days in Ireland (not to mention most DrupalCons and DevDays internationally) we give presentations. This year we are giving three talks at Drupal Open Days Ireland 2015. Here's what we'll talk about:

Red Crackle: Code quality guidelines for large Drupal projects

16 hours 31 min ago
Are you wonderig what code quality guidenlines your Drupal developers should follow in addition to Drupal's coding standards to make the code readable, secure and performant? What are the best practices so that developers can follow each other's code easily and make code review faster? Read this post to view the guidelines you should follow in addition to the Drupal coding standards.

LevelTen Interactive: Drupal 8 Makes A Strong Case For Your Enterprise

Sun, 04/26/2015 - 23:00

Deciding upon an open source, flexible, enterprise-ready solution for your marketing efforts, is a daunting task. Should you build custom solutions leveraging a framework, or adopt a pre-built CMS? What are the costs involved? Can you live with limitations or being boxed in? How well can it be supported?... Read more

Merge: Next Generation Web Apps using the Service Worker

Sun, 04/26/2015 - 14:05

The open web achieved a small but important milestone with the latest release of Chrome (42) and its added support for push notifications, offline usage and performance. These features are essential in closing the gap between native (IOS/Android) and web (HTML5) apps.

agoradesign: Naming conventions for D8 libraries

Sun, 04/26/2015 - 05:45
Given the fact, that in Drupal 8 every module and theme has to declare their CSS and JS files as libraries, we should think about and discuss naming conventions and best practices for these.

Bert Boerland: DrupalJam 2015, come for the Jam, stay for Drupal

Sun, 04/26/2015 - 01:22


Drupal. I didnt come to Drupal code 14 years ago, I came for the community and stayed for the functionality. That is part why I never liked the "Come for the code, stay for the community" slogan. Sure, it is a perfect cheesy slogan. If all you want attract are coders in the community, it is even a perfect slogan. For a perfect community, of perfect happy coders.

We have got to learn to address humans. Not just humans who can code. That is, if we want to be a true community for a product. A product that is well designed and does attract both the business and the user to participate in the product, the process and hence the community.

Leaderers. Entrepeneurs. Visionaries. Testesters. Document writers. Project Managers, marketeers. To name just a few. Of course developers can also have the skills to do these jobs, an often overlooked fact. But someone who is "just" a marketeer, will not come for the code. (S)He might come for the job at hand, money that might be involved, the functionality, but the best reason why an external non developer should come to the community to help out, is the community that is helping her/him out. Not clean lines of code, but helping hands of love.


This is I am active in the Drupal community, to help out to get others on board. With a rocking team ( Marja, Imre, Rolf and Peter and others) we are organising the DrupalJam event in the low lands. The DrupalJam started with 20+ persons and pizzas in a room and is now a big event with over 300 people attending, over 25 sessions and a budget in the tens of thousands.

DrupalJam -organised by the Dutch Drupal foundation- will be held in Utrecht, April 30 and it really represents the helping hands -not just the lines of code- of the community. With keynotes from Bruce Lawson ( HTML fame), Marco Derksen (digital strategist, entrepreneur) and featured speakers like Jefrey Maguire (moustache fame, D8), Anton VanHouke (leading design agency in the NL, introduced scrum in to strategy and design), Stephan Hay (designer, writer) and Ben van 't Ende (Community Manager for the TYPO3 Asssociation).

And like last year, Dries will do a virtually Q-and-A. If you want to ask him nearly anything, do so at this form.

The event will be held in an old industrial complex as can be seen in these shots

I am really looking forward to this event, it has a long tradition and always strengthened the community and brought in new blood. People who "Come for the business and stay for the community" Those who come of the need for design and stay for the love. Or love the functional and stay for organising the next DrupalJam.

PS: Now this head has rolled, it is time we decide what we do the body. If you have 5 minutes of your spare time, read this post and if you have one minute more, see this one from 2008 as well.

Drupal @ Penn State: Switching from one install profile to another

Sat, 04/25/2015 - 11:06

I recently had to switch profiles for this website. In the process of doing that, I immediately afterwards said “wow, I feel like other people have had this issue”. Sure enough they have… on this blog early last year by our own @aitala in the post How to Remove Drupal Install Profile.

A Dev From The Plains: Yeoman Generators for Drupal: What’s out there?

Sat, 04/25/2015 - 05:39

 

 

 

 

 

 

I’ve been hearing about Yeoman for quite some time now. Pretty much since the project took off, or soon after. As a tool born in the Javascript community, I came across this little gem when I was learning about Node.js and the different tools and frameworks available for it, either in my free time, or as part of my labs time at my company. Sadly, I didn’t really pay much attention to it. At the end of the day, Node.js was just something I was learning about, but not something I was going to be able to put in place or introduce in projects in the short term. Or, even if it was something I *could* do, it wasn’t in my plans, anyway.

The other reason why I didn’t look into it closer, was that I mistakenly thought it to be a tool only useful for Javascript developers. Some time ago I noticed that Yeoman was getting plenty of attention from other communities too, and in a closer look, I understood that it wasn’t a tool for Node.js, but instead, a tool built on top of Node.js, so I decided to give it a try and see if I could make something useful out of it for Drupal development.

Warming up…

So, what’s Yeoman then? It’s a code scaffolding tool. That is, it’s an utility to generate code for web apps. What’s the purpose of that? Well, the purpose is that developers save time by quickly generating the skeleton of the web apps they build, leaving more time for the important things, such as the most complex business logic of the app, integrations, testing, etc… In short: it’s a tool that should help developers deliver more quality in their apps. To get a better picture of what Yeoman can do, I’d point everyone at their site, which has some nice tutorials and a very good documentation for writing your own generators.

My plan was to write a few generators for the most common pieces of boilerplate code that I normally have to write in my projects. Unsurprisingly, I found that there are a few yeoman generators for Drupal already out there, so I thought I should review them and see if they’re of any use to me, before writing one that already exists. Yes, that can be a boring task if there are too many generators, but I was lucky that there aren’t *that* many for Drupal, so I just spent a couple of hours testing them and documenting my findings. Hopefully, this blog post will help other Drupal developers to find out in a matter of minutes whether the existing generators are useful for them or not. So, let’s get into it!

1.- Generator-drupalmodule

Github repository hereCreation date: Around 2 years ago.

Structure created:

module: |- drupalmodule.css |- drupalmodule.info |- drupalmodule.js |- drupalmodule.module |- package.json

This one scaffolds a basic structure for a simple module. Needs bower and a package.json file to download dependencies, but not a problem anyway since you’ll probably have drush. Creation is a bit unintuitive: you need to create the module folder first, cd into it, then execute yo drupalmodule.

The generator asks if you want JS and CSS files, but it doesn’t even add functions to add them to the page. It’s a generic purpose generator, and doesn’t have anything that is not in module_builder already.

2.- Generator-drupal-module

Github repository hereCreation date: Around 2 months ago. Latest commit about 2 weeks ago.

Structure created:

module: |- templates (if hook_theme chosen). |- drupal_module.info |- drupal_module.install |- drupal_module.module

More neat than drupalmodule in the surface, but doesn’t do much more. It asks us if we want hook_theme(), hook_menu(), hook_permission() and hook_block_info / view implementations, which is nice, yet that doesn’t make it much of a gain compared to other simple scaffolding tools, like PhpStorm live templates. In contrast to the drupal-module generator, this one doesn’t ask us if we want a CSS or JS file.

3.- Generator-drupalentities

Github repository hereCreation date: 9 months ago. Latest commit about 6 months ago.

Structure created (“publisher” entity):

Views and license files are optional, based on the settings specified in the command-line.

module: |- views |- publisher.views.inc |- publisher_handler_delete_link_field.inc |- publisher_handler_edit_link_field.inc |- publisher_handler_link_field.inc |- publisher_handler_publisher_operations_field.inc |- LICENSE.txt |- publisher.admin.inc |- publisher.info |- publisher.install |- publisher.module |- publisher.tpl.php |- publisher-sample-data.tpl.php |- publisher_type.admin.inc

Generates a full drupal module for a custom entity, based on the structure proposed by the model module.

One issue I experienced is that if I select to “add bundles”, the Field API screen seems broken (doesn’t load). However, a general “fields” tab appears, but if you try to add a field, you get some errors and get redirected to a 404. So, bundles are offered on the plugin creation menu, but not really supported! Same for revisions. It’s asked on the command-line prompt, but doesn’t seem to do much. Not choosing bundles support, still lets you add bundles on the admin UI, and doesn’t seem to break anything, though.

In spite of the issues I had testing it (I didn’t bother much investigating what was the issue), it seems to me an useful generator. The only reason why I doubt I’ll be using it, is that it’s based, as mentioned, on the model project for Drupal, which is quite nice, but rather outdated now (4 years old), and doesn’t leverage some of the latest Entity API goodies. Also, I’ve developed some opinions and preferences around how to structure custom Entity Types, so starting to use the model approach would be, in a sense, a step backwards.

4.- Generator-ctools-layout

Github repository hereCreation date: 5 months ago. Latest commit about 14 days ago.

Structure created:

my_layout: |- admin_my_layout.css |- my_layout.css |- my_layout.inc |- my_layout.png |- my-layout.tpl.php

Generates a ctools layout plugin folder structure, with all the files needed to get it to work out of the box. It makes no assumptions about how the content will be displayed, so there’s no styling by default (which is perfect), and it allows to specify as many regions as desired. It’s quite likely that I start using this in my projects. No cons or negative aspects to mention!

5.- Generator-gadget

Github repository hereCreation date: 1 month ago. Latest commit about 1 month ago.

This one, rather than a code generator for Drupal elements, is a yeoman generator to serve as an scaffolding tool for another repo from Phase 2. While I didn’t get to test it out, the grunt-drupal-tasks repo really looked interesting (check the features here), and I might try to give that a go, although I’m familiar with Gulp and not with Grunt. Long story short: very interesting project, but it’s not meant to scaffold any code for your drupal modules.

6.- Generator-drupalformat

Github repository hereCreation date: 6 months ago. Latest commit about 3 months ago.

Structure created:

drupalformat: |- includes |- js |- drupalformat.settings.js |- theme |- drupalformat.theme.inc |- drupalformat.tpl.php |- drupalformat.api.php |- drupalformat.info |- drupalformat.install |- drupalformat.module |- drupalformat.variable.inc |- generator.json |- LICENSE.txt

This one is very specific, tailored to provide views and field formatters for jQuery plugins, and it’s based on the owlcarousel module. It’s very useful if what you’re looking for is to easily integrate other jQuery plugins with your Drupal site. Very interesting generator, as it’s focused to scaffold the most repetitive parts for a very specific task, instead of trying to be a very generic solution that covers many things. You can see another great example leveraging this generator in Echo.co’s blog, for the jQuery Oridomi plugin. Not something that I have to pick up daily, but I’ll definitely have this plugin in mind if I have to integrate new Javascript libraries.

7.- Generator-drupal-component

Github repository hereCreation date: 6 months ago. Latest commit about 3 months ago.

Structure created:

drupal_component: |- ctools-content_types |- drupal_component.inc |- drupal_component.scss |- drupal_component.html.twig |- drupal_component.info |- drupal_component.js |- drupal_component.module |- drupal_component.tpl.php |- drupal_component.views.inc

I found this one rather peculiar. The boilerplate code it produces is rather basic, yet offers options such as creating a views style plugin by default, or a ctools content_type plugin. The good thing is that each component can be generated individually, which is rather convenient. The only issue that keeps me from using it is that, again, none of the components offer any options particularly advanced that could benefit from having an interactive tool like Yeoman (e.g: asking whether the ctools content type plugin will need one or more settings forms). For my particular case, I can generate all of these easily with PhpStorm live templates or template files easily.

Is that all, folks?

Ye… no! There are indeed a few more generators thought around drupal projects in the Yeoman registry (click here and search by “Drupal”). Some of them are very interesting, to do things such as:

However, I decided to leave those out of an in-depth review because, as interesting as they are, they cover several aspects of Drupal development, and people often has very specific preferences about how to structure a theme, for example, or what tools to use in order to create a Headless Drupal. 

Since the goal of this article was to give a bird’s eye view of what generators Drupal developers can use right now without changing anything in the way they work, I preferred to describe mainly the generators done around drupal modules, and more specific components. Hope this blog post has saved you some time. Expect to see a new one on this topic as soon as I’ve written my first Yeoman plugin.

Forum One: Edge Toolkit: Staying Relevant in the Long Run

Fri, 04/24/2015 - 09:01

Launching a website is just the beginning of a process. Websites need nurturing and care over the long run to stay relevant and effective. This is even more true for a service or tool such as LibraryEdge.org. Why would users come back if they can only use the provided service once or can’t see progress over time? And how can you put that love and care into the service if it is not self-funded?

This month, LibraryEdge.org released a number of changes to address just these issues.

Helping Libraries Stay Relevant

Before we dive into the release, here’s a bit on the Edge Initiative.

With the changes created by modern technology, library systems need a way to stay both relevant and funded in the 21st century. A big part of solving that problem is developing public technology offerings. Even in the internet-connected age, many lower-income households don’t have access to the technology needed to apply to jobs, sign up for health insurance, or file taxes, because they don’t have personal computers and internet connections. So where can people go to use the technology necessary for these and other critical tasks? Libraries help bridge the gap with computers and internet access freely available to the public.

It’s important that libraries stay open and are funded so their resources remain widely available. By helping library systems improve their “public access computers/computing,” the Edge Initiative and its partners have made major strides in making sure libraries continue to be a valuable resource to our society.

That’s where LibraryEdge.org comes in. The Edge Coalition and Forum One built LibraryEdge.org in 2013 as a tool for library systems to self-evaluate their public technology services through a comprehensive assessment – plus a series of tools and resources to help library systems improve their services.

New Functionality Reassessment

The biggest feature update we recently launched was enabling libraries to retake the Assessment. They can see how they have improved and where they still need work compared to the previous year. To create a structure around how libraries can retake the Assessment, we built a new feature called Assessment Windows. This structure allows the state accounts to control when the libraries in their states can take the Assessment. States now have control over when their libraries conduct the Assessment and can track their libraries’ goals and progress on Action Items. This feature allows states to more accurately assess the progress of their libraries and adapt their priorities and programming to align with library needs.

Results Comparison

The Edge Toolkit was initially built to allow users to view their results online, along with providing downloadable PDF reports so libraries can easily share their results with their state legislatures and other interested parties. Now that libraries can have results for two assessments, we’ve updated the online results view and the PDFs. Libraries can now see a side-by-side comparison of their most recent results with their previous results.

Graphs

It’s common knowledge that people retain more of what they see, so we’ve also visualized important pieces of the results data with new graphs. If a library has only taken the assessment once, then the charts will only display its highest and lowest scoring benchmarks. However, if they’ve taken the assessment a second time, they can also see bar graphs for the most improved and most regressed benchmarks.

Improved User Experience Interviews

We made a number of enhancements based on feedback from libraries that have been using the tool for the past couple of years, as well as from interviews that we conducted with State Library Administrators. Starting with a series of interviews gave us great insight into how the tool was being used and what improvements were needed.

New Navigation

The added functionality of being able to retake the Assessment increased the level of complexity for the Edge Toolkit. So we redesigned the interface to guide users through this complex workflow. We split out the Toolkit into four sections: introduction/preparation, taking the assessment, reviewing your results, and taking action. This new workflow and navigation ensures a user is guided from one step to the next and is able to complete the assessment.

Notification Messages

Several dates and statuses affect a library system as they work through the assessment, such as how long they have to take it and whether it is open to be retaken. We’ve implemented notifications that inform the user of this information as they are guided through the workflow.

Automated Testing

When we release new features, we need to ensure other components on the site don’t break. Testing this complex of a system can take a long time and will get expensive over the lifetime of the site if it’s done manually. Furthermore, testing some sections or statuses involves taking a long assessment multiple times. In order to increase our efficiency and save time in our quality assurance efforts, we developed a suite of automated tests using Selenium.

What’s Next for Edge

The updated LibraryEdge.org now allows libraries to assess their offerings again and again so they can see how they are improving. Additionally, we’ve built a paywall so Edge can be self-supporting and continue to provide this valuable service to libraries after current funding ends. The launch of this updated site will help Edge remain relevant to its users and, therefore, ensure libraries remain relevant to our communities.

Lullabot: Distributed Design

Fri, 04/24/2015 - 07:27

Design work is a lot of show-and-tell. It can be challenging to effectively communicate and collaborate on a distributed team. Join hostess Amber Matz, Lullabot Creative Director Jared Ponchot, Lullabot UX Designer Jen Witkowski, and Justin Harrell, Interactive Designer for Drupalize.Me, as they talk about the unique challenges, processes, and tools they use as part of a distributed team.

Jim Birch: Drupal 7: Offsite Backups with Backup and Migrate

Fri, 04/24/2015 - 07:00

At the time of this writing, just under 300,000 websites use the Drupal Backup and Migrate module.  It is an great tool for moving databases from production back to staging and development servers, and it is an essential tool for automatic backups of the database and files of the production server.

About a year ago, Version 3.0 was released, which integrated the offsite functionality from another module, and brought additional functionality, like files and code back ups.  This is what I would like to go through today in the steps below.

Why offsite backups?

I hope by now everyone has heard of the Backup 3-2-1 Rule.  If you haven't, it is a good thing to strive for in all things digital.  The rule mentions "In case your house burns down", but in our case, with web servers, there are a lot more risks.  The server could get hacked.  The developer or client could accidentally delete.  The hosting company could go out of business.  There are probably a lot more reasons that I sudder to think about!

Read more

Acquia: Yhteisöllisyys and global Drupal: "Friendships beyond business"

Thu, 04/23/2015 - 15:31
Language Undefined

If only non-Finns could easily pronounce it, I think "yhteisöllisyys" would be a perfect motto for Drupal. To explain what it means, I dragged Lauri Eskola, Drupal Craftsman from Druid.fi, away from the contribution sprints at DrupalCamp Brighton 2015 long enough for him to fill me in on that, as well as his trip to Drupal Camp Delhi 2015, what he's excited about in Drupal 8, and how doing business in the Drupal world–based on values like sharing and openness–must seem strange and different to outsiders.

Pages