🇹🇼Taiwan @g-brodiei

Added the missing `hook_user_delete` solution from @slowflyer to MR !13

Tested the records of deleted user's uid is gone in `persistent_login` table right after user deletion.

Setting status to needs review, thanks!

Changing the target branch to 2.x.

When a deleted user that has a persistent session record not expired, the end user who previously logged in with their browser may encounter this PHP error message since the uid matching the current browser session can no longer load any user entity.

Added a new commit providing a hook_update to remove records in persistent_login table based upon deleted users before the fix of token delete is working.

g-brodiei → made their first commit to this issue’s fork.

Hi, we've met the same issue on a use case to render a taxonomy menu by linkset feature.

We're using Drupal 10.2.5, taxonomy_menu 3.6

The test in merge request does not update the menu item shown in linkset endpoint, please see the gif below where I'd unpublished the term.

Steps with old patch:

1. Unpublished term
2. Refresh to check menu item disabled, yes
3. Refresh endpoint of linkset menu to have menu item disappear, still exists

I've figured out another fix that successfully updates the menu item's "enabled" property while also affects linkset endpoint.

Steps with new patch:

1. Unpublished term
2. Refresh to check menu item disabled, yes
3. Refresh endpoint of linkset menu to have menu item disappear, the unpublished menu item disappears as well

g-brodiei → created an issue.

Sure! thank you for the feedback in such short notice!

g-brodiei → created an issue.

Confirmed this happens on webform_migration for 2.0.x and Drupal 10.2.5

Settings form element from '#unique: false' to '#unique: NULL' resolves this webform unique issue.

Set the branch target to 2.0.x-dev

Provides MR and update patch for 2.0.x-dev that resolves this bug, set back to NR.

g-brodiei → made their first commit to this issue’s fork.

  /**
   * Display last registered user to visitors block.
   */
  protected function showLastRegisteredUser(): string {

    $last_user_uid = $this->database->select('users', 'u')
      ->fields('u', ['uid'])
      ->orderBy('uid', 'DESC')
      ->range(0, 1)
      ->execute()
      ->fetchField();

    $user = $this->entityTypeManager->getStorage('user')->load($last_user_uid);
    $username = [
      '#theme' => 'username',
      '#account' => $user,
    ];

    $item = $this->t('Last Registered User:') . $this->renderer->render($username);

    return $item;
  }

#12 applies cleanly to 2.x-dev, but the render array of 'Last registered user' still escapes html element, setting back to NW, thanks!

Created MR for 6.2.x

Providing another patch that applies against 6.2.2

Set to NR.

g-brodiei → changed the visibility of the branch 3440309-first-option-of to hidden.

Provide demo webform yaml file.

g-brodiei → created an issue.

+++ b/src/Plugin/Block/VisitorsBlock.php
@@ -265,7 +265,7 @@ final class VisitorsBlock extends BlockBase implements ContainerFactoryPluginInt
+    $item = $this->t('Total Visitors:') .$count;

@@ -295,7 +295,7 @@ final class VisitorsBlock extends BlockBase implements ContainerFactoryPluginInt
+    $item = $this->t('Registered Users:') .$registered_users_count;

Thanks for the patch, works fine on 2.16, just some nit picks I see here, need to add space for concatenation.

This issue seems to be an duplicate of 🐛 Remove Not rendering HTML Needs work , closing this issue since the other has provided a valid patch that works.

g-brodiei → created an issue.

Even though this issue is postponed, I ran into this request earlier today and needed a patch to allow ckeditor5 to work with uploading webp files.

I'm leaving this MR for the future when other dependent issues are resolved, or others who may need a quick fix to make use of this as a patch.

Tested with 10.1.x
Hope this helps, Thanks!

g-brodiei → made their first commit to this issue’s fork.

Setting to need review, thx!

Provide gif to prove result after applying patch.

Add 1 count per page reload+cron run.

g-brodiei → created an issue.

This should correct the behavior expected from the module's documentation → .

I have encountered the same issue and scenario as OP, after looking into this code. I've made change to assure the renderStrategy string may be fetched from the correct source, whether it's from the Plugin Configuration or the settings object.

Settings to needs review.

g-brodiei → made their first commit to this issue’s fork.

You're welcome, glad it worked out for you!

Removing assigned, and hopefully a lovely person may review the code to set it to RTBC (reviewed and tested by the community), then that will be terrific!

Hi @binkdot5,

On what version are you using atm? I've generated this patch for 8.x-1.x, which is tagged as 2.0.1

If the patched was skipped, then the patch will not take effect at all.

How I patched the project was like the following:

composer require drupal/role_login_page:^2.0
composer require cweagans/composer-patches:^1.7

Under composer.json, look for the extra section, add a patches within.

You can either use the online patch file, or download it into a directory locally for composer to use (point it to './patches/xxx.patch')

Once it's updated, use composer install to apply the patch
composer install

Hope it works for you. We're using drupal 9.5.10, role_login_page 2.0.1

Set to needs review

This issue is caused by the stdClass fetched from DB that was set as default param in the route class.

Attempt to resolve this by converting stdClass data into array, and update the way how data are fetched within the module code base.
(e.g. from using '->' to ['key']).

Since this is merely a document change, I believe the description is now clear to explain what this method do as OP originally proposed.

Applied patch cleanly to 10.1.1

Changes are seen on web/core/lib/Drupal/Core/Test/FunctionalTestSetupTrait.php

Set to RTBC

Thank you for spending time to attend to this issue!

Trying to reproduce with the following steps, but the issue described did not show.

1. Installed Drupal version: 10.0.9 locally
2. Copy example.settings.local.php to /sites/default/settings.local.php
3. Uncomment last paragraph to in settings.php to take settings.local.php to override
4. Check development.services.yml has the following http.response.debug_cacheability_headers: true under parameter section.
5. Clear cache
6. Open site homepage and chrome devtools
7. Navigate to Network tab on devtools and click on the homepage link shown in image
8. See response headers for X-Drupal-Cache-Contexts, X-Drupal-Cache-Max-Age, X-Drupal-Cache-Tags, X-Drupal-Dynamic-Cache
9. The Response Headers show as expected, can't reproduce

Hi @lanapt,

For module development, you may look into Documentations of module creation.
https://www.drupal.org/docs/develop/creating-modules →

For examples on the possibilities, check the examples project where it provides detailed comment within the project code to demonstrate ideas of what a module could do and override.
https://www.drupal.org/project/examples →

As for the scenario you described, yes it's doable, but you may have some parts to consider and implement before putting your site into public.
Such as:

1. Spam bots, publicly exposed form may be spammed and attacked by bots, which will consume most of your Openai API usage and exceed the limit, you won't want to wake up and see a huge bill by the end of the month. There are numerous modules that handles this on Drupal.
2. Safety best practice on usage of AI tools, please look into https://platform.openai.com/docs/guides/safety-best-practices
3. Billing limit, https://platform.openai.com/docs/guides/production-best-practices/settin...
4. How to write secure code in Drupal, https://www.drupal.org/docs/security-in-drupal/writing-secure-code-for-d... →
5. For more where you need support, please seek help and suggestion on the slack channel #support or #openai

I'm going to close this issue as the original issue is resolved. Best of luck!

Hi @lanapt,

You might need to recheck the credentials you have provided on /admin/config/openai/settings page.

I just bumped into the same issue like yours this morning, it turn out to be me using 'Personal' as the organization id.

It should be 'org-xxx', can be found on https://platform.openai.com/account/org-settings page.

Hope this helps, cheers.

Haha, it must be confusing, thanks for spending the effort double checking, cause I still didn't see it on my account page, probably it's a cache problem.

Will wait and see, cheers!

Hi @larowlan, thanks for crediting everyone, just wanted to check if there is a mis-credit between the two Michaels? (@mstrelan) and me (@g-brodiei)?

Closed
🐛 User language preference is ignored when the default site language is the same as the selected one in the user account Closed: cannot reproduce

This is the guideline policy change discussion issue, I suppose we should give credit to those who have participated within?
🌱 [policy, no patch] Adopt a set of guidelines for closing stale bug reports Fixed

Triaged
🐛 Routing system + authentication system + format-specific routes (e.g. those in rest.module) = frustrating, unhelpful 403 responses instead of 406 responses Needs work

Followed the steps from summary with screenshots, and can't reproduce this issue as well.
Closing this bug as cannot reproduce, if OP may be able to reproduce, please reopen this issue and update the reproduce steps, thanks!

1. Install new site with standard profile [Success, I choose 10.0.8 and 9.5.8]
2. Enable Interface translation module [automatically installs dependency language module]
   
3. Add a new language (French in this case) [same]
4. Keep english as default language [same]
   
5. In language Detection and selection page enable only User and Selected language detection methods [same]
   
6. Select French in Selected language configuration page [same]
7. Edit your admin account and select English in Site language [same]
   

Final result:
P.S. The screen shot was taken after I finished the config setup with admin logged in. So the interface appears in English.

Logged in as admin, displays English interface:

Logged out viewing as anon, displays French interface:

Sorry for the noise, tagging BSI for record.

Updated steps to reproduce and manually tested on 9.5.x

The issue is no longer valid on 9.5.x. and 10.1.x (see screenshot)

Closing it as cannot reproduce.

If this is issue still valid for OP to reproduce on a fresh Drupal install, please reopen it and adjust the steps to reproduce for future contributors to debug. Thanks!

Checked the page → , wording changed as suggestion, thanks!

Set to RTBC

Saw this issue from bug smash initiative channel from @quietone to check wordings on policy page.

+1 on the policy change. I’ve read through the threads and notice a slight wording diff on the policy page.

On the issue summary:
If the stale issue meets these criteria, it should be closed:

On policy page → :
if an issue meets these three criteria, it should be closed:

I believe the word `three` would make it clearer for future readers (not native English speaker) to understand the criteria, thanks!

Adding new tags for steps to reproduce and requires summary update for new contributors to step in easier.

Setting status to needs review, still needs tests to be written

andy-blum → credited g-brodiei → .

Wow, didn't realize I'd get credit for this, thank you making the effort.

andy-blum → credited g-brodiei → .

andy-blum → credited g-brodiei → .

I see, thanks for the info @Mingsong!

adding new tag

Hi, will you elaborate more on the situation where you'd like the custom streamwrapper to be set on image field type?

As image field may only choose it's upload destination of public/private at its field settings page by nature, I'm setting this issue as 'feature request'

If you'd like to support other upload destinations, you may take a look at project https://www.drupal.org/project/s3fs → as ref for how they implements in by code.

Confirms this patch provided works for 2.0.8 and applies cleanly

Review the code implementing the same logic from \Drupal\taxonomy_manager\Controller\MainController Line 48, and works as expected

Thanks for writing this!

Glad it helped @mattea.turnbull! We were affected while updating one of Acquia's distribution lightning/workflow.

Rewriting title for easier understanding.

Changing to critical as this bug deletes node, paragraph contents.

Confirms #5 patch works on drupal core 9.5.2 + amswap 3.1!
Thanks for the effort!!