solved Revisiting blogs...

Dazed
Dazed
@dazed
10 years ago
1,022 posts
I have another issue I, actually had this issue in JR4 also, that I need some help on.

Issue:

I allow premium artists blogs to appear on the index page. I need to limit each artist to one 1 blog on the index page. This way one artist is not able to take over the main page with their blogs.

Currently artist 1 can post a blog and it appears on the index page. Then artist 2 adds four new blogs pushing artist 1 off the page. I would like it so that the last artist blog will only appear on the index page.

Ideas?

Thanks!
updated by @dazed: 10/26/14 04:23:01AM
paul
@paul
10 years ago
4,326 posts
{jrCore_list module="jrBlog" group_by="_profile_id" . . .}

Not tried it but something like that might do the trick?
Pa


--
Paul Asher - JR Developer and System Import Specialist
brian
@brian
10 years ago
10,148 posts
Yep a "group_by" on _profile_id and an order_by="_item_id desc" should do the trick.


--
Brian Johnson
Founder and Lead Developer - Jamroom
https://www.jamroom.net
Dazed
Dazed
@dazed
10 years ago
1,022 posts
Thanks for the help guys. I tried the below but the results were a little off. I had posts appear from several months ago and nothing from today.


{jrCore_list module="jrBlog" group_by="_profile_id" order_by="_item_id desc" search1="profile_quota_id in 4,5,7,8,9,16,18,19,21,22,23,24,25,26"  search2="blog_category not_in about,news,welcome,latest,featured,exclusive"  template=$site_blog_premium_template pagebreak="4" page=$_post.p}
        
michael
@michael
10 years ago
7,715 posts
check the results against what you've asked for to figure out what you've got.

Asked for (from the query above):
* get me blog posts
* only 1 per profile_id
* order them by newest at the top
* make sure the profile_quota_id is one of these 4,5,7,8,9,16,18,19,21,22,23,24,25,26
* make sure the blog category is NOT about,news,welcome,latest,featured,exclusive
* I only want a total of 4 posts.
Dazed
Dazed
@dazed
10 years ago
1,022 posts
Hey Michael - What returned was this:

No posts from September and it should have returned 4 I believe. The posts that came up were from August, July and April so we were missing a lot of posts.
michael
@michael
10 years ago
7,715 posts
Take a look at the datastore for one of the posts that should show up and make sure that it doesn't match the exclusion criteria you have.

If its what you've asked for it should show up.

If should show up but doesn't then we need to locate why it doesn't show up.
Dazed
Dazed
@dazed
10 years ago
1,022 posts
Hey Michael - What I did was just hit the blogs page and took a little inventory of what was there since it displays all blogs. The only thing that should change on the index page is that members in the specified quota with more than 1 post should only display their last post. I definitely should not have posts appearing from April.
michael
@michael
10 years ago
7,715 posts
So what I'm understanding is happening is: The group by is working to only display one post from each user, but the post that is being displayed is not the newest post for that user.

Is that right?

If so, try removing the group_by and see if all their posts come out. Sounds like its not selecting the right post. Ill try to setup something to check it out.
Dazed
Dazed
@dazed
10 years ago
1,022 posts
Hey Michael - Currently the call has a order_by="_created desc" and I removed that and added order_by="_item_id desc" and the order looks the same. So the group by clause seems to be causing the issue.
brian
@brian
10 years ago
10,148 posts
I have a specific DataStore unit test that checks for this and it is working, so I am suspecting a module listener is interfering in some way - I will see if I can replicate.

Thanks!


--
Brian Johnson
Founder and Lead Developer - Jamroom
https://www.jamroom.net
brian
@brian
10 years ago
10,148 posts
OK I know why this is happening, and unfortunately there is no "easy" fix for it - the issue is that we are trying to group by a column that is in a table that is being joined to the main item table (in this case the _profile_id) - which is at the core of how the DS works.

So there's really no way currently to make this work AND have the results be paginated. Instead, what we will have to do is setup something like JR4 had - i.e. something like max_per_profile="1" (or something like that). The problem is that when doing this you can't paginate, since it has to pull down MORE results than will match, and then "prune" in the template display loop, which breaks pagination.

So I will look into something like that for the jrCore_list support.

Hope this helps!


--
Brian Johnson
Founder and Lead Developer - Jamroom
https://www.jamroom.net
Dazed
Dazed
@dazed
10 years ago
1,022 posts
Thanks for the help Brian
brian
@brian
10 years ago
10,148 posts
I've come up with something that I think will work for situations like this - basically on your "group_by" command you add the special UNIQUE keyword - i.e.

{jrCore_list module="jrBlog" group_by="_profile_id UNIQUE" ... }

That will make it so it is grouped on the _profile_id UNIQUELY - i.e. only ONE entry in the result set for each _profile_id. This can be used on any key - i.e.

{jrCore_list module="jrBlog" group_by="blog_category_url UNIQUE" ... }

would have one entry per category, etc.

This will be in the next core release.

Hope this helps!


--
Brian Johnson
Founder and Lead Developer - Jamroom
https://www.jamroom.net
brian
@brian
10 years ago
10,148 posts
This is now supported in Jamroom Core 5.2.10 - let me know if you see any issues.

Thanks!


--
Brian Johnson
Founder and Lead Developer - Jamroom
https://www.jamroom.net
Dazed
Dazed
@dazed
10 years ago
1,022 posts
Thanks Brian