Within our company we use Drush and Drush alias files a lot. Recently I wrote a company blog post (in Dutch) about the workflow we’ve set-up and this post is its English translation. For those of you not familiar with Drush, I’ll start with a short introduction. If you are already familiar with Drush and Drush alias files, you can skip to the interesting part.
There are already many Drupal modules to display or import Tweets on your website, but most of them come with limitations: they just display the tweets instead of importing them. This makes it hard to filter, especially when you display a specific hashtag. In some cases, it’s pretty handy if you can quickly unpublish an unwanted tweet. The modules that do import tweets have other limitations.
You may have heard of CSS preprocessors like SASS and LESS before. And you may have - just like me - never actually used it on a project. But for me, that changed recently. A few weeks ago, during Frontend United, I saw a few presentations that touched this subject and so I decided to put it to the test in our LimoenGroen projects.
This weekend the first Frontend United event took place in Amsterdam. The successor of the Drupal Design Camp was visited by over 200 attendees and really one of the best Drupal events I’ve been to.
Or: how to improve the process of becoming a co-maintainer?
I’ve had more than a few projects where we used a contrib module and found a bug. We then searched the issue queue of that module to find out we were not the only one with that bug. And if we were lucky, there was also a patch that fixes the bug, so we could patch the module and carry on. But we need to make sure we document this patch to not override it when we update the module. As a Drupal developer you really want to use full released and unpatched modules.
