It sounds like you're hitting a similar issue to this one:
The issue seems to be that the route which would normally default to the index action is also matching the other action so, in the absence of any other means of prioritisation, the first action is being used. As I mentioned on that other post, if you can't rearrange the actions (or would prefer to have more control over priority), you can override the mechanism to select the appropriate action using an action constraint.
There may well be a way to resolve the issue by modifying the registered routes but, if there is, I've not worked it out.
Thank you for your answer, Paul.
It's such a pity that it is not handled by the default Epi's matching policy.
Anyways, we decided that relying on the order of the methods is not really good idea as we will most likely forget about it after some time. We created custom action constraint based on your other post and automatically applied it to all `Index` methods in `PageController`s using `IActionModelConvention`. A little bit hacky but will satisfy our needs just fine.
I ran into the same issue and posted my findings in
In short: you can't assume that the method that gets picked will always be the same. We have debugged this with the team and noticed that the sort order & scoring (each method is assigned a "matching score" and then the first one with a score of >= 0 gets picked) of these methods can suddenly change when adding other controllers to the codebase. On top of that, the order isn't even always the same for all developers running the same codebase.
Our conclusion is that you're better off putting the action methods on a separate controller. In retrospect, that's probably also why url.action isn't working out of the box for action methods on content controllers.
Hello!
When visiting a page the default route seems to not be the 'index' action in the page controller but rather the first action in the code.
Let's take this controller as an example:
When visiting '/events/random-event-page' path (which is associated with EventPage) it will display an array of events instead of routing to the Index action and render the view.
Reordering these actions 'solves' the issue - but it is rather covering it than actually solving it.
I was able to reproduce it in the Foundation solution as well if that helps (for the BlogItemPageController after moving GetTags method above Index)
Did anyone encounter the same issue? Is there any additional configuration that might affect this behavior?
Thanks!