mirror of
https://github.com/BookStackApp/BookStack.git
synced 2026-02-06 19:06:02 +03:00
"Page not found", but does exist #5340
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @TomSpidge on GitHub (Jul 2, 2025).
Attempted Debugging
Searched GitHub Issues
Describe the Scenario
I have a single page within a chapter that no-one can see. It claims 'page not found' for all users, including the page owner and admin users (with all rights). When the page is recreated from a copy elsewhere there is no problem.
There are no errors in the logs, turning on APP_DEBUG shows the same page.
When looking in the database, I can see the page in the
pagestable, alongside the replacement. Both are in the same book and chapter and the only differences are dates, priority, revision count and created by entries.There are no entries in
entity_permissionsfor either page, so presumably both should inherit the chapter permissions, and yet one works and the other is 'page not found'Exact BookStack Version
25.05.1
Log Content
Hosting Environment
Ubuntu 24.04.2 LTS
Apache/2.4.58
PHP 8.3.6
MySQL 8.0.42-0ubuntu0.24.04.1
@ssddanbrown commented on GitHub (Jul 2, 2025):
Hi @TomSpidge,
If you run the Regenerate Access Permissions command, does this page then show up again? (at least when viewing as a member of the original Admins user role).
@TomSpidge commented on GitHub (Jul 3, 2025):
That seemed to fix it. Nothing had been done behind the scenes though - it was only edited through the main pages or API so I'm not sure what caused it.
Thanks for the help (and for bookstack itself!)
@ssddanbrown commented on GitHub (Jul 3, 2025):
Happy to help.
This may be related to #4838, which I've been working on via #5689 to be part of the next feature release.
@TomSpidge commented on GitHub (Jul 3, 2025):
That sounds about right - we have a script that runs through and updates permissions on pages and will generally run a few one after the other, so could trigger it if the timing is right. I've increased the interval between API calls so hopefully shouldn't happen again before you fix it.
I know what to do now if it does, at least