-
-
Notifications
You must be signed in to change notification settings - Fork 9.6k
Customizable FileLinkFormatter #60338
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Some IDE support file mapping directly. In PhpStorm, you have to set Deployment Mapping
In
Adding this feature would be the more beneficial: this is a common need and it may be added without much complexity. Maybe using some syntax like this:
On an other note: when I was faced with this problem, I cheated by mounting the files in Docker on the same path as locally. As a result, the file paths coincide between the local filesystem and Docker. |
Thanks @GromNaN that's a great comment, very helpful. here it goes for me, I defined a target path in my
At this time I still decorate the class but I believe it can almost be copied/pasted. I am not sure how to proceed with a PR, and what is the repository to be modified, but let me know if you would like me to make it, if this code is found to be useful.
|
Uh oh!
There was an error while loading. Please reload this page.
Hello,
While integrating Symfony’s FileLinkFormatter to display relative paths for Dockerized environments, I encountered limitations that make the class hard to adapt for such advanced setups.
The class is marked as final, and most of its configuration (like $baseDir, $urlFormat, and $requestStack) is declared as private directly in the constructor. As a result:
• It’s difficult to extend or decorate the class behavior cleanly, and the class cannot be reused.
• Custom relative/host path mappings require rewriting the class instead of reusing its logic.
Would you consider:
• Making the class more extensible (e.g. via an interface or service decoration hook)?
• Promoting key properties to protected or configurable through setters?
• Or, exposing relative path rewriting directly as a feature?
These changes would make Symfony debugging much easier in virtualized setups and would avoid the need for brittle custom implementations.
Thanks for your advising on that or any help to bypass this issue !
The text was updated successfully, but these errors were encountered: