I'm trying to produce a list of members (that belong to a member group) and show some of their properties. It's is listing the LoginName's correctly but fails to load the properties.
Hope someone can help me out:
<%
string[] users = Roles.GetUsersInRole("Certified");
foreach (string user in users)
{
MembershipUser mu = Membership.GetUser(user);
var m = new Member((int)mu.ProviderUserKey);
%>
<h3><%= m.LoginName %></h3>
<p><%= m.GenericProperties.Where(p => p.PropertyType.Alias == "Street").FirstOrDefault() %></p>
<% }%>
I've set the defaultMemberTypeAlias in the web.config.
I think each member has a lot of properties. When you request a poroperty it does a Database call, see also this blogpost. Had the same issue when developing MemberExport and changed my code to access the database directly.
thanks guys. But if this member stuff in umbraco is slow and old wouldn't it be wiser to swap it out in favor of aspnet_Membership db scheme or would that break the membership admin UI and possibly other stuff?
Is there any plans on reworking the member API in future versions of Umbraco? The fact that property getters/setters hit the database is a bit of an anti-pattern and I keep seeing problems popping up from it.
@Yannick You can plugin your own MemberShipprovider You can even view data, I think you can't update Data, not 100% sure.
Since V5 is completely rearchitected I assume there will be no more performance issues for members and content. I'm not sure if the complete ASP.Net membership DB scheme will be implemented, since it's a provider model it shouldn't matter as long as the underlying stucture is fast.
He Richard, I know about the possibility of configuring the web.config to use the SqlMembershipProvider but I was wondering what effect it'll have on the umbraco membership elements like the membership admin or even the permission system. Any experience with this to confirm that update is a no go with this approach like Richard says?
Yannick I think there is a package that might do what you are after. I tried getting it working but there was a few bugs I had to overcome. I am planning on realising it as a package but won't be for a few weeks until things calm down.
Yes there seems to be a profile editor in the osMemberControls. I've tested it on the frontend site not inside umbraco backend yet. Not sure how much work it would be to integrate it into the members section.
Can't produce list of members with properties
I'm trying to produce a list of members (that belong to a member group) and show some of their properties. It's is listing the LoginName's correctly but fails to load the properties.
Hope someone can help me out:
<% string[] users = Roles.GetUsersInRole("Certified"); foreach (string user in users) { MembershipUser mu = Membership.GetUser(user); var m = new Member((int)mu.ProviderUserKey); %> <h3><%= m.LoginName %></h3> <p><%= m.GenericProperties.Where(p => p.PropertyType.Alias == "Street").FirstOrDefault() %></p> <% }%>I've set the defaultMemberTypeAlias in the web.config.
on a side note, loading this code for 100 members takes over a minute!
As always just after posting I found the answer: propertyalias should be lowercase, even though you saved it upper-case!
and the FirstOrDefault() needs .Value appended.
If anybody want to comment on the speed that would still be very helpful!
Hi Yannick,
I think each member has a lot of properties. When you request a poroperty it does a Database call, see also this blogpost. Had the same issue when developing MemberExport and changed my code to access the database directly.
Cheers,
Richard
Would go with Richard's suggestion and query the db directly instead of using the member api which may be slow when used with +100 members.
Cheers,
/Dirk
thanks guys. But if this member stuff in umbraco is slow and old wouldn't it be wiser to swap it out in favor of aspnet_Membership db scheme or would that break the membership admin UI and possibly other stuff?
Not sure why this slow stuff is still in umbraco.
Is there any plans on reworking the member API in future versions of Umbraco? The fact that property getters/setters hit the database is a bit of an anti-pattern and I keep seeing problems popping up from it.
I don't mind helping out if I can.
@Yannick You can plugin your own MemberShipprovider You can even view data, I think you can't update Data, not 100% sure.
Since V5 is completely rearchitected I assume there will be no more performance issues for members and content. I'm not sure if the complete ASP.Net membership DB scheme will be implemented, since it's a provider model it shouldn't matter as long as the underlying stucture is fast.
Cheers,
Richard
He Richard, I know about the possibility of configuring the web.config to use the SqlMembershipProvider but I was wondering what effect it'll have on the umbraco membership elements like the membership admin or even the permission system. Any experience with this to confirm that update is a no go with this approach like Richard says?
According to the wiki (http://our.umbraco.org/wiki/how-tos/membership-providers/how-to-integrate-aspnet-membership-control-with-umbraco) it is true what Richard says about not being able to edit custom user properties without doing some custom user controls.
Should I add a codeplex workitem to request this feature?
Yannick I think there is a package that might do what you are after. I tried getting it working but there was a few bugs I had to overcome. I am planning on realising it as a package but won't be for a few weeks until things calm down.
Yes there seems to be a profile editor in the osMemberControls. I've tested it on the frontend site not inside umbraco backend yet. Not sure how much work it would be to integrate it into the members section.
is working on a reply...