We are running a multi site setup on Drupal 6.22. We had been running on Drupal 6.20 and recently updated to 6.22. Several years ago, we created a RSS feed and block on each of the subdomain sites to pull into the subdomain site and put in a block on the front page specific content we created on the main domain site that had a certain taxonomy term. This was how we maintained an ''announcements'' feature on the subdomain sites.

On each subdomain site we enabled the block created by the feed and assigned it a space on our theme in the left sidebar. It worked great. The block appeared when we had a fresh announcement; it disappeared when the aggregator limit had been reached -- 3 days but the block REMAINED enabled and assigned to the right space. And when we posted a new piece on the main domain site with the correct taxonomy term it would appear, like clockwork, on the subdomain sites. Swell.

Now, we have updated to 6.22. We do not know whether the update is related, but what we do know is that the feed aggregator block that we set up does not stay visible -- it disappears after several hours AND the block itself becomes disabled and is no longer assigned to a region on the theme. We manually re-enable the block and it will reappear again, but only for a few hours.

We thought that perhaps the feed we set up had become flawed; we created a new one, same behavior -- disappeared from the sidebar AND from the enabled block list within a few hours.
We thought it might be related to the cron running on the server, but we don't think so. Timing is not right. We run cron only once a day. We have asked our server folks to look to see if there is anything in cron that could be doing this but they say no, doesn't appear so.
We are operating poormanscron. Could this be a problem? If so, why would this all of a sudden be a problem. We've always run poormanscron.
Is it possible that with the Drupal update, the aggregator module behaves differently with a feed coming from the main domain?

I apologize that this support request is a bit vague. Frankly, I don't know how you can replicate this unless you have a multisite setup. And I have searched high and low in the issues, forums and groups to see if I could find any reference to this or anything like it. The only thing I saw that was related was that some folks lost all or many of their blocks upon updating Drupal, but that does not seem to be the problem here. And what makes this difficult is that it was working; now it isn't.

Any help -- suggestions on how we could trouble shoot this -- would be most appreciated. And if anyone has ever run into this, please offer some ideas to us on how we can fix this.

Thanks so much.

#4 aggregator_block_fix-1283442-4.patch4.24 KBBen Coleman
PASSED: [[SimpleTest]]: [MySQL] 190 pass(es). View


ggevalt’s picture

Too long a post? Sorry?
Would love some help on figuring out why our feed aggregator block appears and then disappears and is also disabled from the block list. Anyone run into this?

porjo’s picture

I just updated to 6.22 and this is happening for me too! I set my feeds to display on the right sidebar, they stay visable for awhile then go back to a disabled state.I suspect it may be the cronjob as the timing does line up for me. I've tested this by disabling the cronjob altogether and now the feed stays visible..but of course the feed itself doesn't get updated :(

Ben Coleman’s picture

Category: support » bug

I have run into this, too. The entry in the blocks table for aggregator blocks are being deleted by the block module's _blocks_rehash function, which is called by block_flush_caches (an implementation of hook_flush_caches). Thus, anytime hook_flush_caches is invoked, the aggregator blocks will disappear. This includes cron (hook_flush_caches is invoked by system_cron), but I presume hook_flush_caches may be called at other times (which may explain ggevalt's having the aggregator blocks disappear after a few hours when his cron only runs once a day). When you run /admin/build/block to look at the blocks, the blocks table entries for aggregator blocks are re-created, but of course, they are in the disabled list.

I've dug into this while writing this comment. The reason that _blocks_rehash deletes the aggregator blocks at times is _blocks_rehash invokes hook_block on every module, and any blocks currently in the blocks table which are not reported by hook_block are deleted. The hook_block function for aggregator, aggregator_block, returns nothing if the current user does not have the 'access news feeds' permission(the contents of the function are wrapped in an "if (user_access('access news feeds'))" block. If hook_flush_caches is invoked for a user who does not have the 'access news feeds' permission, aggregator_block returns nothing, and it looks like there are no aggregator blocks currently defined. This causes _block_refresh to delete the blocks table's entries for those blocks.

In our case, we had 'access news feeds' _not_ set for the anonymous user, and of course, cron runs as anonymous, so aggregator blocks got deleted every cron run.

You can work around this by giving 'access news feeds' permission to the Anonymous and Authenticated user roles. If your application requires *not* giving this permission to everyone, then the code will need to be fixed.

I presume that at some point, keeping aggregator blocks from being shown to those who don't have permission was implemented by wrapping the contents of aggregator_block with the user_access test. This is apparently now wrong. I'm not sure if this needs to be fixed by removing the user_access test from aggregator_block entirely and implementing it in the appropriate places that call aggregator_block, or by, say, only wrapping it around the op 'view' code. I'll leave that to those who are more familiar with aggregator code.

Ben Coleman’s picture

Version: 6.22 » 6.x-dev
Status: Active » Needs review
4.24 KB
PASSED: [[SimpleTest]]: [MySQL] 190 pass(es). View

Ok, I've got a patch for the above problem. I took a look at how this is done in Drupal 7, and found that in Drupal 7, the block API is slightly different. In 6, you have hook_block, with the first parameter being an op: list, view, configure, etc. In 7, you have a hook for each 'op': hook_block_view, hook_block_list, etc. I noticed that in 7, of the aggregator_block_* functions, only aggregator_block_view checks for 'access news feeds' permission. In 6, this permission check is being made for *all* of the ops, which seems to me erroneous (it causes at least the problem specified in this issue). You want to check the 'access news feeds' permission when viewing, so that someone without the permission can't view, but for other other ops, you want to report what's actually out there.

The attached patch moves the 'access news feeds' permission check in aggregator_block to the 'view' code only.

twistor’s picture

Status: Needs review » Reviewed & tested by the community

Good catch. Works like a charm. I can confirm that the bug exists as described and is fixed.

Gábor Hojtsy’s picture

Status: Reviewed & tested by the community » Fixed

All right, I'be reviewed the patch line by line to ensure the functionality is kept as-is (minus the bug). I agree this looks pretty bad, and further improvements to the aggregator_block() code would be great. Eg. the list of blocks and the block data itself are both gathered in a $block variable, which is pretty misleading. Anyway, this patch looks great to fix the bug for now and we can clean it up elsewhere if need be. Thanks.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.