Stop relying on VBO, implement a custom Views Form handler instead

Thx a lot for the interest, bojanz. I know that you mentioned Views Form earlier too, but to me it was easier to work with the existing VBO based code. However, I would very much like it if you gave it a shot. The current code is functional.

I have considered ditching the spool - I just wanted to fix the core functionality first.

Thx for the patch. I'll look at it tonight. (It sounds very promising.)

[...] You weren't even using the entities loaded by VBO [...]

I know.

I think you have made your case for switching to Views Form handler ;-)

I have tested the patch and everything seems to work. Patch applied in commit f592188.

@bojanz: It would have taken me quite some time writing this patch. The big picture is easy enough with Views Form handlers, but your patch contains a lot of, to me, sophisticated details. Thanks.

@bojanz: Sorry, I forgot to set you has author when doing the commit. I gave you all the credit in the change log, but I know that isn't really sufficient. I guess there isn't an easy way to fix this since I have already pushed the code here.

This sandbox is no longer in use, but I would prefer to keep the discussion in one location ...

@bojanz: Now that Views Send doesn't use VBO, how do we execute it programmatically from Rules (using the configure form). Is this option completely lost, or is there some general way to execute Views Form handlers in Rules? It would be really sad to loose that functionality ...

Same question here, any answer?

I've come here from #2066023: Doesn't work if the View has a pager. I think for a lot of use cases, that issue is a showstopper -- as soon as your view lists more users than you can comfortably fit on a single page, you can't email them all. It doesn't take long for something like an OG group to get to that size.

There is a feature request to include the 'select all items on all pages' as part of Views: #1836126: Select all items on all pages. But there the verdict seems to be that that's not going to happen.

So to fix #2066023: Doesn't work if the View has a pager there are three options:

a. duplicate lots of VBO in here. Ugly.
b. include the 'select all items on all pages' as part of Views: not going to happen
c. reverse the consequences of this issue, and reintroduce VBO as a dependency

Given that option c is by far the most preferable, I've had a bit of a poke around at this, and respectfully, I disagree with what was decided here.

I think the problem with this module wasn't using VBO, it was using hook_action_info() to declare its operation. Core actions are really not very good for anything remotely complex -- in fact I've found them a pain to work with, what with things like the hardcoded callback built on the action name.

If instead of a core action, we define a VBO Operation plugin, then it all becomes easier. There's no need for hook_form_alter(), as we have methods on the plugin class that let us define all the fields we need -- we just need a minor (and IMO very necessary anyway!) patch to VBO: #2072057: pass the $handler object to adminOptionsForm() so it can access the view.

I'm attaching the patch of my work so far -- bear in mind this is just today's work, and I have been approaching this as a proof of concept, and focussing on finding out whether it works.

What's in the patch so far:

- VBO plugin
- I've moved the selection of the 'To' fields to the VBO handler configuration (because with a plugin we can do that now!!!). It makes no sense to have to pick these every time you use the VBO form, and it's also very confusing to the end-user to have to do this.

What I've not yet implemented:

- options for priority, receipt request, extra headers: these are just extra form elements, I see no problem here
- token replacement
- mimemail options
- file attachments
- clean up and remove all the bits of the module we no longer need!!!

The file attachments is the bit where I am concerned it could fall apart, as there could be issues around grabbing the attachments out of the VBO plugin's formSubmit() -- though I've not looked at that at all. Though for my project at least, I'd rather lose the ability to attach files in exchange for the ability to send to all emails in the view!

Hi again, joachim.

First of all I think you should post your patch as an issue against the View Send project and not this old sandbox. In that issue you can refer back here. Other Views Send users won't notice your work here and they won't be able to comment on your ideas. I know for sure that file attachments was very important to several users ...

Secondly, I would like a git formatted diff and you should not modify more than what is needed to make it work as a VBO plugin. Other improvements should be done in other issues. The code is ugly so I'm not offended by people improving it, but you shouldn't break things like this change do:

     // Add field position to ensure unique keys.
-    $field_key .= '_pos_' . $field->position;
+    // TODO: not sure what this is for, as $field_name is already unique.
+    //$field_key .= '_pos_' . $field->position;
+    $field_key = $field_name;

You would have noticed the problem when you got to the token replacement, but then again, that part of the code might also change ...

Thirdly, if we can make it work properly, I'm not against doing this. Hopefully we can bojanz to comment on your work when you have created the new issue. I'll put your code into a branch of the Views Send project until we make a decision.

I'm closing this as a won't fix since this is an unmaintained sandbox.

> I would like a git formatted diff

Could you explain what you mean by that? The patch I posted was made with git.

> you should not modify more than what is needed to make it work as a VBO plugin.

Guilty as charged :(

> Other improvements should be done in other issues.

I'll file a load and mark them as postponed for now, as it's best if this big change isn't chasing a moving branch head.

Filed a new issue here: #2072415: restore use of VBO, but as an operation plugin.

> I would like a git formatted diff

Could you explain what you mean by that? The patch I posted was made with git.

No, I can't - since I was 100% wrong. Not sure what I was thinking.

Looking forward to your work in issue 2072415.