[Meta] Convert core listings to Views

forum blocks

rss

User blocks:
Newest users
Who's online

This is part of (maybe a dupe of) #1864980: [meta] Figure out how to integrate Views into core.

I went through all the blocks from #1535868: Convert all blocks into plugins:

Most likely Views

1. Aggregator category block (CategoryBlock).
2. Aggregator feed block (FeedBlock).
3. Comment "Recent comments" block (RecentBlock)
4. Forum "Active forum topics" block (ActiveBlock) (Would probably need forum data integration for {forum_index} to avoid potential performance regressions)
5. Forum "New forum topics" block (NewBlock) (as above)
6. Node "Recent content" block (RecentBlock)
7. Statistics "Popular content" block (StatisticsPopularBlock)
8. User "Who's new" block (UserNewBlock)
9. User "Who's online" block (UserOnlineBlock)

Maybe Views?

1. Language switcher block
2. Poll "Recent poll" block (PollRecentBlock) but maybe not. (You can make this block with a view, but it's only one record.)
3. Shortcut ShortcutsBlock? (Would require shortcut intergation)
4. Search block (could be an exposed form block for a search view)

Not Views

1. Book menu block
2. Menu, system menu, and custom menu blocks
3. System help block (conceptually view-like, but help is provided as a bunch of hook implementations rather than database content.)
4. System main content block (though, note that all page displays end up in this block)
5. System "Powered by Drupal" block
6. User login block

An interesting thing about several of these is that the block derivatives in the current patch are filling the role of Views' arguments.

update

Comments Admin
http://drupal.org/project/better_comments_admin

If #1874534: Introduce a dblog / watchdog views integration will be implemented, than there will be another place for views: reports/dblog.

#6 possible cross over with #1823608: Admin views in core and related.

what criteria makes a listing a good candidate for converting to views?

I'm guessing admin/structure/taxonomy would need to stay custom, but it's just a guess.

YesCT: A good candidate for Views, IMO, is:

"Can it be replicated more or less as-is without loss of functionality by a View, without writing additional use-case-specific Views plugins?"

If yes, make it a View.

If no: "Can a generically-useful Views plugin be written such that the first question becomes true?"

If yes, write that plugin and make it a View.

If no, do not make it a View.

Also. search result listings, see catch's comment here #702940-45: Make the number of results per page configurable

Given #10 what about node comments? Among the rest, this would make #1807322: Filter comments taking into account the current content language not necessary.

plach: That probably would require an in-core hierarchical/nesting style plugin, and for SCOTCH to complete so that it can be "just a block" (that is, a View). If someone were to write that, it would be kinda awesome. :-) (That falls into category 2 from comment 10.)

Yep, exactly :)

I guess this would be feature, or would it fall into the conversion umbrella?

The modules/extend page!

Updated issue summary.

...adding related issues from the issue summary of #1864980: [meta] Figure out how to integrate Views into core

Permissions administration

Neither of those would be able to be listed by views. Unless you write a new query backend.

I know :/ ...

As I said in #1868444-28: Introduce tags[] in module.info.yml file to categorize modules by provided functionality. , we'd first need some way to convert modules to entities (parse the actual modules from the file system and auto-create corresponding entities that are listed in that page).

Also the brand new "Add block" page (/admin/structure/block/list/block_plugin_ui:[theme]/add) and the "Custom block types" page (/admin/structure/custom-blocks).

Added #1938062: Convert the recent_comments block to a view.

Added also #1938096: Convert the node comments list to a view

@dawehner, #21:

Please try to keep this issue on focus. ...

I missed the fact that #430886: Make all blocks fieldable entities got kicked to D9 back in December. So, yeah academic I guess for D8. Or perhaps pave the way ;)

Updated issue summary.

Related: #113344: Taxonomy term manager view.

Updated issue summary.

added https://drupal.org/node/1984588

Updated issue summary.

Updated issue summary.

Added #1986606: Convert the comments administration screen to a view

Added link to 1986606

Added comments admin link under administrative listings.

Updated issue summary.

This is just an FYI. I started working on the blocks in preparation for tomorrow's sprint. What I've started are:

• Forum "Active forum topics" block (ActiveBlock) (Would probably need forum data integration for {forum_index} to avoid potential performance regressions)
• Forum "New forum topics" block (NewBlock) (as above)
• Node "Recent content" block (RecentBlock)
• User "Who's new" block (UserNewBlock)
• User "Who's online" block (UserOnlineBlock)

I didn't see any issues where blocks were being worked on, so if there is one or more, please point me to them.

Related: #2005166: Create simple file listing under admin/content/file

Shouldn't the Node "Recent content" block (RecentBlock) block display be part of this view: #1895160: Convert admin/content to a View, keep a non-views fallback with no bulk operations?

The More link at the bottom of the block is a link to admin/content.

@oadaeh, sounds like a great followup issue to add the additional display. :)

Add aggregator conversion issue

@oadaeh, do you have issues for any of the items you list in #29?

After recreating the "Recent content" view (for the second time), I'm having second thoughts about whether it should be part of #1895160: Convert admin/content to a View, keep a non-views fallback with no bulk operations because I had to override every section to get all the settings correct. (Well, every section except for Header, Footer, and No results behavior.)

Sorry for the delay. Here they are:

• "Active forum topics" block: #2020387: Convert "Active forum topics" block to a View
• "New forum topics" block: #2020391: Convert "New forum topics" block to a View
• "Recent content" block: #2020393: Convert "Recent content" block to a View
• User "Who's new" block: #2020395: Convert "Who's new" block to a View
• User "Who's online" block: #2020399: Convert "Who's online" block to a View

I will update the summary.

Updated issue summary.

Also see #1941830: Convert tracker listings to a view.

Add newly created block issues.

Updated issue summary.

...added #2005166 to the list of related issues.

...added #1874534 and rearranged issues chronologically also fixed a minor typo.

Added #2083717: Convert Search Results to Views

Added search module to the list

Would it be possible to make forums/forum_list's into table views?

I don't think we have the views integration, but it would be worth a shot

Ok, will take a look

These conversions are not release-blocking, but they are an important part of the win of VDC, and it would be desirable to have many of them available by beta 1. I have vague memories of discussing this with @dawehner previously and him having some concerns, but I've forgotten now how it went. :)

FYI, I think we've decided to "won't fix" the idea of making search results pages into Views. With #1853536: Reintroduce Views integration for search.module (not supporting backlinks view) people will have the ability to make views with search keywords as the filter (that needs a review, hint hint!) but I think we've decided that the search results page itself is not going to be converted to a view.

I am posting this here rather than updating the issue summary in case it merits further discussion, which I suppose should perhaps happen on the issue itself? (#2083717: Convert Search Results to Views)

#2015149: Replace dblog recent log entries with a view

Shouldn't the custom block library listing also be converted to a view?
/admin/structure/block/block-content

Yes, but we need views integration for block content first, which would be a feature at this stage

Yes, but we need views integration for block content first, which would be a feature at this stage

Is there a discussion where that was decided? IMO, a content entity type that has non-ephemeral storage, but cannot be queried by Views, is a bug.

Here we go #2375589: Convert custom block library page to views.

doing https://www.drupal.org/contributor-tasks/update-allowed-beta
evaluating for https://www.drupal.org/contribute/core/beta-changes
using Drupal 8 beta phase evaluation template https://www.drupal.org/node/2373483

it is not an "unfrozen" only change. it is not on the "priority" list... although maybe "reduce fragility"... I need some help thinking about fragility.

I need some help describing its disruption:
Will it be disruptive for core/contributed and custom modules/themes because it will require a BC break/deprecation/internal refactoring/widespread changes... ?

updated the issue summary. please make any corrections there (and add a comment as to why).

I think then, we can make a similar update on open child issues saying they can proceed as part of this.

Shortcut ShortcutsBlock? (Would require shortcut intergation)

Created #2502151: Convert shortcut block to view

This issue was marked as a beta target for the 8.0.x beta, but is not applicable as an 8.1.x beta target, so untagging.

As disruptive changes and feature additions, these would go into 8.2.x at this point.

We should also reflect a naming standard views entities lists. For example I work on "form_mode_manager" now and I have to add a button " LocalAction " on a number of entities . My main problem is really the parameter " APPEAR ON " because I have here "guess" the name of entities listings depending on the entity or I add my local actions. When we use the listings of entities we had a common element

'appears_on' => ["entity.{$entity_type_id}.collection"];

In order to identify the list in question and with his views we have nothing in common ... eg : node = > ' system.admin_content ' media = > ' view.media.media_page_list ... Can we discuss of it here or from right thing? what are your opinions ?

I fully support this initiative ! goal we just need a naming rule I think.

Hi @dawehner,

Thank for your response, sorry for delay but I've focused all my efforts on Media last time. But i restart the developements about form mode / entities now and i 've created issue #2838944: Content entities overviews list standard.

I created too these issue #2838938: Taxonomy term overview with strong links with these issue because Taxonomy term overview need do appear in this issue to change with view overview page.

I'am okay to help my best in this efforts

1.) Convert /admin/reports/fields to a view to change some aspects like the number of shown items per page or to filter and sort for certain things, etc. Therefore we need access to a listing type: fields.

2.) We can reach content type already in node views, but I would also vote for getting content type description. This would make it possible to show aggregated content type glossaries with count of entries and some nice description of the content type or we can even replace /node/add with a custom view.

#65: That's #2959299: Add exposed filters and sorts to field list report I believe. Added to the list.

Adding a new idea to #2999938: Replace content translation table with a view

What about /admin/structure/views? This could be a view and then people could customise it, for example see #2929931: Show view tags on administrative list of views. Shall I create an issue for it? It looks like we don't currently support a view of views, so it's probably a little tricky.

We don't support views of config entities, so without https://www.drupal.org/project/efq_views in core there is no point in creating such an issue.