@sboden

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.

In my mind it's clear that the current fix for LANG_CODE_NOT_APPLICABLE is wrong.

In the case of LANG_CODE_NOT_APPLICABLE no language prefix should be generated. No language prefix was generated before, it should not after since it will break a lot of stuff around the world. If you use LANG_CODE_NOT_APPLICABLE, you specifically don't want langcode, why would langcode be added.

See also https://www.drupal.org/project/drupal/issues/3385550 🐛 Language negotiation breaks updating Drupal 9 to 10 Needs work , I spent an hour trying to figure out why openid_connect breaks. I will include a patch in the latter issue.

LANGCODE_NOT_APPLICABLE should in my mind not have a language prefix: I have language negotation active on my site, but openid_connect that is used for authentication is very "touchy" about the URLs that you can use.

So in Drupal 9 my custom code generated "https://mysite.com/openid_connect/acm-idm" and after upgrading to Drupal 10 that is magically changed to "https://mysite.com/nl/openid_connect/acm-idm", which breaks openid_connect.

One comment I have since I created https://www.drupal.org/project/drupal/issues/3385550 🐛 Language negotiation breaks updating Drupal 9 to 10 Needs work :
I'm not sure it's a good idea to create the function: LanguageInterface::LANGCODE_NOT_APPLICABLE and LanguageInterface::LANGCODE_NOT_SPECIFIED are very different.

- LANGCODE_NOT_APPLICABLE: I do not want to have a langcode even if it's setup in the system.
- LANGCODE_NOT_SPECIFIED: Langcode is not specified, but if there's an active langcode, add it.

In most cases you would still have to distinguish between the 2 cases anyway.

sboden → created an issue.

For the second case I can typehint to get rid of it.

For my first case, this is actually the exact statement how it should be changed "for the new way", and it should be figureoutable by the analyzer. After further checking I found this one: https://github.com/mglaman/phpstan-drupal/issues/586 so if it's fixed over there, it will also come to upgrade_status.

sboden → created an issue.

sboden → created an issue.

sboden → created an issue.

sboden → created an issue.

sboden → created an issue.

sboden → created an issue.

Some more debugging.

Number 1. got solved by running "drush updatedb", my bad.

For number 2. I would suggest to introduce a new field and use that instead of the system name of the instance of the plugin in the redirect URL. For backwards compatibility: when the new field is empty the system name could be used anyway. Sole reason is that Drupal system names can't use '-', and some OIDC providers (e.g. the one of the Belgian government) do use a dash ("acm-idm").
For the name of the name field, no idea what it should be called. Right now the redirect parameter is filled in in "parentEntityId" and it gets taken from "client_id", which it not really is in OIDC terminology.

Short term work-around for me is to override the parameter for the redirect URL in my own client, which would actually revert it a bit more like v1.

Thanks for the information... maybe an entry could be made in the readme file to explain upgrades.

I'm still not out of the woods with the problem but I pinpointed where it is.

But first, I need my own OIDC client since I need a small extension to support a "login_hint" feature. So what I do is make a new client that extends OpenIDConnectClientBase, which is empty besides a copy of the authorize() method from OpenIDConnectClientBase to which I add 2 lines. But for testing purposes I even just extended OpenIDConnectClientBase and removed all methods.

Then I get the error "Symfony\Component\Routing\Exception\InvalidParameterException: Parameter "openid_connect_client" for route "openid_connect.redirect_controller_redirect" must match "[^/]++" ("" given) to generate a corresponding URL. in Drupal\Core\Routing\UrlGenerator->doGenerate() (line 203 of /var/www/html/www/core/lib/Drupal/Core/Routing/UrlGenerator.php)." when I go to my site.
Reason for this is because in the method below the "$this->parentEntityId" is an empty string.

  public function authorize(string $scope = 'openid email', array $additional_params = []): Response {
    $language_none = \Drupal::languageManager()
      ->getLanguage(LanguageInterface::LANGCODE_NOT_APPLICABLE);

    $redirect_uri = Url::fromRoute(
      'openid_connect.redirect_controller_redirect',
      [
        'openid_connect_client' => $this->parentEntityId,
      ],
      [
        'absolute' => TRUE,
        'language' => $language_none,
      ]
    )->toString(TRUE);

    $url_options = [
      'query' => [
        'client_id' => $this->configuration['client_id'],
        'response_type' => 'code',
        'scope' => $scope,
        'redirect_uri' => $redirect_uri->getGeneratedUrl(),
        'state' => $this->stateToken->generateToken(),
      ],
    ];

    if (!empty($additional_params)) {
      $url_options['query'] = array_merge($url_options['query'], $additional_params);
    }

    $endpoints = $this->getEndpoints();
    // Clear _GET['destination'] because we need to override it.
    $this->requestStack->getCurrentRequest()->query->remove('destination');
    $authorization_endpoint = Url::fromUri($endpoints['authorization'], $url_options)->toString(TRUE);

    $this->loggerFactory->get('openid_connect_' . $this->pluginId)->debug('Send authorize request to @url', ['@url' => $authorization_endpoint->getGeneratedUrl()]);
    $response = new TrustedRedirectResponse($authorization_endpoint->getGeneratedUrl());
    // We can't cache the response, since this will prevent the state to be
    // added to the session. The kill switch will prevent the page getting
    // cached for anonymous users when page cache is active.
    $this->pageCacheKillSwitch->trigger();

    return $response;
  }

I compared what the URLs were in openid_connect v1.2.0 and what solves it for me in v3 is this. Replacing $this->parentEntityId by $this->getPluginId() in the authorize() method.

    $redirect_uri = Url::fromRoute(
      'openid_connect.redirect_controller_redirect',
      [
        'openid_connect_client' => $this->getPluginId(),
      ],
      [
        'absolute' => TRUE,
        'language' => $language_none,
      ]
    )->toString(TRUE);

$this->getPluginID() results in my case in "acm-idm" (the system name I used for the plugin, and also the id of the OIDC server). And the URLs I get out of it are:

redirect URI = "https://mysite.be/openid-connect/acm-idm"
authorization url = "https://authentication-server.be/op/v1/auth?client_id=e243df5e-9f0d-4977...

The strange thing is also that on the client config screen the Redirect URL is calculated as "https://mysite.be/openid-connect/acm_idm"... which in my case is wrong: the acm_idm is the system name of the client config (which can't have dashes, while the actual string should "https://mysite.be/openid-connect/acm-idm" (dash instead of underscore), BUT it does find "acm_idm" while during the actual execution that part is always empty. The reason for the discrepancy is that the formbase for the config screen has its own getRedirectUrl() method which calculates the string with the system name of the client config.

So I still have 2 problems:
1. The parentEntityId doesn't get filled in properly. I see it being filled in in the initializePlugin() method of OpenIDConnectClientCollection, but I see no evidence of it actually happening.
2. If parentEntityId would be filled in properly I can't make it work since I need "acm-id" as part of the URIs, and system names in Drupal can't contain a dash, so I can't make an OIDC client system name that I can use with my OIDC server. And I'm only a user of the OIDC server, so I can't change anything to the setup there.

I've been debugging a bit in openid_connect.

It seems when moving from v1 to v2 the config data changed names, anyway my config from v1 isn't visible anymore in v2.

So I recreated my config. After that. I have my own client that derives from OpenIDConnectClientBase and that doesn't seem to be able to get its config data, e.g. the parentEntityId (which seems to be filled in in plugin initialization) is "", while the config actually has a value for it.

sboden → created an issue.

I mistakenly thought "open webform" would start a webform, but that's not what it's for.
I wrote an ECA action that starts a webform.

In the meantime I worked around it, but I will probably need the functionality later on. I can give it try.
Any preference for the name of the (new) backend feature?

sboden → created an issue.

Present a specific webform to a user.

What I would like to have is a model that "When a user logins and certain conditions are met, have him fill in webform x. When some other conditions are met have him in webform y".

The conditions/webform are currently hardcoded in a controller, but it would be nice to make it "no code/low code" with ECA.

I've just been looking in the code, "open webform action" sets the status to open but not much more.

Regards,
Sven

sboden → created an issue.

#2 does the trick to make some address fields always visible. Closing this issue.

Tests are missing, ok.

For the upgrade path, that might be tricky. But, when you define a field with allowed_values_function, you can't use allowed_values in the Drupal GUI anymore - the options are mutually exclusive. So the patch is actually "new" functionality: without the patch search_api would only take allowed_values into account, after the patch allowed_values_function is also taken into account which people who defined a field as such would want to use. When allowed_values_function is filled in, allowed_values is empty anyway.

Are there people who defined a filter on a field using allowed_values_function but assume users will filter using its key as search criteria (without dropdown), I doubt it. That's e.g. why I ended up on this issue.

sboden → created an issue.

Wrote/rerolled the patch for search_api 1.29.0

I wrote the patch before finding this issue, in hindsight in exactly the same way as the already existing patches. Could this patch be merged, so we don't have to keep rerolling it: the patch is a clean solution. I'm using it in production on a Drupal 9.5.7.

sboden → created an issue.

Partitioning seems to be a dead end: the column used for the partitioning needs to be part of all of the unique keys on the table, and adding type to the primary key seems to be "dangerous".

Redis yes, Search API Solr not yet. The biggest problem now is a bundle containing 1.3 million entries with 10 fields, of which we want to show in a view the last 25 rows (paging) which have a state "printed". Of the 1.3 million entries, except for the last 10K or so, all are in a state "printed". My intuition says that Solr will not be that useful for that: too many rows and too little cardinality.

I am also looking at activating partitions in MySql on node and node_field_data per bundle, so that those tables are at least already "split/partitioned" per bundle/type since most Drupal queries I see filter on bundle.

Any other ideas on making Drupal faster for larger volumes?

"Something went wrong" is usually a PHP parsing/coding error. I get that a lot on development, I've always been able to fix it without losing data. If you have that on production, you're doing something wrong. Have enough tests (behat e.g.) around your site in development to cover all flows through your site and you should be ok.

Any software will potentially have errors, whether you use Drupal, WordPress, Laravel, ... or some other technology. Drupal is quite stable and has a helpful community of users/developers.

Also tested #12, it works for me.

I also made a patch from scratch based on 'update_status'. Patch attached, the main difference is that phpunit tests now also work.

Fixed:

FILE: modules/contrib/serial/tests/src/Functional/SerialFieldTest.php

STATUS         LINE                           MESSAGE
--------------------------------------------------------------------------------
Check manually 16   Drupal\Tests\BrowserTestBase::$defaultTheme is required. See
                    https://www.drupal.org/node/3083055, which includes
                    recommendations on which theme to use.
--------------------------------------------------------------------------------
Check manually 137  Call to deprecated method drupalPostForm() of class
                    Drupal\Tests\BrowserTestBase. Deprecated in drupal:9.1.0 and
                    is removed from drupal:10.0.0. Use $this->submitForm()
                    instead.
--------------------------------------------------------------------------------
Check manually 163  Call to deprecated method drupalPostForm() of class
                    Drupal\Tests\BrowserTestBase. Deprecated in drupal:9.1.0 and
                    is removed from drupal:10.0.0. Use $this->submitForm()
                    instead.
--------------------------------------------------------------------------------

FILE: modules/contrib/serial/serial.info.yml

STATUS         LINE                           MESSAGE
--------------------------------------------------------------------------------
Check manually 0    Value of core_version_requirement: ^8 || ^9 is not
                    compatible with the next major version of Drupal core. See
                    https://drupal.org/node/3070687.
--------------------------------------------------------------------------------

Still open as "deprecated in 10.x":

  2x: The theme 'classy' is deprecated. See https://drupal.org/node/3223395#s-classy
    1x in SerialFieldTest::testSerialField from Drupal\Tests\serial\Functional
    1x in SerialFieldTest::testSerialEntityCreation from Drupal\Tests\serial\Functional

I used 'classy' as theme for now to make the tests work again. In https://drupal.org/node/3070687 they suggest to use "stark" as theme but then some more changes are needed in the unit tests.

This issue ended up being a duplicate for https://www.drupal.org/project/views_data_export/issues/3341342 🐛 Exporting a filtered view results in duplicates Closed: duplicate

I can see that in Drupal 9.5.3 the patch is already included in core, but I still have see problem.

sboden → created an issue.

Can you try the last patch from https://www.drupal.org/project/reroute_email/issues/3261831 ✨ Support symfony_mailer, which doesn't use hook_mail_alter Fixed

Sorting while having multiple workflow states on 1 page is not working.

1 workflow state field works better, but not yet completely correct to me.

I added 3 screenshots... test with a single block view on a page:
- ws_default_order is the order on the title (the first column).
- ws_order_down is the order after pressing once on the header of the workflow state (the second column): not that the workflow state order remains, while alphabetically they should change.
- ws_order_up is the order after pressing once more on the header of the workflow state: now they are in the proper order according to the workflow state (first letters V, G, F in descending order)

I only see 2 orders of workflow states no matter how many times I click on the workflow state header: the order according to title and the descending order by workflow state, the ascending order does not show.

sboden → created an issue.

My situation is a bit more complex.

- I retested a simple case: a view (page based) including a workflow status. Everything works as expected.

- My situation: I have 4 views as blocks on a single page. Each view is on a different bundle and each view contains a (different) workflow status. I activate sorting on the headers in all of the views.

The result for me on Drupal 9.4: The workflow status seems to be fixed in 1 order. I sort on another field and that sorting works, when such other order shifted the order of the workflow states, and I press the order on the workflow status header the original sort order of workflow status is applied, but when I click multiple times on the header to sort differently it doesn't budge anymore. So it seems stuck in 1 order.

What does work but has other side effects:
- I put in a relation in each block to "workflow transition". Then sorting up and down on workflow status works properly.
- However, then I get multiple rows (which is warned for). So I used "Table Aggregate" mode, "compress and enumerate without duplicates", but then the "show field as link" does not work anymore on the title field (this is not workflow related): you get the html on screen instead of the proper link it should create.
- The order of workflow status also seems to be on the system name of the workflow status and not the description of it, rewriting the result with the value itself also does not help.

sboden → created an issue.