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
This is an unintended side effect introduced in e4514d8.
By not populating the routes after resolving, this means the default route is resolved before any extensions are able to add routes to the route collection.
Neither api nor admin need the same fix as they do not have customizable/backend default routes.
I found the bug after trying to find out why fof/tags suddently stopped passing the correct API document, and discovered that it was not using my custom Content class and instead passing an array of discussions to the page.
The text was updated successfully, but these errors were encountered:
The issue caused Flarum to always pre-load the discussion list, even when Tags was set as the homepage.
Then, when clicking any link that was supposed to filter the discussion list from the Tags page (clicking a tag, or "following", or similar links), the initial load of the discussion list would use that pre-loaded data and ignore the filter, causing all discussions to show without regard to the current selected tag.
The issue was reproduced on the beta test site.
The issue was confirmed solved on the nightly test site.
This is an unintended side effect introduced in e4514d8.
By not populating the routes after resolving, this means the default route is resolved before any extensions are able to add routes to the route collection.
Neither
api
noradmin
need the same fix as they do not have customizable/backend default routes.I found the bug after trying to find out why fof/tags suddently stopped passing the correct API document, and discovered that it was not using my custom
Content
class and instead passing an array of discussions to the page.The text was updated successfully, but these errors were encountered: