Feed aggregator

Views offers a neat grouping mechanism that allows you to list content with matching criteria under said criterion. For example, if you had 3 press releases from 2011 and 2 from 2010, you could display them like this:

2011

• Press Release #5 (April 1, 2011)
• Press Release #4 (March 31, 2011)
• Press Release #3 (January 25, 2011)

2010

• Press Release #2 (December 3, 2010)
• Press Release #1 (June 1, 2010)

To do this, you create a view with three fields:

• Title (linked to node)
• Date (in Month Day, Year format)
• Date (in Year format; exclude this from display) -- if you want to save yourself some confusion later, open this field, go to the "More" section, and enter "Year (grouping header)" to make it clear why this field is there even though it's not shown

Next to your view format (unformatted list, HTML list, etc.), click Settings, and then pick your second date field as the grouping header under "Grouping field Nr.1". Check off "Use rendered output to group rows." Save.

I've done this quite a few times, but on my current site, I found that even when I told it to group by year, it was coming out like this:

2011

• Press Release #5 (April 1, 2011)

2011

• Press Release #4 (March 31, 2011)

2011

• Press Release #3 (January 25, 2011)

2010

• Press Release #2 (December 3, 2010)

2010

• Press Release #1 (June 1, 2010)

This makes a little sense, since the dates all technically are different, but it's supposed to be grouping by the rendered output, which is just 2011 and 2010. I dug around and found that even though it looked like just "2011" to the naked eye, the code was actually <span class="date date-display-year" property="dc:date" datatype="xsd:dateTime" content="2011-04-01T05:00:00-05:00">2011</span>. The month, day, and even time values were still being stored even though they weren't visible.

To fix this, I opened the year field, went to the Rewrite Results section, and checked "Strip HTML tags." This gets rid of the code that differentiates the values from each other, leading to the expected grouping behavior. If you wanted to do the same thing for month and year grouping headers (e.g. December 2010), all you'd need to do is change the format of your grouping field to use the month and day instead of the year.

For more on date formats, see Modifying the page display for a monthly archive view (the "Three steps, for reusing" section).

Like the ’90s, Drupal really is alive in Portland, the city made popular again from the much-watched TV show, Portlandia. Portland is the homebase for the Drupal Association and host for this year’s DrupalCon, Drupal’s largest North American conference.

This will be Forum One’s biggest presence at DrupalCon since we went to our first conference in Washington, DC, in 2009. We’ll have 17 web developers, project managers, and strategists attending the event from our offices in San Francisco, Seattle, and DC. We can’t wait to meet more Drupalers, share our experiences, and explore Portland!

During our Day Stage session, EPA.gov: Building a Sustainable Drupal Platform, we’re excited to share the challenges and successes we faced in migrating EPA’s large web presence to Drupal. In a “game-show” style session, we’ll investigate how we navigated the unique needs of a large government agency, share project challenges, champion our successes, and provide best practices for other large organizations considering moving to Drupal.

Another highly anticipated session is What Users Want (or Why Webpages are Dead) by Nam-ho Park and Stein Setvik. They’ll dive deep into real questions about the future of websites in the face of the rise of mobile and explore the implications for Drupal.

Each year, it is encouraging to see Drupal growing. With 613 active distributions and more than 25,000 contributors, Drupal is now the largest and most recognized open-source community. It will be interesting to see how keynotes from Dries Buytaert, Karen McGrane, and Michael Lopp address the sheer size of the project and how to get Drupal to even more users.

If you’re going to be in Portland next week, stop by our booth. We’ll have free “Nodetoriusly” awesome T-shirts that will be sure to take you back to the golden age of hip-hop. Plus, we’ll raffle off an iPad mini. And if you have a big heart and bright mind, consider joining our team by checking out our career openings. Come talk to us and help us keep the dream alive at Portland DrupalCon!

Like the ’90s, Drupal really is alive in Portland, the city made popular again from the much-watched TV show, Portlandia. Portland is the homebase for the Drupal Association and host for this year’s DrupalCon, Drupal’s largest North American conference.

Welcome to another Commerce Module Tuesday! Today we are looking at Commerce Product URLs, maintained by Maciej Zgadzaj who is a senior developer at Commerce Guys. This project almost doesn’t require a video. If you’re running Commerce 1.6 or later, just go download this, enable it, and love yourself for making the world a better place. Actually, enabling the module, by default, doesn’t do anything, but the magic is there. And that’s where the video takes the next step. It shows us how to hack the URL to link directly to specific products.

(Video after the break.)

Track Drupal page load times easily with the Google Analytics moduleTuesday, 14th May 2013

If you're a Drupal developer who's worked on a project with any real complexity I'm sure you've experienced some (or maybe a lot) of slow pages due to some kind of performance bottleneck in your code. Drupal is flexible enough that there's usually quite a few options available to help speed up slow pages, from the "one click" caching solutions provided by core, to third party cache tools like Entity Cache, through to targeted profiling and code refactoring on the level of individual functions with a dedicated PHP tool like xhprof.

In this post I'm not going to discuss fixing performance issues; I just want to talk about an easy way to detect that you have a problem in the first place.

So many times when I've heard somebody complain about a slow site (or section within a site) I see them click around a bit, maybe the cache kicks in and then they say "oh, it's not so bad" or maybe part of the site is only slow in a particular browser or maybe mobile devices are hanging on that cool javascript animation you wrote or maybe your audience doesn't live in the same country as your server. Whatever the situation, the performance you should be interested in is not what you or your clients see on a development setup but the page load times the users of your production site are experiencing.

Did you know that Google Analytics tracks page load times out of the box?

Well... not quite. "Out of the box" Google Analytics only tracks the page load times of 1% of your total page impressions. From Google's own API documentation:

"If you have a relatively small number of daily visitors to your site, such as 100,000 or fewer, you might want to adjust the sampling to a larger rate."

If you're anything like me though, you'll probably want to start weeding out slow pages long before your traffic is averaging anywhere near 100,000 hits a day - unless you like thrashing your server and making your users wait. For a new site that 1% might translate to just a handful of data points that are unlikely to be related or help diagnose anything, really.

Since the sample rate is adjustable we can just continue to push it up until we get meaningful data - Google's daily cap is 10k so if you're getting fewer hits than that each day you can safely push the sample rate right to 100%.

Configuring the Google Analytics Site Speed sample rate

Unfortunately the sample rate can't be set through the Google Analytics UI, we need to add the following line to the tracking script embedded in the site we want to track:

// Sets the Google Analytics Site Speed sampling rate to 100%. _gaq.push(['_setSiteSpeedSampleRage', 100]);

If you haven't worked with the Google Analytics API directly before even a relatively simple snippet like this could be confusing out of context (you might be wondering what _gaq is, for example?)

Luckily the Drupal Google Analytics module has a convenient way to handle dropping in custom GA snippets like this one into the right place for you.

On the Google Analytics module's configuration page, inside the "Advanced settings" fieldset, open the "Custom JavaScript code" fieldset and paste the above snippet into the textfield labeled "CODE SNIPPET (BEFORE)". Save the form and you should be done!

Like most changes to Google Analytics, new data will start tracking immediately but won't become available in a useful format in the dashboard for about 24 hours.

To find the site speed statistics in the Google Analytics UI navigate to Content->Site Speed through the left hand side bar. If you haven't configured the sample rate as per the instructions above this section might look completely "broken", depending on your current traffic levels.

Now that you've tweaked your sample rate for your site, you might want to read up on how to interpret your awesome new data.

Syndicate: planet drupal

Mozilla Persona is a single sign on system that allows you to login into websites with a single registered email address. To register an email address head over to login.persona.org and sign up. Once signed up you can login to any website that offers Persona with your email address.

Short video explaining Mozilla Persona Beta 2.

The Mozilla Persona module for Drupal allows you to offer Persona as a login option for your users. You can configure the module to be the only sign in method or have it as a second option.

Drupal  7.20 brought a security fix that prevents DDoS attack on servers.

The big news at Drupalcon Portland is that, for the first time at a Drupalcon, we're having separate frontend and user experience (UX) tracks. That means we were able to offer even more sessions targeted directly at frontend developers, and as the local track chair for frontend, I'm really excited about what we've ended up with!

Groundbreaking frontend featured speakers

[[wysiwyg_imageupload:4:]]First and foremost, of course, we have Jonathan Snook presenting on his concept (and book) Scalable and Modular Architecture for CSS.

[[wysiwyg_imageupload:6:]]SMACSS has had a big impact on a lot of frontend developers and themers — and in fact it's had a huge impact on Drupal itself. The Zen base theme, the most-downloaded Drupal theme out there, has adopted a SMACSS approach.

And Drupal itself is moving toward SMACSS with a re-organization of its CSS in the upcoming Drupal 8 release.

Join Jonathan Snook at Drupalcon Portland on Tuesday, May 21 at 4:30 PM.

Drupal 8 and Twig

Oh yeah, so there's this new version of Drupal coming out pretty soon.

Among the many, many awesome things happening with Drupal 8, one of the most relevant to frontend developers is the adoption (with a little luck) of the Twig templating engine.

Twig, a component of Symfony — a framework being adopted by Drupal 8 — will enable themers to write much cleaner (and safer!) code, and enable module developers to simplify the theming components of their modules.

No joke, at the BADCamp 2012 Twig session, there were literally gasps in the audience as we all saw how cool it was. If you're a themer or a frontend developer, don't miss this!

Join Jen Lampton, Fabian Franz and John Albin Wilkins presenting Twig on Wednesday, May 22 at 3:45 PM.

And so much more!

I've just touched on two of the featured sessions at Drupalcon Portland. In the coming week I'll be posting more about some of the other sessions, but you can browse the frontend sessions right now and start planning to attend your favorites! (Don't forget the User Experience sessions too.)

And if you don't yet have your ticket to Drupalcon Portland, there's still time! Grab your ticket by this Friday and save $50 off the on-site ticket price.

I can't wait to see everyone here in Portland!

Join Rootwork on Twitter, Facebook and SlideShare.

Learn about Rootwork's services for nonprofits and social change.

Start:  2013-05-15 (All day) America/New_York Sprint Organizers:  David_Rothstein

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

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

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

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

By default, the Search API Views sub-module does not allow you to specify the "direct parse" mode when configuring an exposed Fulltext filter. Instead, it always uses the "terms" parser which removes special characters and breaks the phrase into terms based on spaces.

This behavior prevents users from really leveraging the simple but robust Lucene query syntax that Apache Solr's default Dismax parser supports:

Drupal sites have a life cycle. Module support shifts from one version of Drupal to the next. New solutions are identified, and old solutions are refined.

For GHSA.net, updating to D7 meant improving mobile support and implementing a cleaner, more regular presentation, and simplifying content management workflows.

This is a discussion of techniques used throughout the project, challenges, and lessons learned.

I was recently in a meeting with a design agency who had to use Drupal for one of their websites and they hadn’t heard good things about it. The points they raised were common ones so I thought I would cover them here. This blog post isn’t a bash against Drupal, we are clearly huge Drupal fans! It aims to cover some of the issues people raise when they say that ‘Drupal is Rubbish’.

Drupal sites are a huge complicated mess!

One of the most common problems that people run into with Drupal is they underestimate its complexity and the knowledge you need to develop a sophisticated site with it. Sometimes people decide they want to use Drupal for all the right reasons, then they go to a web developer and ask them to build the site in Drupal. The web developer looks at Drupal and thinks ‘well, how hard can it be?’ and gets to work. It is a bit like going to your GP and asking them to perform surgery. In this example your GP would say no and refer you to a surgeon, but most developers have an overly optimistic attitude and sometimes it’s just hard to say no to the offer of work. Disaster follows, and often Drupal gets the blame rather than the web developer. Drupal is a fully fledged CMS, built and designed to compete with some of the biggest commercial platforms out there and it requires specialist knowledge to build a well-designed, stable website.

Drupal has to be complex in order to deliver the advanced functionality you need from a high level CMS platform and you’ll hear the phrase ‘steep learning curve’ regularly. This is one of the reasons that as an agency we only work with Drupal as we find that you need to be a specialist to get the best out of Drupal. Even if you are a senior developer with 5 years Drupal experience, you’ll still be learning something new every day. If a developer says they can build sites in WordPress, Joomla! MODX and Drupal, it doesn’t mean they can take on a complicated Drupal build and we would suggest avoiding developers with non-specialist experience for complicated builds.

The admin section is too complicated for our users

To a certain degree, the administration section can appear exceptionally complicated. This is also mainly due to it's extreme flexibility, in Drupal, the admin section will allow the user the ability to do more than a usual CMS administration menu. Luckily, it's very easy to set up different user levels to show less complicated administration screens to some users. Full access to the admin section is suited to users who like to be at super-user level access or to those who have been trained on how to use it. Drupal management and content administration training is something that we can offer and will allow us to take users from basic screens into more complicated task management. 

Before starting a project, doing a quick check to see whether your users are going to need the scalability and flexibility of a large Drupal solution is a good idea, it may be that your solution doesn't need that level of flexibility and a simpler platform like Wordpress may be a better option. 

Drupal is slow

This is possibly the most difficult claim to refute because quite frequently, if you haven’t set up Drupal properly, then yes, it can be slow. It is usually quickly remedied though, and there are a number of posts on the Drupal.org site which can provide you with more information on how to do this. Alternatively you can check out our high availailitity posts by our very own Mark Pavlitski - High performance in Drupal Part 1: Give your site a boost and High performance in Drupal Part 2: Lightning fast code. This comes back to the flexibility of Drupal and corresponding complexity, if your developers are not Drupal specialists, then ensuring that basic speed processes such as caching, memory optimisation and well written SQL could be missed.

We feel that given that some of the world’s biggest sites are written and run in Drupal (www.whitehouse.gov, www.louvre.fr, mtv.co.uk), we’re not too worried about the speed allegations.

Module dead ends

One of the reasons for Drupal’s success are the 24,000 or so developers that contribute code to the community, who produce a wide range of modules that every Drupal user can benefit from. Whenever something new appears, i.e. Twitter, Pinterest, an enterprising Drupal developer will bring out a module for it. Usually this happens well before the commercial CMS companies with their limited development teams and fixed development roadmaps can respond.

Sometimes, that enterprising developer who spent time writing a module, decides that continuing to support the module or upgrading it to work with the latest Drupal release is not something he or she wants to do any more. Hence module dead ends.

There are a few options for you out there if this happens: replacing it with a different module can often be quick and easy, taking over the maintenance of the module can be easily done and you can then assume control of that module. Evaluating whether a module is going to be developed long term can be an art form for Drupal developers so keep an eye out for an article coming soon on this site about the Top 5 factors to look for when choosing a module.

Summary

Drupal is a very flexible system and can be limitless in its opportunities and potential but this has to come with a level of complexity, a level that can make it unsuitable for developers without the required experience. The possibilities for doing exciting things like module customisations to fine tune Drupal to work perfectly for your site are endless, we just suggest that you employ developers with the best experience possible for your needs.

The title alone says it all. If you're reading this post, it probably is because you desire an easier way to insert a simple icon into your Drupal site. Many times this involves adding an icon library into your theme and doing some pretty undesirable pre-processing or template overrides to insert them where you want.

What are icons?

They're images right? Well, technically yes. Icons are a visual representation of some intended object or action -  a pictogram essentially (think of a stop sign). What I'm really asking though is:... Read more

Per Dries's post about Drupal 8 release risk, this post outlines a plan jointly developed by the Drupal core maintainers (Dries, webchick, catch, and alexpott) for getting Twig into core safely. See that post for more background information.

What's up with Twig?

The Twig template engine was originally committed to Drupal 8 live on stage at BADCamp in November 2012, to wild fanfare. Since then, the team has been working on converting all templates and theme functions in Drupal core to use Twig. Thanks to valiant effort by numerous contributors, the PHPTemplate conversions currently stand at ~30% RTBC, and another ~45% at needs review. This is great progress!

Why aren’t the core committers committing?

The short answer is release risk. We are in the “clean up” phase of the Drupal 8 release cycle (http://drupal.org/core/release-cycle#clean-up-phase). Each commit we make should take us one step closer to a Drupal release. In effect, committing an individual Twig patch to core takes us one step further into uncharted territory. At the moment all of our templates are PHPTemplate and hence each conversion commit moves us further away from a release. We obviously can't ship with two theme systems, so unless 100% of templates are converted, we leave Drupal 8 in an unreleasable state.

Solution

We plan to merge all the PHPTemplate to Twig conversions into one patch. Once complete, we will commit this patch into the mainline 8.x branch. The patch will convert all the .tpl.php files to .twig and remove the functionality that allows Drupal 8 to run both theme engines at the same time. This means that Twig commits will not take the 8.x branch further away from a release, and it gives us an exit strategy if they are not complete by code freeze.

A meta issue has been created to track the merged patch.

The Twig team will:

• Finish converting all the templates.
• Provide benchmarking evidence on each issue that the conversion conforms to the acceptance criteria. If other patches are required to be applied in order to meet this requirements then these should added to both the conversion issue and the meta issue.

Core committers will:

• Review each individual patch and
  • Comment: "+1. Ready for [#1987510]"
  • Status: "closed (duplicate)"
  • Title: prepend '[READY] '
• Commit the merged patch once all templates have been converted and acceptance criteria have been met.
• If a Twig patch is isolated to the current Twig code in 8.x then the core committers will commit it immediately. For example: Allow and test for NULL and integer 0 values in Twig templates

Acceptance criteria

The following are necessary in order to perform the final merge of conversions into 8.x:

• 100% Twig conversions are completed
• 8.x-twig performance is comparable with 8.x PHPTemplate performance, bearing in mind the issues with D8 performance testing - see https://drupal.org/node/1888424#comment-7345926
• there are no critical Twig follow ups

Once the patch is committed further Twig work should continue on 8.x to:

• Convert theme functions to Twig
• Gain the security benefits on Twig
• Further performance enhancements made possible by moving to Twig

Important: It is in everyone’s interest that the conversions are finished as soon as possible. In an ideal world, the merge will take place during Drupalcon Portland.

Rollback criteria

If by 17th June the acceptance criteria are not met, then (with regret) an issue will be created to remove Twig from Drupal 8.x. This gives enough to time to create and test the rollback patch before code freeze on 1st July.

Help wanted!

The Twig team has been doing a tremendous job, and we know the front-end community is very excited about this initiative. The time is definitely here to jump in and help the team push this initiaitve past the finish line! Particularly needed are patch reviews (see http://www.youtube.com/watch?v=Bv4PY_ZEP4Q for a helpful screencast on how to do so!), since most issues have patches but can't be RTBCed by people who worked on them.

So grab an issue to review and/or drop by #drupal-twig on IRC if you'd like to help. It's a great way to learn about Drupal 8, meet awesome people, and vastly improve Drupal for front-end developers at once!

In this tutorial I am going to show you a way you can leverage the power of the Drupal Form API to display form fields in the layout you want. To illustrate this, I will alter a form (the comment form) and arrange the Name and Subject fields in two columns.

I recently started a new development position with Blink Reaction so I needed to get somewhat serious about setting up a local Drupal development environment.

Ariadne

I was leaning towards making use of Vagrant for managing local development environments so I can easily switch between different projects or branches. I also believe Vagrant makes it easier to have as close a mirror to production locally as possible.

I discovered a very interesting project from MyPlanet Digital named vagrant-ariadne. Ariadne is a customized implementation of Vagrant and allows for easy deployment of Drupal installation profiles to a local VM. Another nice feature is that it attempts to emulate Acquia’s infrastructure. This is useful as a lot of Blink’s clients are deployed on the Acquia Cloud.

Assuming you have Vagrant, rvm and a ruby environment installed on your workstation, installing Ariadne is pretty straightforward:

j vagrant gem install vagrant-vbguest vagrant-hostmaster vagrant-librarian [sudo] gem install librarian rake knife-solo git clone https://github.com/myplanetdigital/vagrant-ariadne.git cd vagrant-ariadne bundle install bundle exec rake setup

Everything is now configured to boot a virtual box. Ariadne comes with a simple example that can be deployed:

j project=example vagrant up

Once that command finishes running, the site can be viewed at http://example.dev/ (Ariadne uses vagrant-hostmaster for managing /etc/hosts entries).

A more involved cookbook is a cookbook for deploying the Web Experience Toolkit available on github also. If we wanted to deploy the master branch of this site, we could do:

bundle exec rake "init_project[https://github.com/wet-boew/ariadne-wet-boew-drupal]" project=wet-boew-drupal branch=master vagrant up

And that’s it!

Another nice feature of these deployed environments is that they are configured to allow remote debugging (relevant when setting up an IDE as mentioned later) and the actual site code is shared as an NFS mount. For example, the contents of my /etc/exports file after booting a box with Ariadne looks like:

# VAGRANT-BEGIN: 7ac1cf50-4498-4e49-bd66-edac4a9b2d7e "/Users/posullivan/vagrant-ariadne/tmp/apt/cache" 33.33.33.10 -mapall=501:20 "/Users/posullivan/vagrant-ariadne/tmp/drush/cache" 33.33.33.10 -mapall=501:20 "/Users/posullivan/vagrant-ariadne/data/html" 33.33.33.10 -mapall=501:20 # VAGRANT-END: 7ac1cf50-4498-4e49-bd66-edac4a9b2d7e

Thus, if I navigate to the ~/vagrant-ariadne/data/html directory or import that in my IDE, I can edit the code deployed on the vagrant box.

Drupal Core from git

Another use I’ve found for ariadne is building a local environment for the latest drupal core. To accomplish this, I created a role file named roles/core.rb with the following contents:

name "core" description "Install requirements to run Drupal core." run_list([ "recipe[mysql::server]", "recipe[mysql::client]", "recipe[php::module_mysql]", "recipe[php::module_curl]", "recipe[php::module_gd]", "recipe[php::module_apc]", "recipe[drush::utils]", "recipe[drush::make]", "recipe[php::write_inis]", ]) default_attributes({ :drush => { :version => "5.8.0", }, :mysql => { :server_debian_password => "root", :server_root_password => "root", :server_repl_password => "root", :bind_address => "127.0.0.1", :tunable => { :key_buffer => "384M", :table_cache => "4096", }, }, })

j

Next, I created a new cookbook project named core and created a simple default.rb recipe for this cookbook. This recipe looks like:

branch = node['ariadne']['branch'] git "/mnt/www/html/drupal" do user "vagrant" repository "http://git.drupal.org/project/drupal.git" reference branch enable_submodules true action :sync notifies :run, "bash[Installing Drupal...]", :immediately end bash "Installing Drupal..." do user "vagrant" group "vagrant" code <<-EOH drush -y si \ --root=/mnt/www/html/drupal \ --db-url=mysqli://root:root@localhost/drupal \ --site-name="Drupal Core Installed from Git" \ --site-mail=vagrant+site@localhost \ --account-mail=vagrant+admin@locahost \ --account-name=admin \ --account-pass=admin EOH end site = node['ariadne']['host_name'].nil? ? "#{node['ariadne']['project']}.dev" : node['ariadne']['host_name'] web_app site do cookbook "ariadne" template "drupal-site.conf.erb" port node['apache']['listen_ports'].to_a[0] server_name site server_aliases [ "www.#{site}" ] docroot "/mnt/www/html/drupal" notifies :reload, "service[apache2]" end

With all of the above in place, its quite simple to create a local VM based on the latest in the 7.x branch of drupal core:

project=core branch=7.x vagrant up

The above command simply needs to have the branch name modified to deploy a different branch. Once the above command completes, a site will be available at core.dev and I can log in as the admin user using the credentials specified in my cookbook.

Private Repositories

Most repositories for client projects are stored in private repositories. Thankfully, thats not an issue with ariadne. Ariadne uses agent forwarding to forward the host machine’s ssh session into the VM, including keys and passphrases stored by ssh-agent. What this means is that your VM will have the same Git/SSH access that you enjoy on your local machine. I’ve not had a problem checking out code stored in private repositories on bitbucket for example.

IDE

For an IDE, I’ve been an Eclipse user in the past for Java projects I’ve worked on so Aptana seemed like a good fit for my needs at the moment. A few existing articles already exist on configuring Aptana for Drupal development so I’m not going to go into too much details here.

Installation is very straightforward with the binary downloaded from the site. A ruble exists for Drupal so its pretty natural to install that:

git clone git://github.com/arcaneadam/Drupal-Bundle-for-Aptana.git ~/Documents/Aptana Rubles/Drupal-Bundle-for-Aptana

Next item is to configure Aptana to adhere to the Drupal coding standards. I used an existing profile for Aptana that could be imported for this.

The final thing I needed to configure was a debug configuration. To do this, I created a new PHP web page configuration. First, a new PHP server needs to be added. In this example, lets assume I am using the example box I mentioned in the Ariadne section whose hostname is example.dev. The web server configuration dialog when configured with this hostname and appropriate directory for the site root looks like:

Once a PHP server has been added, the rest of the information to fill in for the debug configuration is pretty straightforward as shown below:

I like to select the break at first line option to make sure the debug configuration works correctly.

With this in place, any visit to example.dev will result in the breakpoint being hit.

Conclusion

I’ve still not settled on this combination for my development environment but I was definitely pretty excited upon discovering the Ariadne project. The drawbacks that I see to using Ariadne are: 1) the need to create a cookbook for each project you want to work with, 2) the project is still in beta stage so documentation is fairly lacking (fair enough for a beta project though), and 3) if you are not familiar with chef, using Ariadne may prove challenging (although it provides the perfect excuse to become familiar with chef).

PHPStorm is the IDE that seems to be pretty popular when I ask what other people are using for an editor but given there is a license fee associated with it, I didn’t want to splurge on that just yet. Aptana looks to work just fine for me and satisfies my needs nicely.

I recently ported my old module Password Require, which allows password protecting any form in Drupal, to Drupal 7.  This module was originally created for my presentation at the Florida Drupal Camp in 2010, as an introduction to module development.

 

Our second event adopted an alternative format not by design but its usefulness has us thinking it may well be the way to go!
Speaker at the seond DPSX event:
Mark Smitham  – Cabinet Office (G-Cloud) A huge thank you… Mark, we appreciate‏ the knowledge shared; old hats, newbies and the curious, we all took away a lot from the discussions.
And the key points shared and discussed:
+ G-Cloud is about engaging the SME sector – it is access to the eco-system #GCloudJoinin
+ has delivered the equivalent of £180m+ in savings; introducing innovative SME enterprises into the eco-system
+ G-Cloud is about greater transparency: there are 29,000 Govt. customers on G-Cloud – the access to opportunities for the SME sector is unparalleled  
+ The new G-Cloud Store interface by the way is a sight of relief! job well done. Note: G-cloud is a non transactional store but a marketplace for Govt. customers to have access to selected SME suppliers that they can engage with
+ on the CloudStore good old SEO is handy for searchability and visibility
+ There are challenges to getting the critical mass from the Govt. customers… SMEs could assist and inform their clients and prospects of the G-Cloud route to product/service acquisition.
+ a short guide to understanding Impact levels and Pan-Govt accreditation

some useful links:
G-Cloud
CloudStore
if you are a buyer
if you are a supplier

if you are not on the G-Cloud as a supplier  and as a Customer/buyer
LocalGov Digital ‏

The next meet-up for Drupal Public Sector Exchange will be held next month and stay tuned on our Twitter account DPSX ‏@DPSXchange

DPSX: @Alanpeart @Calert @Greenman @Kubair @MarcDe_ath @shaunwilde
#Drupal #PublicSector #Innovation #G_Cloud_UK #LocalGovDigital

Quick tip: Use bash aliases to easily run multiple versions of drush at onceSunday, 12th May 2013

There are times where it can be desirable to run two or more different versions of drush on one computer, or even multiple versions for one user.

For example, if you're using a server running the 1.x (stable) branch of Aegir and you attempt to upgrade from drush 4 to 5 globally all of your provision tasks will start failing, rendering Aegir completely useless.

The "real" solution is to upgrade Aegir to the 2.x branch but if you're looking for a quick fix it's easier to just install drush 5 in parallel with drush 4 for your user.

Steps to install drush 5 in parallel with drush 4:

This assumes you already have drush 4 installed, so that running $ drush status will report version 4.x

1. Download the latest version of drush 5 from the project page.
2. Extract the contents of the drush tarball into your home directory in a folder called drush5, so that the drush files can be found at ~/drush5.
3. Edit or create either ~/.bashrc or ~/.bash_profile and add the following line: alias drush5='~/drush5/drush'.
4. Reload your terminal/console or run $ source ~/.bashrc or $ source ~/.bash_profile as appropriate (whichever file you edited).

That's it! if you run $ drush5 status you should see a drush report a version number 5.x

You can now swap between drush 4 and 5 easily whenever you need to.

These steps can be adapted to do the same thing in reverse and have drush 5 run with the drush command and drush 4 with drush4, or you could even have each version explicitly mapped to drush4 and drush5 - it's up to you :)

Syndicate: planet drupal

Knowledge Language English My Mentor/D8MI Drupalcon Portland ScheduleCathy Theys05/12/2013 - 08:28

This is a wishful schedule. Some things I'm committed to be at. Some I'm wishing I will to have time to go to.

Note, the google core mentoring calendar will make it easy to add some of these to your calendar. Core mentoring calendar: 7ss54o2foktlc8b75d1gest4do@group.calendar.google.com

It's a mix of what I'm into: my sessions, mentoring and multilingual.

Tuesday

• 9:00am Programming Diversity by Ashe Dryden
• 10:15am Making core development sustainable by Greg Dunlap
• 11:30am The Current State of Drupal 8 Keynote by Dries (is what I would go to if I were not staffing the Community booth at that time.)
• 2:30pm I'm going to be trying to be calm right before my session. But if not, I'd pick: Dependency Injection in Drupal 8 by Katherine Bailey
• 3:15pm I'll be at my session! Running coaches wanted! Contribution sprints and trainings by Jess, Andrea, Addi and me
• 4:30pm I'll be in a BoF with mentors doing task selection for the Friday sprint, but if I were not, I'd be in UX Case: Love and Hate in The Issue Queue Garden by Michael Keara, Thomas Svenson
• 5:30pm Exhibit Hall for Drupalcon Kick Off Reception
• 6:00pm or so Women in Drupal Meet and Greet

Then on Weds...

We're not talking about Darwin, but about the fact that a website project - even after delivery - will often stay in a state of evolution before becoming ‘stable’. The evolution itself isn’t the problem. Responding to that evolution is often what causes operational headaches. This article will not deal with the technical complexities of the Drupal development lifecycle, the CMI in Drupal 8 should solve that. Here we delve into the operational issues of website evolution.

Some definitionsAbout a decade ago, websites were constructed by ordinary people promoted from among their peers to the role of webmaster. Because websites weren’t used as the powerful marketing tools they are today, many websites remained under construction for a long time. Sometimes forever. Nowadays, websites can be under construction for a long time as well, but the construction phase is more accurately name; used by website engineers as they actually construct the website. Once the website is completed and delivered, it enters the maintenance phase. The actual go-live might happen overnight, but there’s often a fairly long time before development stops. The time between construction and maintenance is what’s called the evolution phase.  for ITIL lovers Within Application Maintenance Services our focus in this article is on Application (Drupal) Support.   Within Application Maintenance we can identify 4 types of Support. Corrective Support (eg. download link does not work), Adaptive Support (eg. make whole website work for new version of Internet Explorer),  Preventive Support (eg. perform security updates) and Perfective Support (eg. Add a carrousel to the new campaign page).     We rather use the term “Evolution” to denote the combination of Perfective and Preventive Support since it better fits the notion that we are talking about, more than ‘support’. ConstructionThe construction phase for websites is that period between having a neat idea, and bringing the resulting idea into production. The most important part of that phase is the concepting phase, while the largest part of that phase is the actual development project. The business model for development projects is fairly straightforward: sell as many development projects as there is capacity while keeping planning and efficiency (i.e. working billable hours at least 80% of the time). To fill the gaps between projects, you can take on smaller projects. The less downtime you have in your work schedule, the better. The resulting website will consist of everything that the client wants to start from. MaintenanceConstruction processes can be standardized to some extent, but it’s impossible to predict fallouts and failures, once software is running stably. The main problem of these fallouts is not the failure itself, it’s making sure you have resources available to fix the problem. So suppliers of modern-day equipment and services need to make sure they have enough permanent resources to address issues as they arise, in order to comply with their Service Level Agreements (SLA). Typically there are peaks moments and there are moments when everything is running smoothly. Only proactive maintenance tasks (e.g. upgrades, increasing memory) become plannable. But for this to be worthwhile, you need enough clients and enough resources to come up with usable heuristics. Once you have proper statistics, the maintenance business model becomes scalable, because it’s not people but statistics that are sold. In fact, resources can be sold multiple times when you’re dealing with small, unpredictable chunks of work. The resulting website will become  stronger and more stable by performing these maintenance tasks. EvolutionThe business model of maintenance is clear (enough resources + enough clients = scalable workflow), but starts to degrade as soon as these chunks of work become too big. This is what happens when the website is in evolution. During that evolution phase, the client will make feature requests that the development team needs to handle. But due to the nature of the request, the client will be unsatisfied if that request is handled as a project (ie. planned to happen in 5 weeks).  The resulting website will consist of improvements to adapt to changing business requirements, staying up to date with the newest technologies (e.g responsive design) or being ready for new marketing campaigns. What is the problem?If the evolution were handled as construction, clients would have to wait too long for small changes.If, on the other hand, it were handled as maintenance, the support team would lack experience  to complete all the engineering going on. Even if they did have the skills to handle those medium-sized chunks of work, accepting these requests would break the statistics of the business model. This could jeopardize the correct reaction time on more critical requests. What we are hearing from prospects and clients working with Drupal websites at the moment does indeed comply with our findings. We hear remarks like, “Yes, we have a support contract, our supplier reacts quickly and communicates well, but the quality of the fix is low or feature A gets implemented, while another existing feature B breaks down.” Or we hear, “Yes, we have a support contract, and the supplier delivers correct solution. They even bundled multiple requests into one release, but it takes weeks, sometimes months to get a small thing changed.”  Possible solutionsThere’s a list of possible ways to be able to deal with these situations, and the Wunderkraut support model currently handles all of them.  Fixed SupportReserve a few people from the development team for a number of days a week/month for a certain period of time, e.g. every Friday for six months, two developers will be available to react to client requests in the issue queue. The following problems arise with this solution:

• It’s very hard to predict how many resources will be needed and for how long, which will result in either too many or too few blocked resources.
• If these developers are unable to get a feature totally released on that Friday, they need to continue working on it, the next week - i.e. it is still slow.
• If the client does NOT have any requests, they will still be paying (maybe partially) for that unused time, and some clients don’t like that.

 Lower the billabiltyAnother option would be to decrease the billabilty of one or more dev-teams, e.g. only the dev-team is directly billable on projects for 60% of the time, so has extra room to handle these small chunks of works. But the problem here is pretty clear: the risk  is completely moved to the supplier. If in one month, none of the clients requests smaller work, the supplier has no income. This is in general not a good business model. On the other hand, this solution does not scale. If the supplier freed up some resources for each of his clients, the dev-team would just be ‘waiting’ for new features to come in, instead of working on new projects. Wunderkraut Evolution model (beta)We’ve finally managed to devise a model that combines the agility of the two weekly sprints of Scrum, with some warranties on reaction time for certain requests. We won't go into the details of the model, but the general idea is that we use a mix of fixed support and lower billability to spread the risk evenly between client and supplier, and at the same time allow small chunks of (evolutiove) development work to be added to the sprint backlog of a selected development team.  We are currently test-driving this solution for some clients, and will report back at a later time to talk about the results. Let’s discuss and learnIt may not come as a surprise that both clients and service agencies are dealing with complex issues as a result of this dilemma. In fact both parties are actually losing time and money in their search for the best solution. Therefore we would like to invite CTOs, CMOs and other company decision-makers and influencers to our round table discussion group in Belgium to exchange views on how to best solve this.  In an informal setting, a panel composed of a  Marketing Director (Kinepolis), a Technical Director (Cultuurnet) and a Supplier (Wunderkraut) will touch upon the different  aspects  of  the website evolutionary support.  The discussion will be moderated by Bart Gysens (project medewerker V-ICT-OR). If you are interested in joining this event please send an email to be.info@wunderkraut.com to register.