🇧🇷Brazil @charlliequadros

Patch from comment 14 updated for compatibility with Drupal 10.4.1. Available for anyone who needs it.

Hi @romulasry, I believe this error is expected.
You need to add a token because, when the module generates URLs automatically, it requires something to differentiate them.
You can try something like "/board/term/[node:title]" or click on "Browse available tokens" to check which token best fits the 'forum' pattern type.

This patch was modified to work with Drupal 10.3.6.

When the user does not select the 'Enforce auto logout on admin pages' option and leaves a window open on a non-configuration page, the system continues counting the time and logs out, even if the user is working on a configuration page in another window. To prevent this, I added this part to the code

 if (localSettings.refresh_only) {
        // On pages where user shouldn't be logged out, don't set the timer.
        localStorage.setItem('autologout_page_activity', 'true');
        t = setTimeout(keepAlive, localSettings.timeout);

which keeps the session active at all times while the user is on an administrative page.

updated patch

charlliequadros → created an issue.

I was also facing the issue when removing the condition, so I updated the patch.

Hi @cilefen,

I followed your suggestion to identify when the issue was introduced.

This issue arose during the resolution of this issue. https://www.drupal.org/project/drupal/issues/3414287 📌 Avoid reading session from the database multiple times during a request Needs work

I couldn’t determine which call was removed to avoid two database requests. Was it "$request->getSession()->save();" or "$this->session->start();

Hi @catch,

I created this issue https://www.drupal.org/project/drupal/issues/3468632 🐛 The session is not being updated. Needs work and, upon investigation, identified that the problem was introduced by this issue. I’d like to understand if the issue is related to calling the
$this->session->start() function twice.

Could you help me clarify this?

Thank you!

Hi @cilefen

In Drupal version 10.2.7, the user's session was updated with each request, meaning that as long as the user interacted with the site, the session time was refreshed, preventing it from expiring during use. However, after updating to version 10.3.0, this behavior changed: the session time is no longer updated. So, if the timeout is reached, the session will be automatically closed, regardless of what the user is doing, such as during content creation or editing, for example. What's not working after the update is the session time being refreshed while the user is interacting with the site.

I created an MR. I'm not sure if it's the best solution, but it solves the problem until someone can fix it properly. I'm available to work on this ticket if anyone can help me figure out a permanent solution to the issue.

charlliequadros → created an issue.

Patch updated to Drupal version 10.3.1.

Hi @Chandansha,
I added the check that @mfb requested in the function where the error occurs. I hope you don't mind.

Hi @smustgrave

The issue occurs because when an unknown file type is created, it doesn't find the MIME type, resulting in a null return from this function.

https://git.drupalcode.org/project/drupal/-/blob/11.0.0/core/lib/Drupal/Core/File/MimeType/ExtensionMimeTypeGuesser.php#L929

One solution would be to set 'application/octet-stream' as the MIME type for unknown file types. This would prevent the error from occurring. However, I'm not sure if this would be the best approach or if the current implementation in the MR is sufficient, as it already resolves the problem.

fixed patch 15

resolve the conflicts they were having
@aaron.ferris

Patch update to the latest released version 3.0.0-rc2.

I will work on this ticket

I will work on it

charlliequadros → made their first commit to this issue’s fork.

charlliequadros → made their first commit to this issue’s fork.

I tested the patch #3, and it worked as expected for me.

I've created a MR, if there's any adjustments needed, please let me know.

The getRawData function wasn't returning the altered data from the settings file, leading to the inability to retrieve the added settings data. Following the suggestion from [name of the person who made the suggestion], it was changed to the get method, which retrieves all data, including those being overwritten in the settings. If my contribution was helpful, please consider giving me some credit. Thank you very much!

charlliequadros → made their first commit to this issue’s fork.

charlliequadros → made their first commit to this issue’s fork.

As mentioned on #258 the patch from #257 can't be applied to Drupal 10.2, therefore I created a new patch for it.

I couldn't apply patch from #69 using version 10.2.1, therefore i'm attaching an updated version of the patch.