drupal

Frontend United, Call for speakers

Drupal Frontend United Conference EU
As Morten announced some time ago, there will be a Frontend Conference in April in Amsterdam targetting all (EU) Drupal themers. Apart from Morten, it is organised by Isabell Schulz, Jesper Wøldiche, Marek Sotak and me.

It will be held at Pakhuis de Zwijger, a rather nice old warehouse in the center of Amsterdam. More information on the conference can be found on frontendunited.org

One of the speakers will be Jeroen Wijering. Who you ask? Well, what Dries is for Drupal, Jeroen is for video on the web. See this whois JW video on Youtube. JW knows all about HTML5, mobile, video and even what browser minor version has what bug and how to get past this. His knowledge matches our themes perfectly:

  • Drupal on every device
  • Frontend performance
  • The Drupal experience
  • Getting visual with data

You know you have some expertise in one or more of these field as well. And if this is the case, please do submit a session. The conference is all about people like you ;-) Even if you don't think you can add anything, please to take something. Like a ticket, hopefully the "community support" one to get extra Awesomeness. Buy your fresh ticket with a couple of clicks. Oooh, and do stalk your employer that (s)he should sponsor the conference, see for yourself what the advantages are.

We hope to see you in April in Amsterdam. It will rock!

Coffee Module, Spotlight meets Drupal

El solo de guitarra
If you own a mac, you use spotlight daily. Or even better, use Alfred. A great way to navigate faster with a keyboard towards the app or data you need.

A very long time ago a Boy Wonder made something like this for Drupal 5, navigating through the /admin pages using a simple spotlight alike interface, see the menuscout module. Unfortunately, Boy Wonder, he wandered off and the module gained dust.

Then some time ago co-worker Michael Mol showed me a module he has been working on. Since he was doing D6 and D7 development at the same time and since the URL's changed and developers use URL's as well for navigation, he decided to d a spotlight alike search on the admin pages so he could remember the name, not the URL. It ended up being coffee, for now a sandbox project but anyday now a real project in d.o. To see it in action, take a look at this screencast.

Think of coffee as spotlight for the admin interface. And if you want an easter egg like the do a barrel roll, get active in this issue.

Drupal conference for CxO's in the EU

Boardroom sketch

Two years ago the Drupal Association organised a meeting for the local Drupal "leaders" in the EU during the DrupalCon Copenhagen. This meal paid by the DA might have been one of the best investments they made. A lot of events were organised as a direct result of this meeting including the DrupalDevDays and the CxO days as well as the Frontend United conference. I am co organising this Frontend United event and will post more soon, just be sure to be in Amsterdam, The Netherlands during the end of march:-) And follow @frontendunited.

On a related note, there will be a Drupal process meet-up in Amsterdam as well. After last years extremely successful CxO days there is now the process. Be sure to sign-up for this event sponsored by and held at the venue of Microsoft and meet your peers.

On 27, 28 and 29 January we are organizing the next Drupal executives meetup (CXO) in Amsterdam. This meetup aims to facilitate peer-to-peer learning about business processes between leadership of Drupal shops. What are the best practices? What kind of processes do you need? How do you grow from a entrepreneur centered culture to a process driven culture?

The myth of the Drupal Learning Curve

Curve
The Drupal Learning Curve. A much debated issue. Drupal was up to 2005 mainly build by people who didn't perse need the tool, were not scratching their own itch but explored the waters of what we call now the semantic web. Creating a tool we love, with a node system that is still ahead in many ways of other systems and with hooks that catch anything. But also a system that up to at least seven didn't give "the user" the best experience when it comes to the interface.

....

And here is where the normal rant ends. Because we need to stop thinking as "Drupal has a high learning curve for the user". Simply because it is false and by saying so we lie, scare of potential "users". Adding content in Drupal 7 is not harder then in for example Wordpress or Joomla; some fields, a preview, a sumbit and you are done. Sure, there is the everlasting WYSIWYG dilemma, and while Drupal does not deal with this in core it is as easy 'solved' as it is in a CMS where the editor is integrated.

There are at least two problems with "Drupal has a steep learning curve for the user".

  1. A fool with a tool, is still a fool

    First and foremost, we forget to define "'user". Drupal always has the vision to cut the middleman, make the webmaster obsolete, drop the database administrator and give the power of these roles to "the user", the content editor.

    The user was traditionally the person responsible for adding content. Now, this person is not just able to create content with adding some data to some field and press submit. This person is also able to make lists of most read items, create new content types and rearrange blocks on the site.

    When I said, First and foremost, we forget to define "'user", I meant, First and foremost, we redefined "user". And by redefining "user", by enabling a normal person to do things he (m/f) had to call IT before, by giving him the tools to excel beyond his normal duties, we created the UX problem. Where the normal User Interface of a database engineer was the command line, we gave the power of a webinterface as the user interface to the one who wants the change. From the database engineer's point of view a great step forward in UX; from the content editor's point of view a complex UI for something he might need only once in a while. Roles and rights to the rescue, one might think. But you can not undo the complex powerfull interface Joe Blogger sees when he installs Drupal under UID 1.

    Drupal doesn't have a bad UI, doesn't have a steep lurning curve. Drupal eliminates the middleman and does this by eliminating the process and procedures around change management of the technical backend and trades this for an unpolished frontend.

  2. Lego duplo upgrade

  3. Up or out?

    Second, we traditionally see the learning curve in relation to horizontal growth. We think that one can become a Chx, Unconed or Dries by submitting a blog post, then install Drupal, tweaking the User Interface, making a template, coding a module and then... one becomes a core maintainer. This classic "growth is seen from left to right" diagram tells it all:


    (copyright Dries)

    The truth is we have hunderds of thousands of people on the left and only a handful of people on the right. And most people who are on the right side of the diagram, didn't grow horizontally, they grew vertically. They came in with a background in programming, had programmed on other systems and choose Drupal because of it's code, community or license.

    And most people on the left are fine to be on the left and don't want to "grow" horizontally, they want to grow vertically. They are good at something and use Drupal for it. And might be good in what they do in the Drupal community and grow in that vertically, not horizontally. They want to become the best testers, community members or write the best documentation. The learning curve there has nothing to do with the tool Drupal, but with the commnuity, the person and the tasks at hand.

    In 2005 I read a very well written book on how great leaders stimulate vertical growth as well, let a waiter become the best waiter on the block, not the manager of the cafe. Dries, you still have my copy of "First Break All The Rules" :-)

    Drupal doesn't have a bad UI, doesn't have a steep learning curve. Drupal should adopt vertical and horizontal growth by eliminating the traditional vision on how people or communities can grow.

Tricycle

So lets do ourselves a favour and stop calling Drupal hard to learn. It is as true as saying "a bike is hard to learn". Biking is not, building or designing a bike is. Ooh, and while we are at it. Stop calling Drupal a WebCMS.

Fingerprinting a Drupal site, what version is that site running?

Fingerprinting a version of Drupal iste
Say you want to find out if a site is using Drupal. You could dive in to the headers as was described by Lullabot some time ago and see if it is the birthday of Dries in the headers:
Sun, 19 Nov 1978 05:00:00 GMT

A much easier way and more generic is installing the "BuildWith Technology Profiler" extension in Chrome(ium). This add-on not just finds Drupal sites, but also other CMS-es like WP, Joomla and dozen of others as well as scans to see if for example Google Analytics code is on the page. A must have for the curious browser. If you find a nice site, you might tag it in delicious with "yads" (yet another drupal site) and or "drupalsite", take a look at some of my findings at http://delicious.com/bertboerland/yads.

Bit what if you want to know what version a specific Drupal site is running? Well, you could look for the CHANGELOG.txt file in the root but that file is often deleted. For good or for bad reasons. Personally I think it is good practise to give as little information as possible to the outside world, for example not echoing the version of the webserver you are running. This can be done in Apache by two lines
ServerTokens ProductOnly
ServerSignature Off

and this was done on drupal.org as well.

There has been some debate if Drupal should hide it's text files as well, like CHANGELOG.txt. Some other CMS-es do this or use a DIE to protect it from prying eyes. In the end consensus was that removing these text files will not make your site more safe; good procedures and adequate updating of core and contributed modules will!

So fingerprinting most Drupal site is easy, one just looks at the CHANGELOG file and knows what version the site is running. Hoewever, if you dont trust the changelog file or it is removed, it is still rather easy to fingerprint a Drupal site.

It can for example be done in the following way:

  1. Download a couple of Drupal core files. Unzip / tar -x them.
  2. Go through all directories to see what files changed. This can be done by something like:
    diff -r -q drupal-7.7 drupal-7.8 | grep -iv info >> drupaldiffall
  3. Fingerprinting works best on JS or CSS files so grep the from drupaldiffall and put the in drupaldevjscss
  4. Now find the files that have changed most often.
    cat drupaldiffjscss | grep -i "files" | cut -d " " -f 2 | cut -d "/" -f 2,3,4,5,6,7,8,9,10 | sort | uniq -c | sort | tail -10
     12 misc/autocomplete.js
     12 misc/collapse.js
     12 misc/drupal.js
     12 misc/farbtastic/farbtastic.js
     12 misc/jquery.js
     12 misc/progress.js
     12 misc/tabledrag.js
     12 misc/tableselect.js
     12 misc/textarea.js
     12 modules/color/color.js

    So out of these lets pick the color.js file that changed 12 times. Note that with Drupal 7 CSS and JS most of the time don’t change at all where in the late 6 versions, these files changed more and more often. Hence the tail -10 outcomes will differ based on the source Drupal cores you downloaded (and yes I suck at regular expressions)
  5. The next step is to make the color.js file unique identifiable in all version. Here is where our old MD5 friend comes handy, the syntax might be different on BSD based systems versus GNU/Linux, but it will be something like:
    find ./ -name color.js | xargs md5 > rainbow
    And the rainbow file itself will be
    cat rainbow
    MD5 (.//drupal-5.22/modules/color/color.js) = 61098c218594ab871b48cd43459dc2ed
    MD5 (.//drupal-5.23/modules/color/color.js) = 61098c218594ab871b48cd43459dc2ed
    (etc)
  6. Now all we have to do is find the color.js file in a site we want to fingerprint and match it against this rainbow file:
    grep `curl http://drupal.org/modules/color/color.js | md5` rainbow
    MD5 (.//drupal-6.22/modules/color/color.js) = f5ea11f857385f2b62fa7bef894c0a55

    So according to this Drupal.org is running the latest stable 6 version. Doing the same for the Belgium/Dutch site will give you less useful information:
    grep `curl http://drupal.nl/modules/color/color.js | md5` rainbow | wc -l
    7

    So all we know now (if we didn't wc the outcome) is that is is one of the latest 7 versions of Drupal 7. So you have to start digging deeper:
    more drupaldiffjscss | grep "drupal-7" | grep "Files " | cut -d " " -f 2,3,4,5,6,7,8,910 | sort | uniq -c (or visit http://drupal.nl/CHANGELOG.txt :-)

So why would one need this information you might ask. Since it is clear that in the wrong hands it will lead to... . Well, the bad guy knowing what version you are running. And to be honest, if the bad guy goes through so much trouble finding out what version you are running, (s)he was going to find out anyway.

But like all tools, it can be used for the Good. My employer takes over a lot of sites build by others (comes with the Drupal growing pains, the freedom of the GPL and the fact that the market is getting closure to an adolescent stage). Most of the times we have to give a raw estimate of maintaining and expanding the site, yet the prospect doesn't know what version he is running and doesn't want to ask his current supplier. By doing a quickscan on amongst others what version the site is running we know how well it was maintained and what budget would be needed to upgrade to the latest version. You might have a different usecase. For the Good.

XML feed