I am trying to set up burnbright / silverstripe-members, but don't manage to get it to use its template when called through a route: it keeps using my default Page template (despite clearing cache in all possible ways).

The module has a MemberProfilePage_Controller (which extends Page_Controller) and a matching template/layout/MemberProfilePage.ss. routes.yml says Director: rules: 'profile//$Action/$ID/$Name': 'MemberProfilePage_Controller'.

When I visit /profile/, I assume the route works, but the Page.ss templates from mysite are used instead of the MemberProfilePage one. Even when I create MemberProfilePage.ss templates on both levels in mysite/template (the general and the Layout one), it still uses the Page templates!

However, if I do in fact create a page in the CMS (which is possible, but not supposed to be required), for example on /profile_page/, then that page does use the correct templates.

So the question is: how can I get a custom PageController to use its own template, if it does not have a matching SiteTree object? And I would prefer not to call ->renderWith or something because then it does not use the cascading template thing (Page.ss for general and MemberProfilePage.ss for Layout).

The readme clearly states this should be possible, so it should work out of the box. I'm not sure though that if you call a page controller 'on its own', it would automatically know its page's layout template...

If you feel this is a bug, you might want to take this up with the module owner by creating an issue here: https://github.com/burnbright/silverstripe-members/issues

[EDIT] Hmm, looks like someone else has a similar issue not related to this module...
http://www.silverstripe.org/community/forums/general-questions/show/111851

Did you find a solution to this? I am not using this module but having the same route issues. I tried with a clean 3.4 install just to be sure and still problems.

My post is the one mentioned by martimiz above.

I'm afraid I ended up using silverstripe-australia/memberprofiles instead... so no, I did not find a solution at the time.

I ended up reading just now beyond the section specifically on the routes.yml because before it wasn't directly relevant to my problem at the time. I thought... Under that section in a bold red box it says.....

You must use the $url_handlers static array described here if your URL pattern does not use the Controller class's default pattern of $Action//$ID/$OtherID. If you fail to do so, and your pattern has more than 2 parameters, your controller will throw the error "I can't handle sub-URLs of a class name object" with HTTP status 404.

Not sure why this worked previously in 3.2 and now I have to go this route 3.3 forward but there it is. So as long as at least for my uses I use the method above all is well. Don't really like it that way as I liked having all my routes in one file.

Not sure if this would have fixed your issue as well. I noticed you only had two parameters but this seems to have been a workaround for that too. Or just used OtherID instead of Name.