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.x declares core_version_requirement: ^11.3 || ^12.0
  • 3.1.x declares core_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() to DownloadManagerInterface and implement it in DownloadManager, 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.module instead of as an OOP hook. 3.1.x supports ^10.3, and Drupal 10 ships no Drupal\Core\Hook\Attribute\Hook class 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

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.

Command icon 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

daniel.pernold created an issue. See original summary.

daniel.pernold’s picture

Status: Active » Needs review

MR !116 opened against 3.1.x.

It carries DownloadManagerInterface::rewriteFileUrl() and its DownloadManager implementation unchanged from #3577151: Implement hook_file_url_alter() to support linking to files that do not exist yet locally, and implements the hook procedurally in stage_file_proxy.module rather than as an OOP hook, because 3.1.x supports ^10.3 and 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.x yet. If you would rather keep the two branches in step, this can wait for that one and be rerolled if it changes.

smustgrave’s picture

A 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.

daniel.pernold’s picture

@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.

smustgrave’s picture

Which 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

daniel.pernold’s picture

Unfortunately, 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.

smustgrave’s picture

let 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.

smustgrave’s picture

Status: Needs review » Fixed

Spoke 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.

Now that this issue is closed, review the contribution record.

As a contributor, attribute any organization that helped you, or if you volunteered your own time.

Maintainers, credit people who helped resolve this issue.

daniel.pernold’s picture

Thank you very much!

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.