Refactor code loading and support loading from PHAR archives

Nice. Love it. Note that the stream wrapper does not support directories AFAIK and so you can just drop those. In fact, if all the stream_wrapper is doing is include 'drupal://' then stream_open, stream_read and stream_eof is enough.

Oh you are using the phar archives as directories! Very clever. I hope the bot passes. Will review more.

sub

Maybe I'm missing something: why should this be in core?

Subscribing.

+++ b/includes/bootstrap.inc
@@ -538,102 +540,6 @@ function drupal_settings_initialize() {
-function drupal_get_filename($type, $name, $filename = NULL) {

+++ b/modules/simpletest/tests/bootstrap.test
@@ -321,37 +321,38 @@ class HookBootExitTestCase extends DrupalWebTestCase {
-    $this->assertIdentical(drupal_get_filename('module', 'php'), 'modules/php/php.module', t('Retrieve module location.'));
+    $this->assertIdentical(DrupalModuleStreamWrapper::getBaseFileName('module', 'php'), 'modules/php/php.module', t('Retrieve module location.'));

Wondering whether it would make sense to keep drupal_get_filename() as simple procedural wrapper?

24 days to next Drupal core point release.

love to see this on drupal +1. Subscribing

Subscribing.

While I don't know that modules should ship as phar archives, once we have a lot more namespaced class-per-file code it may be better to use a built phar archive rather than a built mega-file to reduce autoloading. See related discussion here: #1241190: Possible approaches to bootstrap/front loading of classes

+++ b/includes/bootstrap.incundefined
@@ -158,6 +158,8 @@ define('REGISTRY_WRITE_LOOKUP_CACHE', 2);
 define('DRUPAL_PHP_FUNCTION_PATTERN', '[a-zA-Z_\x7f-\xff][a-zA-Z0-9_\x7f-\xff]*');
 
+require_once DRUPAL_ROOT . '/includes/module-fs.inc';
+

We could save ourselves this line of code if we just place the file at core/lib/Drupal/Core/StreamWrapper/ModuleStreamWrapper.php and stick use Drupal\Core\StreamWrapper\ModuleStreamWrapper; at the top of each file we use it in.

-10 days to next Drupal core point release.

Brilliant idea

Can D7 work from PHAR archive?

Does this refactor make it possible to run Drupal completely from a PHAR archive?

I did a pretty deep dive into PHAR archives a few months back, investigating to see if they were suitable for a D8 deployment. I found several issues including:

• PHARs can't contain symlinks, which significantly complicates setting up the public file system.
• PHAR can't compress more than 2347 files.
• When you load a PHAR for a web request, PHP buffers the entire file into memory counted against memory_limit
• I ran into issues with indexing the contents of PHARs in PHPStorm, though the issue looks to be marked as obsolete.
• There's a significant performance hit when serving static files from a PHAR.

Given the lack of updates on this patch, and all the above, I'm closing as wontfix. PHARs are great for CLI tools, but not for for web facing apps.