Add a "Drupal news" block to an appropriate administrative area in the Standard profile

A great idea, look forward to the patch (aka subscribe)

Great idea! Code looks good. Easy patch is easy.

Now all that's left is to bikeshed the position of the block for the next 197 comments.

Just kidding.

webchick pointed out that title & description should be wrapped in t().

1. The patch leads to a fatal error in the installer, since aggregator module is not enabled... (Look closely at the test results in #2 - we apparently have an interesting bug where "0 passes" makes it look like the patch passed tests.)
2. Regarding wrapping in st(), translation in the installer is a bit of a complicated mess, but I think the answer for this one is "yes". Background reading to confirm that I'm right/wrong is at:
   #1048006: Name of vocabulary (Tags) created during install cannot be localized
   #1016006: Default title, body and other field labels not localizable
3. When defining the block:
   

   +      'delta' => 'feed-1',
   

   I don't think we can assume this on some databases. aggregator_save_feed() may need to be modified to return the actual feed ID that was saved so we can use that instead.

A big +1 from me in favor of adding this block; it's one of the things that's on the agenda for the Snowman 'Small Group Tool' installation profile as well, and putting it in Standard makes sense from a Drupal branding perspective. It's probably worth paying a little extra attention to our d.o. front page node titles, though, as a lot of the stuff that shows up in that feed (other than Drupal release notes) is a bit opaque from a microcontent perspective.

It's outside of the purview of this particular patch, but writing to the audience of People Who Installed A New Drupal Site vs. People Who Read Drupal.org is something to keep in mind!

The code looks good now (except for whatever is causing that failing test). Also, aggregator_save_feed() should have its @return documented.

I had a similar thought as @eaton when looking at the list of aggregator item titles. What would someone relatively new to Drupal think when they saw that list - would they really have enough context to understand what they were looking at?

It's been a long while since I looked at the Wordpress version of this so I don't quite remember how it works, but I seem to remember it being a bit different... maybe they have descriptions next to the items? Or an overall description at the top of the block? It would be worth taking a look. It may be we can't do much to change this without changing the behavior of the aggregator module itself and/or improving the titles of d.o. front page posts (which is a bit out of scope), but it does feel like it would be improved with some kind of extra sentence of context or what not.

Looks good to me, I dont think we really need to do much customization, the reason Wordpress also has teasers is because they are trying to balance the visual elements on the dashboard (several blocks with only links, is not going to help that).

Does this require aggregation module to be enabled by default? Because that to me, seems like a more major concern given the UX problems it has.

I agree that for the initial user experience, its unlikely to cause any issues. With that in mind we can definitely consider letting this go in. However in light of the recent discussions about our product, we should definitively have to talk whether this module as a whole deserves a place in the product (other issue, though). Even if we remove aggregator we could have a block like this.

The issues I see with aggregator are not in the administrative section, but rather in the front-end (the results). These are really hard to discover and understand the relationship between pages. It uses its own form of categorization, which has many confusing side effects (e.g. categorize pages with no content, empty configuration pages and poor navigation between categories and feed streams). But also the initial experience of aggregator, being an "empty" one - unless you do some customization its likely the first feeds you pull in are going to be empty till an update comes by. In the administrative section there are other problems, such as the categorization and feeds shown on one page, with several feeds and categories this gets messy quickly.

I am not sure how this patch is implemented, but does it create a "default" setting here by creating a "Drupal news" feed? If so, we need to consider whether hiding it - makes sense. This because for the user it will be somewhat confusing to see a "administrative" feature being performed by a module. The connection between the block, and what is shown in aggregator will not immediately be clear.

I have no knowledge of existing issues about this, clearly it hasn't been a focus point of us. Given the problems we face for D8, I doubt we will get to it.

It does mean that yes, but it's buried pretty deep in the UI, so the chances of someone stumbling across it are fairly nil. Are there specific UX concerns with aggregator module, and are they captured in other issues?

One patch that's been kicked around for Aggregator is forcing it to follow the same pattern that's being proposed for other listing pages: allow both the listing page and the block to be turned off independently, so that there's no externally-facing UI/menu cruft to discourage this sort of usage. That's definitely a task for another patch, though.

Much love for this. A lifeline between your install and the mothership.

Webchick: Understood. Which means that Aggregator module would be enabled in the standard profile right? (Not only still part of core, but switched on, even)

I'm thinking this could use a 'register now' call to action to unlock the membership block with welcoming get started links. Basically, rework the 'contributor links' block on the d.o. dashboard for support/community onramp. Which is another issue. But this news block might be a good place for triggering it.

@eaton I would definitely favor that, although loads of this brings us to the component & page library idea we had for a more consistent approach.

@webchick Interesting to see your position on this, I don't really want to hold this up because I feel its a useful thing to endeavour. But I do wish to note that fundamentally we did not consider aggregate as part of our "enabled by default" product offering because "we" believe that this type of functionality is not a common usecase for the first 3/4 hours of initial experience. You seemed to have changed position on this, but I find it weird to "enable" something just to proof people wrong that even core doesn't use it. We should have a clear use case we are trying to support in the initial user experience. Hence my attempt to evaluate enabling aggregator independent of this issue.

When it comes to the example data purpose, I dont find it similar to forum and contact. In those modules the sole purpose of it is, to provide direction. Here we use it for actual functionality, if you remove this "Drupal news feed" it will impact the UX of your administrative dashboard. So it's not really example data, its simply using the functionality of the system with the added bonus that this module doesn't start out empty.

Again I don't wish to hold this functionality on this. But please remember, that during the Drupal 7 period we enabled a number of modules with supporting usecases for the initial user experience, in this case that doesn't seem to apply (or at least hasn't been discussed).

More important is the workflow here, do we repeat the Drupal 4/5/6/7 workflow of putting stuff in and than fixing the major(not critical) UX issues later, or do we require these to be solved before we enable new functionality? In this instance, aggregator its problem are very solvable - but will delay actual implementation of this issue.

Thanks for the screenshot in #11. I guess those teasers were the extra text I was thinking of in the Wordpress case, and we probably don't need to deal with having those (especially not in this issue).

But in our case, a description of the feed still seems like it would provide useful context, especially since the patch tries to save one to the database anyway. We don't have to deal with that here either, but I created an issue for it at #1270476: Aggregator feed blocks should have an option to display the feed description. (Note that there's a related bug with the patch; the description that the patch tries to save to the database gets overridden immediately afterwards with an empty string, since the aggregator module gets descriptions from the feed itself, and drupal.org apparently doesn't provide a feed description that the aggregator module can understand. So this should probably be fixed on drupal.org rather than trying to save a description as part of this patch.)

I've rerolled the patch to fix the failing test. My other feedback above (on the missing @return docs) is already being handled in #1266322: aggregator_save_feed() should return the feed ID so there's no need to worry about it here.

The patch in #19 adds an extra text case.
Was that really intended for this issues?

There is no extra test case, just an extra test module, which was introduced in order to fix the failing test.

(There are a couple other ways to fix the failure, but this seems like the most future-proof to me, since it's the only one that doesn't require the user module to depend on knowledge of some other random module in core.)

Dashboard is gone now.

Views? Panels-in-Core (or whatever they're calling it these days)?

I think there are some options here.

We dont have a dashboard, and I doubt that feature can make it in now. This is a good idea, but one for D9.

That is too bad. It would be a nice addition. Even if it were just a block featured on the home page and an available option for folks to enable/disable later on.

We do need to have more means to push people back to the community after they have downloaded the code.

Just to add. Also CiviCRM does this.

This could be very useful as a strategy to help build community awareness.

Should this be closed now #3206643: Project messaging channel in core (as experimental) ?

I am inclined to agree with #44. Therefor I am closing this.