@sboden

The file is ok, but it's referenced in better_exposed_filters in the wrong way (besides being referenced in a good way).

The actual file is here, when I'm in the root directory of a Drupal project:
./www/libraries/nouislider/nouislider.min.js

In the better_exposed_filters.libraries.yml you see:

nouislider_internal_npm:
  js:
    /libraries/nouislider/dist/nouislider.min.js: { minified: true }
  css:
    component:
      /libraries/nouislider/dist/nouislider.min.css: { minified: true }

There is no "dist" in the path.
But there's also "nouislider_internal" section which has the right paths.
I don't think anything is affected but my calculation of the .js/.css hashes as they point to non-existing resources.

sboden → created an issue.

Attached the patch you can use with cweagans/composer-patches

sboden → created an issue.

And here is the rerolled patch from #112 (as close as possible) for Drupal 11(.2.3).

The difference between #115 and #118 is that:
- #115 tries to fix the problem without looking at past solutions.
- #118 is a re-roll of #112.

This code is a PITA. If it's not in before Drupal 12, we will need to reroll it again.

It's 2 issues which cause the problem in this issue:

Purpose for patch a: Fixes the SelectionPluginManager to handle missing plugin groups gracefully

- Problem: The original code assumed $selection_handler_groups[$base_plugin_id] always exists and is an array
- Solution: Adds defensive checks with fallback logic:
a. Checks if the requested plugin group exists and is an array
b. If not, tries to find any available group as fallback
c. As last resort, constructs a default plugin ID pattern ($base_plugin_id . ':' . $target_type)

Impact: Prevents fatal errors when entity reference fields use selection handlers that don't have the expected plugin group structure.
You can find other issues on drupal.org with the uasort error but with without autocreation. e.g. https://www.drupal.org/project/drupal/issues/3509376 🐛 TypeError: uasort(): Argument #1 ($array) must be of type array, null given in uasort() Active

Purpose of patch b: Implements autocreate functionality for ViewsSelection handlers

1. Interface Implementation:
- Implements SelectionWithAutocreateInterface
2. createNewEntity():
- Creates new entities with proper label and bundle
- Sets entity ownership if the entity supports it (EntityOwnerInterface)
- Uses entity type manager to handle storage operations
3. validateReferenceableNewEntities():
- Validates that newly created entities match allowed target bundles
- Handles both array and string bundle configurations
- Returns filtered array of valid entities

Impact: Allows entity reference fields using Views-based selection to automatically create referenced entities when they don't exist, improving user experience during data entry.

Patch "a" you always need, patch "b" there are different options. Patch b is a different way from the patch in #112.

To get and reset your hook_update number:

# to get:
drush sql-query "SELECT value FROM key_value WHERE collection='system.schema' AND name='workflow';"

# reset: replace 8001 with the number you want to set it to.
drush sql-query "UPDATE key_value SET value='i:8001;' WHERE collection='system.schema' AND name='workflow';"

johnv → credited sboden → .

Don't manually change your composer.lock file: nothing ever good comes from that, EVER.
composer require 'drupal/workflow:2.1.x-dev@dev' properly updates composer.json and composer.lock file.

I have 2 projects: one recent Drupal 11.2.3 and a Drupal 10.4.5 on which that workflow version works (the version of yesterday anyway, commit tag 41669fddb1b390a441e3516c261374dacd30617f). So if you want to try my exact current version do: composer require 'drupal/workflow:=2.1.x-dev#41669fddb1b390a441e3516c261374dacd30617f'

Questions:
a) Do you see any errors in watchdog after opening the workflow view: drush ws --extended
b) Do you have an old database that you can retry with, one from before you had this problem. If so, reload and retest.
c) When you make new workflow transitions now, do they show up properly? And what does watchdog show after creating a workflow transition.

I had the patch from #112 running on Drupal 10.4.5, it stopped working after upgrading to Drupal 11.2.3

I had Claude Code rework the patch, and after a couple of tries it came up with attached files. It works for me, but I need other people to test.
The patch is in 2 pieces, because there are also 2 problems. This should also minimize re-rolling.

The Drupal 11 patch. No guarantees that everything works, but this is the patch I used on my Drupal 11 instances.

sboden → created an issue.

It's nice to be able to upgrade workflow from Drupal 10 to Drupal 11 without having to change application code.
I've always used workflow v1.7 on Drupal 10, since workflow v1.8 broke things for me.

Now it looks like I can upgrade from v1.7 to the latest 2 version in dev without problems.

Looking at the changes that were made in v2, I was at first pessimistic a simple workflow upgrade would suffice.

Thank you.

Unittests as a patch, and a replacement README.md file.

sboden → created an issue.

Strange... I had it too, but it's fixed in the latest versions for me.

Can you try:

composer require 'drupal/workflow:2.1.x-dev@dev'

and test again?

The behats are green, code look ok.
Fine by me.

Looking at https://git.drupalcode.org/project/workflow/-/commit/9dc7f7d12a1592a19ad7652123e6e072131c34c9 the last part of this one still needs to be included (it's partially in):

         // Note: Field name may have been set, if empty initially.
         $field_name = $definition->getName();
-        $cache_key = "{$uid}:{$entity_type}:{$entity_id}:{$field_name}";
-        $access[$cache_key] = $access_result;
+        $new_cache_key = "{$uid}:{$entity_type}:{$entity_id}:{$field_name}";
+        $access[$new_cache_key] = $access_result;
       }
+      
+      // Store the result for the original cache key as well
+      $access[$cache_key] = $access_result;

You're right, with either workflow_transion or workflow_transition my tests now pass (probably because those are running as administrator role).

I run custom tooling that tries to detect anomalies, and that came up as anomaly while fixing the array reference. The array reference is real.

Can we get a tagged version when it's +- stable. It's easier to explain to upgrade from v1.7 to v2.x.y, than to provide a commit tag to upgrade to.

Almost but not quite, 8 behats of the 225 fail:

1. In https://git.drupalcode.org/project/workflow/-/blob/2.1.x/src/Access/WorkflowHistoryAccess.php?ref_type=heads

there's 2 times "workflow_transion", which should be "workflow_transition". A typo.

2. there's a small bug in the key caching you transcribed.

Patch attached.

After this patch I can replace workflow v1.7 by the dev 2 version without application changes.

sboden → created an issue.

New patch to make the logout confirmation dialog work in all circumstances. This patch on is on the dev-3x patch with MR 167 applied.

To the maintainers: it took a while to get everything working as it should, be careful to include all "moving" parts.

I would like to get it in the baseline, and I guess I'm not going to be the only one.

wfr,
Sven

sboden → created an issue.

I tried the 3 dev version. It's not yet completely working as I get a:

TypeError: Drupal\openid_connect\Controller\OpenIDConnectRedirectController::authenticate(): Argument #1 ($openid_connect_client) must be of type Drupal\openid_connect\OpenIDConnectClientEntityInterface, string given in Drupal\openid_connect\Controller\OpenIDConnectRedirectController->authenticate() (line 271 of /data/code/energiescan/www/modules/contrib/openid_connect/src/Controller/OpenIDConnectRedirectController.php).

But I will debug.

Let me know when you did all patches. Or you think you're finished, and I will let my behats run again.

kubokura, can you try this fix: https://www.drupal.org/project/workflow/issues/3520853#comment-16225281 🐛 Extra Workflow fields don't work as of v1.8 Active

I fixed a few other small things until all my projects using workflow had green behats.

This should be used instead of the previous ones in this thread. Base is still "dev-2.1.x bc9ef90".

So, for testing purposes:
composer require drupal/workflow:dev-2.1.x#bc9ef90

The patch for Drupal 11.2.3, possible Drupal 11.x

I just upgraded from Drupal 10 to Drupal 11.2.3, and I still get the error:

Deprecated function: mb_check_encoding(): Calling mb_check_encoding() without argument is deprecated in Drupal\Core\Cache\DatabaseBackend->normalizeCid() (line 501 of core/lib/Drupal/Core/Cache/DatabaseBackend.php).
Drupal\Core\Cache\DatabaseBackend->normalizeCid() (Line: 120)
Drupal\Core\Cache\DatabaseBackend->getMultiple() (Line: 110)
Drupal\Core\Cache\DatabaseBackend->get() (Line: 326)
Drupal\Core\Cache\CacheCollector->lazyLoadCache() (Line: 144)
Drupal\Core\Cache\CacheCollector->get() (Line: 112)

Which exact version do I test?

I debugged both Drupal 10 and Drupal 11.

The results:
In WebAssert.php method pageTextContains(), there's following line to get the contents of the page:

$actual = $this->session->getPage()->getText();

And in Drupal 10 the responsive tables on the page are in $actual. While in Drupal 11 using the exact same code and database, the responsive tables seem to be filtered out.

When I do a local hack to:

$actual = $this->session->getDriver()->getContent();

it usually works, but also not in all cases as that will output the contents as html. If you have text that crosses tags that it also fails.
So the change is "damned if you, damned if you don't".

It's a small change behaviour, which is going to cause a lot of rework for a lot of people.

sboden → created an issue.

sboden → created an issue.

sboden → created an issue.

Found it. It looks like "11434" is prefilled, but it's not of course (it's just a placeholder)

I would remove the placeholder "11434" in the text field, and put below in the description "The port number for the API. Ollama normally uses 11434. Port be left empty if 80 or 443.

Or additionally really prefill the port to "11434".

sboden → created an issue.

After debugging and patching, I asked an AI to have a look at the workflow module and suggest some easy very local optimizations. And it did. I reviewed the changes, they look very much ok.

I made a new patch of its changes + there's also a summary of the changes.

All my behats are still green with this patch (this patch also includes everything from #36).

So please evaluate and integrate.

I debugged and made a patch... actually 2 patches.

This patch is a manual patch. What changed:
- In workflow v1.7 when you requested the workflow status of a newly saved bundle, it would return the creation status. In v2 it would return ''. You could work around it since you know when you have a newly saved object and set the creation status yourself, but it's easier to be backwards compatible.
- In some cases owners could be empty, giving problems. Patch now works around it by filling current user when not filled in.
- getCreationStatus() was doing a lot of stuff it didn't need to do. We can exit with the first creation status you find (which is probably the first anyway), and no need to try and create a creation status every time.

With this patch on worflow "dev-2.1.x bc9ef90" (I did a composer require 'drupal/workflow:2.1.x-dev@dev) all of my behats are green again. Not that 100% proof correctness, as I don't use comments and scheduled transactions e.g.

This patch is also included in the next one. Please use the next one.

When I debug I find this message as exception "Drupal\workflow\Entity\Workflow::getFirstSid(): Argument #3 ($user) must be of type Drupal\Core\Session\AccountInterface, null given, called in /var/www/html/www/modules/contrib/workflow/src/Entity/WorkflowTransition.php on line 1053"

I'll debug further in the weekend, and hopefully find a fix.

I retested my behats. What I did:

ddev composer require 'drupal/workflow:2.1.x-dev@dev'
# Which got me "Cloning e21f8ee43f"
ddev drush updb
 ---------- ----------- --------------- -----------------------------------------------------------------------------
  Module     Update ID   Type            Description
 ---------- ----------- --------------- -----------------------------------------------------------------------------
  workflow   8007        hook_update_n   8007 - This will fix the Error 'Mismatched entity and/or field definitions'
                                         on /admin/reports/status.
  workflow   8009        hook_update_n   8009 - Updates existing configuration to match configuration schema.
 ---------- ----------- --------------- -----------------------------------------------------------------------------
ddev drush cr
ddev robo behat
...

--- Failed scenarios:

    features/backoffice/operator/operator.feature:3
    features/frontoffice/frontoffice.feature:57
    features/frontoffice/frontoffice.feature:124
    features/frontoffice/frontoffice.feature:167
    features/frontoffice/frontoffice.feature:200
    features/frontoffice/frontoffice.feature:256
    features/frontoffice/frontoffice.feature:344

225 scenarios (218 passed, 7 failed)
10429 steps (10344 passed, 7 failed, 78 skipped)

All behats worked successfully with workflow 1.7 and workflow 1.8 (with the hook patch) starting from the same database state.

This is a piece of my code that crashes. It crashes because WorkflowTransition::create() returns NULL.

...
    $objection->save();

    // Always set the initial state.
    $current_sid = workflow_node_current_state($objection, 'field_objection_status');
    $comment = $address_overridden ? t('Correspondence address was manually overridden by citizen') : '';
    $transition = WorkflowTransition::create([
      $current_sid,
      // phpcs:ignore
      'field_name' => 'field_objection_status',
    ]);
    $transition->setTargetEntity($objection);
    $transition->setValues($status,
    \Drupal::currentUser()->id(), \Drupal::time()->getRequestTime(), $comment, TRUE);
    $transition->force(TRUE);
    workflow_execute_transition($transition, TRUE);

The problem seems to be that workflow_node_current_state() seems to doing something else than before. When you created a new bundle, workflow_node_current_state() in v1.7 would return the initial state (as string) attached to the workflow, now it seems to return "".

Patch that implements this and agent plugins and changed welcome text at https://www.drupal.org/project/aichatbot/issues/3537048 ✨ Change welcome text Active

Patch that implements this is in https://www.drupal.org/project/aichatbot/issues/3537048 ✨ Change welcome text Active

sboden → created an issue.

sboden → created an issue.

sboden → created an issue.

I will try again... can you give me the exact version of workflow you want me to test. Maybe with git hash?

TL;DR: Using workflow v2.1.3: 218 of the 225 behats that work using workflow 1.7 and 1.8 (with patches) work, 7 failed.

What I did is:

composer require drupal/workflow:^2.1.2

which imports workflow v2.1.3 (at this moment). Then:

drush cr
drush updb
 ---------- ----------- --------------- -----------------------------------------------------------------------------
  Module     Update ID   Type            Description
 ---------- ----------- --------------- -----------------------------------------------------------------------------
  workflow   8007        hook_update_n   8007 - This will fix the Error 'Mismatched entity and/or field definitions'
                                         on /admin/reports/status.
  workflow   8008        hook_update_n   8008 - Updates existing configuration to match configuration schema.
 ---------- ----------- --------------- -----------------------------------------------------------------------------

And then run my set of behat tests. 7 fail... 5 of them with following (and the other 2 are dependent I think):

Error: Call to a member function setTargetEntity() on null in Drupal\jobbonus\Data\ApplicationDAO->saveData() (line 183 of modules/custom/jobbonus/src/Data/ApplicationDAO.php).

And in my custom code this is what triggers it:

$transition = WorkflowTransition::create([
      $current_sid,
      // phpcs:ignore
      'field_name' => 'field_objection_status',
    ]);
$transition->setTargetEntity($objection);           // this is line 183.

Looking at WorkflowTransition::create() it doesn't do the same anymore. workflow v2 needs 'wid' in the input array, else no transaction is created.

Probably a coincidence. I also adapted #20 for 3.0.0-alpha6. I have been using this patch in production now on 1 site for 2 weeks, no-one is complaining so far.

I did add a small piece from another issue as the edits to the same code made me nervous. This is now the only patch I use for 3.0.0-alpha6

Setup takes some time, I will try it during this weekend.

I had the same problem on a second Drupal application, so I did some further investigation. So, for anyone else hitting this problem.

The problem was actually caused by https://www.drupal.org/project/drupal/issues/3029434 🐛 Loading entities can fail in Sql::loadEntities() for required entities, skip those rows Needs work . When the patch from that issue is only half applied (one fragment is rejected), logging is added but the log channel is not. This causes then causes the problem above.

I tried different workflow versions with the behat tests on my biggest Drupal project. The project has 10 node bundle types with each a workflow attached to it and the project does a lot of things upon workflow transitions: e.g. if you change a workflow in one type, it may hunt down nodes in other types and recursively change the workflow in those, which may trigger further other changes. It uses a lot of workflow functionality, except scheduled workflow transitions: we didn't find a use for those.

The behats test system functionality, the behats go through a lot of the functionality to check whether everything is still ok. And since a lot of our functionality is behind workflow transitions, these also get exercised a lot. It does not 100% proof everything works, but if some behats fail, it's a bad sign. 1 behat test can be upto 2 or 3 A4 pages long.

With composer require drupal/workflow:=1.7: all 225 behats runs successfully (as expected). This is my current baseline in production.

With composer require drupal/workflow:=2.0.0: (without my patch above): 220 behats succeed, 5 fail. The 5 failures are about workflow transition history being different.

With composer require drupal/workflow:=2.0.0: (with my patch above): 220 behats succeed, 5 fail. Not expected, but it is what it is.

With composer require drupal/workflow:=1.x-dev#430c793f889ece2a527db93033139eba65df8c1
This was the latest merge I found today (26may2025). All behats break. At first sight this version introduces a problem with saving nodes. Nodes which were saving with the tagged workflow 2.0.0 version now complain they can't be saved, as some fields need data.

For the presave hook in my patch. Personally I would like to have it included in the base workflow version, but I may be biased ;). The presave hook is a little bit sneaky, but it is how workflow worked up until and including workflow v1.7. In workflow v1.8 that functionality broke. From personal experience and the comments in the workflow issues I deduce that most people are still on workflow v1.7 and skipped/delayed the update to workflow v1.8 since v1.8 broke things. To me it does make sense to reintroduce v1.7 behavior to make upgrades easier. E.g. for my projects it will take me about a week per project to find all places where I have to adapt code, if I don't reintroduce the presave hook (and hoping I find all places I need to adapt).

"Re-rolled" patches.

I'll rephrase the problem when going from workflow version v1.7 to workflow v1.8 or v2.0.

In workflow v1.7, the target_entity was saved when a workflow transition happened. This saving happened in a hidden way - probably not even on purpose - but it did happen in workflow v1.7.

In some of our Drupal applications, we change data during a workflow transition: we copy fields from the workflow to its target_entity. After a transition, we saw that the value was also updated on the target_entity.

But in workflow v1.8 (and also in v2.0, which is based on v1.8), that saving no longer happens. The update to the target_entity still takes place (in our custom code), but because it is not saved, the update is lost. In v1.7, the saving was triggered - indirectly - by the workflow_entity_presave hook.

If we want backwards compatibility with v1.7 in v1.8 or v2.0, then workflow_entity_presave is needed. This missing hook is probably also the reason I never updated to v1.8 earlier - because my applications started acting strangely after the upgrade.

Choices:
- Include workflow_entity_presave. In that case, most people can upgrade from v1.7 to v2.0 without many issues.
- Don’t include workflow_entity_presave. Then you have two options:
1. Patch workflow yourself to add workflow_entity_presave. But this might break in the future if workflow changes again.
2. Change your application to explicitly save the target_entity. I’ve tried this, but in some cases it’s difficult to get exactly the same behavior as before.

Personally, I would prefer if workflow_entity_presave were part of the base version of workflow. But if it’s not, I can patch it myself. I don't know how many others are affected when going from v1.7 to v2.0. If you use workflow in a simple way, v2.0 works fine as is. But if your application depends heavily on workflow, then you will run into problems without workflow_entity_presave.

I also noticed that the label "Update workflow" was removed. This caused my Behat tests to fail, because the label on the button was changed. That label was "reorganized away" in v2.0

For template_preprocess_workflow_transition you're right, the patch I have running in production for that part is:

diff --git a/workflow.theme.inc b/workflow.theme.inc
index 1f28e39..b46bebc 100644
--- a/workflow.theme.inc
+++ b/workflow.theme.inc
@@ -20,7 +20,11 @@ use Drupal\Core\Template\Attribute;
  */
 function template_preprocess_workflow_transition(array &$variables) {
   /** @var \Drupal\workflow\Entity\WorkflowTransitionInterface $workflowTransition */
-  $workflowTransition = $variables['elements']['#workflow_transition'];
+  $workflowTransition = $variables['elements']['#workflow_transition'] ?? NULL;
+
+  if (!$workflowTransition) {
+    return;
+  }

   $variables['from_state'] = $workflowTransition->getFromState();
   $variables['to_state'] = $workflowTransition->getToState();

I wanted to make it nicer, but I slipped up.

Attached patch fixes it for me in both Drupal 10.4.3 and 10.4.6

sboden → created an issue.

Attached patch works for me on openid_connect 3.0.0-alpha2 (I can reroll it).

It decouples the config name with the name used in the redirect controller.
Because of that some wiring magic is also needed to convert the other way around: to match config with incoming slug in the redirect controller.

sboden → created an issue.

Patches attached revert the behaviour back to the way v1.7 behaved for saving target entities (in a sneaky way). I have a patch for workflow 1.8 and workflow 2.0

If possible I would like to have them reviewed and published as workflow version 1.8.1 and 2.0.1. It is breaking behaviour, but it's actually reintroducing the way v1.7 worked. The main change is reintroducing the presave hook.

The way I see it, no project is yet using workflow v2.0 (it's too new). Most projects are on workflow v1.7, maybe tried to upgrade to v1.8 but reverted because of the changed behaviour, I did as well.

If you have a project using workflow in a simple way, workflow v1.8 would work as is, the new patch is probably not going to break anything. When you have a project using workflow in a complex way, these patches will revert saving behaviour of the target entity of a workflow transition as that was done in workflow v1.7

Found it in v1.8.

When I add following to workflow.entity.inc:

/**
 * Implements hook_entity_presave().
 *
 * @param \Drupal\Core\Entity\EntityInterface $entity
 *   An EntityInterface object.
 */
function workflow_entity_presave(EntityInterface $entity) {
  if (!$entity->isNew()) {
   // Avoid a double call by hook_entity_presave and hook_entity_insert.
   _workflow_execute_transitions($entity);
  }
}

Then the functionality reverts to the v1.7 behaviour.

Some more information, I'm still debugging.

I have a node bundle subdossier that has a workflow subdossier, and that workflow has some extra fields. These fields pop up on the subdossier node view form depending on the chosen "to workflow" with some manual conditional hook alter forms.

There's a field "field_amount_paid_back" that exists both on the workflow and on the subdossier node bundle. And in the presave hook of the WorkflowTransition the field is copied from Workflow to node bundle with following function:

  public static function presave_transition_paid_back(EntityInterface $entity) {
    $subdossier = $entity->getTargetEntity();
    \Drupal::logger('SBO_INFO')->info('Starting presave_transition_paid_back - Subdossier ID: @id, Label: @label', [
      '@id' => $subdossier->id(),
      '@label' => $subdossier->label(),
    ]);
    
    $subdossier->field_amount_paid_back->value = $entity->field_amount_paid_back->value;
    \Drupal::logger('SBO_INFO')->info('Setting field_amount_paid_back to @value for subdossier @label', [
      '@value' => $subdossier->field_amount_paid_back->value,
      '@label' => $subdossier->label(),
    ]);
  }

I added some extra logging... read from bottom to top (it's from "Recents logs")

  7    24/Apr 12:57   SBO_INFO   Info       Setting field_amount_paid_back to 112 for subdossier 2020CCP003262-C
  6    24/Apr 12:57   SBO_INFO   Info       Starting presave_transition_paid_back - Subdossier ID: 688488, Label:                                        
 2020CCP003262-C
  5    24/Apr 12:57   SBO_INFO   Info       Workflow transition presave - Bundle: subdossier, From: subdossier_paid,
                                            To: subdossier_paid_back
  4    24/Apr 12:57   SBO_INFO   Info       Entering entity_presave for
  3    24/Apr 12:57   SBO_INFO   Info       Node presave - Bundle: subdossier, ID: 688488, Label: 2020CCP003262-C
  2    24/Apr 12:57   SBO_INFO   Info       Entering entity_presave for 2020CCP003262-C
  1    24/Apr 12:57   SBO_INFO   Info       Entering node_presave for 2020CCP003262-C

This happens when I press "Change workflow" on the node view form of subdossier 2020CCP003262-C. It enters the presave for the node, the entity presave is entered. Then the workflow transition presave is entered (the one without label above). And then finally that one field is copied from workflow to node bundle.

The results:
- When using workflow v1.7 the field_amount_paid_back is saved correctly on the node bundle.
- When using workflow v1.8 or higher the field_amount_paid_back is not saved on the node bundle.

However in both cases the flow is the same according to my debug logging statements. In v1.8 and higher the field is copied from workflow to node bundle, but the node bundle doesn't seem to get saved anymore. In v1.7 for some reason the node bundle is still saved after the presave from workflow transition is executed.

The only thing different is the version of the workflow module.

sboden → created an issue.

This one is ok now.

I'm still using patches for this one, but it's becoming a huge patch.

The problem is that we have some government sites that use "acm-idm" as slug in the openid_connect redirect URL, and you can't have a system name in Drupal with a "-" in it (and in the old openid_connect module you could get the "right" redirect URL). I have about 20 Drupal sites integration with the same openid_connect server and I'm not in control of the redirect URL.

So it's only a problem when you integrate with an openid_connect server using -'s in the redirect URL.

On the "admin/config/workflow/workflow/payment/states" I see the weights from the config files, and on there the statuses are always in the correct weight order.

When I have weight -9 on payment open, in v1.8 I see "open" as first option in the status list on the node creation page.

Right after I do a "composer require drupal/workflow:1.x-dev", without drush cim or drush cr, when I refresh the node creation page the payment open status moves to the second place in the list. On the config screen are still in the right weight order. So it has to be something in the workflow code that does something freaky while sorting.

sboden → created an issue.

For better backwards compatibility, it would be best to revert then.

I don't use it in the apps I wrote myself (same idea: it's not workflow responsibility to save entities), but some of the projects I inherited use that functionality.

drush updb did the trick. My bad, I'm reloading the database too much in ddev.

This issue may be closed. What I did find while checking the base field definitions is that v1.8 has ->setSetting('target_type', 'workflow_state') on the from_sid/to_sid fields in the BaseFieldDefinitions. Version 1.x-dev doesn't have that, oversight or intentional?

sboden → created an issue.

I just (08 April 2025) had the exact same problem on Drupal 10.4.6, while testing the new development version of drupal/workflow (1.x-dev, the future v1.9) in a huge Drupal project.

I have a battery of behat tests (about 200 tests), which fail with the new drupal/workflow module version unless I apply patch #9 above. The patch also makes sense to me. I would backport it if possible.

It's ok now. This one can be closed.
Thanks.

I did a complete debug session until the end of one project. I now get my behat tests to green status with both workflow v1.8 and the current dev version, with some minor changes in the workflow dev version. Patch attached, please review and add to the code.

I would still release it as v2.0.0, I did have to make some small changes in my project code: workflow version 1.8 had no problem with yet unsaved objects, but the new version apparently has. Saving objects upfront makes sense but does require a change. So it's not a minor workflow version: you can't just update workflow.

I can do the migration for another big Drupal project, but only beginning of next week.

I'm not fully convinced about the 1.9 development version yet.

I spent 3 hours upgrading one project from workflow v1.8 to v1.9, and I'm about 80% done.

Here are the extra issues I ran into:

- The function workflow_get_workflow_state_names() is missing in v1.9.
- The required parameters for WorkflowTransition::create() have changed a lot. e.g. without a wid value, no transition is created.
- In v1.8, you could use workflow on an entity before saving it. In v1.9, the entity must be saved first. If your code relies on the old behavior, you’ll need to adjust your logic.
- In v1.9, you must set an initial workflow status when creating a node. This wasn’t required in v1.8.
- Some interfaces are missing.
- For some reason, I now sometimes get the workflow status as a system name instead of a label/value. When I switch back to v1.8, this problem goes away.

If you plan to release this version, I think it should be called v2.0 instead of v1.9. When moving from v1.8 to v1.9, I expect everything to keep working, with some extra features. That’s not the case here. In the test project alone, I'm already at 82 code changes, and I expect to pass 100.

Personally, I would roll back to v1.8 and improve it, but keep the existing interfaces the same. Else you're going to create a lot of work for a lot of people.

But then it's not a v1.9 but v2.0. The previous example was from a huge Drupal app that built stuff on top of workflow.
I have about 500 behat tests in total that normally are green.

Some other things that pop up:

Warning: Undefined property: Drupal\workflow\Entity\WorkflowState::$option in Drupal\views\Plugin\views\filter\InOperator->reduceValueOptions() (regel 276 van /var/www/html/www/core/modules/views/src/Plugin/views/filter/InOperator.php)
#0 /var/www/html/www/core/includes/bootstrap.inc(166): _drupal_error_handler_real(2, 'Undefined prope...', '/var/www/html/w...', 276)
#1 /var/www/html/www/core/modules/views/src/Plugin/views/filter/InOperator.php(276): _drupal_error_handler(2, 'Undefined prope...', '/var/www/html/w...', 276)
#2 /var/www/html/www/core/modules/views/src/Plugin/views/filter/InOperator.php(203): Drupal\views\Plugin\views\filter\InOperator->reduceValueOptions()
#3 /var/www/html/www/core/modules/views/src/Plugin/views/filter/ManyToOne.php(112): Drupal\views\Plugin\views\filter\InOperator->valueForm(Array, Object(Drupal\Core\Form\FormState))
#4 /var/www/html/www/core/modules/views/src/Plugin/views/filter/FilterPluginBase.php(1074): Drupal\views\Plugin\views\filter\ManyToOne->valueForm(Array, Object(Drupal\Core\Form\FormState))
#5 /var/www/html/www/core/modules/views/src/Form/ViewsExposedForm.php(105): Drupal\views\Plugin\views\filter\FilterPluginBase->buildExposedForm(Array, Object(Drupal\Core\Form\FormState))
#6 [internal function]: Drupal\views\Form\ViewsExposedForm->buildForm(Array, Object(Drupal\Core\Form\FormState))
#7 /var/www/html/www/core/lib/Drupal/Core/Form/FormBuilder.php(536): call_user_func_array(Array, Array)
#8 /var/www/html/www/core/lib/Drupal/Core/Form/FormBuilder.php(284): Drupal\Core\Form\FormBuilder->retrieveForm('views_exposed_f...', Object(Drupal\Core\Form\FormState))
#9 /var/www/html/www/core/modules/views/src/Plugin/views/exposed_form/ExposedFormPluginBase.php(134): Drupal\Core\Form\FormBuilder->buildForm('\\Drupal\\views\\F...', Object(Drupal\Core\Form\FormState))
#10 /var/www/html/www/core/modules/views/src/ViewExecutable.php(1298): Drupal\views\Plugin\views\exposed_form\ExposedFormPluginBase->renderExposedForm()
#11 /var/www/html/www/core/modules/views/src/Plugin/views/display/PathPluginBase.php(393): Drupal\views\ViewExecutable->build()
#12 /var/www/html/www/core/modules/views/src/Plugin/views/display/Page.php(198): Drupal\views\Plugin\views\display\PathPluginBase->execute()
#13 /var/www/html/www/core/modules/views/src/ViewExecutable.php(1690): Drupal\views\Plugin\views\display\Page->execute()
#14 /var/www/html/www/core/modules/views/src/Element/View.php(81): Drupal\views\ViewExecutable->executeDisplay('page_1', Array)
#15 [internal function]: Drupal\views\Element\View::preRenderViewElement(Array)

and

Error: Call to a member function getTransition() on null in Drupal\workflow\Hook\WorkflowEntityHooks->executeTransitionsOfEntity() (regel 367 van /var/www/html/www/modules/contrib/workflow/src/Hook/WorkflowEntityHooks.php).

These are from a smaller project that uses workflow, but doesn't do anything special with it.

v1.8 was working with patches. I have a couple of projects that use workflow, and they have behats.

So what I did is:

composer require 'drupal/workflow:1.x-dev'

And then I reran the behats, and everything breaks. This is one of the errors I get

Error: Call to undefined method Drupal\workflow\Entity\WorkflowManager::getCurrentStateId() in                                           Drupal\project_extras\Plugin\Field\FieldFormatter\WorkflowStateLabel-> viewElements() (line 132 of                                           /var/www/html/www/modules/custom/project/src/Plugin/Field/FieldFormatter/WorkflowStateLabel.php).

I can try on some other projects as well.

The WorkflowStateLabel looks like this:

/**
 * Provides a default workflow formatter.
 *
 * @FieldFormatter(
 *   id = "workflow_state_label",
 *   module = "workflow",
 *   label = @Translation("Workflow state label"),
 *   field_types = {
 *     "workflow"
 *   },
 *   quickedit = {
 *     "editor" = "disabled"
 *   }
 * )
 */
class WorkflowStateLabel extends FormatterBase implements ContainerFactoryPluginInterface {
...
  /**
   * {@inheritdoc}
   *
   * N.B. A large part of this function is taken from CommentDefaultFormatter.
   */
  public function viewElements(FieldItemListInterface $items, $langcode) {
    $output = [];

    $field_name = $this->fieldDefinition->getName();
    $workflow_field = $items->getName();

    if ($entity = $items->getEntity()) {
      if ($entity->$workflow_field->value) {
        $current_sid = WorkflowManager::getCurrentStateId($entity, $field_name);
        /* @var $current_state WorkflowState */
        $selected = workflow_state_formatter($entity, $field_name, $current_sid);
        return $selected;
      }
    }
    $selected = t('(Creation)');
    $output[] = ['#markup' => $selected];

    return $output;
  }
...

I threw the problem an at A.I. and it wrote a patch for the "PHP 8.2 problem".

Patch attached, I'm still testing it but my behats stayed green.

sboden → created an issue.

sboden → created an issue.

The patch file for v1.5.0

The patch file.

sboden → created an issue.

I debugged a bit further, and I end up at https://git.drupalcode.org/project/views_bulk_operations/-/merge_requests/5/diffs?commit_id=1b7836474527e0039134c9f2a86aa52e81f03901

So it's not a bug, it's intended behaviour. But it's a breaking change: so instead of setting redirect_url, you have to override a method.

sboden → created an issue.

sboden → created an issue.

sboden → created an issue.

Had the same error on Drupal v10.3.2 updating workflow 1.7 to 1.8.

#20 works, but to workflow 1.8 it's not a flawless update.

Any chance of getting an official version that supports Drupal 11 soon? This is one of my last blockers.

My bad, thanks for noticing. I "just" install core-recommended, but my script installs some other small stuff. I'll have to search there probably, I verified your real clean install, it works.

sboden → created an issue.

Patch #65 rerolled for Drupal 10.3.1 (I guess >= 10.3)

Patch #65 does something weird to drupal/webform 6.2.2. Without the patch my app using webform works fine (behat unit tests). After applying the patch webform seems to miss a button. Remove the patch, all is ok again. It's weird, since there are no managed files in the webform.