lee.rowlands

Drupal uses a patch based workflow. Changes to core and contrib projects are suggested in the form of patches attached to each project's issue queue. This is nothing new.

But this is not the norm for projects that use git for version control. Normally they use a traditional git branch/fork process - issues are worked on in branches or forks, when ready a pull request is sent, when approved the code is merged.

The git workflow has a number of advantages over the patch workflow, the most notable being there is no need to re-roll patches - you just merge HEAD instead.

So given Drupal uses the patch workflow, this article shares what I've found to be a successful recipe for maximizing the features of git in the patch workflow constraints.

This recipe has several advantages, including ease of creating interdiffs.

Drupal 8 comes with a new guided help API in the form of the Tour module. PreviousNext put a lot of effort into getting this module into Drupal 8 core prior to feature freeze and are excited by the possibilities it presents to ease the learning curve for new Drupal site-builders.

In part 1 of this post - we told the tale of how this module came to fruition. In this post, part 2, we provide examples of how you can add tour module support to your modules and talk about some of the advanced features of the API.

Drupal 8 comes with a new guided help API in the form of the Tour module.

Here at PreviousNext we were instrumental in getting this module in prior to feature freeze and are excited by the possibilities it presents to ease the learning curve for new Drupal site-builders.

In this post we discuss how the module came about, how we went about building support for the idea and the way the API works.

In part two we will go on to show some examples of how you can add tour module support to your modules and talk about some of the advanced features of the API.

We've entered the clean-up phase of the Drupal 8 release cycle. Drupal 8 is shaping up to be the best Drupal release to date - with a raft of new features and a less Drupal-centric developer experience.

So the question on everyone's lips is, when will Drupal 8 be released? The answer is the same as it has always been, 'When it is ready'!

We can't wait to start working with Drupal 8 on a daily basis. The new features will make our day-to-day jobs so much easier and our development workflow so much cleaner.

So to this effect, I'm aiming to work on one patch per day from now until the Drupal 8 release.

Will you join me in the Drupal 8 Patch a Day Challenge? Read on for more details.

Want to keep ahead of bugs and regressions in your code?
Want to stop other members on the team accidentally breaking your code?
Want to make deployments nice and smooth?
Perhaps you want to ramp up your core commits but are overwhelmed by testing?

Drupal 8 comes with a new type of entity, a config entity.

Those working with Drupal 7 will be familiar with entities for their content.

Drupal 8 introduces the concept of a config entity, which is very similar to a CTools exportable in Drupal 7, but with much of the entity system goodness.

We've recently been working with one of Australia's television networks to build an installation profile that will form the basis of migrating many of their existing sites to Drupal. One of the interesting challenges in the project has been handling collecting additional configuration and settings during the installation profile, but before the database is installed.

Ever needed to output your field collection items in a tabset, one item per tab? Customisable tab titles based on fields on the collection items? Then you need our latest contrib module Field Collection Tab formatter.

Today's security announcement highlights the perils of leaving install.php and update.php available on production sites. This article shows how to quickly deny access to install.php and update.php in an apache environment, with special mention of how to apply it to all of your sites if you're using Aegir.

Drupal's hook_field_instance_settings_form, hook_field_settings_form and hook_field_widget_settings_form are invoked without being passed the $form_state variable. This means you cannot perform ajax callbacks because you cannot access the current form state...... or can you?