Subscribe to feed Planet Drupal
Drupal.org - aggregated feeds in category Planet Drupal
Bijgewerkt: 3 uur 58 min geleden

Jim Birch: Essential Drupal: Global Redirect Module

7 uur 11 min geleden

The Global Redirect module ensures that we will have the best possible technical output from Drupal for Search Engine Optimization (SEO).  It is available for Drupal 6 and Drupal 7, and it looks like they have been hard at work building it for Drupal 8.

For years, the best practice for any site is to make the URLs keyword rich and friendly so the user knows what to expect when they visit.  So we change Drupal's "Clean URL" settings from jimbir.ch?q=node/27 to jimbir.ch/node/27 and then we change Pathauto's settings from jimbir.ch/node/27 to jimbir.ch/blog/essential-drupal-global-redirect-module.

What we are missing is that those original URLs still remain live on the internet, and can be considered duplicate content, a detriment to good SEO.  Global Redirect automatically sets up 301 Redirects for both of the old URL schemes, to the new friendly URL.

The same goes for the trailing slash.  This module removes (or adds if you so choose) the trailing slash, so there will be only one canonical URL living between jimbir.ch/page and jimbir.ch/page/

The last big option is the home page.  In Drupal's Site Information, we set which node we want as the site's homepage.  Global Redirect makes sure that we only have one page indexed, rather than jimbir.ch and jimbir.ch/home.

There are quite a few more options that can be configured at:

Read more

Categorieën:

ERPAL: 6 steps to avoiding unrealistic budgets and deadlines in projects

7 uur 21 min geleden

In our preceding post we focused on the topic of "responsibilities and communication" and the importance of questions that help to clarify duties and responsibilities. Today we’ll deal with unrealistic deadlines and budgets – and how to avoid them.

An 800-hour project is not finished in a day, not even with 100 programmers. The completion time of a project is derived from the sum of the times estimated for the individual requirements. In order to do this reliably, it’s essential to know in detail what has to be done. This is why requirement engineering is vital at the beginning of a project. Even though a deadline (completion date) is determined by the sum of expenses, it’s important to note that not everything in a project can run in parallel, meaning that more is not always faster. A project plan for the overall project and for every single sprint will help you to control the progress, expenses and deadlines.

1) What task requires what expertise?

Not every job requires the same expertise. In addition to technical skills, there are often technical requirements that are necessary to reflect specific customer business processes in the software. These requirements should be stated in the individual tasks. It’s part of the project management to make this categorization a responsibility of the developer. If you optimize your project plan, for example with a Gantt chart, you can plan resources such as time, money and people at the beginning of a project and validate the plan accordingly.

2) Which developers can do which tasks?

One developer is not equal to every other developer. Everyone in the team has specific competencies: you get selected for a project because your skills fit well. Even in software development, it’s rarely the case that everyone all has the same expertise. A good Drupal developer is not necessarily a good site builder nor a good themer. You might make this assumption when hiring a person, but you’ll be disappointed if you don’t verify his/her skills. Therefore, you should be able to associate the expertise of your team with the specific tasks on hand. A good way to illustrate the dependencies of tasks is with a Gantt chart: for realistic budgeting you need a detailed plan so that you know, as a provider, what you have to achieve over which period of time. On the customer side, a detailed plan with clear time estimations helps you know what you’re getting for your money so you can rest assured that all the features – such as deadline, budgets, prices and specifications – are realistic. This is necessary because you want to achieve something positive with your project and, thus, have to rely on the data from good and realistic planning. The deadline is determined by adding up the times required by each developer in the team, taking the dependencies of each task into account. Plan in a fixed buffer for project management, quality assurance and communication.

Project management cannot be hurried. It costs time and money, but if done right, it’s worth it. When the project’s time and budget are reaching the end without the certainty that the project itself is facing a successful end, the quality inevitably suffers. So: plan realistically to protect your team from unnecessary stress and to provide your customer with the assurance that he can count on your word. This is an essential foundation for any successful project.

3) Done does not equal completed

Even when all the development work is done in your project, it doesn’t mean that the project is really completed. Now, when acceptance is imminent, the integration of all the single tasks needs to be (double-)checked. When deploying the project to acceptance you should definitely first check internally whether all benefits promised in the concept were actually implemented and tested. This usually happens on a staging system to prepare a customer presentation. Optimally, for each task you should also be able to demonstrate that you’ve fulfilled it with the promised performance and validated it by testing for proper execution. Only once this internal process is successfully completed should the project results be presented to the client for approval. Unfortunately, it’s often overlooked that the cooperation of the customer is required: your customer needs to test his specification accordingly and, hence, accept the project if there are no more serious bugs. Working cleanly and in detail is even more important at the beginning of the design phase. This becomes evident not just in the acceptance: if there are only minor bugs that don’t prevent the functioning of the concept, the project must be accepted with a bug report, which will then be attached to the acceptance report.

So, try desperately to stick to the following points:

4) Only provide what was actually tested

Although you have the right to repair, it looks unprofessional if you provide your customer with a project result that has obvious errors. This casts the project team in a poor light. So, write down what you’ve tested. Key points about each task and the benefits of the concept are sufficient. Clear acceptance criteria will help prove that all the requirements have been fulfilled

5) Involve your clients in the acceptance and prepare it well

Nothing is worse and more unproductive than if you provide your customer with the results of the project after three months of silence. Certainly, you may argue that you’ve just been doing focused work, but communication is simply essential to managing expectations. Your customer will feel lost if you don’t communicate at all. If you don't communicate recent status updates in recurring meetings, your customer will create his own expectations regarding the progress. So, communicate and show individual project results continuously – but only when they’re also really presentable. Engage your clients in the purchase process and show a demo of what the software can do and how that fits into the concept you created earlier, so your customer isn’t left with doubts and ambiguities but can ask you directly. Questions and problems can then be discussed immediately – and resolved.

6) Collect all the aspects that your customer wants to be changed

Sure, there will be functions and requirements that must be implemented in the software before it can go into production. Collect all these points in an initial protocol. Then, evaluate the different points, examine the requirement changes (change requests) and determine which of the points are still outstanding to the concept. Those still owing must either be implemented as soon as possible or appear in the internal quality assurance. Actually, they shouldn’t be there at all if you’ve already tested internally against the specifications! Change requests are then processed after acceptance. The same applies to minor bugs that don’t affect the functionality.

Both parties should have the same goal: To achieve (partial) acceptance and thus arrive at a decision that a project milestone is completed, after which work can continue and the software enhanced with other useful features. The project is taken forward after each individual milestone, with partial acceptances for single milestones and checks against the project objectives. This has the nice side effect that your customers will become familiar with the software in small pieces and you’ll get immediate feedback on whether the development is going in the right direction or not. So you see :

An agile approach doesn’t mean that there’s no concept! Quite the opposite – planning is important.

In the planning phase, particularly in terms of effort and deadlines, you have to count on further work after acceptance of the project.

The next post will deal with how to manage agile projects with structure and control.

Other blog posts of this series:

These 3 questions help you to ensure satisfactory project results

Setting objectives in projects with these 3 rules

Agile projects for a fixed price? Yes you can!

3 things to consider when creating project specifications

6 rules to follow to promote communication in projects

Categorieën:

Amazee Labs: Drupal 7 total language fallback

10 uur 48 min geleden
Drupal 7 total language fallback Reasons for language fallback

Let's assume you have a website divided by countries. The site structure is:

  • Global (en, de, fr)
  • Germany (de)
  • France (fr)
  • Switzerland (de, fr)

You have your content translated to three languages. Normally, this works, but there could be cases when you need languages per country. Words might have a slightly different meaning from country to country (examples) or spelling might be different (en-US vs en-GB, or using "ß" in de-DE vs "ss" in de-CH). Or, for example, the "Contact us" page can contain a country specific information - locations.

So, the site structure can be turned to:

  • Global (en, de, fr)
  • Germany (de-DE)
  • France (fr-FR)
  • Switzerland (de-CH, fr-CH)

This can bring a translation nightmare until you have a language fallback ;)

Having the language fallback, you would only translate strings/content to the "base" languages and, in special cases, you may also translate to "country" languages.

Fortunately, there is a module for that. The Language fallback.

Language fallback 7.x-1.x

The first version of the module provides language fallback only for locale strings (strings that are passed through the t() function). After the module installation, you can find the "Language fallback" option at the language edit form.

If a string translation is missing for the de-CH language, the translation from the fallback language (de) will be used in this case.

How the locale fallback works

There is a strings override feature in Drupal 7 core. Basically, you can define translations for some strings via variables. For example, you can put something like that into your settings.php file:

$conf['locale_custom_strings_de-CH']['']['Home'] = 'Startseite';

While this possibility is used really rarely, the Language fallback module transforms it into the real power. It saves instances of the localeWithFallback class to locale_custom_strings_* variables. The localeWithFallback implements ArrayAccess, thus it can return string translations automagically.

Language fallback 7.x-2.x

We also want to have the language fallback for our content translated via the Entity Translation module. The second version of the Language fallback module provides this feature.

This option enables the translation fallback for entities on the field level. For example, if an entity does not have a certain field translated to the de-CH language, the de translation of this field will be used for the entity rendering.

How the entity translation fallback works

Actually, this ability is provided by the core Locale module. The Language fallback module just hooks into the process.

Here is the call stack describing how it works:

  • field_language()
  • hook_field_language_alter()
  • locale_field_language_alter()
  • locale_field_language_fallback()
  • language_fallback_get_candidates()
  • hook_language_fallback_candidates_alter()
  • language_fallback_language_fallback_candidates_alter()

The last function does the job.

Language fallback chains

That's another feature only available from language fallback 7.x-2.x.

Now, on the language edit form, you can define several fallback languages in a particular order.

Language fallback 7.x-2.x-amazee

If you try to use the language-per-country workflow with the Language fallback module, the first thing you'll miss is the i18n support. The Internalization module helps us to deal with the translation of menu links, field labels, panels, etc. So, we started work in this direction and have prepared a patch.

After the patch was tested, we found that it would be quite useful to have the fallback information displayed right on the translation overview pages. We implemented this feature, too.

Before:

After:

We've submitted a patch containing both improvements to #2322883: Add support for i18n strings.

After using the new overview pages for some time, we decided to also improve the entity translation overview pages, since it improves the usability for content editors.

This developed into another patch #2444203: Show fallback information on the translation overview. This time, for the Entity translation module. (Be sure to enable the "Show fallback statuses on overview pages" checkbox on the admin/config/regional/entity_translation page after you have applied the patch.)

Language fallback for path aliases

There was an issue we have met implementing language fallback on our projects. The Pathauto module only generates aliases for the existing node translations. To fill that gap we have created the Path alias force module. It forces creation of aliases for all languages. Furthermore, it supports language_fallback, so aliases respect the fallback rules which is nice.

Total language fallback

Having all these patches applied, we have the complete solution for the language fallback on Drupal 7 websites. Now the language-per-country workflow can be used for real projects.

BTW. If you don't want to apply patches, you can use the Amazee Labs repositories which contain all required changes:

Let us know if you have any issues!

Categorieën:

Gizra.com: simpleTest with Behat for Drupal 8

ma, 2015/04/27 - 11:00pm

The first time I heard about Behat was at DrupalCon Munich 2012. Since then use of Behat has grown exponentially and the tools it can be integrate with grew as well. With Behat we can test the markup of a page - pretty neat, right?

Well, it's time to take Behat integration with Drupal a little further. I've decided to try and integrate it with Drupal's simpleTest, as this would open the door for writing simpleTests that are more readable and more "behavior driven" by nature.

Scenario: Testing the login form. Given I visit 'user' And I fill in 'Username' with '@user-name' And I fill in 'Password' with '@user-pass' When I press 'Log in' Then I should see '@user-name'

Amazingly enough, the above Gherkin code which is being executed by PHPunit can test your Drupal installation!

Behat code executed from within Drupal's simpleTest

This functionality is provided by an experimental repo, which comes with an example test.

Continue reading…

Categorieën:

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

ma, 2015/04/27 - 9:03pm

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!

Categorieën:

Chapter Three: Presentation: Drupal 8 Theming

ma, 2015/04/27 - 8:30pm
Categorieën:

Advomatic: Automating Living Style Guides in a Drupal Theme

ma, 2015/04/27 - 8:18pm
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 »
Categorieën:

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

ma, 2015/04/27 - 6:07pm

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: 
Categorieën:

NEWMEDIA: Improve your Frontend Toolset with Grunt and LibSass

ma, 2015/04/27 - 5:26pm
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.

Categorieën:

Nuvole: Drupal 8 Configuration Management with Features

ma, 2015/04/27 - 3:30pm
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
Categorieën:

Jim Birch: Drupal 7: Scheduling Posts with Scheduler

ma, 2015/04/27 - 3:00pm

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

Categorieën:

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

ma, 2015/04/27 - 12:43pm
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:

Categorieën:

Red Crackle: Code quality guidelines for large Drupal projects

ma, 2015/04/27 - 11:30am
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.
Categorieën:

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

ma, 2015/04/27 - 7:00am

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

Categorieën:

Merge: Next Generation Web Apps using the Service Worker

zo, 2015/04/26 - 10:05pm

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.

Categorieën:

agoradesign: Naming conventions for D8 libraries

zo, 2015/04/26 - 1:45pm
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.
Categorieën:

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

zo, 2015/04/26 - 9:22am


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.

Categorieën:

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

za, 2015/04/25 - 7:06pm

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.

Categorieën:

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

za, 2015/04/25 - 1:39pm

 

 

 

 

 

 

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.

Categorieën: