I am not a coder, but have lots of ideas that I want to realize. Recently there was a blogpost from btopro (Bryan Ollendyke) from the ELM Learning Network showing a video on https://www.elmsln.org/blog/post/tool-builder.

Suppose you have an idea, but are not that good in Drupal. In the video you can see that when you can create a view, a content type, a block and a point to Github you are able to make a contribution as a non-coder.

Can this also be done with other Drupal stacks and a point to a git like Github?

I will clearify more by quoting Bryan, the developer:

This is one of the more insane things I've ever added to the project. It will, pave the way to fundamentally changing who can contribute "code" and ideas. Ideas shouldn't stem from one person, or one group of people simply because they know how to write code and understand version control. I'll let the video speak for itself but I'm having trouble containing my excitement throughout said video. We are moving beyond simple remix culture with this and into the elimination for the need to have developers to make meaningful, code based, contributions. People can model their ideas and show us instead of just describing them in the queues. This is what I mean when I say things like "unleashing innovation" or "sustainable innovation". We want to empower you to empower and education others through constructing technology and then be able to share those constructions with others.

3 Answers 3


The ELMSLN Tool Builder as demonstrated in the video appears to be like a set of magic buttons, which:

  • use as input the various options of a Drupal website that is configured using site building techniques only. So there is no custom Drupal coding involved, which is typically done by Drupal developers writing all sorts of PHP, JavaScript, etc.
  • include all sorts of code generation processes to automagically generate a Drupal "install profile".
  • use Drush and GIT, behind the (video) scene, to have the output delivered to an appropriate GIT repository, such as GitHub.

For this "magic" to work (without traditional coding), there are a few criteria (challenges) to keep in mind when you're clicking together these types of contributions, as further detailed below.

Do the modules you're using support import / export?

it is crucial that you're using (contributed) modules that do support "export" of the items that the Drupal site builder has put (clicked) together. Modules such as Views, Rules and Flag are known to come with these import/export facilities.

However, if there are also blocks involved, then you're out of luck for such import/export facilities, since the (core) block module does not have these facilities. Unless ... you use the BEAN module for creating blocks (that module will ensure you can also import/export your blocks).

But, assume your contribution also comes with some set of special "roles" ... which you cannot import/export out-of-the-Drupal-box. You'll have to find a way to also make those exportable (hint: there is a module for it ... also!)

How to package the various functions of your contribution?

This is where the Features module joins the game. It is typically used to select (using site building) the various parts of a site (some views, rules, content types, fields, required modules, etc). The result of this is that you (automagically) generate PHP code (behind the scenes), which at first seems like a typical Drupal module (with a .info file, a .module file, etc). You'll typically have "a number of features" (Drupal-like modules), eg just a few, or a dozen or so. Refer to the article about "Creating content types and fields using a custom module in Drupal 7" for an interesting recap of how use Features to "generate" a custom module for creating some content types and its related fields (and module dependencies).

But putting together the sets of these features is really (repeat: really) an art. Because it is extremely hard to not run into the typical issues (pains) of using Features. Refer to my answer to "How to use the Features module in a 3 dev environnement?" for (way more) details about that challenge ...

Version management and migration management?

It's relatively easy to automagically generate a 1.0 version of such contribution. But think about what it would take to later on generate a 1.1, 1.2, or 2.0 version at some point in the future. Yes there is the Features Diff module, but that's only part of the puzzle when it comes to upgrading.

Even if version management turns out to be doable (fairly easy?), what would be the solution to (also automagically?) migrate the existing content created in (say) a 1.0 version of it towards its (say) 1.2 version equivalent. Do you want to restart from scratch (empty content) when you're launching 1.2? Open question (at least for me): if you do not want to restart from scratch, then how would such content migration procedure be generated automagically?


Something like ELMSLN Tool Builder looks easy to get started with it, but the longer you'd be using such contributions, and the more functionality they come with, the more challenging things will become. Don't take "my" word for it, just verify on drupal.org what the maintenance status of most Drupal distributions look like. Yes there are some well maintained, amazing distributions, but also quite a lot that are not.

  • 1
    Hi @Pierre.Vriens, thanks for this great answer. Your conclusion is a clear one. What Bryan brought in can be very useful for non coders as a starting point. If I want to get further then that I know now also what to do and where to start.
    – user63018
    May 11, 2016 at 9:06

Well, if you just want to ship configuration, you can always use something like Features and distribute Views, content types, etc. in that way. It requires a basic knowledge of how to use Git.

But in all honesty, if you're wanting to developer and distribute Drupal based software, you should either get better at Drupal or find a developer to help you out.

  • It is about sharing ideas. Developing would be more obselete by using this.
    – user63018
    Apr 22, 2016 at 12:39
  • 1
    Developing will never be obsolete.
    – apaderno
    May 11, 2016 at 22:48

Pierre.Vriens write up is absolutely correct. Tool Builder is intended for those that could learn site building (quickly) to be able to portray their idea to the ELMSLN core development team. It is intentionally not a sustainable solution.Features Builder, Profiler Builder, and Drush Recipes are intended (usually) as the starting point for building something more sustainable. While you CAN build sustainable things using the innovation builder in elmsln, as the lead developer, would probably recommend using the tool to get a sense of how to start your next big idea but then branching from there. Similar techniques and using it as a base line lead to things like: We stole this site and you should too.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.