This is an old issue, but I ran into something similar when using the [Password Policy]( https://www.drupal.org/project/password_policy → ) module. I *think* this is the appropriate ticket, so I've created an MR with a quick edit to check if the `$value` is an array before trying to set/access its `_original_delta` value.
beunerd → made their first commit to this issue’s fork.
beunerd → made their first commit to this issue’s fork.
beunerd → created an issue. See original summary → .
beunerd → made their first commit to this issue’s fork.
beunerd → made their first commit to this issue’s fork.
I liked the way the feature was implemented here better, so I've rebased the code to get a new patch that would apply.
beunerd → made their first commit to this issue’s fork.
Actually, I'm realizing this doesn't have any place in workflow_buttons module -- at most it should be added to the core issue queue as a proposal for the workflows core module. It's not related to workflow buttons.
@mlncn What do you think? Is it worth creating a ticket in core for adding the code in this hook? And do you agree we should remove it entirely from this module? And if we do, how do you propose we make sure sites using this module are informed?
Hmm, so maybe we just move it to the README as an example in case themers want to know?
@ras-ben
Thanks, that's a good idea. I've added a commit to the 8.x.-1.x branch. Marking this as fixed.
Thanks, @ras-ben, for the follow up.
but not being used anywhere.
That's correct. This module does not include any twig/template files where the values set in workflow_buttons_preprocess_node() would be rendered. The point is to provide those variables to any Drupal theme that wants to use them in their own node-related template.
@mlncn
Re: "as a temporary workaround to prevent this issue"
I'm still not able to reproduce this issue, so I wouldn't even be able to determine whether the proposed fix in https://www.drupal.org/project/workflow_buttons/issues/3328538 🐛 workflow_buttons should only be loaded/load edit form when relevant Fixed (which I reverted) would be relevant.
Re: "multiple people have seen related issues so i feel like there is some issue here."
Can you point me to the related issues? Again, as per what I wrote in https://www.drupal.org/project/workflow_buttons/issues/3328538 🐛 workflow_buttons should only be loaded/load edit form when relevant Fixed as I understand it the module works just fine in terms of showing/hiding the pseudo field workflow buttons on node/entity view modes. That is, you should disable it in the display modes you want it not to appear. And/or use Drupal's standard "workflows" module permissions to control use/visibility.
I'm going to mark this back as needs more info until we know that there is a problem and how to reproduce it. Otherwise it's going to sit here in "needs work" which we don't know that it does.
@fishfree -
This is the issue queue for the contributed workflow_buttons module → , which can be used to supplement the core workflows module → . I recommend you open a new issue in the Drupal core queue → .
I'm closing as "won't fix" because it's not relevant to the scope of this module. If you feel otherwise, please include additional detail in the description related to the workflow_buttons module (as is, there's no mention of it).
@lelkneralfaro
I'm having trouble reproducing. I think what you're saying is that when you've added the pseudo field to a particular display mode (e.g., "teaser", "full", etc.) via the UI/configuration then when you are viewing the entity (not editing it) you're seeing more than just the workflow buttons? I'm not seeing that on my end. Can you say a little more, maybe with a screenshot too?
@ras-ben @mlncn
First, this function -- workflow_buttons_preprocess_node(&$variables) -- creates two (not one) optional variables for use in node templates: $current_revision_state and $latest_revision_state.
Second, why is this "completely redundant"?
Third, as I explained here 🐛 workflow_buttons should only be loaded/load edit form when relevant Fixed in more detail, checking for view display mode by name is arbitrary and may differ between installations.
@ras-ben, @mlncn
I'm going to revert this change per the explanation above.
@mlncn
I think this should be marked as fixed and merged in. The "workflow buttons" pseudo field can be placed on any view display via UI/configuration. Its visibility to users, then, is handled by Drupal's standard "workflows" permissions. And please see https://www.drupal.org/project/workflow_buttons/issues/3328538 🐛 workflow_buttons should only be loaded/load edit form when relevant Fixed for more.
@sakthi_dev @mlncn
Won't this be a headache for existing drupal installations?
beunerd → made their first commit to this issue’s fork.
Here's a quick patch with a fix for the ${var} warning.
Here's a quick patch that just takes care of the ${var} and ${expr} warnings.
beunerd → made their first commit to this issue’s fork.
@ras-ben, @mlncn
I think the comments above address the first proposed feature, and regarding the second ("A check, to make sure that the user actually has permissions to use workflows - so we can avoid heavy operations for anonymous users.") that's already handled by Drupal's standard access methods. If an anonymous user can use a transition in the content moderation permissions collection, then they can see the buttons; if they do not have those permissions then the buttons do not appear for them. Again, I might be misunderstanding the problem.
@mlncn
What functionality is missing / needs to be regained? I've created a branch on the forked code, but I'm not sure what I need to work on.
@ras-ben, @mlncn
Sorry just getting to this now. Please help me understand what the problem is here, because I don't see it! And I think the fix that was merged in disables some of the module's intended flexibility and utility.
The first of the hooks mentioned in the issue description (hook_entity_view()) is there to show the workflow buttons if they're included in the list of enable components for the node type / view mode loaded. We shouldn't be hard-coding a restriction here for some particular view mode with an arbitrary machine name. That restriction is handled by the view mode's configuration itself. Perhaps we need to add the workflow buttons to the list of disabled components for all workflows by default and let users "opt in" to including them on the various node views, but that preserves the flexibility here. This is not so different from enabling comments on a node type.
The second of the hooks mentioned (hook_preprocess_node()) passes the latest revision workflow state to the node template. That's it. True, it does do an extra load of the $node object to get a list of its revision ids, but there's no rendering or anything heavy going on here.
What am I missing here?
Confirming that the patch in #218 📌 Dynamically provide action plugins for every moderation state change Needs work works on Drupal 9.5.8.
Not sure what might have been going on for @daniel-korte with 9.5.4.
beunerd → made their first commit to this issue’s fork.
beunerd → made their first commit to this issue’s fork.
beunerd → made their first commit to this issue’s fork.
The patch didn't seem to help (drupal 9.5.2, php 8.1), but as a workaround try adding a hidden custom text field to the view toward the top of the list of fields with twig to conditionally look for that key if it exists: {% if raw_arguments.term_node_tid_depth is defined %}{{ raw_arguments.term_node_tid_depth }}{% endif %}. Then you can just reference that hidden custom text field as the argument in your views_field_view (e.g., {{ fields.nothing }}