At http://hushedcasket.com, I'm using Views and Aggregation. Aggregation works fine. But Aggregated items aren't getting updated in Views blocks and pages when non logged into the website. So, once new Feed Items are imported into the database, Views isn't noticing them. They don't appear in the Tracker or in my custom block that I built if I'm not logged into the website.

When logged in, the Feed Items show up in the Views. When logged out, they don't appear in the Views. However, they are always accessible via a direct link...even when not logged into the site.

Is this a Views issue or an Aggregation issue?

Note: When going to Admin > Post Settings > Rebuilt Permissions and running that command, the Views get updated with the latest Feed Items.

Thoughts?

Comments

merlinofchaos’s picture

merlinofchaos commented
Status: Active » Closed (works as designed)

Views does no content caching at all, ever.

From the sound of it, you have page caching turned on, and the aggregation module does not clear the page cache when items update.

Go to administer >> configure site >> performance

ericatkins’s picture

ericatkins commented

I _DID_ have page cache turned on when I first implemented these features. However, once I realized that my site would function as normal without the page cache, I turned it off. I did this a few days ago.

Page caching is off and has been for a few days. Additionally, when looking at the tracker, the tracker will update with current posts...however...it won't display the latest Feed Items. Read: other node types get updated in the tracker. Feed Items don't.

Merlin: Are you thinking this ISN'T a Views issue? If so, I'll go post this over on the Aggregation project page (or some other place if you recommend).

merlinofchaos’s picture

merlinofchaos commented

It seems likely that it's an Aggregation module issue; like I said, at the moment Views does not ever do content caching, so either the output is cached -- and since that's off -- that means the input is cached, which is really bizarre but certainly possible.

vito_swat’s picture

vito_swat commented
Status: Closed (works as designed) » Active

I have similar issue with advertisment module. I created view of ads which one of owner is current user but the output was cashed when I switched users so the other user saw the firs users ads. Workaround was to expose one of the filter.

Maybe Ad module and Aggregation module both miss something to prevent views from putting data into views_cache table.

merlinofchaos’s picture

merlinofchaos commented
Status: Active » Closed (works as designed)

Again, Views doesn't cache anything, so this is clearly not a Views problem. No point in re-opening an issue in the Views queue.

merlinofchaos’s picture

merlinofchaos commented

Rather, Views doesn't cache content.

It caches lots of its own data, but that's unrelated to this.

vito_swat’s picture

vito_swat commented

It seems that ericatkins and my problem are connected not with content cashing of but with views query results cashing. That's why exposing filter is good workaround because it prevent views from cashing query reslults. Is there any other way to prevent views from cashing results of the query?

merlinofchaos’s picture

merlinofchaos commented

Views does not cache query results, either. So by breathing, you have successfully prevented Views from caching query results (which, btw, is exactly what I meant by content caching).

vito_swat’s picture

vito_swat commented

Ok, views does not any content cashing, but the problem remains and because is not the only one module problem it seems connected with Views. Maybe it's only lack of knowledge of modules authors (including me) how to make Views to behave properly.

Views module is quite big and way too complicated to me to find myself what makes Views to behave in such way. If you give us some advice I can prepare patches to aggregation and ad modules to properly support Views.

merlinofchaos’s picture

merlinofchaos commented

I have absolutely no idea why your modules behave the way they do. But I can't imagine that Views has anything to do with it; at its core, Views works about like the basic 'node' does. IT generates a query and displays some results.

Any caching that happens could only happen in node_view() or something like that. If you're asking me to debug your problem, the answer is insane laughter. I'm way too busy for that.

merlinofchaos’s picture

merlinofchaos commented

Another possibility is that for some reason, when you aggregate you're doing something weird and the page cache isn't getting cleared. If you're doing a node_save() I don't know how that could happen, but if you're doing something tricky maybe it could. (That's completely not Views' related, by the way).

merlinofchaos’s picture

merlinofchaos commented

vito: Ok, I should follow up slightly. You posted something that is a basically different problem. (sigh. I hate when peopl e do that).

Views *does* cache the query that gets run. Not the results mind you, just the query. Ordinarily the query doesn't change much. THis leads me to a question about your view: Just how are you setting it to 'current user'? There is a filter for that that is very careful not to cache the current user. Are you using some other method for this?

fonant’s picture

fonant commented

I get the same problem with the latest version of Aggregation: new items are added as new nodes (images too!) but they're only visible to site admin and not anon visitors.

For some reason the nodes aren't being added to node_access table for the "all" realm when we do a node_save() on the new nodes. Re-building the node_access table using the method of the original poster adds them in and all works as expected.

This is a problem with Aggregation, not Views.