🇺🇦Ukraine @UsingSession

Hi @achap,

I checked Merge Request !120 – the "Content language and translation" form is being saved successfully.

"Support adding new entities when translating" also seems to be working correctly.

Thank you

@achap Attaching a screenshot.

I agree with comment #139, I came across it by accident.
The following code causes this behavior (in inline_entity_form.module):

  // A translation submit handler for the case where the main entity
  // changes its language code but the widget is not active.
  WidgetSubmit::attach($form, $form_state, TRUE);

usingsession → changed the visibility of the branch 3428552-drupal-compatibility-fixes to hidden.

As @anairamzap mentioned above, if you need a patch for the stable version 8.x-1.4, you can use the attached file below.

usingsession → changed the visibility of the branch 3428552-drupal-compatibility-fixes to hidden.

I agree. It will be nice

usingsession → created an issue.

usingsession → created an issue. See original summary → .

I created MR!24 to remove the deprecated method.
I don’t quite understand why the Project Update Bot MR!22 suggests specifying the return type for getSubscribedEvents() — it doesn’t affect compatibility.

To review MR!24

Considering the recent changes made in Render the popup with a template 📌 Render the popup with a template RTBC , it makes sense to replace renderPlain with renderInIsolation.

I changed the version because, as I understood from the article — Merge request guidelines → — this is the correct approach.

Thank you for providing the patch. I’ve tested it, and it resolves the issue as expected.
So, I created the MR and merged it

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

@prudloff, I believe the correct one to review is MR !4

usingsession → changed the visibility of the branch 3428552-drupal-compatibility-fixes to hidden.

usingsession → created an issue.

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

About 3428552-drupal-compatibility-fixes-stable-1.4 - I tried to create a patch for module1.4, but composer.json always fails.
!MR6 - also fails

usingsession → changed the visibility of the branch 3428552-drupal-compatibility-fixes-stable-1.4 to hidden.

In PR4 Issue #3428552: Drupal 11 compatibility fixes for config_override_warn everything looks ok.
But I created new PR based on it, because in my opinion, I see no reason to wait for Drupal 12 to remove it.

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

usingsession → created an issue.

Hi @papa-ours, thanks for your contribution.

I just tested this on Drupal 10.4.0 and couldn't reproduce the issue.
Could you please provide more detailed steps to reproduce (STR) or confirm if the issue is still valid?

Hi @octaviosch, thanks for your contribution.

There is an error in the patch.
The change refers to a missing file named izi-message-copy.html.twig,
but it should be izi-message.html.twig.

@raveen_thakur51
Thank you for creating the issue.
This problem has already been resolved in the next release (2.0.3).
You can check it here: ArgumentCountError: Too few arguments to function 🐛 ArgumentCountError: Too few arguments to function Active

If you have any questions, I’ll be happy to answer.
Also, please let me know after the update if everything works as expected.

@3eidoz Thank you for reporting the issue. I have prepared a PR to check if everything is okay.

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

@oily Thank

@smustgrave Yep, sorry about that. I have already closed the old one.

usingsession → changed the visibility of the branch 3502900-inappropriate-error-when to hidden.

My mistake, everything works as expected.

usingsession → created an issue.

I've added a test to cover this scenario: testUpdateFieldStorageDefinitionThrowsException(). This test ensures that attempting to change the cardinality of a field with existing data correctly triggers the FieldStorageDefinitionUpdateForbiddenException. This approach verifies that the fix is properly enforced and prevents unintended schema changes.

@smustgrave Okay, I will write soon.

I believe we could simplify this by adding a check for the presence of $table before array_intersect_key.
However, in my opinion, the current solution is better because it provides a clearer understanding of the situation.

Regarding the pull request for the branch "3502900-inappropriate-error-when" – the issue with the failing test is related to Catch potential exception when calling Request::create() in PathBasedBreadcrumbBuilder 🐛 Catch potential exception when calling Request::create() in PathBasedBreadcrumbBuilder Needs review

For 11.x everything is fine.

@oily

Looks like test coverage goes in SqlContentEntityStorageSchemaTest.php

Okay than, I will try to investigate in more detail.

A current failed test is not related to my issue.
You are able to see error in raw log pipeline .

An appropriate screenshot with the error is attached.

usingsession → created an issue.

@natefollmer Thank you for the update. I’ve tested the patch in my environment, and I’m not encountering the mentioned JS error when clicking 'Yes' to keep the session active. Let me know if there's anything specific (role, autologout settings et.)

Added the classes:

1. ui-dialog-state-transition-form
2. ENTITY_TYPE_ID-state-transition-form

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

While developing this functionality, my primary goal was to avoid creating something new with plugins and implement it as simply as possible. Therefore, a significant portion was described within a hook.

In my opinion, the label configuration could be moved to a plugin, but this would require creating an instance, which might impact performance (though it might not).

I also updated the GitLab CI configuration to enable testing on Drupal 10, as the extra_field module does not yet have a version compatible with Drupal 11 - see If what you want is to run linting and tests under Drupal 10 💬 Disabling OPT_IN_TEST_CURRENT not working Active

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

@natefollmer I fixed the patch

@natefollmer I will take a look over the next few days. It is because the patch has some conflicts.

@dudeweb It seems that this issue does not belong to this module. Please specify which version of Drupal you are using, as well as Commerce. Have you updated Drupal to version 11?

- drupal/commerce_store[2.32.0, ..., 2.40.0] require drupal/core ^9.3 || ^10 -> found drupal/core[9.3.0, ..., 9.5.11, 10.0.0, ..., 10.4.0] but the package is fixed to 11.1.0 (lock file version) by a partial update and that version does not match. Make sure you list it as an argument for the update command.

This message indicates a conflict between the required version of drupal/core and the version fixed in your composer.lock file. The range [2.32.0, ..., 2.40.0] of drupal/commerce_store supports drupal/core versions ^9.3 or ^10. However, your composer.lock file specifies drupal/core version 11.1.0, which is outside this range.

@arantxio
I'm not quite sure if I understood, '...i've noticed if you are browsing other sites it won't give you any warning at all...'.
What exactly did you mean (or expect) in this case (alert, Drupal message ...) ? Perhaps I misunderstood you.

Made a few small changes (described above), can you use the patch or fork branch.

@arantxio

There is truth in your words, indeed. After more detailed testing, I concluded that the previous implementation of destroying the dialog if the page is inactive is a bad idea.

Reason for this modification:

Steps to Reproduce (STR):

1. Set Timeout padding to, for example, 45 seconds.
2. Set Timeout value in seconds to, for example, 120 seconds.
3. Open two tabs and remain inactive in both simultaneously.
4. Wait until the notification appears in both tabs.
5. In one of the tabs, click "Yes" to extend the session.
6. Monitor the other tab where the popup is still present. After 45 seconds, the user will be logged out, even though they were active in the other tab.

Cause:

The logout method is triggered if the user does not interact with the dialog. The logout, in turn, sends a request to the /autologout_ajax_logout or /autologout_alt_logout route, which ignores the last activity and logs the user out.

Solution:

1. Remove autologout_page_activity from localStorage according to the Timeout padding instead of after 30 seconds. I implemented this variant (issue fork).
2. Add a check in the altLogout/ajaxLogout route method, referencing the autologout_last value from the session. - This variant more complex

I fixed the test, but I made a mistake with the branch name (Sorry about that).

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

@kdmdrupal I'm glad I could help

usingsession → changed the visibility of the branch 3494257-custom-tokens-tests to hidden.

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

@kdmdrupal This issue likely arises from applying a patch related to enabling JS Cookie dependencies 🐛 Multiple warnings after upgrading to 8.x-1.5 & 2.x with js_cookie Active , which may have introduced conflicting code. So, please just delete patch from "patches" section in composer.json. After that, reinstall the module

The patch in #3395581-13 works but has two main issues:

Multiple Tabs: If the user has several tabs/windows open, the dialog may appear in an inactive tab while the last active tab isn't focused. This can cause confusion.

Switching Tabs: When switching tabs, the confirmLogout timer is triggered in the inactive tab, while the dialog appears in the active one. This creates inconsistent behavior.

Fixes:
document.hasFocus() is used to ensure dialogs only appear in focused tabs.
blur event clears the paddingTimer and destroys dialogs for inactive tabs.

Patch below may improve multi-tab handling.

@anybody, okay, I got it :)

Thank you, Ahmed Eid (3eidoz), for creating the issue.
This was an important point, and I'm glad to inform you that a solution has already been found and included in the latest release.
Thanks again for your contribution!

UsingSession → created an issue.

@ady1503 Oh, okay, sorry. We will monitor the situation, I also ask you to remain active in this issue, as soon as I find a solution I will provide a patch.
Thanks for using my module :-)

@ady1503 Please try my " 3458283-izi-messag-stopped-working-with-drupal-10.3.patch → " patch only.
It is not necessary to use the patch from the 10.3 upgrade now missing status-message theme suggestions 🐛 10.3 upgrade now missing status-message theme sugestions Active issue

@ady1503 Just in case, did not use these two patches together?

@ady1503 Did you clear your cache?

About which cookies are created when popup is showing ?
Please provide more information

Added for review about the page update.php (or MAINTENANCE_MODE)

@freelylw It has been tested and no problems have been observed. Please review the settings:

Show Better Messages on specific pages

should be:

Show on only the listed pages.

if you want to see popup message on this pages

As said @rleela

this is not a Better Messages issue, this happens because Bootstrap theme is flushing all messages after it gets them

also Bootstrap render message with custom template