You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Nextcloud serves an app under both /apps/learniq/... and
/index.php/apps/learniq/..., but generateUrl() returns only the form the
instance is configured for. Used as the vue-router base, that means a visitor
arriving on the other form has a pathname the router cannot strip its base
from. No route matches, the catch-all takes over, and they land on the
dashboard with no error at all.
Measured on a live instance, across all 282 routes: /apps/learniq/courses
resolves to Courses, /index.php/apps/learniq/courses resolved to the dashboard.
Not one broken page, every deep link in that URL form.
routerBase() derives the base from the pathname, so it always matches the URL
the visitor actually arrived on. openregister, opencatalogi, stackiq, larpinq,
zaakafhandelapp, pipelinq and keepiq already do exactly this.
pages.spec.ts could not have caught it. Its route table addressed every page as
'#/courses', a fragment the history router never reads, so all 24 cases loaded
the dashboard and asserted the dashboard was fine. Both of its assertions, a
non-blank body and no console errors, hold there. The paths lose the '#' and
the test now asserts the URL is the route it asked for, which is the check that
keeps this fixed. /settings was in that table and is not a route; it is dropped.
Verified live: 23 passed, against 1 passed and 23 failed before the router fix.
0 commit comments