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.

brettp wrote on 42307343-07-15

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

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

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.

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()