0

Longtime VF developer, and just looked into Communities for the first time last week.

In Community Builder, on the Administration Workspace -> Login & Registration page, you are able to choose Community Builder Pages to replace the default pages for a few selections:


enter image description here


I would expect consistent results in each of the three lookups. Either pages related to each action (Login/Register/Password), or the same lists for all selection.

But instead, Login results are from Site.com pages, and Register/Password results are from Community Builder pages.

The includeRoute parameter in the query string seems to be the culprit, but I dont know if its intended. And if it is intended, it seems a bit obtuse and jarring. It took me quite a while to figure out where these site.com pages were located since I hadnt used it before.

Why am I selecting Site.com pages for login (or VF pages only, for Change Password) when Im in Community Builder? I thought they were separate beasts.


<> myurl/_ui/common/data/LookupPage?lkpr=0DB4B0000008OXF&lkfm=editPage&lknm=loginPageOverride&includeRoute=false&lktp=SiteforcePageLookup&lksrch=

<> myurl/_ui/common/data/LookupPage?lkpr=0DB4B0000008OXF&lkfm=editPage&lknm=forgotPasswordPageOverride&includeRoute=true&lktp=SiteforcePageLookup&lksrch=

<> myurl/_ui/common/data/LookupPage?lkpr=0DB4B0000008OXF&lkfm=editPage&lknm=selfRegPageOverride&includeRoute=true&lktp=SiteforcePageLookup&lksrch=

I appreciate any insight.

2

Yes, the UI around this is definitely misleading/confusing.

In all cases, when "Community Builder Page" is selected in the picklist, it does in fact query data from Site.com. Community Builder, while it's a separate declarative editor, still utilizes Site.com data under the hood.

Where things start to become a bit more complicated is that Site.com has 2 types of pages: regular pages that it's always supported and SPA (single page application) pages where the page itself has essentially sub-pages or views which are accessible by individual routes (e.g. the route with '/foo' URL maps to the 'foo' view). At a high level, Lightning-based Communities are ultimately made up of these SPA pages.

For the Login override, it can point to any Site.com page (regular or SPA page), which is what you've observed.

For Forgot Password and Self Register, it can point to any regular Site.com page but it also can point to the individual Forgot Password or Self Register views that are provided as part of the Login SPA page (e.g. it'll show up as something like /login/ForgotPassword). In the page lookup UI, if you clear the search text that gets pre-populated, you should see results that reflect this.

I'd recommend just assigning the Login page to the 'login' Community Builder page and then set Default Page for things like Forgot Password and Self Register etc. It should automatically use the views set by the Login page. But if you are truly looking to deviate from the default experience and mix and match pages, you can definitely do so of course.

0

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.