🇺🇸United States @couloir007

OK, I'm having an issue on a custom fieldable entity. Not sure if there is something about the entity itself or that the field just doesn't work with custom entities.

Hi @arunsahijpal,

To be clear, you are saying it is an issue on user entities, but not an issue on node entities?

couloir007 → created an issue.

I don't. I'm just saying my situation can't be solved with '|render'.

{{ drupal_view('who_s_new', 'block_1', tid|render) }}

I'm not sending any arguments, so wouldn't apply to my situation.

Whether I set the view in PHP or Twig, the error is the same.

{% set output = drupal_view('videos', machine_name ) %}

InvalidArgumentException: "attributes" is an invalid render array key. Value should be an array but got a object. in Drupal\Core\Render\Element::children() (line 97 of /app/web/core/lib/Drupal/Core/Render/Element.php).

Seems like rending views this way is broken.

This might be the same issue.

https://www.drupal.org/project/adaptivetheme/issues/3460269 🐛 Error after updating to Drupal 10.3.1 Active

I'm not certain this is a twig_tweak issue anymore. I replaced my code with PHP code and I got a similar response.

I have this:

  {{ title_prefix }}
  {% if label %}
    <h2 class="content-list __title">{{ title }}</h2>
  {% endif %}
  {{ title_suffix }}

and when I dump title_prefix and title_suffix:

array:1 [▼
  "level" => "h2"
]

and this is the error I get. It aslo is an issue for "attributes".

InvalidArgumentException: "level" is an invalid render array key. Value should be an array but got a string. in Drupal\Core\Render\Element::children() (line 97 of /app/web/core/lib/Drupal/Core/Render/Element.php).

Even users created after the migration can't log in.

It was installed automatically with the upgrade to D10. As far as debugging, the site just says username or password unrecognized. No error. I'm assuming the hashed passwords are incompatible. No attributes are different other than upgrading all the modules to be D10 compatible.

drush sql:query "SELECT uid, name, mail FROM users_field_data WHERE pass IS NOT NULL AND pass NOT LIKE '$2y$%'"

No user has an updated hash. I created a user on the D 9.5.11 site before migrating to test. There is nothing I can do to log in.

Requesting new password will log a user in, but the new password will not have the correct hash. I login with "drush uli" and change a user's password and that doesn't work. Nothing I can do after the upgrade will correctly store a hashed password. They are using Password Policy but I disabled that and nothing changed.

Is it possible that exporting the DB to test on local can mess with the hashes?

https://www.drupal.org/docs/upgrading-drupal/upgrading-from-drupal-8-or-... →

I migrated using composer. I've done 4 or 5 other sites with no issue. Password Policy is enabled. I updated the password via admin drush uli and still can't log in. Odd.

couloir007 → created an issue.

By this being closed works as designed mean there is no issue? I started seeing this as soon as we upgraded to PHP 8.2, which to me makes it seem like there is a real issue.

couloir007 → created an issue.

couloir007 → created an issue.

couloir007 → created an issue.

I used the 10.2.1 patch on 10.2.2, and it worked. It seems impractical to worry about spaces before an opening php tag, given how many of the vendor files contain these. Also, this was only an issue on my local Lando, not on my production servers.

Hi Hephaestus, I did not. We ended up using the username.

I can get my metadata downloaded, but I cannot view the admin screen that tested the login and provided the available variable.

couloir007 → created an issue.

couloir007 → created an issue.

This is still an issue. Does it seem unreasonable that an extraneous space at the beginning or end of a settings.php file should break a module?

Below is what I receive from the IdP.

{
    "saml:AuthenticatingAuthority": [
        "https://*****.****.edu/adfs/services/trust"
    ],
    "saml:AuthnInstant": 1697210395,
    "saml:sp:AuthnContext": "urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport",
    "saml:sp:prevAuth": {
        "id": "_b914341e-c16f-422b-a432-c6f52b420db8",
        "issuer": "https://*****.****..edu/adfs/services/trust",
        "inResponseTo": "_c0a72910e2840ac2e1865a6bcdd1d0ebbf0d8b0855",
        "redirect": "https://test-my-site.pantheonsite.io:443/simplesaml/module.php/core/authenticate.php?as=default-sp"
    },
    "saml:sp:IdP": "https://*****.****..edu/adfs/services/trust",
    "Attributes": {
        "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress": [
            "MontagueS@****.edu"
        ]
    },
    "LogoutState": {
        "saml:logout:Type": "saml1"
    },
    "Authority": "default-sp",
    "AuthnInstant": 1697210408,
    "Expire": 1697239208
}

I have this in my authsource.php

    'attributes' => array(
      // Map the attributes received from the IdP to Drupal user attributes.
      'email' => 'http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress', // Map IdP attribute 'email' to Drupal user 'mail'..
    ),

Seems like there is a disconnect here. I've tried multiple things here but I don't think this has any influence on the Drupal module.

In the module settings, I have the following. There is no username provided by the IdP nor do I want to rely on it even if there is one.

in the simplesamlphp_auth.api.php I see the following:

/**
* Hook to map pre-existing Drupal user based on SAML attributes.
*
* Allows other modules to decide if there is an existing Drupal user that
* should be linked with the SAML-authenticated user authname, based on the
* supplied SAML atttributes.
*
* E.g. When a SAML-authenticated user logs in, try to find an existing Drupal
* user which has the same email address as specified in the SAML attributes.
* In that case the existing Drupal user and SAML-authenticated user will be
* linked, and that Drupal user will be loaded and logged in upon successful
* SAML authentication.
*
* @param array $attributes
* The SimpleSAMLphp attributes for this user.
*
* @return \Drupal\user\UserInterface|bool
* The pre-existing Drupal user to be SAML-enabled, or FALSE if none found.
*/

What I'm failing to get to work is "E.g. When a SAML-authenticated user logs in, try to find an existing Drupal user which has the same email address as specified in the SAML attributes." Is this related to the attributes array? I'm having a hard time with the IdP admins in conveying what I need. SAML is creating a new user with the same email address as my existing user. It is not checking the email address and I'm failing to figure out how to make that work.

couloir007 → created an issue.

couloir007 → created an issue.

couloir007 → created an issue.

Thank you. I'll give this a try.

couloir007 → created an issue.

This did the trick. Thank you.

couloir007 → created an issue.

I'm having the same message but for a different reason. A module is passing a null library but I can't figure out how to track down which. For now I do this which works but obviously no long term solution.

  if($library != null) {
    $final_libraries[$library] = $library;
  }