I can sum up this feature request in a picture:

A screenshot of the find content page

This page is absolutely central to the lives of content authors (aka "victims" of Drupal), and yet it is utterly horrible and useless.

1) Despite the Shortcut's false advertising, there is not, in fact, any way to actually "Find content" from this page. It would more adequately be called "Pray that whatever content you're looking for is pretty recent, otherwise you are screwed." But that's a little long for a Shortcut name.
2) The filtering options are extremely sub-par. Want to find content by author? BZZZT. Sorry. Not going to happen.
3) The fields themselves are also useless. In many cases you want to view, say, an excerpt of the content in question, or a thumbnail of the product image, or what have you. Tough luck, sucker. Those fields are hard-coded and they're not getting any better.

(There are other examples of further uselessness of hard-coded admin overview pages, as well; the user listing at admin/people that doesn't allow you to search by e-mail or real name, for example.)

With Views now in core, one might think they can rejoice, and bask in an angelic glow of possibilities. Except BZZZT. No, you can't. Why? Because there's no way to perform bulk operations on your content, so we're going to have to leave this crappy, horrible page in for Yet Another Release...


Proposed resolution

Port Views Bulk Operations module to Drupal 8, and put it in core. :D

Remaining tasks

There are some blockers to this (bojanz had some thoughts), which I know include at least the following:

#1823572: Port Views Bulk Operations to Drupal 8
#1823570: Convert Actions to Plugins
#1788104: Convert actions to plugin sub-system
#1088048: Add ability to schedule actions

So... please? :)

#1 vbo_kind_of.jpg51.45 KBandypost
vbo-plz.png61.85 KBwebchick
Members fund testing for the Drupal project. Drupal Association Learn more


andypost’s picture

51.45 KB

Actions + admin_views should cover 3/5 of core admin screens, other forms (inputs)

vbo plugin also has some UI and actions got config


dawehner’s picture

Issue tags: +VDC

It would be absolute phenomenal to have VBO part of views.

When i last talked with bojanz about this, he mentioned the requirement for a proper action api for core to be able to
integrate both core actions and rules at the same time. I fear that this will not happen. Maybe related #1788104: Convert actions to plugin sub-system

Maybe there will be time on badcamp to discuss that.

The shortcut set can still be defined by a manual hook_menu entry, so that's not a problem.

For the edit dropdown, there has been an issue in d7 #1608920: Add drop-button field display which should not be a problem to port to d8.

bojanz’s picture

I have no problem with starting work on this patch right away.

1) Most of the actual VBO integration with Views is in the Views Form API which is already in core. However, that API is implemented in an awkward way on the Views side, so we should definitely re-evaluate it and see how it should be extended / refactored (which will in turn, affect VBO).
This is a topic that can be attacked during the upcoming Views sprint.

2) VBO in D7 has an abstraction layer for Rules and core actions.
We finally dropped support for hook_node_operations() and hook_user_operations().
Obviously, that abstraction layer can't go into core.

If we want VBO to continue to be useful for contrib in D8, we need to make sure that the core Actions API is not useless out of the box (like it is right now :P).
This is something I personally consider a priority regardless of VBO, so I wouldn't block VBO on it (but attack it in parallel).

3) chx has plans for improving the way batch api works (in regards to the queueing), which could reduce the amount of work VBO needs to do.
This is also not something that should affect the VBO patch, just noting it.

So, the only question is do we want to attack #1 before rolling the first patch.

dawehner’s picture

Remember, our goal is to get features for the users by default.

When i started to just port VBO to d8 i realized that there is a lot code
which might could be left out in the initial patch and extended/cleaned up later.

  • Aggregation of the items
  • Maybe batch handling
  • Maybe the fancy JS / Doing both select and buttons as selection
  • Probably/Hopefully the actions permissions api
  • As bojanz already told, the abstraction between Rules and Actions

Which of these features do you think are so fundamental, that it can't be dropped.

I think for most people using VBO in core should "just" be able to replace the admin listings.

Bojhan’s picture

Here to work on any UI facing part when needed.

andypost’s picture

For entities now we have listController with operations, so views could reuse this. I thing we can extend this operations with some kind of flags(attributes) to indicate operations/actions that available as mass (works with a ID-set as argument)

Cause we have no trigger in core but have CRUD events for each entity (via EntityNG per typed property) suppose new rules will care about that

damiankloip’s picture

Not too sure if the ListController would help out VBO here to be honest; The view listing uses this controller, so it's really a different type of thing.

webchick’s picture

YAY! People! Saying stuff! :D

2) VBO in D7 has an abstraction layer for Rules and core actions.
We finally dropped support for hook_node_operations() and hook_user_operations().
Obviously, that abstraction layer can't go into core.

While I agree with not putting any Rules-based assumptions into core (unless Rules itself moves into core), I have always flagrantly despised hook_node_operations() and hook_user_operations() and wouldn't object at all to a generic "hook_entity_operations()" or whatever. Does dropbutton being in core make this easier now by chance?

I can't speak to #3.1, as I have no idea how much work it is or how much it would block other things. Probably indeed best to tackle that question during the VDC sprint.

sun’s picture

  1. First of all, I think we need to clearly separate this from #1823608: Admin views in core. History with admin_views module shows that there is actually no interdependency between these two feature requests. To whit, admin_views actually contains an unfinished + hidden feature to take over the taxonomy vocabulary + term admin views, and those do not contain bulk operations.

    Turning the administrative listing pages into views (table style plugin) results in a shittonne of completely independent usability improvements: Proper filters, realtime Ajax filtering, dynamic arguments, "customizability", Ajax pagers, and did I mention realtime Ajax filtering yet?

    From a usability and technical perspective, this has to be clearly differentiated. They have completely different requirements and technical challenges.

    Also, if someone would ask me this today:

    Hey sun, we are going to release Drupal tomorrow.

    We could add a lot of usability to all of Drupal's administrative views, but we would have to drop bulk operations entirely, without replacement; contrib would have to add that back.

    What do you think we should do?

    My answer would be crystal clear: Do it.

    That is, because the current architecture of those bulk operations are horribly poor anyway, we have long-standing major bugs in the queue dating back to 2005, and no one, literally no one, cared for these anti-APIs in the past years. From a feature perspective, there is factually nothing to lose (Did you ever try to use this?). From a technical perspective, neither — the entire hook_XYZ_operations() crap was tacked on for some modules (but not for all), is horribly inconsistent, full of bugs and pitfalls, is completely unable to cope with more sophisticated entity access mechanisms, and is a pain to interact with if you're not the module that is owning/exposing the hook (Mollom module "allowed" me to perform plenty of hours of head-desking in this area).

    So. Yes, my answer would be crystal clear: Let's remove a shitload of code that does not work in the first place, in favor of significant usability improvements that will allow you to actually perform content management.

    Due to this, I'd like to encourage everyone to work on #1823608: Admin views in core in parallel. This definitely does not mean "No VBO" (if you assume that, then you misinterpreted the above, or you didn't read it). Instead, it means "given the tools at hand, and ignoring history, what is the best experience we can deliver today ?"

  2. I'm not up to speed with Views' actual current entity listing implementation. Do we load full entities or are we loading individual fields of queried entities?

    I'm relatively sure that a generic actions/operations approach based on the entity system (including entity access checks) would require full entities to be loaded and handled by views/VBO.

  3. #1608878: Add CTools dropbutton to core did not really improve any part of the situation here.

    It only led to the introduction of a EntityListController, but my personal interpretation always has been that Views would actually NOT be an EntityListController implementation. That is, because Views actually produces infinite amounts of "entity lists" in infinite variations, whereas an EntityListController only exists once, and only once. There potentially could be a views_entity_info_alter() that injects a particular view + display for a particular entity type, so as to use that as default list controller. But aside from that, the concepts do not really match up from my perspective.

  4. The introduction of EntityListController added a rather inconsistent notion of "operations" being defined for an entity, but only within the list controller. We already discussed in the Dropbuttons issue that there's massive room for improvements there.

    Likewise, EntityFormControllers are sorta duplicating that information already in EntityFormController::actions(). Those are defined on their own, and completely detached from the operations in EntityListController.

    That, on top of hook_node_operations() and hook_comment_operations() and all the other anti-APIs.

    Lastly, #1008166: Actions should be a module landed very recently, which moved the actions facility from System module into a standalone Actions module. The primary entity modules, Node and Comment, actually implement a dozen of entity actions actions, each, which are, again, completely detached from entity list operations and entity form actions.

  5. If we didn't aim for administrative Views views, then we are actually talking about tables that are enhanced by the tableselect/select-all JS library facility. Edge module contains a new #type 'table' since 2010:
    #991454: Add element #type table (with tableselect and tabledrag support)

    Moving that into core for D8 is on my personal top priority task list, regardless of whether we are going to switch to administrative Views views or not, since that facility has a gazillion of other use-cases in core, contrib, and the real world. The corresponding core issue is:
    #80855: Add element #type table and merge tableselect/tabledrag into it

    This is relevant, because:

    • Current EntityListControllers could leverage this very easily.
    • If Views' table style plugin was using core's #theme/#type 'table' (apparently it doesn't), then it could leverage this, too.
  6. On the scope of VBO in core: KISS. The 80+% use-case only.

    That would be the views field (of 3.x if that's still relevant), and the enhanced table style plugin. Nothing else; all the rest has to be implemented in a more sophisticated way within core, as alluded to earlier (entity access, entity actions/operations, etc).

sun’s picture

Issue summary: View changes


dawehner’s picture

  1. I totally agree that we should seperate the listing of entities itself with admin_views from the VBO part.
    It seems to be, at least for me, that most things which are done is finding single content entries you want to edit/publish/delete.
    The multiple part itself is used on either really big sites, or on sites which has spam, mostly comments.
  2. Views does not implement the entity listing interface, but it already loads all entities involved, because it's needed for a lot of things. When the entity listing interface was started it was just for configuration entities, which at least now, have no views integration so that's where the concepts don't overlap.
  3. If views would implement this interface, we would probably end up with just calling views functions at the end, and so don't gain anything from that.
  4. To gain the maximum amount of freedom for the user, the actions available for the entity type could be directly used by views to produce a dropbutton but also one individual link per action, so the sitebuilder could choose.

    Together with the entity property api this would be a huge step towards a really generic/automatic integration.

  5. It would be great to have #type 'table' in and at the same time use the core api for rendering tables. I have to ask earl why it was done that way in the first place, but you could assume both easier theming and missing features in theme_table.
  6. We started (@daminankloip) to port VBO to drupal8 as it is, to understand what is really fundamental and required for the 80%
    and at the same time improve the api to implement things in a clean way. In #1823574-4: [Meta] Improve the Views Bulk Operations (VBOs) that are in core i tried to reduce the features which should go in.
ParisLiakos’s picture

bojanz’s picture

Assigned: Unassigned » bojanz

I'm working on the last big VBO 7.x change to batching & queueing in #1367644: Batch the selecting of all ids on all pages, clean up execution types..
When that lands (next 24h), I will open a D8 branch and merge in the porting work done by the VDC team, then remove things that shouldn't go into core.

And yes, many parts of VBO should not approach core. Off the top of my head:
1) Aggregate actions (doesn't allow batching to be used, conflicts with #2)
2) "Select all items on all pages" (This is something people find very useful, but will need further review so it's followup material.)
3) Action permissions
4) Custom VBO actions (though core should get an action for deleting entities at one point ;))
5) Rules and Drush integration (Duh)

That kills half of the current VBO code :)
What remains and needs to be in the patch is the views field + multistep form + the batch code (without which VBO has very little point).

I will keep the operation plugin type (that unifies actions and rules) until core gets a decent Action API.
So if that doesn't happen, contrib can still fill in the need.

sun’s picture

@bojanz: That sounds like an excellent plan. Looking forward to the core commit. :)

sun’s picture

Apparently, in my epic list in #9, I forgot about contextual links, which is yet another, separate API for which you have to specify available operations separately.

dawehner’s picture

To keep it as simple as possible we started to write one which just integrates the actions: #1828410: Provide a bulk_form element for actions

yoroy’s picture

What remains and needs to be in the patch is the views field + multistep form + the batch code

I can also work on UI for this where needed, this is definately killer end-user feature material.

bojanz’s picture

Status: Active » Closed (won't fix)
Issue tags: -VDC

#1828410: Provide a bulk_form element for actions is now RTBC.

It doesn't contain batching and most other things that the current 75k users of VBO expect, but at least we have our shiny checkbox.
I guess that's enough to start with.

See you in contrib.

sun’s picture

Assigned: bojanz » Unassigned
Status: Closed (won't fix) » Active

Yes, I totally agree there.

However, we still have 4 weeks, so I think that there's sufficient time and room, if anyone would want to advance on that bulk_form views plugin implementation. There's no reason nor need to end this issue prematurely :)

catch’s picture

Adding batch support (at least for single pages, not sure about the selecting past pages stuff) wouldn't be subject to feature freeze at all since that's a performance improvement - although it might be easier to wait for the new batch API.

YesCT’s picture

Is there a dedicated issue for the content list admin page?
#1279624: Add translation filter to content listing admin page wants to know. :)

dawehner’s picture

#1823608: Admin views in core is probably the issue to look for.

tim.plunkett’s picture

Title: Views Bulk Operations (VBO) in core » Improve the Views Bulk Operations (VBO) that is in core
Issue tags: +VDC
heddn’s picture

Title: Improve the Views Bulk Operations (VBO) that is in core » [Meta] Improve the Views Bulk Operations (VBOs) that are in core

This really seems like a meta issue. Re-titling.

tkoleary’s picture

tkoleary’s picture

Issue summary: View changes


xjm’s picture

Issue summary: View changes
Status: Active » Closed (duplicate)

This issue is extremely out of date and irrelevant with no specific goal or substeps, so closing as a duplicate of any number of admin view-related features that have gone in. File new, dedicated issues. Thanks! :)

jhedstrom’s picture

This was closed as a duplicate, but I was unable to find an issue regarding the batch support, so I've added #2844312: Batch support for processing bulk action views.

I'm also unable to find an issue regarding the setting/updating of field values in bulk, aside from some tangential issues such as #394496: Add ability to bulk update nodes with adding terms.

andypost’s picture

The proper issue for batching is #2603820: Add batch support for bulk operations