Let the Debates Begin - Part II

Other articles in this series:

• DrupalCon Amsterdam 2014 - Historic Mirror on Drupal's Future
• Historic DrupalCon Amsterdam 2014 - Let the Debates Begin - Part I

Intro

Whatever it is, and in this article we are going to venture a proposal for a canonical definition, Headless Drupal seems to synthesis a heartfelt need in the context of the current Drupal problematic. It has been a hot subject for quite some time now, with an active group presence on Drupal Groups, and with a veritable avalanche of articles and presentations. Barring the obvious number one topic of Drupal 8 (which we'll debate in the next article in this series) and successfully competing with "the new PHP" itself as a center of interest, it was really the number one topic at DrupalCon Amsterdam 2014, with training, presentations and at least one very important BOF:

I really think that a debate needs to continue around Keynote: Dries Buytaert for the purpose of understanding the forces at work competing for the future of Drupal and indeed all open source projects. Leaving to one side without comment the really weird Dries doppelganger designed somehow to elevate the image of one of the sponsors, it was indeed saluted by many as being very special. A glance at the tweets feed for the keynote, for example, (or this one) were by and large ecstatic, and many interpreted the talk as exceedingly progressive. "The power of the people"... #digitaldisruption... "This is @Dries most socialist #Driesnote ever." "Applause even in the overflow room..." "Most relevant and interesting #DriesNote in a long time. Well done..." "Exciting. The best Dries keynote ever."

Drupal has immersed all our lives in the web, and the biggest conclusion we can draw from this DrupalCon is that Drupal in particular and we, as creators and consumers of Drupal, are all being rocked to the core by the fast pace of change in the industry. Changes in the development, scope, architecture, process and workforce dynamics prevalent in the development and acquisition of ever-more complex web applications and systems are rocking Drupal too, and the result is a scrambling for solid footing.

The footing we all find, and the journeys we take to find it, will determine our future.

First and foremost we need to come to grips with the debates, with what is shaping up. We need to learn a lot just to fathom the consensus on what the options are now. Then we must prick up courage and make choices.

But one truth is acknowledged by all: there is no simple and straightforward path forward, from here on in we mix and match, we build on an industry-wide workbench to common standards, or we build not at all. There is no more protective balloon, the big blue bubble has burst, or worse, is in the act of bursting now.

But this is not a bad thing. We just need to keep our heads, even if Drupal cannot. If we can drive @eaton's Promiscuous Drupal to its logical limit, if we can Keeping it Simple with @sdboyer we can "bring that knowledge back to the community" no matter what, as @crell guides us through Managing Complexity (be sure to check out his reading list) and the portals decouple, while beset with New Wave PHP, and at every turn: Drupal in the Hip Hop Virtual Machine with the @outlandishjosh.

That's the intoxication of sampling the key presentations from this historic DrupalCon Amsterdam 2014: let's find out what it's all about.

Of course, this is just my own shortlist (grouped by topics, of which, it is worth pointing out, headless is second only to Drupal 8 and way ahead of anything else as a concern), but whether or not I left out any well-deserving items from the list, it's more than enough to be able to say "Wow, we live in interesting times".

Keynote

• Keynote: Dries Buytaert

Drupal 8

• Drupal 8: The Crash Course
• Managing Complexity
• Drupal 8 CMI on Managed Workflow
• Twig and the new Drupal 8 Theme System
• Drupal 8 multilingual hands-on
• Drupal 8 Media

Headless Drupal

• Turbocharging Drupal syndication with Node.JS
• Decoupled Front-end and the Future
• Building Modern Web Applications with Ember.js and Headless Drupal
• A Decoupled Drupal with Silex
• BOF: Zariz & RESTful - We've got your headless covered
  • Video

PHP Renaissance

• Drupal in the Hip Hop Virtual Machine
• New Wave PHP
• OOP For Drupal Developers
• Drupal’s PHP Component Future

Web Dev Future

• Styleguide-Driven Development: The New Web Development
• Distributed Companies are the Future
• Open Source Enterprise Continuous Delivery with "Go"

Drupal 7

• Future-Proof your Drupal 7 site

Check some of these out, we need to talk about this over the next few days.

And in later articles and repos, I will be sharing concrete examples of how I am dealing with all of this, and how I am planning, well, my future.

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

$ drush @site1 status

So, how to set up an aliases file?

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

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

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

• In my Linux user directory, I created the file ~/.drush/aliases.drushrc.php
• Contents:

<?php

$aliases['site1'] = array(
  'root' => '/home/thevictor/site1/drupal-yii',
  'uri' => 'drupal-yii.example.com',
);
$aliases['site2'] = array(
  'root' => '/home/thevictor/site2',
  'uri' => 'site2.example.com',
);

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

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

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

A few days ago I shared my experience in setting up Bitnami LAMP Virtual Machine Stack using VirtualBox for Drupal development on my MacBook Air. That article serves well for the initial setup with the latest version of VirtualBox. Now, a few days later, I would like to share "what I really had to do" to get comfy with this local laptop/workstation development environment, the actual steps necessary for acquiring a truly useful tool.

Short List ("back to work")

•    Obtain IP of running Bitnami Guest unless you are using static IP (recommended)
•    Fix Local IP in /etc/hosts and login with terminal
•    Mount codebase via sshfs and work with IDE, Atom, Sublime, etc. or else use Eclipse remoting.