Feb 11 2020
Feb 11
Sun through a lense

"A picture is worth more than a thousand words". True, but a large picture will make your webpage slower, which will affect your SEO in a negative way. And eat away at your servers space, megabyte after megabyte.

There are several ways to remedy such a behaviour, but one way is to use image compression services to save space. With online services or programs on your computer you can remove unnecessary information and compress images with sometimes up to 80% gain.

Here I'm going to show you how to integrate the TinyPNG service in your Drupal installation which automatically compresses your images.

TinyPNG

There are many different services on the internet, but one of the best I have found is TinyPNG - and it's supereasy to implement on your Drupal site.

It's also super easy to see if you can benefit from using their service. If you visit their Page Analyzer and enter your site url, you will be presented with statistics. If you are over 25% savings, I would suggest you start using a compression service.

Statistics over how much your website can benefit from using an image compression service, in this case TinyPNG

Step 1: Installing the Drupal module

By using composer to install the module and the TinyPNG library, it's super easy to get started.

Type

composer require drupal/tinypng

in your terminal. Composer downloads the module, places it in the correct folder and downloads its dependency - TinyPNG PHP Library - and places it in the vendor folder.

 

Head into your Drupal website and click Extend in the menu. Scroll down (or filter) to TinyPNG and activate the module. 

Step 2: Getting an API key

API Key? What's that? Well, to make TinyPNG accept the requests from your website to the service you need an API key. It's a way of saying "howdy, can I get some service". It's also a way for TinyPNG to track how many images you get compressed per month. Don't worry, you get 500 for free every month, so unless you upload more that that, you're in the clear

If you should send more than 500 requests then you won't get access to the service until next month - or if you pay for the service. 

For normal use, 500 requests should be enough.

Getting an API key couldn't be simpler. Just visit the developer section of Tinypng.com and enter your name and email. 

You get an email with a link. Click it, and - boom! - you're in. On the page you can see your API key and also a counter that lets you know how many requests TinyPNG has processed using your unique API key.

Screenshot from TinyPNG's developer page with an API key

Step 3: Make the magic work in Drupal

Click the Configuration link in Drupal's menu and look under Media. There you find TinyPNG Settings. Click it.

Now it's time to copy the API code you got from the TinyPNG service. Paste it into the field on the settings page and hit Save configuration.

Screenshot from the settings page of TinyPNG inside Drupal

Step 4: Choose your compression method

The module facilitates two different kinds of image compression: on upload or via Drupal's own Image Styles - or both. I myself use the uploading kind since I then know that I won't reach the monthly limit through the API. If I would use the image style version, then I could reach - and pass - the limit in a fast way since I manage a site with a lot of images. Sure, I don't need to use the image action on every single Image style I have in Drupal, but I sure would be tempted to do so. 

If you choose to use the TinyPNG API whn uploading you get two options under Integration method: Download and Upload. They are the same, the only thing to remember is to use Upload on your local installation and Download on your live server. The help text says it all: "The download method requires that your site is hosted in a server accessible through the internet. The upload method is required on localhost." Though, personally, the names could be better. But anyway, it does the job.

Step 5: Save some megabytes

Well, actually there isn't a step 5. After installing the module with its dependencies, entering your API key there isn't much more. Just sit back, relax and watch the images shrink when uploading and/or showing them to the users making their experience on your website faster and better.

Some numbers

Here is also a comparison before and after using TinyPNG.

Type   Before compression   After compression   Saved, %Image 1, PNG   1.1 Mb   267 Kb   75%Image 2, PNG   1.1 Mb   287 Kb   75%Image 3, PNG   1.2 Mb   269 Kb   77%Image 4, PNG   985.7 Kb   274.0 Kb   72%Image 5, PNG   5.6 Mb   1.5 Mb   73%Image 6, JPG   3.5 Mb   524 Kb   84%Image 7, JPG   197 Kb   104 Kb   47%
Jan 22 2020
Jan 22

Whether RSS has a future or not is debateable, but I often find myself removing the standard RSS icon in Drupal, sometimes for good or sometimes for just placing a nicer version of the classic icon somewhere else in my theme, linked to the RSS feed.

In Drupal, like with so many other things, there are several ways of removing the RSS icon in the theme. I'm going to show you the way that I have found to be the easiest and the way that also sticks when you're trying out, or switching to a new theme.

The frontpage of Drupal where we automatically is served an RSS icon with a link to the feed.The frontpage of Drupal where we automatically is served an RSS icon with a link to the feed.

Sure, you can remove the icon in the theme you're putting together, or you can hide it with CSS (don't do that, that weakens your SEO ranking) so the way I'm going to show you is within the system, within the awesome thing that is Views.

What... Views?

For those who don't know it, Views is a module in Drupal (up until version 7 of Drupal it was a stand-alone module, but from version 8 it's part of Drupal and makes every listing a view, which is awesome!). Views can be described as a "point and click interface to ask simple or complicated questions about the content of the website", or "a graphic way to get content in listings (or just one result) from the database". Whatever you want to use Views for, it's highly competent and when you get to know the way Views in Drupal works, it's only your imagination that set the limits of what you can do with the content after that.

Every listing you see in Drupal, both the listings for the editor and the listings that visitors can see and visit, are powered by Views. And you are able to edit all of these, able to bend them to your pleasing.

With that said, let's dig into Views and make a teeny, tiny change that'll remove our RSS icon.

Structure -> Views

Log in to your website, navigate to Structure and then Views. The image below shows the way (the dropdown menu is not native to Drupal, it's an add-on module (or plugin if you will) called Admin Toolbar.

Image showing where to click in Drupal to get to the Views sectionClick "Structure" and then "Views" to get to Views section of Drupal.

Behold! Views!

When accessing Views for the first time, it's kind of boring. It's only a listing of different Views that you know nothing about.

The landing page for Views in Drupal

Well... See this as a "beginning of a beautiful friendship".

Different displays in Views

Another thing you need to grasp before heading into the interface of Views is "displays".

You can have as many Views as you want, but it's common and recommended that you collect them and sort them depending on what the views are for. 

For example. If you want to have three content listings - perhaps landing pages - showing the articles you have written but you want to sort them differently or want to show different version of the content depending on the situation. In the first listing you want to show everything - preamble, the article itself, images and a description of you as an author. The second listing should only include a small version of the article image and the preamble - to tease your readers. And the third listing should only include the title and the date of when the post was published. Since all these three listings handles the same content in some way, it recommended that you create one View, and have three different displays in that View.

There are many different displays in Views - and you can add and create your own - but this article will only mention them.

Different displays in Views

Let's dig in!

Time to do the thing we're here for. Time to edit a view! And not only a view - one of the displays of a view!

Start by finding the View called Frontpage and then click Edit to start editing the View we want to change.

Click Edit for the view called Startpage

What you see next can be a bit much, but don't worry, we won't go into the depths that are Views, we are just going to do some clicking around, uncheck a checkbox and save the view to accomplish what we are here for.

What we are editing now is the list of content that are shown on the frontpage of Drupal, and the feed icon is there because there is another Display in this View.

Remember, you are recommended to use one View for similar content and here is another great example: content shown to visitors and a RSS feed, shown also to users, but with a RSS Reader of some kind. Same content - shown in two different ways.

This View has two displays: Page (the one that are used as frontpage) and Feed (the RSS feed). The RSS feed is represented by the icon and are attached to the Page display. In other words, whereever the Page is shown, the feed tags along like an annoying little sister or brother.

The two different displays of the View

Ok, let's remove the RSS icon now already!

Yes, time to operate! We are going to edit the second display, the Feed, and detach that one from the first display, the Page.

To do that, click the display for the Feed.

Then, in the middle column, find Feed Settings. 

Next to Attch to:, click Page.

Uncheck the Display called Page.

Click Apply.

End this by clicking Save, to save the View and make your changes take action on your website.

And, voilà, when you visit the frontpage of your website, the icon is gone!

Think of this as well

Even if the icon is gone, the feed is still active and can be accessed via the URL /rss.xml. If you want to remove the feed, you need to deactivate the Feed display in the View called Frontpage.

You can choose to disable the feed altogether

Another way to make the feed more difficult to find is to change the URL to the feed, set your own path to it.

Under Feed settings in the middle column of the View, click the /rss.xml path to change it to whatever you want. Don't forget to Save the view after you've changed something.

You can change the path to the RSS feed as well

"But wait, there's more..."

Yes. There is one other thig to remember. Well, there are many other thigs, but Drupal also generates RSS icons to taxonomy feeds as well. Taxonomy is the name for terms, tags, categories, and these are displayed by default in Drupal.

The taxonomy listing is structured in the same way as the Frontpage, with two displays where the Feed is attached to the Page. So to remove the RSS icon from the feed of taxonomy terms all you need to do is to repeat the process shown above but within the View called Taxonomy term.

Also change the view called Taxonomy Term

That's it!

That's my way of removing that pesky RSS Icon. Hope you have enjoyed the guide. Please feel free to read some of my other guides and walk-throughs in Drupal.

TL;DR;

For those who already know Drupal: Detatch the Feed display from the Frontpage Page display in Views. Repeat with Taxonomy Term if you want to remove the RSS Icon from that listing as well.

Sep 30 2018
Sep 30

Not only did DrupalEurope in Darmstadt a couple of weeks ago give me the opportunity to learn more about Drupal and meet old friends and community members - it was also the new start of coming back to doing a pod again.

The Drupal pod Drupalsnack has been on hold for a year when I wrote a book about old commercials found in comic books during the 60s, 70s, 80s and 90s. But when the book now is printed and can be found in stores - it's time to go back to recording a pod.

And the first episode is about DrupalEurope. Me and my podcast colleague Kristoffer took the opportunity to interview Michael Miles who came all the way from Boston, USA, to visit DrupalEurope. I also spoke to Baddysonja - Baddy Breidert - who has been the project manager, leading the masses in organising DrupalEurope, and Kristoffer stopped Dries in the hallway and interviewed him about all the news around Drupal.

All in all, it is great doing a podcast again, and this episode is in English since we did all the interviews in English. Next episode will be in Swedish again, which will be a relief. I consider my English to be quite good, but it is always easier to do a podcast in your native language.

Listen to the DrupalEurope episode of Drupalsnack by clicking here.

Jul 28 2016
Jul 28

Ever since Drupal 7 I've used GIT to keep track of both my personal repos as the ones the company I work for manage. In short, I use GIT quite a lot. A colleague of mine use GIT to keep track of his computer setup so he easily can pull down his settings and .profile whenever he chooses to reinstall his computer or get a new one. I've heard of a guy (or girl, can't remember) who use GIT to keep track of all his documents. That seems a bit handful, but GIT is wonderful to keep track of the changes in your, for example, Drupal repo.

And even if I've used GIT for so long, I'm still learning new stuff about GIT and it makes my daily work even better and more streamlined. Below I'll share some of my discoveries when working with Drupal and GIT.

I've updated many modules, but I want to commit them one by one

I've done a total update perhaps, or anyway updated more than one module, but I want to make separate commits due to OCD or company guidelines, well as long as the module is located in it's own folder (which they are), that's no problem.

Example: I've updated two modules, Token and Metatag, and now I have a list of 40+ files which are listed as either modified, deleted or new. Instead of doing a total commit of them all, I simply add the folders, one by one, and do separate commits of them.

$ git add sites/modules/token
$ git commit -m "Updated Token module"
$ git add sites/modules/metatag
$ git commit -m "Updated Metatag module"

Two modules, nicely committed one by one. Now you can sleep without any OCD nightmares.

Add all files, but not all!

This is one of the latest I learned. Sometimes, when I update Drupal Core I want to add all files, but for some reason I want to exclude one or two files.

Example: I've updated Drupal core, which led to 60+ modified, deleted or new files but among them I have my settings.php and an updated module (let's choose Metatag again) that I want to exclude. I could do a separate git add for the module folder if I want, but perhaps I don't want to commit it at all, and that's where this comes in handy.

$ git add -A    // Add all the files
$ git reset -- sites/all/modules/metatag**     // "un-commits" the metatag module folder
$ git reset -- sites/default/settings.php    // "un-commits" the settings.php
$ git commit -m "Updated Drupal Core like a pro!"

I've made changes to a file, but want the original file back

This happens a lot. You try something out, go wild, and then suddenly want your original file back. No worries. Just use this to make the changes disappear and the original file will magically appear again.

git checkout [filename]

You can even make all the changes disappear, going back to square 1 on your repo.

git reset --hard

That command will not erase new files, though, so you might be standing with a bunch of new files that GIT won't ignore. You can either delete them, file by file, or you can use the following command to erase all the un-committed files:

git clean -d -x -f

There's changes in my file? What changes?

Sometimes when you upgrade a module or if you just come back to a project and you can't remember what you've done, there's a quick and easy way to see the differences in a file. If you do a git status and a file comes up as changed you can type git diff followed by the filename or complete path to the filename and you'll see the changes. If there are a lot of changes you might want to check out other ways of analyzing the changes. If you're using Sublime Text Editor I can recommend Git Gutter.

$ git status    // Lists all changed files
$ git diff .htaccess   // Shows the changes in the .htaccess-file

That's a few examples of what you can do with GIT, use it for. As I discover more, I'll write them down here so we can spread the knowledge.

Jul 20 2016
Jul 20

When I started making sites with Drupal 8 I missed a special body class that I sometime need for theming as well as other times, and that's the language body class. When making multilingual sites this comes in handy sometimes. For Drupal 7 this was made possible by the Internationalization (i18n) module, but since that module has been moved into core in Drupal (source) that special body-class-adding-thingamajig seems to have vanished.

After facing the need of language id when making this site I started to search for a solution, but came up with very few answers. When I solved it I thought I could make a short entry to spread the knowledge.

My needs

Basically, I had two needs for the language class to be added to my theme. 

  1. I wanted to hide some of the meny items depending on which language the content was presented in. (I later solved this in another way in my theme, but that was the initial need for a body class representing the current language.)
  2. I have two different RSS-feeds, one for posts in English and one for posts in Swedish. To make it work 100%, the path to the feed needed the language id as well. This was the latter need for me, and also the need that made it to the final site.

The theme

The themes I've used for Drupal 8 haven't had the language flag/path, but some themes may have implemented it, so if you have the path in the body class then you probably don't need to read this.

The example I'm going to show you is from the the Bootstrap Clean Blog, which I use for this site, and I will show you the code for adding the language id to it.

The files

In the theme folder of Bootstrap Clean Blog you need to locate two files:

  • bootstrap_clean_blog.theme, which is in the root of the theme folder called bootstrap_clean_blog and
  • html.html.twig which is located in the templates folder.

In bootstrap_clean_blog.theme (or any other .theme-file you might have in the theme you're using/developing) add the following code snippet to it:

function bootstrap_clean_blog_preprocess_html(&$variables) {
  $language = \Drupal::languageManager()->getCurrentLanguage()->getId();
  $variables['language'] = $language;
}

If you're using a different theme than Bootstrap Clean Blog, the name of the theme-file is something like XYZ.theme, where XYZ is the name (lowercase with underscores) of the theme. For example, if you're using the Pixture Reloaded theme, the theme-file is called pixture_reloaded.theme.

The code above calls for the language by getCurrentLanguage() and assigns the value to the variable $language. After that the value of $language is assigned to the global variable array $variables['language'].
You could shorten this down to

function bootstrap_clean_blog_preprocess_html(&$variables) {
  $variables['language'] = \Drupal::languageManager()->getCurrentLanguage()->getId();
}

but I wrote it on two separate rows to make it more clear. The shorter code snippet is quite allright, though, and you can use that in your .theme-file.

Next up: The TWIG-file

Allright, so far we've collected the language and stored it in a global variable. Now it's time to make it visible on the webpage, to print it. This is done via TWIG, a fast and secure template engine that Drupal 8 started using. To print the $variables['language'] you write the following "twig code" in your template where you want it to be printed.

{{ language }}

So, in my example, if we want to print it in the body class, I open up the template html.html.twig in the templates folder of the theme and search for the line where the body is set. It looks like this:

<body{{ attributes.addClass(body_classes) }}>

It prints the following HTML when rendered in a browser:

<body class="user-logged-in path-frontpage">

Though, we can't just add {{ language }} to the body tag since it won't be a part of the {{ attributes.addClass(body_classes) }}. Those are set a couple of lines up, but it's easy to fix it. They look like this:

{%
  set body_classes = [
    logged_in ? 'user-logged-in',
    not root_path ? 'path-frontpage' : 'path-' ~ root_path|clean_class,
    node_type ? 'node--type-' ~ node_type|clean_class,
  ]
%}

In i similar way we add:

language ? 'lang-' ~ language|clean_class,

so the final result looks like this:

{%
  set body_classes = [
    logged_in ? 'user-logged-in',
    not root_path ? 'path-frontpage' : 'path-' ~ root_path|clean_class,
    node_type ? 'node--type-' ~ node_type|clean_class,
    language ? 'lang-' ~ language|clean_class, 
  ]
%}

Now comes the thing that's very important. After saving your theme-files, you must clear cache for the changes to appear. Click Configuration > Performance > Clear all cache. Then reload the page and check the source code of it et voilà - it works and the source code looks like this:

<body class="user-logged-in path-frontpage lang-en">

That's that. You can now use the class lang-en to distinguish your English pages and on your pages in another language it might look something like this:

<body class="user-logged-in path-node node--type-article lang-sv">

You can also use {{ language }} anywhere else, for example is you have the same need as I, to make a link language-dependant: 

<a href="https://www.adamevertsson.se/{{ language }}/feed">RSS</a>

which gives you the following complete HTML

<a href="https://www.adamevertsson.se/sv/feed">RSS</a>

or

<a href="https://www.adamevertsson.se/en/feed">RSS</a>

if the visitor is on the English part of the site.

Hope this helped you in some way. Happy drupaling!

Nov 19 2015
Nov 19

Ever since I started using Drupal I've wanted to share the knowledge I have gathered around Drupal. I did some screncasts a couple of years ago, in Swedish, and they were appreciated. Then, time disappeared, other projects ate my time. Since I teach the basics of Drupal at schools and more specialized educations for companies, I've never given up on the dream of continuing the screencasts in some way.

Earlier this year the company I work for, Kodamera, gave me green light to make screencasts about Drupal. My dream has come true! A website was put together to promote the episodes and so far I have made five screencasts on Drupal. My greatest challenge will be to do these screencasts in English, since it's only my second language. Though, growing up with Monty Python get straight A's in school when it came to learing English should help a litte.

Since a stable version of Drupal 8 has been released now, I'm planning a whole series of screencasts to cover the basics of Drupal, how to get to know the system. These are not meant for us who already know Drupal, instead they are meant to give newcomers and people who are curious of Drupal a good start. The first screencast - how to install MAMP and Drupal - was released earlier this week.

[embedded content]

I also wrote a loooong blogpost on how to install MAMP: http://screencast.kodamera.se/drupal-introduction-and-installation

Hopefully I will do a good job recording these screencasts, and I will do my best to include some good jokes and something from Monty Python now and then. ("Nobody expects the Spanish inquistion!")

If you want to know when I do a new screencast, subscribe to the playlists on YouTube, check the official Twitter account or follow me on Twitter, I'll retweet the tweets.

See you around!

// Adam

Oct 09 2015
Oct 09

I've been a part of the Swedish podcast Drupalsnack for over 2 years now, and it's always fun to do a podcast while at a DrupalCon. This year, we managed to record the podcast in one of the BoF rooms, but some interference with the recording led up to a re-recording a couple of days later. 

This year, we did three interviews: Kristoffer's colleague Kevin who was a first-time-attendee at a Drupal event ever, Antje from the Drupal Documentation Group and Holly Ross. Furthermore we talked about the conference itself, highlighted some of the sessions we attended and also covered the upcoming release of Drupal 8 RC1 (that was released two days ago). 

You can click here to download the mp3-file or visit the official site of the Drupalsnack podcast to listen in your browser. We apologize for grammatical errors and that we sometimes sound like The Swedish Chef (hurdy-burdy-gloop).

Apr 13 2015
Apr 13

When classic Drupal-sites like GotDrupal, YadaDrop, NodeOne and DrupalDude aren't updating their Drupal resource sites and/or pages anymore, there are always new sites around the corner to help you in your Drupal quest. I've listed 5 of them earlier, and here's five more...

ModuleNotes

If you find the information for the different modules on drupal.org too long and hard to get a grip on, ModuleNotes might ease your pain. Written by users for users, in plain English - "this is what this module do, and it's awesome!".
Visit http://modulenotes.com/

Drupalstatus

Do you have a bunch of Drupal sites out there? Tired of getting email messages whenever there's an update available? A rather new, and free, way of keeping track is Drupalstatus.org. Through a module you connect your site to Drupalstatus and get an overview, and a weekly summary of what modules you should update, security information and such. Came along when Droptor was on the slope, and became the savior for all of us who looked for an alternative. (See related post here.)
Visit https://www.drupalstatus.org/

DrupalDump

Slightly older and not so updated anymore, but it still holds a lot of information and tips and tricks. Hundreds of knowledge snippets, sorted into different categories makes this a good place to collect good information about Drupal - at least for a couple of years.
Visit http://www.drupaldump.com/

DrushCommands

If you're an avid Drupal developer or just building one site, one time there's a lot to gain of using Drush. Drush is a bunch of terminal commands that speeds up development and/or theming Drupal. It's like an AddOn-pack for your favourite boardgame. With Drush, your terminal usage will increase but you will also spare a lot development time. Just clearing cache is a dream in Drush, and with that you can skip opening up the Performance page and clicking the button to clear your cache. Anyway, DrushCommands.com offers a comprehensive list of all different versions of Drush available to us as users and which commands that works in which version. Great to have around if you want to start using - or improve your usage of - Drush.
Visit http://www.drushcommands.com/

DrupalShowcase

"I've never heard of this Drupal, I don't like, I don't think anything is built with that Durpel thingamabob..." Ever heard something like that from a client, a friend (ex-friend!) or other. Well, if you want to stick it to them, and show them that there are many beautiful, clever and useful sites out there, running on Drupal - DrupalShowcase is a great way to start. Thousands of Drupal-sites are listed here - and you can easily add your own!
Visit http://www.drupalshowcase.com/

This blogpost was featured in Bob Kepford's The Weekly Drop, issue 185! Awesome! (At least for me...)

Oct 08 2014
Oct 08

DrupalCon Amsterdam has come to an end (well, it ended last week, buy hey, I need to catch up on some work as well). It was the biggest DrupalCon in Europe ever, 2,300 attendees! Pretty impressive. I've written a couple of blog entries, trying to capture my stay in Amsterdam and my feelings for a DrupalCon which I attended for more than three days (which has been the case with DrupalCon London and DrupalCon Munich).

Not only did Drupal 8 get a BETA during these days, but a lot of sprinting was happening (as always) and it was pure joy walking through the Berlage in the center of town and at the venue, seeing all that work being put into Drupal.

Tuesday and Wednesday was filled with interesting sessions, and both Tuesday evening with nice boat rides and pub crawl and Wednesday evening with open museums (the light installations at the EYE was spectacular!) was very nice indeed. Thursday, the day for separation for many of us, was also filled with good sessions and the closing talk with Holly and Stephanie both invited us to DrupalCon Barcelona next year, as well as presenting cool statistics about the Con.  

The good...

All of the sessions I attended was good, and, as always, I'm impressed by the time and energy people devote to making Drupal happen and spreading the knowledge and some love. Dries Buytaert's keynote ('the Driesnote') was inspiring, but I didn't agree with everything he said. He talked about the "free-riders", the ones who doesn't help out with Drupal, the ones who only take advantage of the system witouth giving something back. Such a thing is a bad thing, according to Dries. But I think that we also need those free-riders, becuase those free-riders are the ones using the system, making the statistics for Drupal go up worldwide, spreading the word of Drupal. If we don't have free-riders, are the only ones who should use Drupal the ones who code it and support it? If so, Drupal won't get far...

Amsterdam RAI, the venue, was a good venue. Apart from some sessions being very popular (which is a pain in the a** forseeing) so I couldn't get into them, the rooms and hallways were good for sessions and sprinting. The technique was good as well, sound and vision in the sessions was flawless. Big thumbs up for that. The recorded sessions was also professionally made, at least the ones I've had time to watch. Finding them on YouTube the same day or, to some extent, the next is also impressive. Big thumbs up to the techinal team who worked on that during the Con.

The evening activites was also impressive. Ingenuity, local connection and very nice people raised the bar a lot. I kind of fell in love with the architecture of Amsterdam with it's old crooked buildings, canals and the narrow streets, and the boatride on Tuesday evening was magical!

...the bad...

But there's always something that brings a frown to the face. This time I frowned upon three things. The wi-fi. The coffee. The food.

The wi-fi. It's shouldn't be that hard to calculate that if 2,300 persons gather in a closed area and at least half of them have both laptops and phones, there will be much traffic. I don't want to drag Drupal Association of the local community in the dirt here, they hired a company to manage the network and wi-fi, but it's irritating trying to get online for various reasons, and the network dies several times a day.

The coffee. Apparantely the coffee last year in Prague was bad. The worst thing about coffee this year, was that it wasn't free. It cost me 2.5 Euro. When I pay this much for a ticket to a DrupalCon I kind of expect coffee or some other drink to be free. If it's too hard to calculate, try giving out beverage tickets, two or three per day. Some will get lost, some won't be used, but at least I won't have to pay 2.5 Euro for a small cup of coffee that's not even that good.

The food. A small bowl of pasta or paella. A sandwich and some dessert. I was hungry three hours later. I had the opportunity to visit DrupalCon Munich in 2012 and the food there was out of this world. Every DrupalCon after that will always have worse food. But this one is a killer. No imagination. Lots of garbage (in a time where we try to limit our carbon footprints). No drink. (At least I couldn't find any. Or maybe I was supposed to go and buy me a drink for 2-3 Euros.) Didn't get that. Didn't do that either.

There. Now that's out of my system. I won't remember that when I'm, 60. But I'll remember the rest of DrupalCon Amsterdam. The sessions. The laughs. The excursions.

...and the ugly...

Well... I found an ugly statue somewhere in town, but otherwise that headline was only in it for the Clint Eastwood reference.

Special thanks to...

It takes a lot of work making a DrupalCon happen, and the Drupal Association pulled it off with a gold star I think. Sure, there were flaws, but then perhaps those won't happen next time, or there were good reasons to why there were flaws. But the Drupal Association do this for a living, so I will only give them a normal-sized 'thank you'. The big 'thank you' goes to the local community who gave the DrupalCon a Dutch feeling. I also want to say thank you to those people who were mentoring before, during and after DrupalCon. Instead of working with the code like you perhaps wanted to, you devoted your time and energy to encourage us lesser beings who want to learn more about Drupal. Also, a big hug to Annertech, who made the Quiz Night happen. It's not an easy task trying to get Morton and Bert the crowd quiet so you can present questions and answers. The man with the microphone also liked the name of our team - Fools drush in - which was nice!

You all know who you are - THANK YOU!

Oct 04 2014
Oct 04

For many years, I've been using Drupal as many people do - by clicking, publishing information and creating websites through the addition of modules and themes. I know how to code in PHP, but with my involvement in the local Drupal community, organizing three DrupalCamps in Gothenburg (2012, 2013 and 2014) and having family and friends, there hasn't been much time to dig down into Drupal and help out with issues and writing code.

When DrupalCon Amsterdam came closer I chose to take a couple of vacation days, and stay for the sprints after the camp. To take part in the First-time Sprinter Workshop on Friday and learn how to code in Drupal.

First-time Sprinter Workshop

We were a big bunch of people, gathered in a room at the Amsterdam RAI, to learn how to code, or at least how to help out. We would have three hours of introduction, which I had high hopes for. Apart from us, there were about 20 mentors helping out. The first thing we had to do was to install all necessary programs, like GIT, Acquia Dev Desktop, Limechat etcetera. Since I work with GIT, have been on IRC for many years, nothing of this was new. Installing the Dev Desktop was troublesome though, and much time went to figure out what was wrong. During this time I couldn't pay attention to what was said about drupal.org and the issue queue, so suddenly I had no idea of what to do with my (slightly) new coding environment. I just didn't know what to do. I asked one of the mentors, and he said to go find an issue in the Drupal Core and work on that. Work on it how? What should I do with it? This was why I wanted to stay for the sprinting, to learn what to do, perhaps even how to do it. Frustration was creeping up on me...

YesCT to the rescue!

So I sat down in front of the issue queue and tried to find something to do. I didn't know what to look for, and I ended up helping out on IRC and helping a guy sitting next to me, who knew less about GIT than me. Felt good to help someone, and to actually feel useful. Then suddenly Cathy Theys, YesCT on Twitter, comes in and asks some of the guys in the room if the mentors had explained what to do when the coding environment installation is done. Since they hadn't been that thorough, Cathy took some time to do so, and that was so welcome. Suddenly I actually had some clue of what to do. A little better clue anyway. With Cathy's words in mind, I also asked a mentor called Andy if he could help me finding something to focus on. He took care of me, placing me next to two other guys who are new to Drupal coding as well, and together we explored the issues queues, trying to find appropriate tasks to do.

"Is that a wall heading my way?"

I realised quickly that even an issue tagged with 'novice' was often to hard for me, since I'm new to Object Oriented Programming, but after a while I started reviewing a patch here, a patch there and summarizing an issue here and an issue there. A fellow podcast member, Kristoffer Wiklund, said that even though everyone here wants as many as possible working on, patching and reviewing Drupal 8, there are still thousands of themes and modules out there, both getting re-written for Drupal 8, but also having issues for Drupal 7. Therefore, I also took time to look at some of the modules and themes that I use, to see if I could help out there. And I could! You can't imagine the feeling when I'm suddenly taking baby-steps towards helping out more and more. My Dashboard on drupal.org was, within the hours, filling up with comments of what I've summarized, what I've added and reactions to my comments. That, my fellow Drupalistas, is something you can't put a price tag on.

Ending on a high note

The day started quite bad, but ended much better, in two ways. Apart from the wounderful mentoring of Andy, we were also approached by some other mentors handing out a handful of cards, with different tasks on them. It was Sprint task cards, and when summarizing what I've been doing with Drupal for the last 4 years and what I've done during DrupalCon Amsterdam, I suddenly was eligible for 4 out of 6 cards. Sure, the mentors were a bit nice on some tasks, but it felt really good on getting 4 stickers with "Explorer", "Mentor", Issue mover" and "Community contributor". The last one was extra nice, since I work quite hard on arranging the DrupalCamps in Sweden.

"One more thing..." 

But that was only one thing that made the day extra special. What about the other? At 5 o'clock, Cathy entered the room and announced it was time to see when webchick, Angie Byron, commits patches to Durpal 8 core live - on stage. Well, there wasn't a stage, but at least in front of everybody. I was sitting at the desk in the front, so I had a very good seat. They did the commits, and denied some, and everything was nice and so. Webchick has a really good sense of humour which made everything extra nice. In the end she thanked the people who had made the patches she committed this afternoon but then  - and I could applause this for a very long time - she also said that it's all of us who are important, from the tiniest little bug reporter to those who do screenshots and write summaries. That showed me that I really can make a difference and that I shouldn't pack it up and go home, just because I can't write code that fixes all the major bugs in Drupal 8. And now for the good part - when Angie asks everyone that had helped out with patches to stand up I thought I shouldn't stand, but my mentor Andy encouraged me to stand up. Sure, I had helped, but I didn't think it mattered that much. But he did. And I thank him for that. That extra encouragement made me want to go home and continue looking through the issue queues at Drupal.org, helping out, fixing it. So we can get Drupal 8 out the door. Together.

(I ended up visiting an art exhibition of LEGO statues called 'Art of the brick' that evening, but that's a different story.)

Sep 29 2014
Sep 29

Even if I went to bed early, my B&B's location close to the fire department made my night eventful (two fires apparantly) and my morning at bit slo-o-o-ow. I did have the time to get my registration done at the venue, get a cup of coffee and join the other Drupalistas in G104 for my first community summit.

Addison Berry greeted us, along with MortenDK and Holly Ross and topics were mentioned, topics covering different parts of the community around Drupal. You could discuss and help out with COD (Conference Organizing Distribution), dig into groups.drupal.org, work on drupal for non-profiting organizations and a bunch of other topics. I chose the topic closest to my situation right now - how to get local groups running and how to make people help out.

The problem in many countries

During the discussion many of us identified two major problems. First, it's hard to get people to get involved. The bigger cities don't see this problem, naturally, but smaller cities and even countries are facing the same problem. Second, the possibility of stress and burnout for those few who are getting involved and gives it all for Drupal. Many of us nodded our heads when the latter one came up in the discussion. And the same people seemed to have seen the same thing happening, fewer and fewer getting involved in the community. Well, they still attend meetups and camps, but they don't have the time nor the energy to help organizing.

So then what? We identified loads of problems, we wrote all down in a Google Doc for others to read and find courage and strength (as well as good tips and tricks) in. Next stop is to make a website where we make this information available for all those around the globe struggling with the same problems in their community - or want to start a local community group, or perhaps arrange a camp.

Other goals and tasks we identified this afternoon were to gather all the local groups we know about and try to find the other ones, so we can create kind of a catalogue of all local groups in one place. A nice thing that surely will be beneficial in the future.

Where do we find this information?

Until the website is up, and full of information, the best place to find the results of this particular discussion of the Community Summit on DrupalCon Amsterdam would be these:

What about the rest of the day?

The Community summit ended at 3 o'clock, which was a bit disappointing, but work was piling up, so perhaps it was for the best. I also got to spend an hour downstairs in the Europe Foyer, where the sponsors had arrived and set up their booths. Got me some cool swag (stickers, stress ball in the shape of a rocket, T-shirts) and had really nice and interesting talks with a lot of people. After that, I went to Brouwerij Troost where the Community Summit dinner was held. They served the best burger I've had in... well heck of a long time. And the beer was awesome. Talked to a gentlemen about something called CMS-garden, which is a really cool project where open source CMS's are being presented at different conferences such as CeBit. We actually discussed such a thing earlier today during the summit, and behold - here it is. Amazing (to paraphrase an anonymous Apple employee).

Tomorrow it's time for Dries keynote and all the sesions to start. I'm really looking forward to that.

EDIT: Since the wifi is really unstable at DrupalCon, this post wasn't published until Tuesday afternoon.  

Sep 28 2014
Sep 28

My first day of DrupalCon Amsterdam comes to an end, and behind me are a visit to the wonderful sprint venue Berlage, which is located near the train station in the center of Amsterdam, and a loooong walk to Vondelpark (no, not Wunderkraut-sponsored Wunderpark, which many suggested). My global aim for this DrupalCon is to dive into the code of Drupal, becoming more custom to the code behind Drupal. Normally I classify me as a Drupal user, I use modules and tune them to make Drupal do the stuff I want Drupal to do. But I want to evolve, to learn something more than just using Drupal. So when my co-workers are going home on Thursday, I will stay for the sprints on Friday and Saturday to hopefully learn something about coding for Drupal.

My visit to Berlage was a small step in that direction, to see if I can help out and learn something. It turns out I came just when people were leaving to welcome the people coming to DrupalCamp Amsterdam by bike (!). I knew some of these people, so naturally I came along to Vondelpark to welcome the cyclists. A barbecue was firing up, beers were cooling and people were nice to talk to. I met a whole bunch of new people, and some old acquaintances as well (which was surprising since I don't consider myself a Drupal-globetrotter). 

The local Drupal Community really showed off a good time, arranging this barbecue, and they also talked about what will happen during the following couple of days, which really looks promising. There are around 15 persons in the local community, and it seems they have done a good job! It's going to be nice seeing what will become of this.

Tomorrow, I'm going to spend the whole day at the Community Summit - and since I'm coordinating my third DrupalCamp Gothenburg seven weeks from now, I hope to pick up some good tips and tricks and perhaps get some of the other people to come to visit Gothenburg.

Sep 17 2014
Sep 17

My blog has been suffering alongside my work with DrupalCamp Gothenburg. It's hard work since we're only two guys making it happen this year, and there's a lot done and more to do. It brings me great pleasure to say that we just passed a major mile-stone when releasing the website for DrupalCamp Gothenburg. It's a new take on camp-sites, at least what I can gather. This site wont disappear after a couple of years, when the community looses interest in it. This site will not only promote this year's camp, it will also act as a collection of the earlier sites, tying sessions together, acting like a "blast from the past" - one site to rule them all. 

Why, you might ask? Well, time is limited and since it's hard to get volonteers in Gothenburg to help out, this is a way to tighten the information flow and a way to skip doing the same thing year after year (making, coding and releasing a new site). Instead, we will focus on presenting the information from former DrupalCamps in a good way on the site, perhaps making it more interesting for our sponsors since their sponsoring presence won't disappear after a couple of years.

This year, though, we have a new design, since it's a new take on the website all together, and Daniel Andréasson is the one pulling the strings behind the curtain. He has done a lot of work on it, and I'm truly grateful for his help. His effort has given me the chance to focus on the sponsoring part, talking to hotels to bring good rebates to our visitors during the camp-weekend, and also see if some of all the other ideas might come to life at the camp.

Well, enough talking, head over to the new site and check it out. And, if you're up for the task - add a session and share your Drupal knowledge!

http://gothenburg.drupalcamp.se/

Jul 03 2014
Jul 03

Fact: Using the Update module for collecting data has been the standard since Drupal 6.0.
Another fact: Sites not using that module aren't submitting usage statistics to drupal.org.
Yet another fact: Third-party monitoring services are rendering the Update module rather useless.
Result: Misleading statistics on Drupal core and module usage.

When Drupal 6.0 was released the Update module started submitting statistics to Drupal.org, a great initiative. Though, you can disable this module for different reasons, thus creating misleading statistics on Drupal.org. The same goes for Drupal 7, you can disable the module there as well.

Third-party services rendering the Update module useless

A couple of weeks ago the third-party service Droptor shut down unexpectedly and at the same time, DrupalStatus.org experienced a major boost in both design and functionality. (You can read more about it here.) I can't be the only one making the switch from Droptor to DrupalStatus, but with this service I discovered something that made me think.

Droptor, and another service called DrupalMonitor, used a module to send the information from your Drupal site to it's service - and these modules had a dependency on the Update module. DrupalStatus sends it's data on it's own, without using the Update module. (Don't get me wrong here, I love DrupalStatus, it's making my life easier in many ways, but the way it works result in information loss at drupal.org.)

Naturally, you shut off the Update module. Why use it, if it's not needed? Sure, by enabling it you get a GUI for adding and downloading new modules, but as an experienced Drupal user I don't do that, I use Drush to do those kind of things. So, I disabled the Update module. On every site I own. Since I don't need it. And Drupal.org is experiencing some loss of statistics.

Why does this matter?

Statistics are a good way of trashing systems like Drupal (or any other system for that matter), and if we can present more accurate statistics, we are also better prepared for such attacks. Also, as accurate statistics as possible is a good thing, both for Drupal itself as for module developers (seeing the individual module statistics going up is a great thing!). By using as correct statistics as possible in marketing, Drupal can benefit from it in the long run.

So what's the solution?

So what do I suggest? I suggest moving the reporting functionality away from the Update module - or any module - so every Drupal installation sends statistics of it's version and modules to drupal.org. Let Drupal report statistics all the time. It's as simple as that, and at the same time I realize it's not a trivial thing to accomplish. At least, I raised my voice in favour of getting better statistics for the system I care about - Drupal. Or am I completely wrong? Give me your opinion in the comment section!

My issue on Drupal.org: Collect all module usage and send it to drupal.org
Source: Drupal.org (Popularity of modules)

May 26 2014
May 26

For long, I've been using Droptor to get an overview of all my Drupal sites and it's a powerful service that not only gives you an overview but also statistics of your content and several checklists (security, performance, SEO and health) to see how your website is doing. It's great and much needed, but there isn't happening a lot at Droptor. I've submitted several suggestions on how to improve their service and they have applauded them, saying that these suggestions will come in newer versions of Droptor but then ... nothing.

If you, on top of the lack of evolution of the service, add a couple of lengthy outages, and a complete silence on twitter, their support email and other forums things start to add up and present a dark future. What will happen with Droptor? Vim Leers tweeted the other day

@droptor http://t.co/ReiONvTihR is unbearably slow. Even loading the front page takes >1 minute.

— Wim Leers (@wimleers) 11 maj 2014

No response from Droptor there.

When these things start to happen to a service, usually the natural selection kicks in and someone else takes the wheel. A couple of years ago DrupalMonitor from NetNode was released. A promising competitor to Droptor, that takes the good parts from Droptor and adds a nice graphic touch to it. (That is something Droptor really lacks - good design.) Though, development seems to have stalled at Drupalmonitor as well.

Enter, the new kid on the block - DrupalStatus.org.

Drupalstatus.org uses a module called System Status, similar to the modules Drupalmonitor and Droptor are using, to monitor your site. That enables the service to get a small peek (well, a big peek) into your system and then present this information to you in a nice manner. Both Drupalmonitor and Droptor does this of course, but DrupalStatus.org adds a great deal of good-looking graphic. It's also a tiny bit easier to connect your site to DrupalStatus.org.

After you've enabled the module you simply go to the configuration page and choose to add your site to DrupalStatus.org.

Screenshot of Drupalstatus.org

A couple of minutes later, after the first necessary information has been gathered, the site will present itself in your DrupalStatus.org listing.

Screenshot of Drupalstatus.org

So far, you've got a couple of different listings:

  • Sites: A quick overlook that gives you which version of Drupal you're running per site, and the number of modules used.
  • Modules: A list of all the modules used, and how many sites that uses each module.
  • Individual view. A drilldown of each specific site that shows not only what version of the different modules your site is using, it also lists the recent activity amongst the modules. And of course, it lists all the modules and recommends upgrading some of them...

Screenshot of Drupalstatus.org

To sum it up: I applaud this initiative, and though the usage statistics for the module on Drupal.org is quite modest, I see a bright future for the module and the service DrupalStatus.org. Hopefully the service doesn't stop at listing the different modules, but also present more relevant statistics of your site(s).

UPDATE 2014-06-01: Droptor.com has sent out an e-mail stating that they are shutting down within 5 days. 

Feb 13 2014
Feb 13

So you're a regular at drupal.org, and feel right at home in groups.drupal.orgDrupal Answers is practically your own living room and Google's results on "drupal" is your best friend. Well, have you tried these resources of Drupal knowledge...?

Ever had a great line of code you save and re-use over and over again? Well, you're not alone. Not at all. And with DropBucket you can share this with the rest of the Drupal Community, and get some karma along the way. At DropBucket you can find snippets to use with Drush, making modules, theming, you name it. The service is created by Tim Kamanin (TimOnWeb Drupal developer).
Visit http://dropbucket.org/

If you're quite new to the wonderful world of modules for Drupal, you might need some guidance before you find yourself knowing which modules to use and when. DrupalModules lets you give a short summary on the different modules you can use for Drupal, review it, grade it and thus helping others. A good place to start is the Module Finder page where you can sarch for modules via name och category.
Visit http://drupalmodules.com/

Drupal Association has a YouTube account where they publish recordings from the different DrupalCons, starting with DrupalCon London in 2011. If you just want to find that special session you remembered, or if you want to check out the different keynotes and sessions in case you couldn't attend - this is the place for you.
Visist http://www.youtube.com/user/DrupalAssociation

A bit old, and perhaps not the most updated site these days, but it sure contains a lot of tips & tricks and some screencasts as well. Especially interesting if you suddenly find yourself developing for a site built with Drupal 6.
Visit http://gotdrupal.com/

Not so daily anymore, but like GotDrupal it's an impressive collection of videos. 141 and counting. A good way to start learning Drupal, and for those who already know the basics, learn more.
Visit http://codekarate.com/daily-dose-of-drupal

Did I miss your favourite? Comment on the article below.

Aug 22 2013
Aug 22

The Drupal Association contacted me when I was working on DrupalCamp Gothenburg 2013 and asked me to write a blog entry about the camp. This is the result, posted at The Drupal Association website in June of 2013.

After visiting a DrupalCamp in 2011, I set off with a mission - to arrange a DrupalCamp in my hometown of Gothenburg. This became a reality only 5 months later and with the experience from that said camp of 2012 we set off to make the next one even better.

And at the time when drupalers from all over the world started their journey back home from DrupalCon Portland, or stayed for the sprint weekend, a similar, but much much smaller event took place some 7700 kilometers away. That event was DrupalCamp Gothenburg 2013.

I took the role of project manager again and together with 12 others, we arranged a great DrupalCamp - or should I say, a Drupal Weekend!

A Drupal weekend in Gothenburg

We turned our DrupalCamp into a real Drupal weekend, starting with a kickoff at a local pub. There, a number of us started (and ended) Friday night with discussions covering Drupal, PHP, Symfony and Swedish things like surströmming and, of course, the sunny weather. As a Swede, you always discuss the weather.

Friday turned into Saturday and in the morning we opened the doors of our venue of this year’s DrupalCamp Gothenburg, Folkets Hus - the House of the People, a community area with many rooms, perfect to hold sessions in.

This year, we were glad to present a full schedule, 15 sessions, that covered the whole day. The keynote was held by Tobias Sjösten, a well-known voice in both the Drupal and Symfony community in Sweden, and covered the symbiosis of Drupal and Symfony.

The sessions consisted of very diverse things, from web accessibility to Drush, via Git and Drupal 8. A whole session was dedicated to inform about Drupal Association and community-based work in Gothenburg.

After the sessions (and a lot of coffee) we headed upstairs to the restaurant in the same building where we dug into a buffet provided by the restaurant at the venue. With a beer in our hands we continued the evening with mingling, networking and enjoying ourselves. The sunny weather invited us to sit outside and when the place closed later that night, some of the attendees headed off to a club downtown.

Sunday came around and whilst we who arranged the DrupalCamp gathered for a well-deserved lunch together, others gathered at the office of Kodamera where there was a code sprint to help get rid of more bugs from Drupal 8.

From start to end, a 48 hour ride with Drupal as the common denominator, that was the final of some six months planning and work.

Tips and tricks for organizing a camp

When we arranged our first DrupalCamp in 2012 we ended up with a long list of things to improve. This year, all of the things on the list was improved, and we ended up with another list of things to improve for future DrupalCamps. With these kind of iterations, we learn and make better DrupalCamps in the future.

So what did we improve this year? What advice can I give to all you out there planning or arranging DrupalCamps all over the world?

The most important is to listen. Listen to your visitors, sponsors and session speakers. Ask them about their ideas and their feedback about your camp. Use that information to plan and improve your camp next time. If you’re a first time camp-organizer, then seek this kind of information from your local Drupal community, or post a thread in groups.drupal.org

When the camp is over, send out a survey to get feedback from all of those that you didn’t have time to talk to.

Second most important is to have fun. Make place for fun. Our camp is 100% community-driven so besides the experience, fun is an important ingredient to make all this work.

Look in the calendar and see what’s going on. Choose a date when your camp doesn’t have to compete with other major Drupal events. In our case, we ended up very close to another camp in Sweden, and of course, DrupalCon Portland. Date-wise, we didn’t really have a choice when to have our DrupalCamp before the summer would be here, and we ended up paying for it with less visitors.

Another thing is to launch a website early, and try to set a schedule with sessions early. That attracts both visitors and sponsors.

My last tip for all you out there: Avoid growing pains by growing slowly. Start off with a one-day event, then add a code sprint next time, after that perhaps a kickoff the following and then start experimenting with business days connected to your DrupalCamp. For us, we are somewhere in the middle, we have a great camp, and in the future we’ll explore the many possibilities a DrupalCamp can offer.

DrupalCamp Gothenburg 2013

About Drupal Sun

Drupal Sun is an Evolving Web project. It allows you to:

  • Do full-text search on all the articles in Drupal Planet (thanks to Apache Solr)
  • Facet based on tags, author, or feed
  • Flip through articles quickly (with j/k or arrow keys) to find what you're interested in
  • View the entire article text inline, or in the context of the site where it was created

See the blog post at Evolving Web

Evolving Web