Problem/Motivation
#3577151: Implement hook_file_url_alter() to support linking to files that do not exist yet locally adds a hook_file_url_alter() implementation that points a public file which is not present locally at the origin site, together with DownloadManager::rewriteFileUrl() behind it. In #3577151-3: Implement hook_file_url_alter() to support linking to files that do not exist yet locally that issue was retargeted from 3.1.x-dev to 4.0.x-dev.
That leaves the change out of reach for every site that cannot run 4.0.x:
4.0.xdeclarescore_version_requirement: ^11.3 || ^12.03.1.xdeclarescore_version_requirement: ^10.3 || ^11
So a site on Drupal 10 can only install 3.1.x, and on 3.1.x hook_file_url_alter() is not implemented at all.
The gap shows up for files whose URL is rendered into markup and then fetched without the request reaching this site in a way the module's request subscriber can act on. Non-image files such as PDFs, video, or packaged HTML (SCORM) are the common case, which is the same scenario #3577151: Implement hook_file_url_alter() to support linking to files that do not exist yet locally describes.
Proposed resolution
Port the same change to 3.1.x, leaving out the parts 3.1.x cannot use:
- Add
rewriteFileUrl()toDownloadManagerInterfaceand implement it inDownloadManager, identical to #3577151: Implement hook_file_url_alter() to support linking to files that do not exist yet locally. - Implement the hook procedurally in
stage_file_proxy.moduleinstead of as an OOP hook.3.1.xsupports^10.3, and Drupal 10 ships noDrupal\Core\Hook\Attribute\Hookclass and no attribute-hook discovery, so a#[Hook]implementation would be installed but would silently never run there. A procedural implementation runs across the whole supported range.
Image style derivatives (public://styles/) are deliberately left alone, since those are already handled by the module's own image download controller.
Remaining tasks
- Review.
- Decide whether this should wait for #3577151: Implement hook_file_url_alter() to support linking to files that do not exist yet locally to land in
4.0.xfirst so the two branches stay in step. That merge request is still open at the time of writing.
User interface changes
None.
API changes
DownloadManagerInterface gains one method, rewriteFileUrl(). DownloadManager itself is @internal and final, but the interface is not, so a site providing its own implementation of the interface would need to add the method.
Data model changes
None.
Issue fork stage_file_proxy-3623587
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #3
daniel.pernold commentedMR !116 opened against
3.1.x.It carries
DownloadManagerInterface::rewriteFileUrl()and itsDownloadManagerimplementation unchanged from #3577151: Implement hook_file_url_alter() to support linking to files that do not exist yet locally, and implements the hook procedurally instage_file_proxy.modulerather than as an OOP hook, because3.1.xsupports^10.3and Drupal 10 ships no attribute-hook discovery.The merge request on #3577151: Implement hook_file_url_alter() to support linking to files that do not exist yet locally is still open, so this ports a change that has not landed on
4.0.xyet. If you would rather keep the two branches in step, this can wait for that one and be rerolled if it changes.Comment #4
smustgrave commentedA lot of this is reading like AI input..so just posting this https://www.drupal.org/docs/develop/issues/issue-procedures-and-etiquett...
I'm trying to keep 3.1.x as just bug and security fixes so for me this is a won't fix but will leave open in case another committer wants to take a look.
Comment #5
daniel.pernold commented@smustgrave As mentioned in another ticket, my native language is German, so I'm translating my texts with AI. I would be happy to discuss the solution.
Comment #6
smustgrave commentedWhich is fine just have to disclose AI please.
But 3.1.x is on it's way out and 4.0.x being the active branch. Typically when that happens just do bug and security fixes into the old branch with new features going into the next (in this case 4.0.x), so not sure if we should continue new features into 3.1.x
Comment #7
daniel.pernold commentedUnfortunately, we still have to run sites on Drupal 10 (likely beyond its EOL), so we are investing in backports. This isn't a critical issue—it mostly affects developers - but it would still be a quick win.
Comment #8
smustgrave commentedlet me get back to you later today and ponder it. I'd like to start shutting down 3.1.x but may consider supporting small new features until D10 is EOL in a few months.
Comment #10
smustgrave commentedSpoke to another maintainer and he's fine with the approach of small features going into 3.1.x but will stop when D10 is EOL.
Comment #12
daniel.pernold commentedThank you very much!