404 on page creation when path name starts with »admin«

[rwam]

CONTEXT

We are creating a knowledgebase for our software product. And the product has an area «Administration» so we like to create a corresponding area in our documentation.

EXPECTED BEHAVIOR

Create a page with title Administration with subfolders resp. subpages.

CURRENT BEHAVIOR

Neither a page Administration nor subpages cannot be created if the folder name on the root level starts with admin

STEPS TO REPRODUCE

Easy to reproduce

I'm locally on grav.localhost but the behavior is independent of the domain and environment.

1. Add a page:
   
2. Press Continue
3. Result: redirect to http://grav.localhost/pages/administration/:add which results in an 404
   

Not as easy to reproduce because the error exists after renaming

1. Add a page Management on the root level; add content, subpages, modules and so on → everything works fine
2. Rename the folder on the tab Advanced to administration
   
3. Result: everyhing seems to work but you cannot add subpages or modules → result on creation is a redirect and a 404

It seems that it doesn't matter how the folder name is in general as long as it doesn't start with “admin”. Tried different folder names:

• administration → 404
• administrator → 404
• badminton → no issue
• home-administration → no issue
• admin-it-doesnt-matter-whats-coming-next → 404

This issue applies only to the top level. Having a folder administration on a deeper level does not have any issues.

[rhukster]

Thanks for the unusually thorough report, the folder-name table made this easy to pin down.

Root cause: in Admin::redirect() the regex that checks whether a redirect already points at the admin route matched the admin base (/admin) without requiring a path-segment boundary after it. So a redirect like /pages/administration/:add was read as "already an admin path" (because administration literally starts with admin), the /admin prefix was not added, and you landed on a non-admin URL that 404s. That is also why badminton and home-administration were fine (the admin substring is not at the start of the segment) while anything starting with admin at the top level broke.

Fixed for the next release by anchoring the match to a segment boundary (the base must be followed by / or the end of the path). Top-level folders such as administration now redirect correctly, and real admin paths (including the /en/admin multilang form) still match as before.

Note for anyone finding this later: this is specific to the classic Admin plugin. Admin Next (the new SvelteKit admin + API plugin) addresses pages by an explicit route parameter and does its navigation client-side, so it never does this prefix rewriting and is not affected.