🇵🇱Poland @alorenc

The function field_group_remove_empty_form_groups expects that groups are ordered from parent to child
Added an additional function which orders groups.

Updated to 'drupal/field_group:^4.0'

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

I was able to replicate the issue consistently.

I created the following nested group hierarchy:
- Level 1 (parent of Level 2)
- Level 2 (parent of Level 3)
- Level 3 (contains the body field)

I then reorganized the structure using the Field Group UI:
- Level 3 becomes the top-level group
- It contains Level 2
- Which contains Level 1
- And Level 1 contains the body field

I exported the configuration and noticed. The weight values were correctly updated. However, the field order in the YAML config remained unchanged, still reflecting the original nesting order.

It looks like the Field Group module builds the field group hierarchy based on the order of items in the YAML configuration file, instead of relying solely on the weight and parent_name properties.

This becomes problematic when reversing the hierarchy (e.g., changing a parent into a child or vice versa), because:
* The updated structure is not respected during render
* Fields and groups may not display correctly, even if weight and parent_name appear valid

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

Tested 2 scenarios: with inline form errors and without inline form errors.
Both look good.

alorenc → created an issue.

alorenc → created an issue.

Merged the latest changes from 1.2.x, resolved conflicts, and provided Stylelint fixes.

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

alorenc → created an issue.

alorenc → created an issue.

Thanks, I was able to replicate it, and the patch resolved the issue.

Thank you; I no longer see the 'Deprecated function: addcslashes(): Passing null to parameter' error.

alorenc → changed the visibility of the branch 3510842-cloning-nested-paragraph to active.

alorenc → changed the visibility of the branch 3510842-cloning-nested-paragraph to hidden.

alorenc → created an issue.

alorenc → created an issue.

alorenc → created an issue.

alorenc → created an issue.

alorenc → created an issue.

alorenc → created an issue.

It has a certain downside: I will have to enter the password every time I want to change the settings
Maybe we can add a checkbox, similar too
https://git.drupalcode.org/project/symfony_mailer_lite/-/blame/1.0.x/src...

Looks fine

I can see a potential issue here: OG 8.x-1.x can be installed on D9, but attributes were added in D10.

I can see a potential issue here: OG 8.x-1.x can be installed on D9, but attributes were added in D10.

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

probably we could add @deprecated to RdfUriGenerator but I am leaving that to maintainer of this module

Created MR based on the previously provided patch.

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

We have a custom ActionLinkType, and I had to provide four parameters to lazy_builder (flag.link_builder:build) - view mode.
At the same time, I had to update getAsFlagLink method, as ActionLinkTypePluginInterface requires $view_mode as well.

alorenc → created an issue.

Okay, I think we can add a module setting that will determine the usage of the queue.

alorenc → created an issue.

It works as expected; the issue was related to customization, which had to be rewritten after the module upgrade.

It looks like the issue is related to my project.
The following code sets view_mode,
https://git.drupalcode.org/project/flag/-/blob/8.x-4.x/src/ActionLink/Ac...

alorenc → created an issue.

alorenc → changed the visibility of the branch 3168014-typeerror-argument-1 to active.

alorenc → changed the visibility of the branch 3168014-typeerror-argument-1 to hidden.

I don’t think this is a good idea.
If you want to clear autosubmit, it means that you probably don’t want to use this module.

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

Please see the attached image. The decision was made by the eTransaction team. I am not happy about it because it complicates testing, but it is what it is.

You can find that on https://language-tools.ec.europa.eu/#documentation
"Guidelines on integrating eTranslation in your web pages", next "How to request translations using the eTranslation webservice" and "SecuredWSEndPointHandlerService"

alorenc → created an issue.

alorenc → created an issue.

Looks fine, Ajax calls do not generate infinite errors.

This has some side effects. If I log in again inside the second tab, the system will no longer update messages in the first tab.
I don't know which option is better

+ for GitLab CI. Could this be merged? It would be highly beneficial for addressing future tickets.

I have exported configuration before applying the patch, otherwise it is fine.

I got the following errors

'views.view.calendar:display.by_month.display_options.pager.options.display_reset' => 'variable type is integer but applied schema class is Drupal\Core\TypedData\Plugin\DataType\BooleanData'
'views.view.calendar:display.by_month.display_options.pager.options.use_previous_next' => 'variable type is integer but applied schema class is Drupal\Core\TypedData\Plugin\DataType\BooleanData'
'views.view.calendar:display.by_week.display_options.pager.options.display_reset' => 'variable type is integer but applied schema class is Drupal\Core\TypedData\Plugin\DataType\BooleanData'
'views.view.calendar:display.by_week.display_options.pager.options.use_previous_next' => 'variable type is integer but applied schema class is Drupal\Core\TypedData\Plugin\DataType\BooleanData'

Rolled 2765065-10.3.x-154.diff to Drupal 10.4.x

Looks ok on my side, triggered
composer require 'drupal/field_group:^4.0@alpha'
and next
composer require 'drupal/field_group_nav:^1.0'

I performed some manual test based on 4.0.0-alpha1 module, looks ok.

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