Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Suppose most of them will migrate in core.
Comment | File | Size | Author |
---|---|---|---|
#5 | d8.admin-views.patch | 62.07 KB | damiankloip |
Comments
Comment #1
sunGood 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)
Comment #2
dawehnerJust 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).
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.
Comment #3
damiankloip CreditAttribution: damiankloip commentedI 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 :)
Comment #4
damiankloip CreditAttribution: damiankloip commentedOk, 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.
Comment #5
damiankloip CreditAttribution: damiankloip commentedOk, 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.
Comment #7
damiankloip CreditAttribution: damiankloip commented#5: d8.admin-views.patch queued for re-testing.
Comment #9
sunI 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:
hook_enable()
andhook_disable()
to load + programmatically change + save a range of default views in core to add and remove its stuff when necessary.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 berm 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?
Comment #10
moshe weitzman CreditAttribution: moshe weitzman commentedBuilding 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.
Comment #11
xjmThis is part of #1864980: [meta] Figure out how to integrate Views into core.
Comment #12
YesCT CreditAttribution: YesCT commented#1279624: Add translation filter to content listing admin page is related, especially to @sun 's comments in #1
Comment #13
xjmRepurposing this as a meta, since we'll be converting the listings one at a time.
Comment #14
xjmActually, let's just centralize discussion at #1823450: [Meta] Convert core listings to Views since most of what's here is out of date.
Comment #15
sunThis 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.
Comment #16
tkoleary CreditAttribution: tkoleary commentedsee #2022297: [META] Unified toolset for Views in core
Comment #17
klonosComment #18
mgiffordComment #22
kenorb CreditAttribution: kenorb commentedComment #23
xjmReally closing this; this issue is many years out of date and no longer relevant.