feature: generic 'featured item' method for entities

[propertunist]

some plugins, such as 'blog_tools' allow entities to be featured, so that views/widgets can be created which only display the featured items.
this allows admins to provide a focus to the site and to draw attention to the most useful info on the site.

i think a core function should be added to allow all entity types to be featured. widgets can then include the options to display only featured items or not.

[ewinslow]

+1
On Jan 1, 2014 11:28 AM, "ura soul" notifications@github.com wrote:

some plugins, such as 'blog_tools' allow entities to be featured, so that
views/widgets can be created which only display the featured items.
this allows admins to provide a focus to the site and to draw attention to
the most useful info on the site.

i think a core function should be added to allow all entity types to be
featured. widgets can then include the options to display only featured
items or not.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/6293
.

[mrclay]

Another case for entity list #2567

[jdalsem]

Closing in favor of a lists api as concluded in #7888

[propertunist]

this was passed on to the 'entity list system' ticket and then rejected as not being part of that change. so i request to re-open this ticket, as advised here #2567

[hypeJunction]

I think this is a perfect candidate for a plugin, in core or otherwise. I do not think we will be adding another method to the entity classes. Just simple metadata setter/getters would work.

• add setitngs to specify which type/subtype pairs can be featured (or perhaps context based approach is better $entity->featured = 'groups'; where featured is multi metadata)
• add menu items (ajaxify)
• add permission checks
• add menu item to page filters
• route featured pages
• create widgets

I don't see anyone on the core team or contributors working on this. I would imagine if you create your plugin, most of us will be happy to contribute. I have too much on my plate as is, and featured items are not high on my priority list.

[ewinslow]

If this is based on entity list API I think the only thing to do is standardize on the name of the list.

[ewinslow]

Would "featured" be equivalent to "sticky" in the case of discussion forums?

[propertunist]

@ewinslow - good question. personally, i would like to see the ability to switch between featured and non-featured items in a list using just a one-click ajax action.. which would act like a list filter. this is similar, though not exactly the same as a sticky; in that sticky's are intended to always be seen at the top of the list, whereas the featured items are more of an 'editors choice' type of selector. some users may be attracted to look at the list of featured items and others may not be so attracted to look at them, whereas stickys are the admin 'sticking' their activity into the user's viewport whether the user likes it or not!
if the stickys and featured items are separated, then that also gives the possibility for having a list of featured topics on the homepage, for example, while not being forced to include 'forum guidelines' and other common 'sticky' topics within that featured list. flexibility is always helpful for admins.

[mrclay]

The lists API will handle these cases easily. https://github.com/mrclay/Elgg-elggx_lists_api#using-a-list-in-queries

[jdalsem]

Because of this discussion, i started #7888. With the lists api, there is only one question left, what will be the standardized name (if we would choose one). Every plugin can have its own featured interpretation, so if we use the lists api, there is no need to leave this ticket open as there is no action left related to this ticket. Core currently uses "featured" items on 1 location (groups plugin). It uses metadata for it featured_group.

[mrclay]

I figured a group might have one big /GUID/featured list, and for viewing you could filter that by subtype or whatever.

Plugins making their own list reduces the potential for collaboration, but nothing stopping them: /GUID/myplugin:featured.

[mrclay]

In a site I run users can create "collection" ElggObjects, or add attachments to any other their content, including comments. All list powered. When you view any entity on the site, you can lookup which collection(s)/attachments it's in.

[jdalsem]

So we only need to write a best practice on how to use lists. If we add that action to the API lists ticket, do we still need this ticket?

[mrclay]

I guess the question is whether core is going to provide the front-end UI for this feature in a new bundled plugin. I would vote no.

[mrclay]

We can always re-open if we decide to pull in a 3rd party implementation.

[jdalsem]

Also a no for me, as the problem will be to get a consensus on what "featured" means

[ewinslow]

FWIW, I'd also vote no on providing a UI.

@propertunist do you feel this issue is resolved sufficiently?

[propertunist]

@ewinslow - from what i gathered here, the decision was made not to code this, i'm not really clear how this has been resolved, did i miss something?

[mrclay]

Today, core is not interested in developing a plugin that does this. We are first focusing on underlying APIs that will make it easy and fast. Later we may concider reopening this.

[propertunist]

i see, ok.