🇫🇷France @duaelfr

duaelfr → created an issue.

duaelfr → created an issue.

Real work is done here: 📌 Automated Drupal 11 compatibility fixes for extra_field Needs review

Here is a patch for composer that applies on 11.x

MR rerolled on 11.x
Patch attached for composer

duaelfr → changed the visibility of the branch 3326950-expose-imageitem-width to hidden.

Patch for composer with latest changes

Rerolled MR.
Patch attached for composer.

MR squashed and rerolled.
Patch attached for composer.

Patch for composer :)

MR !4294 squashed and rerolled

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

Hi @manuel.adan!

Thank you for reporting this.
I am aware of that issue and I filled a request on the appropriate issue queue to get this fixed: 💬 Extracting a submodule in its own module Active

While it's really unexpected and not ideal, it doesn't prevent the module from working.
I hope this is going to be fixed soon but in the meantime there is nothing we can do.

@niharika.s Thank you for trying to help here!
Sadly, updating the info.yml file was not what was expected here. For these changes, the appropriate location is 📌 Automated Drupal 11 compatibility fixes for extra_field Needs review .

duaelfr → created an issue. See original summary → .

PHPUnit tests fix is related to 📌 Automated Drupal 11 compatibility fixes for extra_field Needs review

Postponing because most remaining issues in phpstan and phpunit are related to these other issues

This have never been so easy ;)

duaelfr → created an issue.

duaelfr → created an issue.

@pcambra #19: Changes in test classes may seem unrelated but tests are failing without these because classes ending with "Test" are considered as test classes by PHPUnit so it tries to run them.

duaelfr → changed the visibility of the branch project-update-bot-only to hidden.

This is the last module I need to be able to move my project template to D11!

So, I focused on things to fix for D11 compatibility (+ unit tests).
Now GitlabCI is enabled, we'll need a followup issue for coding standards cleanup, though.

Plus, according to deprecations in this module's code, some changes also have to be made before releasing a 3.0 version (see \Drupal\extra_field\Plugin\ExtraFieldDisplayManagerInterface::fieldInfo()). I believe that should be another followup task.

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

Hi @eiriksm
Thank you for committing that!
Would you publish a new release so people can enjoy this module using D11? ;)

duaelfr → created an issue.

The current state of this module needs the following patch applied on field_group

    "drupal/field_group": {
      "
            
              
              
              ✨
              Add $form and $form_state parameters to formatter plugins' settingsForm method
                Active
              
             Add $form and $form_state parameters to formatter plugins' settingsForm method": "https://www.drupal.org/files/issues/2024-12-20/3495221-4.patch"
    },

I released 2.0.0-alpha1 and 2.0.0-alpha2 today.

This should be natively fixed in 2.0.0-alpha2

You can call me stupid :D
MR and patch updated with the most important part

Attaching patch for composer

duaelfr → created an issue.

Here are updated patches for composer

@andypost I accepted your suggestion an rebased the branch on 11.X
I have no idea how to write the deprecation test, though. Would you guide me, please?

Minor changes for clarity

@apotek Hi! I think there is a small misunderstanding.

Drupal Core provides two different hooks to manage updates:
- hook_update_N whose implementations have to be located in .install files and are ran sequentially from the lowest to the highest N value for a given module (hook_update_dependencies can declare dependencies between hook updates from different modules)
- hook_post_update_NAME whose implementations can be located in a .post_update_.php file and are ran sequentially in alphabetical order (these cannot declare dependencies)

Both these hooks are executed when running drush updb or using the update.php route.
It was once possible to separate them with the --no-post-updates option in drush but it is not available anymore.

The need described in this issue was to be able to run code once (like those hooks), after the configuration has been imported because update hooks are meant to be ran before config import. The proposal was to introduce a new hook_post_config_import_NAME hook but it turned out to be a bad idea because we were trying to solve an issue related to the deployment process and not the update process.

This is when drush released their drush deploy command which was running updates, then config import, then a brand new hook they created: hook_deploy_NAME. This solved all issues mentioned above so the development of this post import hook was abandoned.
But, as some people pointed out already, drush is not part of the Core so it would be better to have this in Core than only rely on an external dependency. That's why this issue ✨ Add new route to run deploy hook implementations from the UI Active has been opened (even if its current title can be misleading) .

I hope this helps you understand the current status of this and consider pushing this topic forward in the related issue.

Duplicate of 📌 PHP 8.2 compatibility Needs work

duaelfr → changed the visibility of the branch 3176488 to hidden.

duaelfr → changed the visibility of the branch 2.x to hidden.

I created a new branch from !10's code on top of !12 (from 📌 Support content language in the selection mode Needs review ) so we can apply both patches in our projects.
We'll adapt when one of those issues is committed.

Back to RTBC which is the status of !10.

Extracted the code related to this from #3176488-12: support other translatable entities → in a MR.
Both MR cannot be applied on the same codebase until this comment ✨ support other translatable entities Needs review has been solved.

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

Opened a MR
Added a patch for composer
Still needs tests to showcase the issue (help needed here)

duaelfr → created an issue.

I also have this issue on one of my projects.
After xdebugging this, I figured out that the issue happens in \Drupal\path\Plugin\Field\FieldWidget\PathWidget::validateFormElement() where Drupal checks that the given alias doesn't already exists for another source but the same language.

During the usual process, either the alias is empty (new node) or the alias matches the source (node edit).
In our case, the alias is set to the cloned one by \Drupal\quick_node_clone\Entity\QuickNodeCloneEntityFormBuilder::getForm() but the source is empty so it doesn't match.

I can see two ways of solving this:

1. we unset the path alias before creating the new node or before building the form
2. this is not working because it needs a saved entity

Ideally, we should unset the path alias only if the pathauto checkbox is checked but we don't know that before building the form unless we look into the Request which seem really dirty.

FIY the following hook implementation fixes the issues but it's not really clean either:

/**
 * Implements hook_cloned_node_alter().
 */
function MY_MODULE_cloned_node_alter(NodeInterface &$node) {
  $node->path->alias = NULL;
}

Does someone here with a big brain have an idea to fix this issue?

I'm not sure I understand your use case and I'm not sure this patch would allow you to achieve your goal.

My proposal is a very simple implementation of tokens for nested arrays (now I can see how it is confusing with the issue title and might be out of scope).

Before my PR, it was not possible to access deep values of a nested array with tokens because the last part of the token was considered as a simple key, even if it contained colons. Now, if there is no value with the key and if it contains colons, we explode the key and use it as a nested array selector to get the value.

I can't write examples because I'm on my phone but if it's still not understandable enough, tell me and I'll try again later.

I don't think anyone is ever going to fix these issues but I'd keep them until D7 official EOL because someone might want to get a patch from them and might not think to search in closed issues. Marking the D7 release as unsupported is totally okay, though.

There you go!
Thank you for your involvement!

Hi Dieter!
Thank you for stepping up and offering to maintain this module.
As a package, would you also want to maintain the Required by role → module? ;)

@christian.wiedemann Sorry my comment was unclear.
The idea was to replicate the feature of \Drupal\Core\Render\Renderer::mergeBubbleableMetadata() without calling the renderer service, which is not needed here.
I added a commit to the MR to illustrate.

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

duaelfr → created an issue.

Here are the patches I use. I don't know if it covers your use case but it's worth a try!

        "drupal/ui_patterns": {
            "Support extrafield": "https://github.com/nuvoleweb/ui_patterns/pull/282.patch?20211019",
            "
            
              
              
              ✨
              Support modules that use field_layout data (eg. field_group).
                Needs work
              
             Support modules that use field_layout data (eg. field_group). ": "etc/patches/upstream/ui_patterns/13.patch",
            "Support fieldgroups nesting": "https://github.com/nuvoleweb/ui_patterns/pull/284.patch?20211019",
            "Allow to use field_group label in patterns": "https://github.com/nuvoleweb/ui_patterns/commit/c09132b8f615ad05cccc201597f74c3801e9c6d8.patch?20211123",
            "Prevent empty groups to be displayed.": "https://github.com/nuvoleweb/ui_patterns/commit/3bb7917e803a23e6d23496f183e4ca92bb4fb6d5.patch?20211130"
        },

Hi @julien tekrane!
I'm using this patch on my projects if it can help you fix that issue.
I hope to get some free time soon to give some love to this module so this kind of patch is not needed anymore.

@andypost Feedback addressed, thanks.

I rerolled !3858 into a new MR based on 11.x.
I converted procedural hooks to object ones.

Attached: patches for composer

duaelfr → changed the visibility of the branch 2585169-alter-local-actions-render to hidden.

It looks good at it's working. Good job!

Hi @patelh84

Thank you for your offer but I don't think a co-maintainership is needed for this module right now.
I published the D11 version yesterday with some fixes provided by the community and I started the 2.1.x branch which will drop CKE4 and D10.2- support.

Keep providing feedback and patches, they are always welcome!
Kindly,

Thank you for maintaining that patch!
As told in #4, I'll wait for the Core issue to be fixed before merging that to stay consistent with the Image plugin.

Nice work! Thank you!

Done, thank you

Duplicate of 📌 Automated Drupal 11 compatibility fixes for editor_file Needs review
Thank you for your work here!

Good job fixing that!

Duplicate of 📌 Automated Drupal 11 compatibility fixes for editor_file Needs review
@prudloff thanks for your work here, I credited you in the other issue.

Adding credits from 📌 Automated Drupal 11 compatibility fixes for editor_file Needs review

Thanks you all for fixing that and testing!

@catch #71: This is exactly what this issue is about. The original issue was caused by the fact the tables names were only truncated. Now we hash the end but we still have to handle the existing values, hence the upgrade path.

Rerolled #53 on HEAD in a MR.
Fixed phpcs and phpstan issues.
Updated the upgrade path to clone tables instead of renaming them. (I wish I could use a Merge query for this but... 🐛 Merge queries should allow setting the conditionTable Active )

duaelfr → created an issue.

Hiding files now there is a MR

@quietone on ##6:
I think I'd like to have two copies of the same table more than having to maintain that legacy way of handling migrate tables.
If we decided to follow the flag way, one day we would certainly like to deprecate that and prepare a new upgrade path that would be the same as the one we would code today, isn't it?

Rerolled patches in a new MR
Addressed some comments from #49 (points 1 and 3)

Rerolled MR on HEAD
Added patch for composer

Rerolled MR on HEAD.
Updated IS.
Added a patch for composer.

Patch #64 applies on Drupal 10.3.x and fixes the issue.
I updated the IS and I believe that comments from #60 and #61 don't apply anymore with the approach followed in the patch.

For novices: please convert #64 patch to a MR to ease maintainers job.

Looks good!
There is no white/blacklist terms remaining in the codebase and the new wording is good.
Thanks!

duaelfr → created an issue.

@Grimreaper you were right! Thank you!

Hi there! Thank you for supporting that.
Wouldn't it also be needed for the other formatter? I guess that's what one would expect if using "UI limit".
Would you mind updating your MR accordingly?

There we go! Thank you for waiting that long!

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

Sorry for the massive delay...
Rebased and added dependency injection because I like that better ;)
Thanks!

Thanks!

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

Thanks

Good catch!
Fixed for both branches.

Ported to 2.x too :)

That was a good point :) Thanks!

Thanks!

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

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

Hi there!
Good point, thank you for fixing that.
I took some time to weight adding the ui_patterns_settings related elements or letting that responsibility to someone else. I decided that we could handle that for now and remove it later if someone upstream has a cleaner solution.