Don't show aggregator messages to anonymous users

I believe this comment http://drupal.org/node/342128#comment-1203466 can be used for that.

Please post back how that works out for you.

- Arie

LOL I missed that was your own post :-D

I guess you mean it's a workaround and not a final solution right?

AFAICT from the comments in #291026: change E_NOTICE to warning and allow selection of error level there are no plans to back port that patch to D6 but I guess you could give it a try.

- Arie

Don't like to do it this way, but still: "subscribe".

Temporary I've uncommented drupal_set_messages generated by aggregator, because most of them get logged by watchdog() anyway

I'd like to support this feature request. It should be possible to control the messages. I'm using Poormanscron, too, and that way anonymous users trigger the cron run and then get the message.

I see these messages in one message box, while not logged in:

• There is new syndicated content from site 1.
• There is no new syndicated content from site 2.
• The feed from site 3 seems to be broken, because of error "404 Not Found".

Now:

1. This is clearly a bug. These messages are aimed at admins, not anonymous users, or even regular users.
2. Even an admin probably doesn't care whether aggregator encountered new content or not every time cron runs. The messages are logged in the watchdog anyway.
3. The third message is marked as a warning in the watchdog, but not in the message box.

The problem: aggregator_refresh() is called both from cron and from /admin/content/aggregator (a manual refresh). In the latter case you do want messages shown to the screen, in the former you don't.

The patch does this:

• do not show messages when the refresh is called from cron
• mark error messages to the screen as "error"

#9: aggregator.patch queued for re-testing.

Here's a patch implementing kenorb's 3rd option in #4

With this patch the system messages related to feeds will be shown only to those users who have 'administer news feeds' privileges.

Submitting the last patch after rebuilding from current head release.

subscribing

I want this feature too. We should be able to control to whom the message displayed.

subscribing...

Hi kevinwal, perhaps try here: #894166: testbot cannot find file in patch for 6.19

Thanks Gaele, I'll take a look. Not sure what I'm doing wrong here. Tried a handful of times.

subscribing

subscribing

Patch from #27. (See #894166: testbot cannot find file in patch for 6.19)

Hi
Sorry to slip this in here, i am new to Drupal, "1 month", I am also having this issue on this module, could you tell me what I need to do to install this patch? happy to test Beta's as the alternative is that I remove this functionality until resolved.

...go to top of this page -> enter the term 'patches' in the search field and start a search -> in the search results, the 4th or so is one called 'Applying patches' -> visit this link -> read and experiment -> if patch refuses to be applied, go to the end of that article and visit the 'Applying a patch manually' link -> once again read end experiment.

I am sure that after a few tries you'll get it right. Good luck with it ;)

subscribing

#27: aggregator.patch queued for re-testing.

kevinwal, testbot only tests on D7. So don't let it test again, or the status will be reset again as well.

Setting status to RTBC to allow Gábor to have a look at #33.

Roger that Gaele,

I was unsure on what the resolution was from the patch you posted without a status?

When trying to test the patch on a Linux box I get 3 out of 3 hunks FAILED.

jleroi, which version of Drupal did you use? The patch is for 6.19.

I'm using 6.19. I tried resaving and giving it another go but no joy. I'll keep trying.

Apparently the patch was not for 6.19.
jleroi, try this one.

Still not working. Getting errors

I appreciate the help gaele, but same here. Still getting the hunk failed errors.

This applied cleanly on my fresh 6.19 check-out.

subscribing

Patch in #47 seems to fix most of it, except that error messages still show to an anonymous user.
The line: drupal_set_message(t('The feed from %site seems to be broken, because of error "%error".', array('%site' => $feed['title'], '%error' => $result->code .' '. $result->error)));
repeats twice in the aggregator.module, so maybe the patch should apply to both of them?

True. Which brings us back to my original patch from #9 :-)

Patch in #50 seems to work just fine! :)

Seems ready for Gábor.

subscribing, having the same issue.

1. Does this apply to Drupal 7? Looks like this was not discussed. I assume it does.

2. The $admin default seems to be FALSE, which changes default behavior for API functions from how they worked before. I agree it makes them work in more logical ways, but that is not the point. We should keep backwards compatibility.

3. Not sure naming the argument $admin is a good idea. Maybe $messages or something like that? If it just has effect on those as I'm seeing.

The argument is named $admin, because it is used when checking if the user is an admin or not. If the check was to display messages or not, then something like $messages would be ok. If $admin seems to 'generic' and there is fear of confusion, then $messages is as generic too. How about $user_is_admin or $role_is_admin? (or something like $show_messages if we want to avoid the word 'admin') ...I mean drupal coding standards do allow underscores in variable names. Right?

Yes, indeed $show_messages would be consistent with how Drupal handles this elsewhere.

$admin renamed to $show_messages, defaulting to TRUE.

I tried D7 with a bogus feed url, but couldn't get any messages to appear on screen. Didn't look into it any further, though.

#58 seems to work! Thank you for the patch.

I applied #58 and anonymous users still saw the new syndicated content message.

Any update on this issue? I've tried Drupal tweaks and it still didn't make any difference.

There is a new module called "Disable Messages", I am hoping this might be a work around.
http://drupal.org/project/disable_messages

My clients keep reporting the infamous "There is new syndicated content..." as a bug.

Thanx for the info Danny ;)

Mine too! Thanks for the heads up *goes off to download*

In my opinion this should be controlled via theme's template engine...

Below is what I use and has been very helpful. Just add it anywhere in your theme's template.php file. It even handles the Operating Offf-line mode message which I remove when themeing.

/**
 * Provides message status visibility control for:
 *  @offline_status = FALSE
 *  @new_syndication_status = FALSE
 *  @no_new_syndication_status=FALSE
 * 
 * Pass TRUE for messages to be removed.
 */
function remove_message_statuses($offline_status=FALSE, $new_syndication_status=FALSE, $no_new_syndication_status=FALSE) {
	$removals = array();
	if($offline_status)            $removals[] = l(t('Operating in off-line mode.'), 'admin/settings/site-maintenance');
	if($new_syndication_status)    $removals[] = t('There is new syndicated content from ');
	if($no_new_syndication_status) $removals[] = t('There is no new syndicated content from ');
	if(is_array($_SESSION['messages']['status'])) {
		$statuses = array();
		foreach($_SESSION['messages']['status'] as $status) {
			$save = TRUE;
			foreach($removals as $remove) if(strpos($status, $remove)===0) $save = FALSE;
			if($save) $statuses[] = $status;
		}
		if(!count($statuses))	{
			unset($_SESSION['messages']['status']);
		} else {
			$_SESSION['messages']['status'] = $statuses;
		}
	}
}
global $user;
$admin = $user->uid == 1;
remove_message_statuses(TRUE, !$admin, !$admin);

Only tested in D6

are there any news? tried disable_messages and that code in my template.php and i'm still getting the same annoying message..
Thanks!

This hasn't made it into D8 yet.

This is still valid, at least for some error messages, for example from DefaultFetcher:

 }
    catch (TransferException $e) {
      $this->logger->warning('The feed from %site seems to be broken because of error "%error".', ['%site' => $feed->label(), '%error' => $e->getMessage()]);
      $this->messenger->addWarning(t('The feed from %site seems to be broken because of error "%error".', ['%site' => $feed->label(), '%error' => $e->getMessage()]));
      return FALSE;
    }

Could we just use trigger_error() instead, then showing a warning or not would be based on error display settings. Or just rely on the log messages.

The aggregator module has been removed from Core in 10.0.x-dev and now lives on as a contrib module. Issues in the Core queue about the aggregator module, like this one, have been moved to the contrib module queue.