Provide Drupal root path on file system admin form

I think the best practice for private files is to not even locate them under the installation root (see https://www.drupal.org/documentation/modules/file, managing file locations and access.) If we give a hint to the installation root here, maybe it should also say you don't need to use it. Perhaps "You can use any absolute writable path, or the following path within this Drupal installation: @privpath", and append sites/default/files/private to the DRUPAL_ROOT for @privpath?

@mailomio i try to applied #3 and #2 patches but giving error would you please suggest me that how i will check it sharing screenshot .....

@mailomio even i am also facing same issue unable to apply patch , If am doing wrong let me know how to apply it properly.

No feature request allowed over 8.9.x branch, updating target branch to 9.3.x

The patch in #2 needed a reroll. Attaching a rerolled patch here, thanks!

Patch #16 applied cleanly and working as expected ,Provide Drupal root path on file system admin form. Sharing Screenshot for reference.

Why is this buried in the "private file system path" description? Wouldn't it be better to show it as its own item?

Applied patch #16 applied successfully
After patch root directory description has been added in description
Thanks for the patch

Alternative approach that implements #18, with additional help text explaining what this means.

I think clearer than both approaches so far would be to add the DRUPAL_ROOT as a prefix to the displayed value.

@joachim if we are to do that we should just resolve the full absolute path of each value, rather than trying to figure it out ourselves - we don't want to prefix with DRUPAL_ROOT if the path is already absolute, for example.

Applied patch #21 applied successfully

> if we are to do that we should just resolve the full absolute path of each value, rather than trying to figure it out ourselves

Maybe we should do that?

What's the actual purpose of this form? None of these paths can be edited in the form, can they? So, is the purpose here:

A. Show what is literally defined in settings.php
B. Show the location of the file folders

If it's B, then resolving it makes sense.

This issue is being reviewed by the kind folks in Slack, #needs-review-queue-initiative. We are working to keep the size of Needs Review queue [2700+ issues] to around 400 (1 month or less), following Review a patch or merge request as a guide.

This could use an issue summary update for the proposed solution. Seems there is still discussion going on so when the path forward is decided it should be added to the IS. Will help the committer.

Rerolled #21 in a MR. Added descriptions for items regarding absolute values if applicable.

Thanks!

Code wise I think it looks fine. Not sure if we will need a trigger_error for the new parameter or not.

This could use a simple change record though to announce the new parameter option.

Added CR https://www.drupal.org/node/3341696
Updated constructor to handle new parameter addition.

Thanks think this good for committer review now.

This is changing the user interface, adding tag. As such this should have before and after screenshot available from the issue summary. This is also adding text to the public and private file descriptions, so I think this should have a usability review.

I read the change record, well several times, and I am still not sure what 'related' means in "public, private, and temporary paths are related". Tagging for a change record update. This is not a complicated change but a screenshot could be useful in the change record.

I skimmed the patch and made some comments. I also note this was set to RTBC with an unresolved comment.

Changed the relative paths with absolute as this will show the actual location of specific stream wrappers.
Added check for path accessibility. The realpath() file_system method fails absolute path resolving if the directory not exists.
I have added screenshots before, after, and after with warning messages.

Brought this up in #ux channel and it was briefly looked at but was mentioned

taken a look but it would be helpful if the issue summary would have been updated illustrating the changes that will be made. at the moment the ui changes section only states The content of the page File system will be updated. . even if i apply a patch i consider it helpful to get an overview which changes were made.

I agree that IS needs to be updated, but please check the screenshots from #35.
The latest changes in MR convert paths to absolute if they are relative. And if the destination does not exist, the path value is printed as is (relative or absolute) with an appropriate warning message that reuses existing sentences and translations.
In case such behavior is acceptable I'll update IS as I can.

rerolled
assets filesystem wrapper added since then
if #35 comparison approach is good to go with, I'm ready to create updated screenshots and attach them to the IS.

Rebased the MR and added screenshots and user interface changes to the issue summary. I'm not sure the change record is really necessary.

The one minor concern I have is that it's now unclear if you were to move your Drupal installation to another location, would the file system paths remain in their original locations? That would depend on what's in your settings.php file, and you can no longer determine the answer from the config page.

Usability review

We discussed this issue at #3547674: Drupal Usability Meeting 2025-09-26. That issue will have a link to a recording of the meeting. For the record, the attendees at the usability meeting were @rkoller, and @simohell

If you want more feedback from the usability team, a good way to reach out is in the #ux channel in Slack.

It has to be noted upfront that we usually don't do a review with two attendees only. Initially we wanted to call off the meeting but then ended up talking about that issue anyway, and due to the fact that we've started a review in #3541474: Drupal Usability Meeting 2025-08-29 together with benji before, we've continued our conversation and exploration.

In general we were in line with the changes this MR introduces. We've considered it useful showing the absolute paths on admin/config/media/file-system. It provides context and situational awareness to the user. In regard to clarity there are two minor nitpicks:

1. The description for the application root directory states The top level directory of the Drupal installation. Relative paths shown below are relative to this location.. The second sentence is sort of confusing. With the MR applied the page is showing only absolute paths while this second sentence is referring to relative paths; that is potentially confusing and might make the user search for relative paths on the config page (at least I've did). Then the second sentence also uses directional language with "...shown below..." which is not adiseable. So we've wondered why not simply strike the second sentence? And in regard to the first The top level directory of the Drupal installation. we've wondered if it would make sense to add a detail that web is the docroot? Not a recommendation more of a question, intention was to help less technical users to distinguish what is the root path and what the docroot? We would have come up with a suggestion but none of us is a native speaker, and it is always preferable to have at least one native speaker attending for providing a suggestion or recommendation for anything micro copy related. We could revisit that in next weeks meeting with hopefully native speakers attending, as long as no one beats us to it with a suggestion on the issue here or argues against such an addition.
2. And we agree with #41 and consider that sort of a problem, but from our perspective probably out of the scope for this issue and more suitable for a follow up? With the MR applied we've quickly tested the following scenario: We've created a folder playground in the root of the project. Then added $settings['file_private_path'] = '/var/www/html/playground'; to the settings.php resulting in /var/www/html/playground on the file system page. We've then changed the line in the settings.php to $settings['file_private_path'] = '../playground';; the output remained the same, without any indication that a relative value is being used in the settings.php file. And that it is possible to actually use a relative value in the settings.php file is also counter the comment in the settings.php file which states "A local file system path where private files will be stored. This directory must be absolute, outside of the Drupal installation directory and not accessible over the web.". So having at least an indication of sorts that the output value is based on a relative value on the settings.php might help the user in the context of debugging and/or context awareness. But as we've said from our point of view this point is out of the scope for this issue.

Tried to address the feedback from #42

Usability review

We discussed this issue again at #3559145: Drupal Usability Meeting 2025-11-28. That issue has a link to a recording of the meeting. I am giving issue credit here to the attendees: @benjifisher, @sahilps6, @the_g_bomb, and @simohell.

Thank you for updating the MR in response to the review in Comment #42. Unfortunately, we see a few problems with the current approach:

• Adding the bold label "Absolute path" makes it harder to scan the page and see the primary headings: "Application root directory", "Public file system path", and so on.
• The markup uses <small> and <b> tags. For accessibility, it would be better to use more semantic tags, like <label>.
• There is no easy way to select the absolute path. Compare this to the path configured in settings.php, which can be selected with a triple click.

We often say that "less is more", and the first point is a specific case of that principle. Before thinking about the other points, we should decide whether it is worth adding this information to the page.

Looking at the comments on this issue (#18, #22, #23, #25, #41) it seems that the idea evolved from "prefix the relative paths with DRUPAL_ROOT" to "show the absolute paths" to "show both the configured paths and the absolute paths". No one ever gave a use case for showing the absolute paths. Comment #35 mentioned "... the actual location of specific stream wrappers". @voleger, can you say more about that? If it is something that comes up often, then it is worth some effort to add information to the page. If it comes up rarely, then we can let the occasional user combine the root directory with the relative path.

In short,

1. Decide whether it is really worth adding the absolute paths to each entry.
2. Depending on (1), either go back to the approach of Comment #21 or else come up with more semantic, accessible markup for the absolute paths.

If you want more feedback from the usability team, a good way to reach out is in the #ux channel in Slack.

Simplified changes, removed new markup for absolute paths resolution results.
Provided feedback in the #ux channel
Here is an example of how a user can view the resolved absolute path:

Updated screenshots.

The code for checking whether to add an absolute path version or not seems a bit off. I feel it shouldn't render "Not set" the same way as an absolute path. This would be an issue with special cases in the conditions.

Usability review

We discussed this issue at #3565344: Drupal Usability Meeting 2026-01-09. That issue will have a link to a recording of the meeting. The attendees at the usability meeting were @benjifisher, @pallavi singh3013, @rkoller, @sahilps6, @shaal, @simohell, and @the_g_bomb.

First we were under the impression that the germinal question @benjifisher asked in #44, about if it is worth adding the information about the absolute path to the page, was not answered yet. But during the write up I've noticed that you @voleger have already elaborated on that on slack in the thread to the meeting of the last review (https://drupal.slack.com/archives/C1AFW2ZPD/p1764581370956939?thread_ts=...)

The germinal question aside, we've looked at the recent changes adding the absolute path displayed on hover. Turns out that approach has several downsides from a usability and accessibility perspective:

• On touch devices the option to hover is not available with the current implementation - the absolute path is inaccessible to the users.
• For screenreader users using the keyboard instead of the mouse, the information conveyed in the tooltip is also inaccessible - see voiceover.mp4 illustrating the stepping through with the VoiceOver cursor (*another aspect to note that was not touched in the discussion, you already have the problem as a screenreader user only using the keyboard, it is already kind of hard and cumbersome to copy for example the application root directory - text not within a text field is kind of hard to select and copy without a mouse)
• In Safari the time the cursor has to remain still until the tooltip shows on hover is past the time you would wait and expect a tooltip showing up - it takes two to three seconds. In consequence the odds are low to discover that information on an accidental hover. The amount of time the tooltip shows up in Edge is similar (i've only tested in Edge due to the lack of an installed version of Chrome).
• The presence of the information has also no affordance. Strictly speaking, due to the aforementioned required delay to hover until the tooltip shows up in many browsers, the odds are rather low that someone will notice the existence of the absolute path by accident - the user has to know that it is there and then deliberately hover.
• The way the tooltip behaves it is not meeting WCAG2.2 SC1.4.13. It isn't meeting the second out of the three success criteria hoverable - you are unable to move the pointer over the additional content without the additional content disappearing.

Aside the aforementioned issues directly related to the tooltip you also have related problems on the page in general:

• The inconsistency checking whether to add an absolute path version or not @simohell already added in #47
• The bolded labels get a mouse pointer on hover, which creates a perceived affordance for the label - users might expect a potential interaction even though there is none. Out of the scope for this issue, but it should be fixed in a separate followup.

In summary, based on the fact that the information about the application root directory and the relative paths is already available and a user is able to piece together the absolute path on their own, and due to the number of accessibility and usability related issues in relation with the current tooltip implementation, we would rather suggest to make this issue only about adding the application root directory. And move the work and discussion how the absolute paths are communicated and acted on to a dedicated followup issue.

If you want more feedback from the usability team, a good way to reach out is in the #ux channel in Slack.

Something that appears missing is test coverage for this change.