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.
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
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.
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.
sboden → created an issue.
I can confirm #9: saving the config again will solve the problem.
#7 is right. I played with drupal/webform in the beginning of the projects and removed it afterwards. But in the config I still had:
editor.editor.webform_default.yml: - filter.format.webform_default
editor.editor.webform_default.yml:format: webform_default
And "webform_default" does not exist anymore as a filter.
If this could be handled without fatal error it would be great.
When you need to redirect in a function that has $form_state, you can use $form_state->setRedirect(): that works as before.
I would suggest to close the bug as chances of the root cause being reverted seem slight, and there is a viable workaround, either using $form_state->setRedirect() or the solution from #9.
But it does suck that it breaks existing functionality.
I applied patch "3463712-fix-fatal-error" above on Drupal 10.3.1 with drupal/security_review:^3, and it still crashes with the same error message.
I tried installing a clean Drupal 10.2.7 (drupal/core-recommended) and upgrading to 10.3.1: works fine, editor_post_update_sanitize_image_upload_settings executes without problems.
But for the moment I don't see what config on my real sites could crash editor_post_update_sanitize_image_upload_settings.
The sites which I upgraded are very simple sites: drupal/core-recommended (initially even installed at 10.2.7, not that long ago) with the least amount of contrib modules. On some back-end forms we use ckeditor but without special config, it's possible to upload images but none of the sites have uploaded images for the moment.
sboden → created an issue.
This is part of code for a Form. An API call fails and in that case I want to go back to with an error message on .
The new behavior is that you go to but the error message doesn't show there, the error does show when you go to the form on which the exception occurred/where the error was added.
It's not breaking Drupal, but it's breaking the flow of a Drupal application when that depends on the old behavior of status messages.
I tried disabling bigpipe but that does not make it revert to the previous behaviour.
Patch is included. At this time Drupal 8 is not supported, so it's probably best to upgrade to a newer Drupal to solve this problem.
I'm going to close this one. I figured out what's going on.
There's a cronjob that resets the daily stats, my app runs in AWS Fargate and its cronjob triggering process apparently broke.
I had a problem with status messages going from Drupal 10.2.7 to 10.3.0 and a "git bisect" leads to here.
I create a ticket for it at https://www.drupal.org/project/drupal/issues/3458135 🐛 \Drupal::messenger() changed behaviour between Drupal 10.2.7 and Drupal 10.3.0 Active
In short status messages are not appearing where/when they were appearing before.
I did a git bisect and end up at this one:
522404706e440106fe7e5d382ce018b0f89637d4 is the first bad commit
commit 522404706e440106fe7e5d382ce018b0f89637d4
Author: Alex Pott <alex.a.pott@googlemail.com>
Date: Thu Feb 22 13:05:24 2024 +0000
Issue #3414287 by catch, longwave: Avoid reading session from the database multiple times during a big pipe request
(cherry picked from commit 213906e2867ddf6187bb140a3002db2c1144ab92)
.../Core/Session/ResponseKeepSessionOpenInterface.php | 16 ++++++++++++++++
core/lib/Drupal/Core/StackMiddleware/Session.php | 3 ++-
core/modules/big_pipe/src/Render/BigPipe.php | 12 ------------
core/modules/big_pipe/src/Render/BigPipeResponse.php | 3 ++-
.../OpenTelemetryAuthenticatedPerformanceTest.php | 3 +--
.../src/FunctionalJavascript/StandardPerformanceTest.php | 4 ++--
6 files changed, 23 insertions(+), 18 deletions(-)
create mode 100644 core/lib/Drupal/Core/Session/ResponseKeepSessionOpenInterface.php
sboden → created an issue.
The daily and total count for me are always the same, so the daily count doesn't reset.
sboden → created an issue.
sboden → created an issue. See original summary → .
Patch to make it work on Drupal 8.
sboden → created an issue.
sboden → created an issue.
There is a workaround. There don't seem to be that many people with the problem. I can't replicate it in other Drupal projects.
Closing this.
As followup, when you ever have an error on "help_post_update_add_permissions_to_roles" while doing drush db the solution is as follows:
drush pmu help
drush updb
drush en help
And then do a drush cex and check the changes: in Drupal 10.2.3 this gives a lot of small changes in the config files.
sboden → created an issue.
sboden → created an issue.
sboden → created an issue.
As documented in [ https://www.drupal.org/project/drupal/issues/3420019] → ( https://www.drupal.org/project/drupal/issues/3420019 🐛 TranslatableSectionStorageInterface not found Closed: won't fix ) patch #72 correctly applies to a Drupal 10.2.2 instance, but it breaks the site.
I found the fix in the meantime. If anyone else is having this problem:
Following patch applies correctly, but breaks Drupal 10.2.2.
"3044993: Allow synced Layout default Translations: translating labels and inline blocks (depends on override patch above)": "https://www.drupal.org/files/issues/2023-07-26/3044993-d10-72.patch",
We don't use layout_builder but that patch was a left-over from another Drupal project we started from.
sboden → created an issue.
I'm closing the issue. It was solved by a drush update for me and at least 1 other person.
No point in keeping it open.
I applied this patch to openid_connect 3.0.0-alpha2, it works for me. Tests looks ok.
I don't think we need an option to be enable/disable the check as in the related issue, this one is good enough.
#6 fixes the issue on a Drupal 10.2.2
This issue can be closed. The short term solution is as suggested in #7 not to switch on the "Link label to the referenced entity" for the workflow fields that don't have a canonical view (e.g. "From state" and "To state").
Follow up issue at https://www.drupal.org/project/drupal/issues/3415993 ✨ "Link label to the referenced entity" changed behavior from Drupal 10.1 to 10.2 Active . It would be nicer when the "Link label to the referenced entity" would not be shown in the settings for fields that don't have a canonical view, or fail silently when displaying the view instead of getting a WSOD.
The behaviour of this changed from 10.1.x to 10.2.x, in 10.1.x it would be silently ignored.
The problem is with a change in functionality of calling a canonical view when the "Link label to the referenced entity" is switched on. In Drupal 10.1.x when an element does not have a canonical view Drupal "skips" requesting it, while in Drupal 10.2.x you get a WSOD when the canonical view/route is called.
For this I would propose not to show the "Link label to the referenced entity" for an element that does not have a canonical view. This would avoid Drupal calling something which does not exist. Example for this are the "From state"/"To state" fields from the contrib workflow module.
sboden → created an issue.
The problems occurs when upgrading from Drupal 10.1.x to 10.2.x: it works in 10.1.7 and 10.1.8, it breaks as of 10.2.1 (I didn't try 10.2.0)
My problem was solved with #7 above. In a view I have the "From state" and "To state" element had the checkbox on for "Link label to the referenced entity". The canonical view for workflow state never existed but in Drupal 10.1.x it gets ignored, while in Drupal 10.2.x it breaks.
The solution is not to switch on the option "Link label to the referenced entity". Better option would be for views not to show the checkbox when the element does not have a canonical view.
#7 stops the error from occurring so that's good, thanks.
Is there a way to make it more error-proof? Disable "something" so the link to entity option doesn't appear in views for from/to state, e.g. the Log Message and Transaction ID field just don't have that option to link to an entity. Alternatively make workflow work with the option, but I guess that wouldn't make much sense. Or a hook that scans the fields in views to switch off the option.
I checked the EVA view involved, it looks ok to me:
- The fields in the EVA are all fields from the Workflow category: From State, To State, ...
- Entity content setting is type "Content", Arguments is "id".
- It has a contextual filter "Workflow: Entity ID" which takes default value of "id in URL"
The EVA shows the list of workflow transitions of the node it's on.
It does work in 10.1.x, but not in 10.2.x
I only got the error by accident, it's from the issue in the OP.
I get it when I use the contrib workflow module on a Drupal 10.2.x, when I view a node of a bundle that has a workflow attached to it, where the workflow history is in an EVA on that node.
The '%s' is definitely wrong, but since the parameters are 'flexible' it's a PITA to create a proper error message. Unless there's somewhere a function to convert a "callback" to something readable.
It's not $callback, I tried. $callback is an array that even exhausts memory when you print_r() it.
Yes, also correct for me. I did an upgrade from Drupal 10.1.7 to 10.2.1 with composer and then it breaks. Later on I tried 10.1.8 that works, Upgrade to 10.2.2 breaks.
I have the problem locally in a ddev environment and also on our ECS test environment on AWS with a CI-CD flow, so the environment is always clean (no left-overs of code or so), "drush updb" is properly run, ...
When I'm on Drupal 10.1.x and I run "drush route" entity.workflow_state.canonical is also not in the output. So my current assumption is that something in Drupal 10.2 triggers that route while it's not supposed to be triggered.
On the node views where it breaks I have an EVA to show the workflow history.
sboden → created an issue.
sboden → created an issue.
sboden → created an issue.
One strange possibly related thing. On Drupal 10.1 after I upgrade dxpr_theme, I tried to enable the layout_builder module by doing "drush en layout_builder", and then I get the error "The module color does not exist.". Trying the same on a backup copy of the project the layout_builder enables just fine.
I upgrade dxpr_theme from 5.2 to 6.0.0-alpha1 on a Drupal 10.1: everything is looking good. And this issue is solved in there.
For a proper name of a drush command, maybe "dxpr_theme:regenerate" or "dxpr_theme:cr" (preference for the regenerate).
sboden → created an issue.
sboden → created an issue.
Thanks to a colleague... this is related to https://www.drupal.org/project/drupal/issues/2683749#comment-11030147 💬 Hide label if field is empty Fixed
And what I'm now doing as workaround is putting the columns to "Hide when empty" in the table settings of the view.
As it worked before... before Drupal 9.5.3 in my case, is that "drush cex" would not export the config-ignored items. Now it does.
In the past config ignored items would not be exported and I would not care about them. Now I get an export of the config ignored items, so I have to check manually which fields are config ignored and which are "real changes": people may change the config ignored items but I'm not interested in their changes from a "configuration view", else I would not have config-ignored them.
Config ignore was for me: "They're config ignored, they're in the database, I don't care about them". Now I do have to care since they will be exported, and if I don't filter them out I will add config to git which I don't care about.
Patch #9 fails: when you remove in_array() the line should be changed to a '=='.
Something as:
if (!isset($options['language']) || ($options['language'] instanceof LanguageInterface && $options['language']->getId() ==
LanguageInterface::LANGCODE_NOT_SPECIFIED)) {
sboden → created an issue.
I'm having the same problem as OP in Drupal 10.1
Site default in 'english', with translations to 'dutch'. All views are langcode 'en'. And I'm migrating from Drupal 9.5.10 to 10.1. When I run "drush cim" and "drush cex" right after each other everything is ok. When I put a "drush updb" in between, all texts are changed to the dutch translation: all views that are "touched" by the drush updb exhibit the behaviour.
The resulting views are still in langcode 'en', but all english text is changed to its dutch translation. The dutch translation then also disappears from the translations under "translations/nl".
When I do a single export of a view using the GUI I also the changes, so I don't think it's all in drush. #22 doesn't fix it for me.
So what I see as a "problem" is for following code (it's a small piece from an openid_connect library):
$language_none = \Drupal::languageManager()
->getLanguage(LanguageInterface::LANGCODE_NOT_APPLICABLE);
$redirect_uri = Url::fromRoute(
'openid_connect.redirect_controller_redirect',
[
'openid_connect_client' => $this->getPluginId(),
],
[
'absolute' => TRUE,
'language' => $language_none,
]
)->toString(TRUE);
Assume you don't know anything about the APIs being called and you just see this piece of code.
Do you expect "/nl" (in my case) to be added to the URL or not? That's the question and the problem I'm having. In the code above I set language explicitly to "not applicable" so I expect the "/nl" language prefix will not be added.
It did not add a language prefix before the fix, but it does now.
I also have no other easy way to get rid of the language prefix (unless we make a LANGCODE_ABSOLUTELY_NOT_APPLICABLE case, just kidding... don't do it). In my case above the generated URL is used for openid_connect and the "other side" just can't handle a language prefix.
Patch that fixes the LANGCODE_NOT_APPLICABLE issue.