Drupal News

Syndicate content
Drupal related news with the junky stuff filtered out
Updated: 2 hours 51 min ago

SitePoint PHP Drupal: Fine Tuning Drupal Themes with Patterns, Arg and Types

August 18, 2014 - 8:00am

In this article, we’ll discuss how you can leverage various Drupal API functions to achieve more fine grained theming. We’ll cover template preprocessing and alter hooks using path patterns, types and args(). We’ll use the arg() function which returns parts of a current Drupal URL path and some pattern matching for instances when you want […]

Continue reading %Fine Tuning Drupal Themes with Patterns, Arg and Types%

Zivtech: Creating Parallax Scrolling with CSS

August 18, 2014 - 6:58am

Here at Zivtech, we are obsessed with creating immersive experiences for mobile and the web using cutting-edge design and Open Source Software like Drupal and Angular.js. One of the web design techniques that we've had on our radar is Parallax Scrolling, which gives depth to a page by scrolling two dimensions of the site at different rates (for example, text in the front would scroll faster than the image behind it). Parallax Scrolling is most often associated with 2D video game development, but has been becoming more and more prevalent on the web (for some live examples see Creative Bloq's post "46 Great Examples of Parallax Scrolling"). 

While we find this technique engaging, we never adopted it for our designs due to the fact that it relied heavily on Javascript tools and techniques that we found caused performance issues, and especially due to problems with making it work within a responsive web design. However, that may be about to change. In a recent post on his blog, Keith Clark wrote about an exciting new way to create Parallax Scrolling through CSS rather than Javascript, making for more mobile-friendly and responsive Parallax Scrolling effects. Clark writes:

Deferring the parallax effect to CSS removes all these issues and allows the browser to leverage hardware acceleration resulting in almost all the heavy lifting being handled directly by the compositor.

This technique, which removes the bulk of the work off the browser, creates the illusion of 3D without bogging pages down. Now, with CSS, we can maintain the same effect without creating a disjointed experience across multiple platforms. Check out Keith's post on pure CSS parallax scrolling websites for code snippets and samples.

Terms: Drupal PlanetParallax ScrollingCSSJavaScriptDrupalAngular.jsDesignWeb Designresponsive web design

Appnovation Technologies: Different Point of Views

August 18, 2014 - 6:25am

The Drupal Views module is an amazing tool. It certainly has contributed significantly to the widespread adoption of Drupal.

Gábor Hojtsy: Moving Drupal forward at Europe's biggest warm water lake

August 18, 2014 - 6:08am

Drupalaton 2014 was amazing. I got involved pretty late in the organization when we added sprinting capacity on all four days, but I must say doing that was well worth it. While the pre-planned schedule of the event focused on longer full day and half day workshops on business English, automation, rules, commerce, multilingual, etc. the sprint was thriving with backend developer luminaries such as Wim Leers, dawehner, fago, swentel, pfrennsen, dasjo as well as sizable frontend crew such as mortendk, lewisnyman, rteijeiro, emmamaria, etc. This setup allowed us to work on a very wide range of issues.

The list of 70+ issues we worked on shows our work on the drupal.org infrastructure, numerous frontend issues to clean up Drupal's markup, important performance problems, several release critical issues and significant work on all three non-postponed beta blockers at the time.


Drupalers "shipped" from port to port; Photo by TCPhoto

Our coordinated timing with the TCDrupal sprints really helped in working on some of the same issues together. We successfully closed one of the beta blockers shortly after the sprint thanks to coordinated efforts between the two events.

Our list of issues also shows the success of the Rules training on the first day in bringing new people in to porting Rules components, as well as work on other important contributed modules: fixing issues with the Git deploy module's Drupal 8 port and work on the Drupal 8 version of CAPTCHA.

Thanks to the organizers, the sponsors of the event including the Drupal Association Community Cultivation Grants program for enabling us to have some of the most important Drupal developers work together on pressing issues, eat healthy and have fun on the way.

Ps. There is never a lack of opportunity to work with these amazing people. Several days of sprints are coming up around DrupalCon Amsterdam in a little over a month! The weekend sprint locations before/after the DrupalCon days are also really cool! See you there!

Acquia: Drupal Stories Kick Off: My Own Drupal Story

August 18, 2014 - 5:55am

It’s no secret that Drupalists are in high demand. I’ve blogged about the need for training more Drupalers and getting to them earlier in their careers previously, but that’s just one aspect of the greater topic which merits a closer inspection as a cohesive whole.

godel.com.au: Use Behat to track down PHP notices before they take over your Drupal site forever

August 18, 2014 - 5:15am
Mon August 18, 2014 Use Behat to track down PHP notices before they take over your Drupal site forever

Behat is one of the more popular testing frameworks in the Drupal community at the moment, for various reasons. One of these reasons is the useful Behat Drupal Extension that provides a DrupalContext class that can be extended to get a lot of Drupal specific functionality in your FeatureContext right off the bat.

In this post, I'm going to show you how to make Behat aware of any PHP errors that are logged to the watchdog table during each scenario that it runs. In Behat's default setup, a notice or warning level PHP error will not usually break site functionality and so won't fail any tests. Generally though, we want to squash every bug we know about during our QA phase so it would be great to fail any tests that incidentally throw errors along the way.

The main benefits of this technique are:

  • No need to write extra step definitions or modify existing steps, but you'll get some small degree of coverage for all functionality that just happens to be on the same page as whatever you are writing tests for
  • Very simple to implement once you have a working Behat setup with the DrupalContext class and Drupal API driver
  • PHP errors are usually very easy to cleanup if you notice them immediately after introducing them, but not necessarily 6 months later. This is probably the easiest way I've found to nip them in the bud, especially when upgrading contrib modules between minor versions (where it's quite common to find new PHP notices being introduced).
The setup

Once you've configured the Drupal extension for Behat, and set the api_driver to drupal in your behat.yml file, you can use Drupal API functions directly inside your FeatureContext.php file (inside your step definitions).

Conceptually, what we're trying to achieve is pretty straightforward. We want to flush the watchdog table before we run any tests and then fail any scenario that has resulted in one or more PHP messages logged by the end of it. It's also important that we give ourselves enough debugging information to track down errors that we detect. Luckily, watchdog already keeps serlialized PHP error debug information serialized by default, so we can unserlialize what we need and print it straight to the console as required.

You will need to write a custom FeatureContext class extending DrupalContext with hooks for @BeforeSuite and @AfterScenario.

Your @BeforeSuite should look something like this:

<?php /** * @BeforeSuite */ public static function prepare(SuiteEvent $event) { // Clear out anything that might be in the watchdog table from god knows // where. db_truncate('watchdog')->execute(); }

And your corresponding @AfterScenario would look like this:

<?php /** * Run after every scenario. */ public function afterScenario($event) { $log = db_select('watchdog', 'w') ->fields('w') ->condition('w.type', 'php', '=') ->execute() ->fetchAll(); if (!empty($log)) { foreach ($log as $error) { // Make the substitutions easier to read in the log. $error->variables = unserialize($error->variables); print_r($error); } throw new \Exception('PHP errors logged to watchdog in this scenario.'); } }

My apologies, I know this code is a little rough, I'm just using print_r() to spit out the data I'm interested in without even bothering to process the Drupal variable substitutions through format_string(), but hey, it's still legible enough for the average PHP developer and it totally works! Maybe someone else will see this, be inspired, and share a nicer version back here...

David MeisterDirector & lead developerDave is one of the two directors of Godel. He is also our best developer. Dave spends his time improving processes, researching new and shiny techniques and generally working on making Godel the best it can be. Want to work with us?

If you have a project that requires a creative but practical approach...

Get in touch Turn your emails in to actions with ActiveInbox Thu July 31, 2014 Harness email hell with ActiveInbox, which turns your Gmail in to actionable tasks and helps you remind yourself to do the things you said you would.

Deeson Online: Using Grunt, bootstrap, Compass and SASS in a Drupal sub theme

August 17, 2014 - 10:37pm

If you have a separate front end design team from your Drupal developers, you will know that after static pages are moved into a Drupal theme there can be a huge gap in structure between the original files and the final Drupal site.

We wanted to bridge the gap between our theme developers, UX designers, front end coders, and create an all encompassing boilerplate that could be used as a starting point for any project and then easily ported into Drupal.

After thinking about this task for a few weeks it was clear that the best way forward was to use Grunt to automate all of our tasks and create a scalable, well structured sub theme that all of our coders can use to start any project.

What is Grunt?

Grunt is a Javascript task runner that allows you to automate repetitive tasks such as file minifying files, javascript linting, CSS preprocessing, and even reloading your browser.

Just like bootstrap, there are many resources and a vast amount of plugins available for Grunt that can automate any task you could think of, plus it is very easy to write your own, so setting Grunt as a standard for our boilerplate was an easy decision.

The purpose of this post

We use bootstrap in most projects and recently switched to using SASS for CSS preprocessing bundled with Compass, so for the purpose of this tutorial we will create a simple bootstrap sub theme that utilises Grunt & Compass to compile SASS files and automatically reloads our browser every time a file is changed.

You can then take this approach and use the best Grunt plugins that suit your project.

Step 1. Prerequisites

To use Grunt you will need node.js and ruby installed on your system. Open up terminal, and type:

node -v ruby -v

If you don't see a version number, head to the links below to download and install them.

Don’t have node? Download it here

Don’t have ruby? Follow this great tutorial

Step 2. Installing Grunt

Open up terminal, and type:

sudo npm install -g grunt-cli

This will install the command line interface for Grunt. Be patient whilst it is downloading as sometimes it can take a minute or two.

Step 3. Installing Compass and Grunt plugins

Because we want to use the fantastic set of mixins and features bundled with Compass, lets install the Compass and SASS ruby gems.

Open up terminal, and type:

sudo gem install sass sudo gem install compass

For our boilerplate we only wanted to install plugins that we would need in every project, so we kept it simple and limited it to Watch, Compass and SASS to compile all of our files. Our team members can then add extra plugins later in the project as and when needed.

So lets get started and use the node package manager to install our Grunt plugins.

Switch back to Terminal and run the following commands:

sudo npm install grunt-contrib-watch —save-dev sudo npm install grunt-contrib-compass —save-dev sudo npm install grunt-contrib-sass —save-dev Step 4. Creating the boilerplate

Note: For the purposes of this tutorial we are going to use the bootstrap sub theme for our Grunt setup, but the same Grunt setup described below can be used with any Drupal sub theme.

  • Create a new Drupal site
  • Download the bootstrap theme into your sites/all/themes directory
    drush dl bootstrap
  • Copy the bootstrap starter kit (sites/all/themes/bootstrap/bootstrap_subtheme) into your theme directory
  • Rename bootstrap_subtheme.info.starterkit to bootstrap_subtheme.info
  • Navigate to admin/appearance and click “Enable, and set default" for your sub-theme.

Your Drupal site should now be setup with Bootstrap and your folder structure should now look like this:

For more information on creating a bootstrap sub theme check out the community documentation.

Step 5. Switching from LESS to SASS

Our developers liked less, our designers likes SASS, but after a team tech talk explaining the benefits of using SASS with Compass (a collection of mixins with an updater with some cleaver sprite creation), everyone agreed that SASS was the way forward.

Officially Bootstrap is now packaged with SASS, so lets replace our .less files with .scss files in our bootstrap_subtheme so we can utilise all of the mixin goodness that comes with it SASS & Compass.

  • Head over to bootstrap and download the SASS version
  • Copy the stylesheets folder from boostrap-sass/assets/ and paste it into your bootstrap_subtheme
  • Rename the stylesheets folder to bootstrap-sass
  • Create a new folder called custom-sass in bootsrap_subtheme
  • Create a new file in the custom-sass called style.scss
  • Import bootstrap-sass/bootstrap.scss into style.scss

​You should now have the following setup in your sub theme:

We are all set!

Step 6. Setting up Grunt - The package.json & Gruntfile.js

Now lets configure Grunt to run our tasks. Grunt only needs two files to be setup, a package.json file that defines our dependencies and a Gruntfiles.js to configure our plugins.

Within bootstrap_subtheme, create a package.json and add the following code:

{ "name": "bootstrap_subtheme", "version": "1.0.0", "author": “Your Name", "homepage": "http://homepage.com", "engines": { "node": ">= 0.8.0" }, "devDependencies": { "grunt-contrib-compass": "v0.9.0", "grunt-contrib-sass": "v0.7.3", "grunt-contrib-watch": "v0.6.1" } }

In this file you can add whichever plugins are best suited for your project, check out the full list of plugins at the official Grunt site.

Install Grunt dependencies

Next, open up terminal, cd into sites/all/themes/bootstrap_subtheme, and run the following task:

sudo npm install

This command looks through your package.json file and installs the plugins listed. You only have to run this command once when you set up a new Grunt project, or when you add a new plugin to package.json.

Once you run this you will notice a new folder in your bootstrap_subtheme called node_modules which stores all of your plugins. If you are using git or SVN in your project, make sure to ignore this folder.

Now lets configure Grunt to use our plugins and automate some tasks. Within bootstrap_subtheme, create a Gruntfile.js file and add the following code:

module.exports = function (grunt) { grunt.initConfig({ watch: { src: { files: [‘**/*.scss', '**/*.php'], tasks: ['compass:dev'] }, options: { livereload: true, }, }, compass: { dev: { options: { sassDir: 'custom-sass/scss', cssDir: 'css', imagesPath: 'assets/img', noLineComments: false, outputStyle: 'compressed' } } } }); grunt.loadNpmTasks('grunt-contrib-compass'); grunt.loadNpmTasks('grunt-contrib-sass'); grunt.loadNpmTasks('grunt-contrib-watch'); };

This file is pretty straight forward, we configure our watch tasks to look for certain files and reload our browser, and then we define our scss and css directories so that compass knows where to look.

I won’t go into full detail with the options available, but visit the links below to see the documentation:

Watch documentatation

SASS documentatation

 

Step 7. Enabling live reload

Download and enable the livereload module into your new Drupal site. By default, you will have to be logged in as admin for live reload to take effect, but you can change this under Drupal permissions.

Once you enable livereload, refresh your browser window to load the livereload.js library.

Step 8. Running Grunt

We are all set! Head back over to Terminal and check you are in the bootstrap_subtheme directory, then type:

grunt watch

Now every time you edit a scss file, Grunt will compile your SASS into a compressed style.css file and automatically reload your browser.

Give it a go by importing compass into the top of your style folder and changing the body background to be a compass mixin.

@import 'compass'; @import '../bootstrap-sass/bootstrap.scss'; /* * Custom overrides */ body { @include background(linear-gradient(#eee, #fff)); }

To stop Grunt from watching your files, press Ctrl and C simultaneously on your keyboard.

Step 9. Debugging

One common problem you may encounter when using Grunt alongside live reload is the following error message:

Fatal error: Port 35729 is already in use by another process.

This means that the port being used by live reload is currently in use by another process, either by a different grunt project, or an application such as Chrome.

If you experience this problem run the following command and find out which application is using the port.

lsof | grep 35729

Simply close the application and run “grunt watch” again. If the error still persists and all else fails, restart your machine and try to stop Grunt from watching files before moving on to another project.

Next steps…

This is just a starting point on what you can achieve using Grunt to automate your tasks and gives you a quick insight to how we go about starting a project.

Other things to consider:

  • Duplicating the _variables.scss bootstrap file to override the default settings.
  • Adding linted, minified javascript files using the uglify plugin
  • Configure Grunt to automatically validate your markup using the W3C Markup Validator
  • Write your own Grunt plugins to suite your own projects
Let me know your thoughts - you can share your ideas and views in the comments below.

 

Read moreUsing Grunt, bootstrap, Compass and SASS in a Drupal sub themeBy David Allard | 18th August 2014

Victor Kane: Super simple example of local drush alias configuration

August 17, 2014 - 6:12am

So I have a folder for drush scripts _above_ several doc root folders on a dev user's server. And I want to run status or whatever and my own custom drush scripts on _different_ Drupal web app instances. Drush has alias capability for different site instances, so you can do:

$ drush @site1 status

So, how to set up an aliases file?

(I'm on Ubuntu with Drush 6.2.0 installed with PEAR as per this great d.o. doc page Installing Drush on Any Linux Server Out There (Kalamuna people, wouldn't you know it?)).

Careful reading of the excellent drush documentation points you to a Drush Shell Aliases doc page, and from there to the actual example aliases file that comes with every drush installation.

So to be able to run drush commands for a few of my local Drupal instances, I did this:

  • In my Linux user directory, I created the file ~/.drush/aliases.drushrc.php
  • Contents:
<?php $aliases['site1'] = array( 'root' => '/home/thevictor/site1/drupal-yii', 'uri' => 'drupal-yii.example.com', ); $aliases['site2'] = array( 'root' => '/home/thevictor/site2', 'uri' => 'site2.example.com', );

Then I can do, from anywhere as long as I am logged in as that user:

$ cd /tmp
$ drush @site1 status
...
$ drush @site2 status

and lots of other good stuff. Have a nice weekend.

read more

Wesley Tanaka: Fast, Low Memory Drupal 6 System Module

August 15, 2014 - 5:24pm

A Drupal 5 version of this module is also available.  If you would like this patch to be committed to Drupal core, please do not leave a comment on this page—please instead add your comment to Drupal issue #455092.

This is a drop-in replacement for the system.module of Drupal 6.33 which makes your Drupal 6 site use less memory and may even make it faster. A test I ran in a development environment with a stock Drupal 6 installation suggested that I got:

read more