A long time coming: Drupal 8 Core directory structure nicely reorganized...

An exciting change has finally been committed to Drupal; the directory structure has been improved to move basically all of the files which are replaced during Drupal updates into a '/core' subdirectory. This should make it much simpler to manage updates and should also mean that there is less chance of new users unwittingly placing their downloaded ‘contributed’ modules and themes into the top-level directories. While it might seem like a very simple change, there is a reason that the issue which proposed the reorganization, first created over six-and-a-half years ago and originally intended as a change for the not-yet-released Drupal 4.7, took so long to be committed — and that it had over 300 comments on it by the time it was closed and marked as “fixed”.

Just what was moved where, anyway?

All of the core ‘.txt’ files were moved to the new /core directory. In addition, the php scripts, authorize.php, cron.php, install.php, update.php and xmlrpc.php were also moved there, along with the /includes, /misc, /modules, /scripts, and /themes sub-directories (and of course all of their files). Of course this meant that paths had to be corrected in many, many files.

I’ve just downloaded Drupal; why don’t I see the core files in a /core subdirectory?

What might not have been clear to everyone from the initial announcement of this re-organization is that this really only applies to Drupal 8 and can’t be backported to Drupal 6 or 7. Even with the 8.x branch the process took place over a number of months and committing it was postponed till after the European Drupalcon (with a couple extra months’ padding). There are too many references from one file to another and paths referenced in patches would also be broken. As it is, the location to run a patch is now (normally) from the /core subdirectory rather than the top-level directory, but some patches which affect other files not moved to '/core' have to be tweaked to run properly. This problem would be multiplied several-fold with the number of outstanding patches for Drupal 6.x and 7.x … and there would also likely be a host of issues with contributed themes and modules. So while I would love to see this issue fix get back-ported to Drupal 7 (and 6, for that matter), I'm not holding my breath. I think we'll have to wait till we are all using Drupal 8 before we can take advantage of this simple but significant reorganization.

Many thanks to Nate Haug (Quicksketch), among others…

It’s been a long time coming and we could have waited till Drupal 9 (or later) had someone (or really more than one) not finally taken the time to sort out all the changes necessary to make this happen and had the core team not moved to commit the changes while they were still fresh enough to include all affected files. As it is, we can see from reading the relevant issue queue’s thread, this was not as quick and smooth as it could have been. There were valid reasons for postponing the commit (for several months till after DrupalCon London), so patches had to be updated to include the removal of many modules from the Drupal 8 core and for the addition of new files, perhaps most notably the new Symfony2 components in the /includes subdirectory. From reading over the issue queue, it’s clear that one of the Drupal community’s greatest assets was among those responsible for muchof the work involved in making this happen: Nate Haug. We already knew you were awesome, but this is icing on the cake of your Drupal awesomeness. Many thanks, Quicksketch!

How can we thank you?

I think it’s not enough, but a start, at least, if we all take the time to vote for his proposed sessions for DrupalCon Denver. Time is running out and with so many sessions, it can be overwhelming to go through them all, but it’s clear that, just like everything else these guys do, their sessions will be done right and will fill a need. So while I’m doubtful that this rockstar of the community needs any more votes than he’ll already be getting, a bit of promotion could clinch any question and at least provide some more flattering numbers.

Nate Haug’s (Quicksketch’s) proposed DrupalCon Denver sessions include:

Randy Fay’s (rfay’s) proposed DrupalCon Denver sessions:

(I know Randy put some real work into this effort and helped keep it moving forward, but he’s told me that the real credit should all be Nate’s… I respect that and have edited this post, accordingly, but I hope he won't mind if I retain a plug for his sure-to-be-great DrupalCon sessions: )