Problem/Motivation

This issue is raised for discussion.
Currently a single bare Drupal installation is around 41.3Mb, this includes a multitude of tests. For some people on cheaper shared hosting packages, this is a large part of their storage allowance. On a production site, do we really need all the tests that are normally used for module/theme or core development?

Proposed resolution

Create a new distribution of Drupal 8 core (before release) with all tests and Simpletest removed. This will reduce the installation size by around 15.4Mb and decrease upload time significantly. This should be clearly identified as for production sites, and should indicate the difference to the normal distribution.

Remaining tasks

Document the new distribution, making users aware of the advantage to using this for production.

User interface changes

SimpleTest module can be removed, and all functional tests.

API changes

None

CommentFileSizeAuthor
#1 drupal8_size.png164.15 KBmbrett5062
Tests_NoTests.JPG69.98 KBmbrett5062
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

mbrett5062’s picture

FileSize
164.15 KB

Just this morning I downloaded a clean copy of Drupal 8 Dev, then proceeded to remove all tests and the simpletest module and PHPUnit from a copy of the download.

I have installed both and done as much manual testing as I can, and as far as I can see everything works fine.

Here is a comparison screenshot of the relative size of the installation.

mbrett5062’s picture

Title: Create a smaller Drupal distribution, removing tests, for production sites. » Create a smaller Drupal core download, removing tests, for production sites.
Category: Feature request » Task
Issue summary: View changes
dawehner’s picture

... You should have described which directories you could remove. You might have for example not removed the phpunit tests from both core as
well as the vendor dependencies.

mbrett5062’s picture

OK I understand, and yes I did remove from vendor as well.

I thought at the time that was a bad idea as they are probably pulled in as a whole from the vendor. I will tomorrow go through all that I removed, and sanitize were I can, then report back here with actual details.

Only code I had to change was the composer and gitignore and stuff like that at top level.

I may have been overly aggressive in my implementation, but I still see this as a worth while exercise if it can be done easily with a script or something.

As far as I am concerned no production site requires all of these tests.

Thanks for taking the time to reply.

P.S. I am no developer by any means, so if this is naive or a waste of time and effort please ignore.

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.6 was released on August 2, 2017 and is the final full bugfix release for the Drupal 8.3.x series. Drupal 8.3.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.4.0 on October 4, 2017. (Drupal 8.4.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.4.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.4 was released on January 3, 2018 and is the final full bugfix release for the Drupal 8.4.x series. Drupal 8.4.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.5.0 on March 7, 2018. (Drupal 8.5.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.5.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

TheDanScott’s picture

mbrett5062: I for one appreciate your efforts, and don't see this as a waste of time.

I've had this exact question burning in my mind for a while (when I worked out that there were some 7000 files and some 20MB of tests that will never be used on a production site). Yeah, you'll have those who'll say "disk space is cheap thesedays, stop whining", but thousands of files across a drupal install slow down source control systems and uploads (of the codebase to a production server) and all manner of things.

As a developer who lives outside a major city and has limited upload speed, the bloat of Drupal is a big deal to me. I manage Drupal through Subversion, so I don't upload directly very much (I tend to pull from one internet server to another when I deploy), but there are times - such as updating my master copy of Drupal in source control - where all that cruft bogs things down.

Rather than a separate core release for production, another option might be some kind of bundled automated process that can be run during config sync (or some other appropriate time) might be an option. Such a script could also remove all the test stuff from the vendor directory, and from contributed modules. Maybe the uninstall hook for the simpletest module would be a good place to run that?

dawehner’s picture

Just to give people a bit more update. We do strip vendor tests, see Drupal\\Core\\Composer\\Composer::vendorTestCodeCleanup

@TheSchmuck
Nice idea! How about writing some script, and call this from drush/composer?

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.6 was released on August 1, 2018 and is the final bugfix release for the Drupal 8.5.x series. Drupal 8.5.x will not receive any further development aside from security fixes. Sites should prepare to update to 8.6.0 on September 5, 2018. (Drupal 8.6.0-rc1 is available for testing.)

Bug reports should be targeted against the 8.6.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

nulf’s picture

Great to see an issue about this. I'm starting a project at work to remove all test-libraries from our production servers just because phpunit has had atleast one remote code execution exploit in the last couple of years. And as phpunit is categorized as a test/dev-library it isn't sure that these kind of exploits gets fixed quickly.

Will follow this and share if I stumble on something useful/interesting.

peterx’s picture

Drupal 8.6.3 is a 16.4 MB download containing 20,369 items and using 83.8 MB on Ext4 disk. I did a quick test deleting just the directories containing tests and the result contains 12,059 items and uses only 48 MB on disk. If something as simple as that can save 35 MB per upload, it will make many uploads faster.

I look forward to a list of the changes you make.

Kristi Wachter’s picture

I would like to voice my support for doing this.

I have a client on shared hosting with unlimited storage space but a limit on number of individual files. They've had to spend time finding files to delete ... and having 1200 files in core/modules/system alone is causing problems.

The problems are multiplied if you don't immediately zip your backups - or if you use drush, which saves unzipped backups to drush-backups.

I'd like to see test files be excluded from the default install, and only added in as a selectable option.

Thanks for proposing this!

TravisCarden’s picture

anavarre’s picture

I feel we should close this issue as a duplicate of #3067979: Exclude test files from release packages if we agree that we don't need a

new distribution of Drupal 8 core with all tests and Simpletest removed

but to remove tests altogether from release packages.

andypost’s picture

Version: 8.6.x-dev » 8.8.x-dev
Status: Active » Closed (duplicate)

++ to 16-17