Repository navigation
[Bug]: F-31 The details sidebar is not restored after a reload, and links with index.php lose the file #65087
Description
⚠️ This issue respects the following points: ⚠️
- This is not a troubleshooting question, general support matter, or webserver/proxy problem, but likely a bug (if unsure, ask the Community Help Forum).
- This issue is not already reported on Github OR solved at the Community Help Forum (I've searched!).
- I'm using a maintained major version of Nextcloud Server and tested against the latest patch level. (Supported major versions and current patch levels).
- I agree to follow Nextcloud's Code of Conduct.
- I've tried my best to provide clear reproduction steps that someone unfamiliar with this bug could use to reproduce it.
Bug description
F-31 · The details sidebar is not restored after a reload, and links with index.php lose the file
| Severity | Low (UI: shared or reloaded links do not open the file details) |
| Component | apps/files/src/sidebar/providers/filesStore.ts, apps/files/src/router/router.ts |
| Affects | 35.0.1 |
| Verified | In the browser, and with unit tests that fail on 35.0.1 |
Steps to reproduce
Steps to reproduce
- Open a folder, choose Details in the menu of a file.
- The URL becomes
/apps/files/?dir=/folder&opendetails=true: without the view and without the file id. - Reload: the sidebar does not open again.
And, with pretty URLs enabled: open /index.php/apps/files/files/123?dir=/folder&opendetails=true
(older bookmarks, links from before pretty URLs were enabled). The router's base is /apps/files,
so the view and the file id are not recognized and nothing opens.
Fix
- When the sidebar opens, the view and the file id of the shown node are written into the URL
together withopendetails. - The router keeps
/index.php/apps/filesas its base when the page was opened with it. This is what
the comment above the base option already describes ("if index.php is in the url … keep using it").
Expected behavior
Fix
- When the sidebar opens, the view and the file id of the shown node are written into the URL
together withopendetails. - The router keeps
/index.php/apps/filesas its base when the page was opened with it. This is what
the comment above the base option already describes ("if index.php is in the url … keep using it").
Nextcloud Server version
35
Operating system
None
PHP engine version
None
Web server
None
Database engine version
None
Is this bug present after an update or on a fresh install?
None
Are you using the Nextcloud Server Encryption module?
None
What user-backends are you using?
- Default user-backend (database)
- LDAP/ Active Directory
- SSO - SAML
- Other
Configuration report
List of activated Apps
Nextcloud Signing status
Nextcloud Logs
Additional info
No response
Activity
Dennis-Otto commentedon Oct 25, 2026
The same link pattern fails harder on master: on Nextcloud 36.0.0 dev the folder view itself does not open.
Setup:
latest-master.tar.bz2of 2026-10-23 in the official Docker image 35.0.2 (Apache, pretty URLs on), SQLite, local storage.Steps:
/index.php/apps/files/files?dir=/.Expected: the file list of
/, as on 33, 34 and 35.0.2 with the same URL and setup.Actual: Files shows its navigation but no file list, and the address becomes
/apps/files/index.php/apps/files/files?dir=/./apps/files/files?dir=%2Fshows the list.Observed in the end-to-end tests of the paperless-sync app (Playwright, headless Chrome): the wait for
[data-cy-files-list-row-name="receipt.pdf"]timed out after 60 s, see the job "coming Nextcloud" of https://github.com/Dennis-Otto/paperless-sync/actions/runs/40119556519. It is the same with the app's script blocked. The tests now open Files atOC.generateUrl('/apps/files'): Dennis-Otto/paperless-sync#249