Port Views Bulk Operations to Drupal 8

Now, after feature freeze, is this gonna happen to be in core? What's the status?

Or, if not, will there be a dev-version to start with? D8 code freeze in aprox. 5 weeks.

VBO in D7 is several things:
1) A views field that provides the selector (the checkboxes that allow you to select items and execute an operation on them, and to configure which operations are enabled in the views backend)
2) A plugin based abstraction over the actions api and rules, allowing an easy way to use and execute operations.
3) Batching and queueing allowing a large number of items to be processed.
4) Several custom actions

#1 is already in D8 core.
#2 (in a much better shape than VBO ever had) is arriving to D8 core through #1846172: Replace the actions API

Once the new actions api lands in core, we can continue to improve the actions bundled with core (removing the need for at least some that ship with VBO, such as "delete entity"), and investigate enabling batching (since Batch API is already in drupal core and it's just a matter of connecting the dots).

So, to summarize: "VBO in core" has happened and is still happening.
I am not yet sure whether we'll need a 8.x branch of the module, and what would be in it, we'll know that after code freeze.

@bojanz

Which UI cuurently exposes this functionality? I want to test it for usability.

-Kevin

Right now the action.module, and its pretty useless.

Very soon, it will be much more improved:
#1846172: Replace the actions API
#1895160: Convert admin/content to a View, keep a non-views fallback with no bulk operations
#1851086: Replace admin/people with a View

I have posted this prototype in a couple of other places. http://invis.io/BSF5E6MF

The more I explore this the more It seems like this really requires a meta, meta issue one level above current meta issues because it touches several areas that really need to be unified.

Seems like this was handled a while ago. Closing up this issue.

No it wasn't.

VBO will need a D8 port because D8's "simple VBO" doesn't support configuring actions before execution (nor queueing, batching, etc)

Ahh, okay I didn't realize that @bojanz, thanks for the clarification. I haven't been able to turn up issues for those items in the D8 queue, which makes sense if they're going to be handled in contrib in D8. Sorry for the trouble!

"modify entity values" is very useful as well and needs to be ported

I picked up work on this. As core is currently frozen I started it as port of views_bulk_operations module.

A first prototype of this can be found here: https://bitbucket.org/oechsler/vbo/
I'm still unsure on some architectural questions. Especially injecting the whole container to ContainerAction feels odd. Advice on this is very welcome.

g.oechsler

Great! If it's going to be in contrib we have more flexibility in libraries that we use to implement this. I suggest we use select2 which would enable several interesting possibilities in the UI.

@g.oechsler, repository seems to be closed to the public.

Oops, you are right! Fixed.

Great! If it's going to be in contrib we have more flexibility in libraries that we use to implement this. I suggest we use select2 which would enable several interesting possibilities in the UI.

I would personally suggest to port the module code and then improve things but keep the amount of changes small at the beginning.
There are enough battles to fight already.

Hello,

I was just curious to see if there was any movement on getting the module on bitbucket hosted on DO or what the status was with the port? D8 core seems to have some functionality that VBO has but not all, so it would be nice to have this module handy in the near future. Thanks in advance.

One more related core issue

@tkoleary: About the select2 usage in this project. I think select2 is an amazing improvement on UI for selects but I don't think it should be encapsulated here for sure. It should leverage the select2 module that is available her, although no d8 version. However, looking at that project there seems to me that the current implementation of that project is missing some of what I would expect from it. Namely a new field type people could use called select2. But this is a bit of a digression away from the topic at hand so I will stop that here.

A D8 version of VBO should likely be simplified considerably due to the additions to/changes in core. The most important feature I see missing is modifying entity fields through bulk form actions. Correct me if I am wrong, but having this project add that option alone into the available actions of "Content: Node operations bulk form" and similar views fields would complete a lot of the features that are expected from this module. I think that would simplify a first release for the D8 version even. Then tackling batch api integration could be next release I would think.

BTW, I do very much like the UI that tkoleary posted in #5 especially since it could avoid the issue of the simple vbo actions in core not having multiple steps.

Just wondered..

We have ActionBase::executeMultiple.

A batch operation can be easily added there. Core could also be extended with some batch method for action execution.

However, it'd be nice to have good old VBO with access to selected view rows, not pure entities.

What about the "Select all" feature. Is there some core issue about it? "Select all" was one of the major features of the module imho, and is missing so far.

Generally speaking, is there a core component, issue tag or something for vbo related issues?

@fago I think this is the relevant issue thread #1823574: [Meta] Improve the Views Bulk Operations (VBOs) that are in core
but as it says at the end of it the issues are scattered through views feature requests

Hi everyone,

I played around a little bit and ported the bare bones "Select All in this View" functionality over to Drupal 8!
The patch can be found over at this Issue.

https://www.drupal.org/node/2603820

Could someone summarize the D8 deficiencies with VBO in core that we can attempt to solve here so that we can look at how to move forward here? Please add them to the issue summary and feel free to take from the comments above.

Once we have a decent list we can prioritize a MVP, create a branch and start working on it.

+1 to Joel's request. My comment in #2 has the initial info.
Most VBO features were never added to core.
The two primary missing features are batching, and the ability to configure an action after selecting the rows.
It would also be nice if every action didn't have to reinvent its own confirmation screen.

here is a module that might be doing something similar in drupal 8
https://www.drupal.org/project/views_bulk_edit

There might be some hard complications with batching in D8: https://www.drupal.org/node/2701829

I started working on the module, there are some serious problems with implementing batching due to https://www.drupal.org/node/2849674 (All current core VBO batch execution issues point to this one, one workaround I tried -> executing batch from views row plugin form - also causes same problem to emerge).

• Batching is implemented using workaround described in https://tech.smartling.com/how-to-overcome-the-limitations-of-the-vbo-mo..., when the core bug is fixed this can easily be switched to a method without an extra redirect.
• AJAX callback on Views field plugin viewsForm method causes error:
  Warning: html_entity_decode() expects parameter 1 to be string, array given in Drupal\Component\Utility\Html::decodeEntities() (line 383 of ore/lib/Drupal/Component/Utility/Html.php) This prevents smooth implementation of action configuration - it needs to be done on a separate page. Also Implemented.

Next step: All items selector.

My dev code: https://www.drupal.org/sandbox/graber/2862860

Issue update:

• As from Drupal 8.3 the AJAX error on view form is not an issue anymore, so action config form is a part of this form now.
• Select all results on all pages implemented as a simple checkbox (no JS or styling yet)
• Changed the roadmap a bit (sandbox description updated)

Graber I looked over this today and it is starting to look really nice. I would suggest this become the 8.x branch after it has a couple passing tests on it. Thank you! VBO is the best, cheers.

Yes, please make an 8.x branch! I want this so bad.

Thanks for support guys, this issue progress is very slow, probably it'll take a lot more time before the branch is actually created. Before it happens I'll continue working on my sandbox and single issues can also be created there.

Checked out the sandbox, and it's looking good.

However it doesn't seem to work with my configurable action - I don't get the opportunity to configure it. A brief look at the code suggests that it does try to pull the configuration form from the action so I guess I'm doing something wrong.

Re configurable actions in #38 - if I have multiple actions I see the configuration options when I switch from one to another, but if I only have one action that update never happens.

What would be the proper way for the Action to get context of the view? I.e. my view is listing entities referenced by a given node, how do I find that node? I see I can probably scrape it from $form_state if the action is configurable, but wondering if there is a clean way to do it.

@skitten

#38, #39 I'll fix this one probably still today, I didn't take default value into account when $form_state has no values yet.
#40 Optionally passing view results to the action still needs to be implemented (check roadmap), I can also pass other params of the view, but I think the best way of getting that backreference, is to run EntityQuery and query for the referenced field value in the action itself.

Next time please just create issues on the sandbox project (https://www.drupal.org/node/add/project-issue/2862860), it'll be easier to keep track of them.

Thanks,
Graber

I've grabbed @Graber's port, renamed the files/namespaces/etc from vbo to views_bulk_operations, ran PHP CodeSniffer on it to fix some coding standards things and pushed it.

I've added @Graber as a co-maintainer to help with this effort.

This issue is now a planning issue and we can create child issues off this to help get this to an alpha release.

Thanks @joelpittet, updated the original sandbox and this issue description so there is no confusion. All access OK, time for some more development :)

Updated description.

There may still be some functional changes to the module, but I think it's slowly reaching a more stable version that can assure backwards-compatibility for other modules.

Also created 2.x version of VBO Export that uses the new Views Bulk Operations module.

If anyone has time for some code review or testing, much appreciated, pls use the issue queue.

Alpha release planned next week. I can say that the API is stable since at least a month and the dev release is used on over 150 sites so it's time.

Beta released. I think this can be closed soon due to lack of activity.

Congratulations, thank you for hammering out this important module up to beta!!

I am using beta-2 and it works like a charm. I suppose the module is ported successfully and this issue can be closed as fixed soon.

The API is stable since alpha1, at the moment there is one extension planned (requierments['_custom_access'] as in routes) and a few UX improvements. Big thanks to everyone that help with the issues!

At first I wanted to skip beta and tag an RC, but I read the Release naming conventions and decided to take the full path. In general - yes, probably I'm too carefull. :+1:

Let's have an rc1 next week and hopefully a stable the week after if nothing unexpected happens. Setting this to fixed, 5 years is long enough.

An incident just happened with views_bulk_edit: a critical that may lead to serious data loss that was there all the time, even if the module was on 500+ sites (thanks for finding it @devad). It's sad but Drupal developers are busy people and in many cases just don't find time to report a bug here, I heard that personally a few times. I don't want anything like this to happen on a stable VBO release (it may happen anyway but with a bit more time odds are much lower).

For that reason, I think it'll be better to get back to my original plan, chill out and have a stable by the end of 2017, leaving 1.5 month for additional testing.

Strange to see this issue as Fixed while there is no Stable release of the port. Expect a plan to cover all phases till and including a Stable release.
Refrained from changing this issue due to strange reactions in the past, also it might be my poor understanding of the issue management in this project. Sounds like a Needs work to me.

Thank you for your efforts, Graber.

@mmjvb
Please refrain from giving prescriptive advice to module maintainers in their own queues. Everyone has their own management style.
For example, I usually keep the "Port to D8" issue open only until an initially functional (pre-alpha) port lands,

@bojanz Thank you for your unexpected respons. Anticipated a reply from either Graber or Webchick. You made it clear that "Port to D8" doesn't have the same meaning for everybody. Don't understand where this is coming from:

Please refrain from giving prescriptive advice to module maintainers in their own queues. Everyone has their own management style.

Even after translation I don't know how to react.

@Graber When you left the issue intentionally as Fixed, that is ok. Figured that you might have overlooked that when deciding for a Stable release at the end of 2017. Assuming it is intentionally, that leaves a gap for the roadmap for Alpha to Stable. Is there a plan for that?
Maybe https://www.drupal.org/node/2574777 is more appropriate to continue that discussion.

EDIT: @Graber, apologize for getting your name wrong. Corrected it as soon as I noticed it, hoping I was on time. Overlooked the first occurrence, corrected now.

The thing is times are hot and I think every employer has a lot of work for developers at the end of year, so no, there is no plan and there will be no plan. The only important thing is to get as much testing as possible from everyone that is using the module to make sure there are no serious bugs. Also I'd like to have #2921769 and the one that'd be nice to have for it: #2922953 in the RC. @mmjvb if you'd like to help, you can do some testing. Also please check the spelling of my name in your last comment and correct it, it looks kind of funny :)

Sorry to say that I don't feel comfortable to contribute to this module. Restricting my contributions to the forum and much needed, in my opinion, pm work in D8CPT. Too bad that communicating a roadmap is not a priority.

Again, apologize for misspelling your name, hate when I make mistakes like that. But, appreciate it to be corrected.

No problem. I created a plan issue after all even if this means extra work for me and PM is not my specialty. There are chances it'll be useful, low but still.

Ref to plan is #2926402: Plan for 8.x-1.0-rc1