Problem/Motivation

This idea came up while working on #2831274: Bring Media entity module to core as Media module. Media entity comes with images that are used as fallback thumbnails. Since they are stored in an image field when they are used they need to live in a public:/ or private:/ files directory.

Media solves that by copying them into the public directory on install. Solution is not the nicest though.

Proposed resolution

It would be nice if core would provide some kind of mechanism for modules to declare the list of files they ship with and need to be publicly accessible. It could be another yml file for example.

Core would then handle this automatically; make sure files are copied to a place inside webroot when module is installed and removed from it when they are uninstalled.

If we would do that we could start moving the actual modules out of the webroot, which would be great for the security. And media would be happy since it woudn't need to use the custom not-so-nice logic that it currently has :).

Alternative

Leverage #2927968: Add system stream wrappers to core

Remaining tasks

TBD

Comments

slashrsm created an issue. See original summary.

phenaproxima’s picture

phenaproxima
he/him
Primary language English
Location Massachusetts
commented

This would certainly benefit Lightning. Pretty much since day one, one of our install routines has had to copy a PNG file from a module into the public files directory so that Embed can use it as the icon for a CKEditor button. Having the file automatically copied by a standard API would save us some trouble.

The relevant code in Lightning: http://cgit.drupalcode.org/lightning/tree/modules/lightning_features/lig...

One possible approach I suggested in IRC, that would not involve copying icons around, would be to implement a new stream wrapper whose only purpose is to link to icons -- either default ones provided by extensions, or overridden ones in a site-owned files directory.

For example, take a URI like this: icon://node/image.png This would first try to use public://icons/node/image.png, if it exists; otherwise, it would fall back to core/modules/node/icons/image.png. One URI that canonically refers to a particular icon, which may exist in several places. I'm not sure how feasible this would be, or even if it's a good idea, but it's perhaps a little more slick than bodily copying icons into the public files directory.

sahilsharma011’s picture

sahilsharma011 commented
Title: Allow modules to declare the list of files it ships with and should be publically accessible » Allow modules to declare the list of files it ships with and should be publicly accessible

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

Drupal 8.4.0-alpha1 will be released the week of July 31, 2017, which means new developments and disruptive changes should now 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.

geek-merlin’s picture

geek-merlin
Primary language German
Location Freiburg, Germany
commented
Issue summary: View changes

Isn't this problem neatly solved when we have module:// stream wrappers?

Implementing this is as trivial as copying a contrib to core:
#2927968: Add system stream wrappers to core

(For some special use case where modules are not publicly readable, *that* should be the wanted API that does the copying magick.)

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

Drupal 8.5.0-alpha1 will be released the week of January 17, 2018, which means new developments and disruptive changes should now 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.

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

Drupal 8.6.0-alpha1 will be released the week of July 16, 2018, which means new developments and disruptive changes should now 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.

Version: 8.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

seanb’s picture

seanb
Primary language Dutch
Location Netherlands
commented
Status: Active » Postponed

Let's postpone this on #1308152: Add stream wrappers to access .json files in extensions.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

nicxvan’s picture

nicxvan commented
Component: base system » extension system
catch’s picture

catch
he/him
Primary language English
commented
Status: Postponed » Active

Modules can reference their own files relatively, as they already do in libraries.info.yml no need for a stream wrapper for this.

nicxvan’s picture

nicxvan commented
Title: Allow modules to declare the list of files it ships with and should be publicly accessible » Allow modules to declare the list of files it ships with that should be publicly accessible
nicxvan’s picture

nicxvan commented
Related issues: +#2984405: Formalize a structure for static assets in modules and themes
nicxvan’s picture

nicxvan commented
Status: Active » Closed (duplicate)

I've compared these two issues and even though this one is slightly older the other is more active with more detail.

I have transferred the relevant info there thanks everyone!