What happens when existing fields and imported FB fields conflict?

Joe,
I'll try to answer all your questions here, but if I miss something, or you have others, just let us know.

1) If you have the 'always import profile' setting enabled, the profile will always be imported and overwrite any fields you have setup to be 'mapped'.

I just looked at our code, and it does look like even blank values will override existing ones.. which we agree, is probably not the right thing to do. I've added an issue to our tracker to change this behavior, but if it's urgent for you, we can probably provide a fix that should stop this behavior so that if the fields is blank, the value won't import. However, if there's a value in Facebook, it would still overwrite whatever is in their Joomla profile.

2) There's no conditional import abilities for the user to select, and we don't plan on doing this. It'd be very complex, and would be very dependent on each of the different profile systems we integrate with. The only option we have is for the admin to decide if it's a one-time import (during registration) or every-login import.

3) No, we don't have this ability. This would add a lot of extra settings to configure, and frankly (after 3 years) is the first time we've had the request, so it simply wouldn't be a high priority for us.

4) You can configure the New User Redirection to go to whatever page you want, but it must be a menu item. We'd recommend you create a menu item for JomSocial -> Profile -> Edit Profile and use that as the new user redirection. You don't have to show this menu item anywhere, but just need it created for JFBConnect to see it.

Hope that helps answer your questions, but if you have more, just let us know!
Alex

Joe,
Sorry for the delay in getting back to this. We have what we think should be a fix to overwriting filled fields with blank data, but haven't tested it yet. If you'd like to try the following change, it should do what you're looking for.

In the /components/com_jfbconnect/libraries/profile.php file, at line 306, you'll see:Update that to:
I see what you're saying about the different types of fields. Right now, we simply show the required fields (if configured that way), but don't even look at what's marked as a registration field. The main reason for this is because we do the field mapping during registration, which means that many registration fields could be filled in automatically.. so we just care about 'required' fields to make an admins life easier. It's a distinction, and difference, from JomSocial, but is meant to keep registration forms to a minimum.. which has always been a primary goal of JFBConnect.

If you can't get a good combination of required vs registration fields going during the initial registration process, let us know, and we'll see if there's an easy change we can make to either 1) show the 'registration' fields instead of 'required' fields or 2) redirect to the profile page you're looking for. If you have a preference between the two, let us know that as well.

Thanks,
Alex

Joe,
No problem for the support. It's what we do, and why we charge for a subscription. We realize Facebook integration is always a moving target for development, and has special requirements for each user's site.. and therefore, needs a high level of support. Without it, JFBConnect just isn't a great extension (though we try to make it so you never need support...)

Definitely understand the JomSocial convention, and realize we don't adhere to it completely. The reason we only show required fields during the "Full Joomla User" process is simply because the admin has deemed them 'required' (i.e. minimal amount of fields that need to be filled in).. and one of the benefits of JFBConnect is a 'quick' registration process.. which is why we focused on those only. It's definitely a disconnect as you may want more fields during registration, even if you don't need the info, but admins that use JFBConnect generally are trying to use it to minimize the registration flow. While that should mean similar requirements for Required and Registration fields, that's not always the case (we think it should be, frankly).

With all that said (yes, I like to talk), if you're using the "Facebook User Only" setting of JFBConnect, really none of the above applies, since only what you map is what gets imported. As for the registration page from JomSocial, there's no way to redirect to that page. The user information isn't stored permanently at that point, only in a temporary state while more and more information is added to their profile. Once the registration profile page is complete, JomSocial actually stores all that info in the database. It'd be really difficult (and JomSocial version dependent) for us to implement support for using their view to do that.

We could easily help you to change the "Full Joomla User" registration flow to show all registration fields though, in case you'd like to do that.

So.. hope that makes sense, and explains where we're coming from, even if it's not exactly what you're looking for. Outside of sending the user to that registration form page, if there are other recommendations you have, we'd love to hear them. Most of the features in JFBConnect came from users at one point or another.

Thanks for all your feedback.. great to hear how user's are using things!
Alex

Joe,
The temporary state of profiles during registration is something I don't think a lot of people know about, and not something we really like about JomSocial. The main problem is that the user doesn't get created if the user leaves after filling out their username/email/password but before submitting the 'registration' form fields. You can test this on your own, but the username/email stuff is something you don't want to lose, even if the user gets scared away by a big reg form. Last time we test was on 2.0, but I think that's the same case in 2.2 as well.

With that said, here's the answer to the other questions:
1) There isn't a way to redirect to the registration form that JomSocial uses while using JFBConnect. They expect some temporary data to be handed to that form, which we don't generate. We can help you to add the registration fields to the JFBConnect registration page, if you plan to use the "Full Joomla User" setting, but with the "Facebook user Only" setting, the only option we can provide is redirecting to the full Edit Profile page of JomSocial.

2) I don't know of any way to separate out the fields in the Edit Profile page of JomSocial. I'd ask in their forums, as they know their code better.. or any add-ons that may do what you're looking for.

For the comments:
a) We agree that JFBConnect can change the flow of JomSocial a bit, but it's something we've heard only positive feedback about in the past. Additionally, since we have the ability to import fields from Facebook, if we were to redirect to the normal 'registration' page of JomSocial, it's possible only one field would be there (or none) since that info may already be pulled in. This could add a different type of confusion for admins and still require re-thinking things.. that's why we have the option to show the fields on 'our' registration page, if you choose to do so.

b) We pretty much do this, just in a different way. Again, I can easily help you to show just registration fields on our login/register form, or required and registration, or just required (what we do now). The only way we can't do that is through the "Facebook Only" flow, which is strictly meant for very quick registration. If you want a longer flow, and more info from the user, "Full Joomla User" is the only option from JFBConnect.

c) That should be still easily be possible with JFBConnect. The new user redirection can let you redirect the user wherever you want. If you have the ability to force user's to fill out fields on this 'new user' page, JFBConnect shouldn't interfere with that at all.

Hope that all helps, but if you have other questions or comments, definitely let us know them. We love hearing from our users, as that's where we've received most of our ideas for new features and improvements over the last (almost) 3 years of development.

Good luck,
Alex