🇩🇪Germany @RobinCS

RobinCS → changed the visibility of the branch 2969406-fix-incorrect-message to hidden.

Since it's still not stated what part of patch #77 needs work, I'm gone retest #77 and put it back to Needs review.

RobinCS → created an issue.

John Cook → credited RobinCS → .

Recap from DrupalCon Lille 2023:

The functionallity of the latest patch #37 📌 Plurals are not exported correctly when exporting source translations Needs work looks fine. If the reroll of the patch passes, we put this back to Needs Review.

Recap from DrupalCon Lille 23:

• The original String-Version of the Formular should be saved in State, not in Config.
• Configuration is not aware of Plural.
• State becomes the primary source of truth.
• This dosn't disrupt common translation-deploy-flows, which currently can only use the import of PO-Files.
• We need to write an update hook, which guesses the Plural-Formular from the current Plural-Array.
• We can generate and and then compare arrays for these plural-forms. This should lead to a correct guess in most of the cases.
• If we don't find a correct guess (for example for a custom or broken language), we need a reasonable default. This default may change depending on the number of plurals in the array.

Reroll the latest patch:
I reroll the latest patch. A merge conflict (changes in an adjacent line) has been solved.

RobinCS → created an issue.

Monitored Room 2 „Hosted Login“

Monitored Room 6 „Technical Writing Workshop“

#87 says the password can be reseted with „this link“, without providing a link. If you mean the link in the browser bar, then the user is already on that site, so there is no need to link to the same site. Also, linking to any site would lock the password form again (#72).
@smustgrave You said #65 had not been addressed, but #63/#65 suggested „You can set your new password now“. What part of #65 has not been addressed?

The www-data user dosn't need write permissions, except for the folders that you can find on [your-site]/admin/config/media/file-system .

These are usually (in relation to the "web" folder) ./sites/default/files and /tmp. You can also change the folder for temporary files in settings.php, if you don't want to give www-data access to /tmp.

For anyone coming to this issue at a later point: I confused cache-tags with cache-keys. Just add a cache key to the children of the render array, and they can be cached. My mistake was that I thougt the cache-tags are the cache-keys.

https://www.drupal.org/docs/drupal-apis/render-api/cacheability-of-rende... →

Going though the latest comments, these seem to be our options:

1. You have used a one-time login link.
2. You have used a one-time login link. You can set your new password now.
3. You have used a one-time login link. You could set your new password now.
4. You have used a one-time login link. You should set your new password now.

The following options didn't seem to be well liked:

1. You have used a one-time login link. Please set your new password now. (Don't use "please". #2921133)
2. You have used a one-time login link. Set your new password now. (Feels a bit too direct and has too much urgency. #63)

I just went ahead with "You have used a one-time login link. You can set your new password now." now, as it is the one that most people liked or felt neutral about.

The final HTML is supposed to be a list with each result item as one <li>.

<ul id="list">
  <li id="item-1" class="list-item">Item 1</li>
  <li id="item-5" class="list-item">Item 5</li>
  <li id="item-2" class="list-item">Item 2</li>
</ul>

This is a simplefied redered string. The actual implementation is more expensive to calculate.

At the moment, I have to render the <ul> and the <li> parts each time I render the output. I want to cache the <li>-Part (<li id="item-1" class="list-item">Item 1</li>), and that for each item. This is the part redered in container__custom_item_theme. What I don't want to cache is the order of appearance of those items within the <ul> Tag.

Both Variables ($app_root and $site_path) are provided by Drupal. You can just put them into the settings.php, PHP will resolve them. The "if (file_exists(…" Snippet should come at the very end of the settings.php, so the values in settings.local.php can override the ones in settings.php.

Within the UI, you can go to Reports → Recent Log Messages (or use the path /admin/reports/dblog) to see the logs. You should find the error message in there.

If this fails or you are on a dev site, you can also enable the output of the error message. For this go to the source code of drupal, then open the file web/sites/default/settings.local.php and uncomment or add the following line:

$config['system.logging']['error_level'] = 'verbose';

Then reload the page with the 500-Response. If no detailed error message shows up, open the file web/sites/default/settings.php and add the following to the end of the file:

if (file_exists($app_root . '/' . $site_path . '/settings.local.php')) {
 include $app_root . '/' . $site_path . '/settings.local.php';
}

I tested the patch. It's working. (See 3256257-test-1.png)

No, I meant it the other way around. The password-field on the user edit form is password-protected. When you forgot your password, you cannot set a new one. The only exception is directly after using the password reset link (the same request this message is shown). Moving from one page to another would lock the password field again, aborting the reset.

This is why we can assume that the user can set their password on whatever page their landing. Because there can’t be a second one. This also means we can’t link to the user edit form in the status message.

My suggestion therefore is: “You have used a one-time login link. You can set your new password now.” or “You have used a one-time login link. You should set your new password now.”

RobinCS → created an issue.

I think we can safely assume that the message will be displayed on a password edit form (although not necessarily the user edit form). If it wouldn’t, people could not reset their password, since they need to know their old password to set a new one.
If a contributed module introduces another workflow, it will likely change the status message as well.

It might be worth highlighting the password field on the user edit form, but this seems like a follow-up issue.

While I personally like "You can set your new password now" more as well, this problem was already addressed in #40 and #43 and should go in a follow-up issue.

I have not noticed this issue on our sites. Have a look into Configuration → People →  Account settings → Password recovery (/admin/config/people/accounts). Maybe you or someone else changed the text there. This text must contain [user:one-time-login-url], including the brackets, all lowercase and in english. Drupal will replace this text snippet with the reset-URL.

If this does not work out, have a look into Reports → Recent log messages and see if you can find anything unusual.

RobinCS → created an issue.