The Services layer of Umbraco is for manipulating the business logic of Umbraco directly to/from the database. None of these methods should be used within your views and can have a very large impact on performance and stability of your application.
However, MembershipHelper or UmbracoHelper only allow one to query singular users bij some kind of property such as ID or Email...
So what to do here if I want fast, reliable access to all users, just like I could with cached content?
Here is an example of how to list all members. (You probobly want to set up your own ExamineIndex instead of using the InternalMember index, but you get the idea. More on setting up your own indexes and searchers here: https://our.umbraco.org/documentation/reference/searching/examine/.)
@using UmbracoExamine
@{
var searcher = ExamineManager.Instance.SearchProviderCollection["InternalMemberSearcher"];
var criteria = searcher.CreateSearchCriteria(IndexTypes.Member);
var searchResults = searcher.Search(criteria.SearchIndexType, true);
}
@foreach (var item in searchResults)
{
<span>@(item.Fields["email"])</span>
}
Actually one thing that I was wondering about when implementing this:
If I create my own indexes (e.g. external member searcher), I assume I can index only 'members'.
Why then, when creating search criteria, I still need to specify :
var criteria = searcher.CreateSearchCriteria(IndexTypes.Member);
When I am already using my member specific 'Searcher'?
The effect of specifying IndexTypes.Member seems to be that way down in the inner workings of the search mechanism a 'MUST' condition is added for the string 'member' and indeed, the string member is all over the relevant index files in the filesystem.
Still, if the searcher only indexes members in the first place, why is this necessary as opposed to just searching the equivalent of '*'.
It would certainly make things somewhat more consistent given the relatively ease of access to content nodes.
Lucene is very nice and powerful it seems but for proper use, requires quite some setup and a good helping of 'you really must know what you're doing' :)
Listing site members in views - don't use MemberService?
Hi,
I am running some sites where team members are 'members' and where we would like to list these members and e.g. their bio on a web facing page.
I am currently doing this by referencing the
MemberService.However, there is mention of such a thing in the 'pitfalls' sections in the docs.
However,
MembershipHelperorUmbracoHelperonly allow one to query singular users bij some kind of property such as ID or Email...So what to do here if I want fast, reliable access to all users, just like I could with cached content?
Hi Kris.
You can use Examine for listing you members.
Here is an example of how to list all members. (You probobly want to set up your own ExamineIndex instead of using the InternalMember index, but you get the idea. More on setting up your own indexes and searchers here: https://our.umbraco.org/documentation/reference/searching/examine/.)
Best of luck!
Excellent, that indeed seems to be the solution.
You'd be surprised how many online resources abuse the services layer for this :)
Actually one thing that I was wondering about when implementing this:
If I create my own indexes (e.g. external member searcher), I assume I can index only 'members'.
Why then, when creating search criteria, I still need to specify :
When I am already using my member specific 'Searcher'?
The effect of specifying
IndexTypes.Memberseems to be that way down in the inner workings of the search mechanism a 'MUST' condition is added for the string 'member' and indeed, the stringmemberis all over the relevant index files in the filesystem.Still, if the searcher only indexes members in the first place, why is this necessary as opposed to just searching the equivalent of '*'.
Don't know if this question makes sense :)
Perfect! Glad I could help you Kris! :)
Have a great day!
Examine is perfect for this, but there should still be a better API for this:
This is the original feature request: http://issues.umbraco.org/issue/U4-4379
This is the improvement: http://issues.umbraco.org/issue/U4-6368
Jeroen
It would certainly make things somewhat more consistent given the relatively ease of access to content nodes.
Lucene is very nice and powerful it seems but for proper use, requires quite some setup and a good helping of 'you really must know what you're doing' :)
is working on a reply...