Flags problem with VBO module in views

Confirmed I am experiencing this too.

That sounds like a general problem with the way our actions are named.

Just got this same error when testing VBO and had the Flag Bookmark example module enabled. Looks a bit like https://www.drupal.org/node/2293773 this to me

A quick update - using `Node operations bulk form` instead of the VBO does not produce the same error so could this be related to how VBO is parsing the actions?

#5 this solves the problem. So the problem occurs with VBO or views?

The problem is the IDs we are giving to the derived Flag action plugins:

  public function getDerivativeDefinitions($base_plugin_definition) {
    foreach ($this->flagService->getAllFlags() as $flag_id => $flag) {
      foreach (['flag', 'unflag'] as $action) {
        $this->derivatives[$flag_id . '.' . $action] = [
          'id' => $flag_id . '.' . $action,

Then contain a dot, which isn't allowed as a key in the Views settings.

just encountered this. In a nice way, I am happy I am not alone. It means I am doing the right thing and using beloved Drupal. What is the final solution to resolve this?

Hmmm. The node solution in #5 works fine. Is this a part of VBO or Views? If not VBO, do we still need VBO?

Thanks Andy_D

There is a bug in Views for filter handlers that save their options in such a way that causes this error. Might be related.

Ok, why not change the dot in EntityFlagActionDeriver to something else that is supported by the core ConfigBase::validateKeys?

'id' => $flag_id . '.' . $action,

IMO not allowing dots makes sense because a dot means a lower nesting level in config structure and in this case we're on the same level even if it's a derivative and from the Flag module point of view it may be a lower level.

Here's a patch that'll do for VBO but it may not be sufficient for the core bulk form.

At least #12 allows to use VBO & Flag together without the exception.
But I found the fix brings problems when importing/exporting flags configuration, colons do not like to Config Manager.

Needs work, I' afraid.

Related: #2780869: Cannot save a view where a filter value option contains a period

Sadly I had similar problems. I tried doing a search and replace on the config, but no dice.

Saving is possible by temporarily commenting the if in validatekeys function of Configbase.php file but this is not a solution.
Need a patch.

Thanks all for creating this issue and the work so far! I ran into this problem today.

I do not claim to understand the problem, but I will try standing on the shoulders of giants and do something similar to the patch in #12. Instead of . or :, both of which cause problems, why not use _? This works in my limited testing so far.

Limited testing: I saved the view, exported and re-imported the site configuration. I cleared caches a few times while I was at it. So far, so good. And the publish/unpublish operations seem to work.

When I include this patch #18 I can no longer add sites to a platform using Aegir (http://drupal.org/project/aegir). I get an out of memory error.

@SocialNicheGuru: I doubt that this is related.
BTW: Does Aegir support D.8 projects while itself runs a D.7 core?

@all changing the . to the _ is a simply patch, but it isn't simple to implement. Doesn't we need to rewrite all existing setups then? We possible have to make that patch part of a new release and have to warn about that there is no upgrade/migrate path then.

This patch caused problems with system_post_update_change_delete_action_plugins() when I upgraded to Drupal 8.6.0 and ran database updates:

Failed: Drupal\Component\Plugin\Exception\PluginNotFoundException: The "flag_action:subscribe_node.flag" plugin does not exist. in                                [error]
Drupal\Core\Plugin\DefaultPluginManager->doGetDefinition() (line 52 of /var/www/docroot/core/lib/Drupal/Component/Plugin/Discovery/DiscoveryTrait.php).

(Got that, Google?)

In further testing, I find that I get similar errors whenever I try to add a new flag. So yes, this patch needs some work. I am updating the issue status to reflect that reality.

There where some places, most importantly the schema, where the changes was not added. Attached patch might fix the issue.

Ok small mistake in the previous patch. This should do it.

The fail in this test is probably because the flag label is generated using $this->randomString(). This is HTML encoded which could lead to the link text not being found. Don't have time to dive further in to this, but hopefully this was a push in the right direction. Everything else seems to work as expected!

After applying the patch from #24, I find that I can create new flags, so this fixes one of the issues I reported in #22. However, when I apply the patch to a site running Drupal 8.5.6 and then upgrade to 8.6.1, I still get the error message I quoted there, so it does not seem to solve that problem.

The patch updates flag_flag_insert() so that, when a new flag is added, an action will be created with the updated ID. I think the problem is that we also have to update existing actions, either in an update hook or a post-update hook. Compare with system_post_update_change_action_plugins(), which makes similar changes.

Here is an attempt at an update function. Does it break anything?

I have not tested it much, but I have to break for today.

If we are really lucky, then the test failure will be fixed by #3000437: Force remove angle brackets from FlagCreateTrait::randomHTMLstring.

I guess we got lucky! Or maybe I should just say that @seanB was right about the test failure in Comment #25.

I have tested the patch in #27, and it looks pretty good:

Apply patch, drush updatedb, upgrade to 8.6.1, drush updatedb
Upgrade to 8.6.1, drush updatedb, apply patch, drush updatedb

The update function that I added in #27 seems to fix the errors I reported in #22. The changes from @seanB in #24 seem to fix the problem with creating a new flag.

@dididoq, does the update function satisfy the objections you raised in #21?

Note that the bug described in this issue is that you cannot create a view with a VBO field, whether or not you enable the flag/unflag options in the VBO field. I think that the patches here fix that bug. If I go further, then I see a new error. If I enable the action associated to a flag in my VBO field, and then try to apply the flag to one or more nodes, then I get the error

Error: Call to a member function actionAccess() on null in Drupal\flag\Plugin\Action\FlagAction->access() (line 78 of /var/www/docroot/modules/contrib/flag/src/Plugin/Action/FlagAction.php).

Patch #27 work for me with 8.5.7 version.
Thanks

That's a pretty clever solution!

Thanks all!

yay! +1 @ all.

Hello,

Thanks all for this issue and the solution. I just encountered the problem and patches from this issue and #2974902: The "flag_action:email_user.flag" plugin does not exist. in Drupal\Core\Plugin\DefaultPluginManager->doGetDefinition fixed the problem.

I suggest to publish a new version as the 4.0-alpha3 is more than a year old.

I am facing an issue, when i use "User VBO(views bulk operation)" to update the notification interval with the help of Message Digest module.
When I try to submit the VBO form from front end it gives the below error

Error: Call to a member function actionAccess() on null in Drupal\message_digest_ui\Plugin\Action\DigestInterval->access()

Please anyone help me in this issue.

I am getting also the same error as on #36. I am using VBO 2.x version, drupal 8.7.1.
In my view I use (views bulk operations) as field instead of "Node operations bulk form" field.
This field permit me to run the action in a batch set up in the view and in case of multiple rows the site will not crash.

Error: Call to a member function actionAccess() on null in \flag\Plugin\Action\FlagAction->access() (line 82 of

I used the patch from #27 and the issue is still here.
Any idea?

@iuana I am also getting same issue while using flag with VBO, Have you find any solution ?

I experienced same error than #36, #37, #38. Debugging a bit I found that is because FlagAction constructor doesn't get configuration from VBO operation. I tried to determine why but no luck, then I implemented a workaround/compatibility code parsing flag type and action from plugin id. Patch Attached

#39 but with better formatting.

I think it doesn't make too much sense commenting the closed issue, but #40 has literally saved my day.
It is worth to open the separate issue I guess.

This is a bit odd having patches contributed to an issue that is already patched and closed. If this stands a chance of getting in, either a new issue needs to be created, or a maintainer needs to re-open the issue. Otherwise this is just going to linger.

Yes, exactly that. There is also #3238783: Integrate with ECA where I also asked for a separate issue.

I added #3317113: Call to a member function actionAccess() on null and attached the patch from #40 here.

Let this issue rest in peace.