Suppose most of them will migrate in core.

CommentFileSizeAuthor
#5 d8.admin-views.patch62.07 KBdamiankloip
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

sun’s picture

Title: Drupal 8 - Admin views » Admin views in core
Project: Administration Views » Drupal core
Version: 7.x-1.x-dev » 8.x-dev
Component: Code » views.module
Assigned: Unassigned » dawehner
Issue tags: +VDC

Good question.

Do we have a battle plan for this? :)

Mind you, one of the remaining challenges in admin_views was and still is that plugins configured for views are not able to define "dependencies."

The prime example of such a use-case, the admin/content/node view, is actually dynamically enhanced by Language module in Drupal core, if it is installed.

That's impossible to do with Views currently, since the configuration of a view without enabled Language module cannot contain the Language field + filter + whatnot, since Views throws a "missing plugin/handler" error otherwise.

However, what this really asks for is multidimensional, dynamic extensibility of views. I.e., if module X is enabled, it should be able to "enhance" the admin view of Y. But, the site admin should still be able to edit/override that view.

I almost wonder whether such, built-in views should be config in the first place, or whether they shouldn't actually be "defined in code." (introducing a completely new and true meaning of that phrase, not the Features/CTools-export fake-meaning)

dawehner’s picture

Just commented on the vbo issue: #1823574: [Meta] Improve the Views Bulk Operations (VBOs) that are in core

The question which is opened up here is, whether extending views horizontally should be a "proper api" or just a bunch of alter hooks.
Together with this comes the question, what happens if you have deployed a view and your next deployment step would be to disable the language module. Should the view automatically change it's behavior or is it the task of the site builder to take care of module changes and views dependencies (which could be supported by some additional tools).

The easy solution at the moment would be to use hook_views_load and put your stuff in, as needed. Do you consider this as a useable workaround? Sadly it seems to be no way to distinct between something which is provided by a module, and something which got changed by
the site builder (i'm pretty sure there are CMI issues for that).

I almost wonder whether such, built-in views should be config in the first place, or whether they shouldn't actually be "defined in code." (introducing a completely new and true meaning of that phrase, not the Features/CTools-export fake-meaning)

Views in D7 had an interesting approach to provide default views, without lousing the intial default views: Templates.
A template for example was a calendar view which just could be cloned, not enabled, which then could work together with hook_views_load.

damiankloip’s picture

I would really like to see admin views make it in, but agree with sun, we need some way to negotiate what we do with various module dependencies.

@dawehner, this could work but would we be allowed to do something like this? I'm not sure :)

Maybe handlers should also store their implementing modules?

Although, I think this issue is almost pointless at the moment, as there is a much bigger issue by the name of VBO. I don't even see much use in entertaining this idea until VBO shows signs of moving towards core.

People should be concentrating on that first, is basically what I'm saying :)

damiankloip’s picture

Assigned: dawehner » damiankloip

Ok, I think I agree with what sun and Daniel are saying in the VBO issue. It makes sense to atleast convert these listings. So we will indeed have superior listing pages. Vbo can, maybe should, come after that.

Assigning to me, I will work on his on the plane I'm about to board.

damiankloip’s picture

Assigned: damiankloip » Unassigned
Status: Active » Needs review
FileSize
62.07 KB

Ok, partly my fault, but this issue has kind of come to a halt..

Here is an initial patch to get things moving; It adds ported admin views from the D7 version and removal of the menu callbacks that they replace. I haven't ripped anything else out of node, user, or comment modules.

This is a definite 'needs work' but just want people to see it.

Status: Needs review » Needs work
Issue tags: -VDC

The last submitted patch, d8.admin-views.patch, failed testing.

damiankloip’s picture

Status: Needs work » Needs review

#5: d8.admin-views.patch queued for re-testing.

Status: Needs review » Needs work
Issue tags: +VDC

The last submitted patch, d8.admin-views.patch, failed testing.

sun’s picture

I think that converting those views is the trivial part — but we need to solve the primary problem in #1 first.

Namely, how can Language module dynamically add a field + filter + exposed filter to e.g. the admin/content view when it is enabled?

All plugins that it adds would also have to be disabled/removed when Language module is disabled. (And re-added/enabled when it is re-enabled.)

With views in config, that appears to be barely possible AFAICS:

  1. Language module would have to implement hook_enable() and hook_disable() to load + programmatically change + save a range of default views in core to add and remove its stuff when necessary.
  2. That, of course, will fail, as soon as any of the views has been customized/overridden.
  3. It would also required all machine names of all (admin) views to be locked/unchangeable.
  4. And lastly, it won't work for all entity views that should be language-aware, because Language module has no way to discover/determine them.

I guess it would be slightly more possible if the config for each views plugin was stored in a separate config object — so when Language module was enabled, it would add views.view.foobar...field.language (+ filter + etc) config objects to affected views, and if it was disabled, those plugin configurations would be disabled (without triggering any "missing handler" warnings or log messages like now), if it was re-enabled, those would be re-enabled, and if it was uninstalled, those plugin configurations would be rm views.view.*.*.*.*.language — or similar. ;)

Overall, however, I still have my doubts whether it is a good idea to put something into config that needs to dynamically adapt and react to environment changes. This smells more like "in-code" material to me, and perhaps the right architectural answer would rather be to introduce a way to build and execute a view (from scratch) via code (which I'd envision to work similar to EFQ).

What do you think?

moshe weitzman’s picture

Building a View from scratch sounds fine to me. Not sure it is up to this task, but the Context system was invented exactly for dynamic adapting of config at runtime for language and such. See #1646580: Implement Config Events and Listeners, and storage realms for localized configuration and improvements at #1763640: Introduce config context to make original config and different overrides accessible.

xjm’s picture

YesCT’s picture

#1279624: Add translation filter to content listing admin page is related, especially to @sun 's comments in #1

xjm’s picture

Title: Admin views in core » [meta] Admin views in core
Status: Needs work » Active

Repurposing this as a meta, since we'll be converting the listings one at a time.

xjm’s picture

Title: [meta] Admin views in core » Admin views in core
Status: Active » Closed (duplicate)

Actually, let's just centralize discussion at #1823450: [Meta] Convert core listings to Views since most of what's here is out of date.

sun’s picture

Category: feature » task
Status: Closed (duplicate) » Active

This is more than a placeholder/meta, and none of the essential discussion here is covered over there.

We still need to resolve these challenges in order to convert administrative listings to views.

tkoleary’s picture

mgifford’s picture

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

kenorb’s picture

Status: Active » Needs work
xjm’s picture

Status: Needs work » Closed (duplicate)

Really closing this; this issue is many years out of date and no longer relevant.