Drupal 7 File System Changes
by Peter Wolanin
On July 26 and 27 I participated on behalf of Acquia in a code sprint with a great group of other Drupal contributors at the Zivetch offices in Philadelphia. Aaron Winborn has already written a good summary of the event. I want to focus here on a big piece of the work that progressed but wasn't finished at the sprint: the File API Stream Wrapper Conversion patch (which weighs in at a big 230 kB and changes 54 files).
Jon Stacey and I reached an important milestone last night in that we got the conversion patch to pass all the core tests. This would be a great time to help review the code and manually test so we can get this ready to be committed soon!
For some background in why this matters, stream wrappers are an abstraction layer for PHP's file handling,. This allows me to reference a file attachment (for example) as a URI like "public://image.jpg" and PHP is able to load the correct class for the "public" scheme (which Drupal registered as an available stream wrapper) and then determine that the actual file location is on your local disk at "./sites/default/files/image.jpg".
One big benefit of this conversion is that we will now have a way to manage both public and private files for the same Drupal installation - and in fact every site will have both. This means that you can aggregate your CSS and JS files into the public directory but still use private files for file attachments.
Another, even more exciting, benefit is that it provides a consistent way to reference files or resources that might be remote as well as local. There already exist PHP stream wrapper implementations, for example, for referencing files in Amazon's S3. So your node could have a file attachment like "s3://mybucket/bigfile.mp3". Obviously, the http URL that you need to click to download this file has to be quite different from that for a local file, and the Drupal S3 stream wrapper class will implement
$wrapper->getExternalUrl(); so that Drupal core can present the URL without needing to know any details about how S3 works.
A side note to this is that the sprint, and the ongoing work, is using git and github to allow simultaneous contributions from different people in the group to a single changed codebase. From that codebase we can generate patches to be applied to Drupal core. Jon Stacey's git clone of Mikkel Høgh's core mirror is where we are working. You can watch the commits there or get a copy of the code directly.