Add option to mass edit entity field values

Is there any specific reason that this feature has to live in VBO, it is self-contained in Views Bulk Edit, can it not stay there as a self-contained feature? Or maybe i'm overlooking something that VBO would provide if the feature lived natively in VBO?

I think it can easily stay in views_bulk_edit, we'll just need to add information that such a feature is available in this issue and in VBO project description maybe.

As to the features, VBO offers a nice API for modules that is an extension of the core action API, I think you could save a lot of code by using it, but I'll have to check your code to actually be sure. You can check the docs to know more, especially the action configuration part.

OK well that sounds good to me. Maybe you could create a patch against VBE that shows how I would have used the new VBO API?

No problem, I'll prepare some prototype, it might also be that the changes required will be very tiny since we're actually using the same action API, only extended a bit.

Thanks!

Have you installed views_bulk_edit?

views_bulk_edit works for me thanks.

I understand that there is no technical reason that the bulk edit code needs to be in VBO. However I think there is a strong usability argument in favour of combining the code into VBO.

1. Consistency with D7. Developers coming from D7 (250,000 of them!) will expect to find the bulk edit in VBO. Having it there will avoid confusion and support requests like #8-10.
2. Save web-site admin time. Installing and updating two modules is more work for everyone than just one.

I agree with your first point because that is certainly a large audience. However, with point 2 that could be argued both ways, for example there could be features in VBO that people don't want, maybe they only need the VBE functionality.

Same here @AdamPS, 1 can be taken into consideration but if we followed your second point we'd have interfaces with a lot of unused features and a lot of unneeded overhead. That's the main reason I'd rather have it as a detached module.

@benjy, checked the code of views_bulk_edit and with VBO dependency it's code base can be significantly reduced. Also we can't keep it working with and without VBO at the same time. I'll get to it when I have a bit time.

@benjy, checked the code of views_bulk_edit and with VBO dependency it's code base can be significantly reduced. Also we can't keep it working with and without VBO at the same time. I'll get to it when I have a bit time.

If we keep it working without VBO though that won't reduce the amount of code? I'd be interested to see what a refactor to use VBO looks like, if it is significantly less code then it could definitely be worth it.

Same here @AdamPS, 1 can be taken into consideration but if we followed your second point we'd have interfaces with a lot of unused features and a lot of unneeded overhead. That's the main reason I'd rather have it as a detached module.

Fair point. I guess another option is for views_bulk_edit to be a sub-module of VBO: avoids the overhead for people who don't need it, but still keeps just one module in terms of updates. However there might be some complications migrating the existing users of views_bulk_edit.

Whatever you decide I think the key thing is to inform users. I have raised an issue to request this #2904110: Document where to find features for users moving D7->D8.

Thanks for the hard work.

Just created a feature branch with the first version of the submodule. It has quite some changes comparing to views_bulk_edit and is not that simple after all, mainly due to the need of including multiple entity types support and all view rows selection support. There also may be performance issues in case of all view rows selection unless we find a better way to get all entity bundles that are displayed by a view (without actually loading and chcking all entities).

Please review.

changes comparing to views_bulk_edit and is not that simple after all

I've not reviewed the code yet but do you think it's simple enough to justify adding a dependency on VBO? If the code benefits are negligible, it may as well live on as its own module without any dependencies.

We actually have a two ways to go:

1. Create a new version of views_bulk_edit that depends on VBO (it'd be 8.x-2.0).
2. Make it a submodule of VBO as in the 2898073-bulk-edit feature branch.

@benjy, as @AdamPS said, as long as we provide all the necessary information where to find it, everything will be ok. The real question is: Would you like to maintain the VBO-dependant 2.0 version of the module and will you have a bit time to improve my prototype (I'll help of course if I can)? If so, you can review my code and create the 2.0. Otherwise I can make it a submodule of VBO.

Thanks,
Graber

The real question is: Would you like to maintain the VBO-dependant 2.0 version of the module and will you have a bit time to improve my prototype

For me, the question still unanswered is, do we even need a version of VBE that depends on VBO at all? As I said, I've not looked at the prototype yet but the VBO prototype would need to deliver real value in terms of the amount of code and maintenance to be worth while IMO.

I wonder if there are actually two questions getting mixed up:

• As @Graber says, where should the "bulk edit" code live: 1) separate VBE or 2) VBO sub-module? This seems a matter of convenience for users and for maintainers. As a user I feel benefits of combining into VBO sub-module, especially if you agreed to be co-maintainers (always better to have more than one!). However you guys are putting in the work so up to you.
• Should the "bulk edit" code use VBO API? If it's a VBO sub-module then it seems yes, why not. If separate VBE then Benjy's argument "only if real value saving of code/maintenance".

@Benjy I feel there are two questions:
How much code simplification do you see in using VBO API? I don't feel I know enough to judge.
Do you feel a personal desire / benefit to the community to maintain a separate VBE module?

Among the added values I can point:

• All benefits of using VBO (ability to select all view results, batching, label override etc)
• Ability to modify entity field values in views that display different entity types and bundles like search_api views with no additional configuration required

Generally, VBO is already quite powerfull, will be continously improved and offers much more than the core BulkForm.

@Graber #22 aha thanks I had missed that part. So it's not just a matter of reducing code and ease of maintenance.

So the user-visible benefit is that "bulk edit" would pick up the other features of VBO (current and future enhancements). This consistency seems important and probably a requirement for some users, especially as it worked in D7 - e.g. bulk edit had batching.

You have convinced me: bulk edit should use the VBO API. That seems to leave the question you asked @benjy in #19, whether to have a sub-module or a separate VBE.

Both points in #22 are compelling reasons. I would have expected 1 to "just work" when when you enabled VBO anyway, without any kind of direct integration?

Normally I'd rather have more modules than less, but i'm not entirely against having a VBE branch that uses VBO. I know there were arguments around less to update but, you can make similar arguments about larger modules being harder to debug when things go wrong.

Performance issue solved.

About sub-module or a separate VBE issue: We can wait a bit, maybe some more people will express their opinion. If nothing new will arise for a few weeks, I'll just merge to dev.

I asked a few more experienced developers and agreed with @benjy that it'd be best if VBE had a VBO-dependant 2.x version. Commits from 2898073-bulk-edit branch have been moved to VBE repository 2.x branch. For further changes, issues and releases check the VBE project page.

Great thanks guys.

Please do consider #2904110: Document where to find features for users moving D7->D8 to help people figure it out.

Till the other day I was on D7. For years together.

Only a few months back, I finally mustered the strength to shift to D8/9.

I installed the D8/9 version of VBO not realising that the "Modify entity values" had been hived off into a new module altogether.

Today, I simply went nuts trying to add the feature to a particular view. All the while I thought I must have been doing something wrong.

[I am on D 9.5.1 and VBO 4.2.3]

Either the #2904110 issue or making VBE a sub-module would be great.

Graber, please to consider :)