Private files are great but they are a huge resource hog. In certain scenarios, lower-resolution versions of the pictures are absolutely fine to be public, only high resolution originals need to be protected. In this case you can use Drupal's private file handling as it is and the following simple trick to make a style public.

I am taking a break from core development for personal reasons. After writing close to 800 core patches and spending years almost nonstop on core development, I need a break. Please leave me out of core debates on IRC, emails etc. Thanks! Contrib work will continue especially on redis_ssi and relation (mostly thanks to my generous sponsors). I am not against paid core bugfixes either :) contact me for paid core or contrib work, I promise to charge a lot less than normal for code contributed back to drupal.org.

Many projects these days keep their work in github and it is a request often to make some dev site automated automatically. When I tried to enter a passworded URL into github, it didn't work. So I came up with what's below.

While patching Views I added this to an existing JS file thanks to caseyn. You can replace the iframe-related code (which is just two lines) to add your JS to Drupal:

I will use today being Christmas and me being on vacation as an excuse not to fight the hard fight of ordering my thoughts into a linear, nicely reading blog post. So here's an unordered list of my thoughts presented as an ordered list only to allow for easier commenting. They do form a picture, however.

I thought this evident but apparently not. You can download Drupal and run the tests provided. Just like that. If you download a few contribs and they have tests you still can run tests on any webserver, any environment what so ever to see whether they work together. It can be a small host or a cloud provider where all you have is the browser and no command line.

Seeing how much work I put into the past four major core releases and how it ended up as an inconsistent, complex mess, I feel it might be better actually if I withdraw and let others steer. Hopefully they can do better. I am not going to review or comment on any D8 feature patches. On the other hand there is an area where I am needed and that's the major bug queue. I am going to focus my attention on that. There are "toxic", year old issues that just don't want to go away. If each bug takes a week to get rid of, which is an optimistic view then we have two years of work ahead.

Say you have http://example.com/drupal/documentation?page=1. Let's presume documentation is an alias for node/26419

Then after a full bootstrap

DrupalCon should be two parallel conferences, one of sessions primarily directed towards business and a free core conversations track. This split is mostly complete: we have had a core conversation track, often in physically separate spaces for the last few DrupalCons. Now we had a session deadline that made it totally impractical to submit any session carrying any value to fellow contributors. The last step is to introduce session only tickets and adjust the focus a little.

There's a website I got involved with -- I built the first version on Drupal 6, with a hacked location_search module (for free). It kind of works, I am not proud of it but surely there are a lot worse sites out there. It's about 1000 nodes with some location search and mapping. The site owner has about 6-800 dollars to get it ported to D7 and clean it up. First we tried with a Hungarian guy who was inept in it. Then another Hungarian company which did some progress (still on D6) but simply disappeared after some time.