Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Need a default river view (Trac #4384) #4384

Closed
elgg-gitbot opened this issue Feb 16, 2013 · 5 comments
Closed

Need a default river view (Trac #4384) #4384

elgg-gitbot opened this issue Feb 16, 2013 · 5 comments

Comments

@elgg-gitbot
Copy link

@elgg-gitbot elgg-gitbot commented Feb 16, 2013

Original ticket http://trac.elgg.org/ticket/4384 on 42155019-02-05 by brettp, assigned to unknown.

Elgg version: 1.8.3

River entries with invalid views (usually from disabled plugins) don't show up at all, but still create a

  • . We either need to create a default river view, or make page/components/list not add the
  • if elgg_view_list_item() returns nothing.

  • @elgg-gitbot
    Copy link
    Author

    @elgg-gitbot elgg-gitbot commented Feb 16, 2013

    ewinslow wrote on 42305823-11-26

    Option 1 sounds impossible to get right, but option 2 will cause this problem: There could appear to be only 13 results when limit was set to 20. Ultimately we need a way to ignore unsupported entries in the river.

    Before executing a river query, we should query for all the unique views that are in the river, filter out the ones that do not exist (using elgg_view_exists), and then add an AND view IN (views list) clause to the query.

    @elgg-gitbot
    Copy link
    Author

    @elgg-gitbot elgg-gitbot commented Feb 16, 2013

    brettp wrote on 42307343-07-15

    Sounds good as long as we cache the valid views list.

    adayth added a commit to adayth/Elgg that referenced this issue Mar 13, 2013
    @adayth
    Copy link
    Contributor

    @adayth adayth commented Mar 13, 2013

    I wrote a modification following your guidelines to get valid views list with SELECT DISTINCT view FROM {$CONFIG->dbprefix}river and checking with elgg_view_exists.

    I'm currently caching valid views in memory in a global var, but maybe you were talking about caching in file cache.

    I want to do a pull request, but I need to know if I'm doing this right.

    See my commit here: adayth@a6ccaf9

    @ewinslow
    Copy link
    Contributor

    @ewinslow ewinslow commented Mar 13, 2013

    That looks like you're on the right track. Thanks for looking into this!

    I'm not really sure how much a file-based cache will matter since the query is simple and we should be caching the results of elgg_view_exists if we aren't already.

    @hypeJunction
    Copy link
    Contributor

    @hypeJunction hypeJunction commented Jun 1, 2013

    Am I wrong to assume that we could tackle this by checking types/subtypes against registered types/subtypes? We already use a river filter that does just that, so perhaps we could partially eliminate this problem; after all, it is likely that a view concerned is likely within the same plugin as elgg_register_entity_type()

    @jdalsem jdalsem added this to the Elgg 3.0.x milestone Oct 27, 2017
    jeabakker added a commit to jeabakker/Elgg that referenced this issue Nov 2, 2017
    This will make river views more generic and it's no longer required to
    provide a `view` to elgg_create_river_item
    
    fixes: Elgg#4384
    jeabakker added a commit to jeabakker/Elgg that referenced this issue Nov 3, 2017
    This will make river views more generic and it's no longer required to
    provide a `view` to elgg_create_river_item
    
    fixes: Elgg#4384
    jeabakker added a commit to jeabakker/Elgg that referenced this issue Nov 3, 2017
    This will make river views more generic and it's no longer required to
    provide a `view` to elgg_create_river_item
    
    fixes: Elgg#4384
    jeabakker added a commit to jeabakker/Elgg that referenced this issue Nov 3, 2017
    This will make river views more generic and it's no longer required to
    provide a `view` to elgg_create_river_item
    
    fixes: Elgg#4384
    jeabakker added a commit to jeabakker/Elgg that referenced this issue Nov 6, 2017
    This will make river views more generic and it's no longer required to
    provide a `view` to elgg_create_river_item
    
    fixes: Elgg#4384
    jeabakker added a commit to jeabakker/Elgg that referenced this issue Nov 6, 2017
    This will make river views more generic and it's no longer required to
    provide a `view` to elgg_create_river_item
    
    fixes: Elgg#4384
    Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
    Labels
    Development

    No branches or pull requests

    5 participants