Planet Drupal

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.

Drupal Commerce Delivery Partner Program to Launch at DrupalCon Portland The Opportunity (and why you should care about Drupal Commerce)

The eCommerce market by anyone's estimate is huge and growing fast, and implementation services represent a significant part of the total. Today, Merchants want a flexible and scalable platform that supports their unique brand, message, and user experience now, but is also agile enough to quickly take advantage of new ways of selling and future sales channels. The rapid adoption of Drupal Commerce is the result, in part, of its ability to meet these needs. But there are other factors involved.

• Rich content and strong community interaction strongly influences buying decisions, and while there are lots of great eCommerce solutions, only Drupal Commerce offers full and seamless access to the power of Drupal, allowing customers to target their customer base and differentiate themselves in the market.
• The power and maturity of Drupal has made it the top open source CMS for medium and large customers, and a large majority have eCommerce needs. Leveraging Drupal Commerce enables them to gain a greater return on their investment in Drupal technology, resources, and content.

As Commerce Guys transitions this year to more of a product orientation, integrators and agencies who sell and implement commerce solutions play a vital role in our future. As an integrator/agency, growth of your business is important. eCommerce provides one of the strongest growth strategies that you can pursue, and if you are already focused on Drupal, it is a no-brainer. If eCommerce is strategic to your future growth, Drupal Commerce offers a great opportunity to achieve your goals.

Drupal Commerce Delivery Program (an open source approach)

The Drupal Commerce Delivery Partner Program is focused on helping you build strong and successful eCommerce practices by establishing meaningful partnerships focused on joint selling and the successful delivery of Drupal Commerce projects.

The reality is that there are more bad partner programs than good ones, primarily because they are created by the software vendor, with only the software vendor's needs in mind. As we began to formulate our strategy and, most importantly, make it valuable for partners and us, we realized that the fundamentals that make open source software great could also make other parts of the business (like a partner program) great. We spoke to many integrators and agencies and concluded that it was a very valid approach. The reason is simple; openness and transparency, along with the ability for all to contribute and influence direction, drives better ideas and results in better decisions that meet the business needs of all stakeholders, ultimately allowing everyone to collaborate to grow the market and drive success.

With this in mind, Commerce Guys is excited to be launching the Drupal Commerce Delivery Partner Program at DrupalCon Portland. It is intentional that this is NOT the Commerce Guys partner program, but a Drupal Commerce community program where collectively we will shape the future of what it means to "Partner" and focus on the needs of the Drupal Commerce ecosystem. Yes, Commerce Guys will manage the program and help to channel input into a common direction, but every open source initiative requires that to be successful. However, governance, programs, policies, etc. will come from input from and decisions made by the Delivery Partner community. Near term, those decisions will center around;

• Joint business development that will reach new customers and grow our pipelines
• Proper backing, support, training, tools and resources to win and deliver successfully
• Quality standards and ways to measure quality to ensure that customer success is the highest priority
• Partner segmentation to ensure that Partners who make the biggest investment see the biggest return
• Promotion and awareness of Partners to make it easy for customers to find the right partner

How to get involved (looking for Core Contributors)

Like every successful open source project, the Delivery Partner Program is open to all but will be greatly dependent on Core Contributors who will share the following characteristics;

• eCommerce is strategic to their future
• They are committed to growing the eCommerce market around Drupal Commerce
• They are interested in working closely with Commerce Guys to develop the program
• They see value in aligning with the Drupal Commerce experts to help them be successful

How can Commerce Guys Help Me? (what we bring to the table)

Many ask us how Commerce Guys can help. As the recognized Drupal Commerce experts, our priority is to enable Delivery Partners by leveraging our skills, expertise, and knowledge around Drupal Commerce, so that you have the competency and know-how to sell and deliver successfully. Our unique products and services are complementary to you and help you to;

• Pursue and win larger, more complex projects
• Reduce your risk on a project
• Deliver on time or more reliably
• Handle complex customizations and integrations
• Provide guidance and oversight to ensure that a site is successful
• Provide higher assurance of success and greater customer confidence
• Provide ongoing support through Acquia to fix Drupal and Drupal Commerce problems quickly

Rather than think of this as a partner program to join, which is typical and an outcome of bad partner programs, ask yourself how you can use this program as a tool to grow and a resource to win.

Interested?

If any of this sounds interesting and fits with your direction and strategy for growth, we would enjoy talking with you further. Come see us at DrupalCon Portland.

Not going to Portland? Go to our Delivery Partner contact form HERE,  or send me an email at scott@commerceguys.com.

If you missed our Delivery Partner launch webinar, view it HERE. 

Tags: Planet DrupalDrupal Commerce Delivery Partner Program

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:

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. 

Read more

Automated installation of apachesolr multicore localy will save you valueable time.

How to automatically install apache solr multicore localy for drupalapachesolrsearchautomationSaturday, May 11, 2013 - 14:49

• drupal 7.x
• views
• menu
• planet drupal

This article describes how to place a custom local task menu tab alongside the 'View' and 'Edit' tabs on a content type.

The Drupal.org infrastructure is a great resource for developers: A hub for development, with a combination of version control access, issue tracking, and automated testing.

Of course, it can be improved, and I don’t want to open a can of worms by saying it is perfect (it isn’t).

But I think the community does benefit from an environment that is designed especially for it.

Within this environment, we also have useful tools that help maintain quality in Drupal code.

1. The issue queues and workflow are set up to foster peer review, which (in line with the open source way) gives unlimited human eyes on a problem, rather than being siloed within a commercial organization.
    
2. Contributed projects such as dreditor allow fast, tangible reviews from reading through code, giving a clear comment for others to work from.
    
3. Automated tests mean that once you’ve set up code, you will automatically get the green or red light as to whether a change has unintentionally broken anything.
    
4. The coder module allows automatic reporting of code style, which helps bring the community towards common coding standards and accelerates the speed at which a contributor can become familiar with a new section of code. 

But these checks do add to the hassle of contributing a patch. Not good.

Formalising the process of review

On one of my projects, the Project Management Module, I was weighing up whether I should formalise the review process.

Previously, whilst a lot of the factors mentioned were taken into account (although not coder), it was a little haphazard, and I felt it wasn’t clear enough.

I wanted a contributor to know what the hurdles they were in advance, so that they could write a patch at the outset that solved the issues.

There are typically several patches undergoing review at the same time in the issues queue, so I also wanted to be able to speed up the review process to minimise the need for patch rerolls.

My biggest concern here was that I would alienate contributors to the project. This would not be an acceptable sacrifice, even if it meant that we were upholding the coding standards more precisely, etc.

Contributors come first

You’ll have got the message by now that one of the biggest risks to an Open Source project is (in my opinion) alienating your contributors.

So, whilst I’ve gone ahead and put a bit more structure in how I review patches, my focus has been on keeping the process easy and worthwhile – with a focus on the new element, coder reviews. 

Those regulars in the Project Management Module issue queue will keep me honest in the comments, I’m sure!

Is there a point to code style?

There are massive advantages to uniform code style among a community, but it is an investment made in a patch, with a longer term reward.

I’ve done two things to make coder patch reviews less painful:

1. Show the results: I’ve set up a developers website for the Project Management Module.
   
   You can see it at http://api.project-management-module.org.
   
   The aim here is for developers now to reap the benefits of the documentation that we’re adding to the code.
    
2. Lower the hurdle: I understand that not everyone has a test site running the coder module, and it adds a lot of time if you need to set that up each time.
   
   So I’ve opened up coder on the Project Management Module demo site.
   
   You can see it at http://drupal-7.project-management-module.org/admin/config/development/c....
   
   A check of a patch now takes a few seconds, and can be done before submitting on Drupal.org (in fact, you could use it for your patches too - it isn't module specific).

So far, I’m pleased with the results.

Nobody has complained about additional hurdle of coder reviews, and there have been some very positive comments about having an API site for all to see.

Conclusion

Alienating contributors is a real risk when formalising a process in an Open Source project, but it doesn’t mean that you shouldn’t try it.

Before implementing any change, think about how you will make the change worthwhile from the point of view of other contributors – whether by showing the point of it, reducing the pain, or both.

When have you tried to formalise a process in Open Source?

Has it worked?

What steps did you take to ensure contributors were not alienated? 

As always, I’d welcome your thoughts in the comments.

Category: WebsitesTags: DrupalDrupal PlanetMaintaining an Open Source ModuleOpen SourceCoderPatches

What is a million dollar house worth if it has bad wiring? Bad wiring means ripping out the drywall, getting it inspected by the city, and starting from scratch. If you have a builder that would allow something like that, as an owner you have to go from the bottom up and review what else they left lurking in your dream home.

Web application development is no different from a house. Sites require real estate, maintenance, and are living, functioning pieces. They require the occasional remodel to add more features as users needs change.

So why do so many web consultants often act like the McMansion builder of the web? Build it fast, cheap, charge as much as we can and walk out the door? Who do they think they're fooling? Maybe the clients, but will they be repeat clients?

Read more