Montpellier, France
Account created on 16 September 2010, over 14 years ago
#

Merge Requests

More

Recent comments

🇫🇷France duaelfr Montpellier, France

Hi there!
Thank you for working on this issue.
Beside @jonathanshaw comments on the MR, this needs to be rerolled now a few changes has landed.
Cheers!

🇫🇷France duaelfr Montpellier, France

This issue is worked on in Add support for media reference fields Needs review

🇫🇷France duaelfr Montpellier, France

Thank you for suggesting that change!

🇫🇷France duaelfr Montpellier, France

Thank you all for your help with this!

🇫🇷France duaelfr Montpellier, France

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

🇫🇷France duaelfr Montpellier, France

Rerolled on 2.1.x (sadly this version has no release so we cannot tag the issue on it).
Patch added for composer.

🇫🇷France duaelfr Montpellier, France

MR with proposed changes open and the related patch for composer.

In my case (huge job item), the call to the trackChangedSource method has been reduced from 83.88773 seconds to 0.34245.
The calls to the flatten method from the trackChangedSource method has been reduced from 1966 occurrences to 1.

I hope tests will pass even if I believe so, given the changes I made.

🇫🇷France duaelfr Montpellier, France

duaelfr changed the visibility of the branch 3513777-simplify-getcropentity to hidden.

🇫🇷France duaelfr Montpellier, France

Note: the issue doesn't happen when manually updating interface or config translations

🇫🇷France duaelfr Montpellier, France

This issue is really annoying for websites using dialogs on front-end because gin_toolbar does not take permissions like view the administration theme into account when loading its CSS. The result is broken dialogs for non-admin users.
The MR suggests a workaround to disable all gin dialog-related styles on frontend but it kind of defeats the purpose of the module for admin users. Would it be possible to implement something like @webflo's suggestion?

🇫🇷France duaelfr Montpellier, France

Code from #89 included in a MR against 11.x
+ fix for JS errors on pages without query string
+ patch for composer

🇫🇷France duaelfr Montpellier, France

The module supports D10 right now.
The accessCheck() method on entity queries will be added to the next major version (D11 compatibility).
See https://git.drupalcode.org/project/extra_field/-/commit/d4752a8125ed4661...

🇫🇷France duaelfr Montpellier, France

Thank you for your contribution on this module!

I first thought it should be in the ImageImport plugin but I then saw your explanation and looked back at the code and saw how much more complicated it would be, so I think it's okay that way.
The MR doesn't apply on 2.0.x, though, so it needs to be rerolled (and maybe even moved to 3.0.x).
🇫🇷France duaelfr Montpellier, France

@idebr Of course! Sorry for the mistake (twice in a row, I must have been tired this day...)

🇫🇷France duaelfr Montpellier, France

Improved document structure for better readability

🇫🇷France duaelfr Montpellier, France

I don't know why I was convinced that 4.X was D11 only. My bad.
Is it better like this?

🇫🇷France duaelfr Montpellier, France

@anybody There you go.
Now Show machine name in "Manage form display" and "Manage display" table row Fixed has been released. This causes an issue where the weight field for the field_group line is displayed. Dragging the field_group around is still functional but it can be troubling for end users.

🇫🇷France duaelfr Montpellier, France

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

🇫🇷France duaelfr Montpellier, France

@pcambra Sorry for that mistake. I didn't check the target branch when I opened the MR…

🇫🇷France duaelfr Montpellier, France

@pcambra Yes, of course!
@chi-teck/drupal-code-generator@ is the package that provides all the Generator related stuff to Drush. The generator classes provided by the Extra Field module extends @DrupalCodeGenerator\Command\BaseGenerator@ so when static tests are running we need to tell Gitlab CI to download this dependency to prevent code analysis to consider that these classes does not exist.

🇫🇷France duaelfr Montpellier, France

Parent issue landed. Removing the postponed status.

🇫🇷France duaelfr Montpellier, France

No, I don't think so!
I has been marked as deprecated in 2.x so it should only be removed from 3.x branch before the first stable release.

🇫🇷France duaelfr Montpellier, France

(Patch attached for composer)

🇫🇷France duaelfr Montpellier, France

@pawelgorski87 Thank you for your contribution. The maintainer (aka @pcambra) asked to only handle things related to D11 compatibility in this issue, though. That's why those other fixes had been done in 📌 Fix code quality issues reported by GitlabCI Active . Would you mind rollbacking your changes, please?

🇫🇷France duaelfr Montpellier, France

What I'm saying is that Drupal Core currently does not allow that. If all fields are disabled, the entity is not displayed.

@pdureau dug a bit in this issue and figured out everything was happening inside \Drupal\field_layout\FieldLayoutBuilder::buildView() and \Drupal\field_layout\FieldLayoutBuilder::getFields().

🇫🇷France duaelfr Montpellier, France

I woke up this morning to see this fixed.
Congratulations and many thanks for this!!

🇫🇷France duaelfr Montpellier, France

I have a similar issue with the following steps to reproduce (also reproduced by @g4mbini on a clean install):

  1. Enable Field Layout
  2. Have a SDC with a string prop
  3. In the manage display form of one of your node types, in the layout settings section, select your SDC
  4. In the props settings, for your prop select "Referenced entities" the any referenced entity then any option in the Source select
  5. Save your settings to see the error

I applied the patch from the MR and I'm still able to reproduce.
Here is my stack trace:

Drupal\Component\Plugin\Exception\ContextException: The 'entity:node' context is required and not present. in Drupal\Core\Plugin\Context\Context->getContextValue() (line 73 of core/lib/Drupal/Core/Plugin/Context/Context.php).

Drupal\ui_patterns\Plugin\UiPatterns\DerivableContext\EntityReferencedDerivableContext->getDerivedContexts() (Line: 124)
Drupal\ui_patterns\Plugin\UiPatterns\Source\DerivableContextSourceBase->getSourcePlugins() (Line: 470)
Drupal\ui_patterns\Plugin\UiPatterns\Source\DerivableContextSourceBase->calculateDependencies() (Line: 264)
Drupal\ui_patterns\Element\ComponentElementBuilder->calculateComponentDependenciesProps(Object, Array, Array) (Line: 238)
Drupal\ui_patterns\Element\ComponentElementBuilder->calculateComponentDependencies('ccu_theme:card_highlight', Array, Array) (Line: 234)
Drupal\ui_patterns_layouts\Plugin\Layout\ComponentLayout->calculateComponentDependencies('ccu_theme:card_highlight', Array) (Line: 170)
Drupal\ui_patterns_layouts\Plugin\Layout\ComponentLayout->calculateDependencies() (Line: 71)
Drupal\Core\Config\Entity\ConfigEntityBase->getPluginDependencies(Object) (Line: 89)
Drupal\Core\Config\Entity\ConfigEntityBase->calculatePluginDependencies(Object) (Line: 149)
Drupal\field_layout\Entity\FieldLayoutEntityViewDisplay->calculateDependencies() (Line: 328)
Drupal\Core\Config\Entity\ConfigEntityBase->preSave(Object) (Line: 272)
Drupal\Core\Entity\EntityDisplayBase->preSave(Object) (Line: 114)
Drupal\field_layout\Entity\FieldLayoutEntityViewDisplay->preSave(Object) (Line: 528)
Drupal\Core\Entity\EntityStorageBase->doPreSave(Object) (Line: 483)
Drupal\Core\Entity\EntityStorageBase->save(Object) (Line: 239)
Drupal\Core\Config\Entity\ConfigEntityStorage->save(Object) (Line: 354)
Drupal\Core\Entity\EntityBase->save() (Line: 617)
Drupal\Core\Config\Entity\ConfigEntityBase->save() (Line: 293)
Drupal\Core\Entity\EntityForm->save(Array, Object)
call_user_func_array(Array, Array) (Line: 105)
Drupal\Core\Form\FormSubmitter->executeSubmitHandlers(Array, Object) (Line: 43)
Drupal\Core\Form\FormSubmitter->doSubmitForm(Array, Object) (Line: 589)
Drupal\Core\Form\FormBuilder->processForm('entity_view_display_edit_form', Array, Object) (Line: 321)
Drupal\Core\Form\FormBuilder->buildForm(Object, Object) (Line: 73)
Drupal\Core\Controller\FormController->getContentResult(Object, Object)
call_user_func_array(Array, Array) (Line: 123)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 593)
Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object) (Line: 121)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext(Array, Array) (Line: 97)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 183)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 76)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1) (Line: 53)
Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1) (Line: 48)
Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object, 1, 1) (Line: 28)
Drupal\Core\StackMiddleware\ContentLength->handle(Object, 1, 1) (Line: 116)
Drupal\page_cache\StackMiddleware\PageCache->pass(Object, 1, 1) (Line: 90)
Drupal\page_cache\StackMiddleware\PageCache->handle(Object, 1, 1) (Line: 48)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1) (Line: 51)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1) (Line: 36)
Drupal\Core\StackMiddleware\AjaxPageState->handle(Object, 1, 1) (Line: 51)
Drupal\Core\StackMiddleware\StackedHttpKernel->handle(Object, 1, 1) (Line: 709)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)
🇫🇷France duaelfr Montpellier, France

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

🇫🇷France duaelfr Montpellier, France

MR rerolled on 11.x
Patch attached for composer

🇫🇷France duaelfr Montpellier, France

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

🇫🇷France duaelfr Montpellier, France

Patch for composer with latest changes

🇫🇷France duaelfr Montpellier, France

MR squashed and rerolled.
Patch attached for composer.

🇫🇷France duaelfr Montpellier, France

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

🇫🇷France duaelfr Montpellier, France

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.

🇫🇷France duaelfr Montpellier, France

@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 .

🇫🇷France duaelfr Montpellier, France

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

🇫🇷France duaelfr Montpellier, France

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

🇫🇷France duaelfr Montpellier, France

This have never been so easy ;)

🇫🇷France duaelfr Montpellier, France

@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.

🇫🇷France duaelfr Montpellier, France

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

🇫🇷France duaelfr Montpellier, France

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.

🇫🇷France duaelfr Montpellier, France

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

🇫🇷France duaelfr Montpellier, France

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

🇫🇷France duaelfr Montpellier, France

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"
    },
🇫🇷France duaelfr Montpellier, France

I released 2.0.0-alpha1 and 2.0.0-alpha2 today.

🇫🇷France duaelfr Montpellier, France

This should be natively fixed in 2.0.0-alpha2

🇫🇷France duaelfr Montpellier, France

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

🇫🇷France duaelfr Montpellier, France

Here are updated patches for composer

🇫🇷France duaelfr Montpellier, France

@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?

🇫🇷France duaelfr Montpellier, France

@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.

🇫🇷France duaelfr Montpellier, France

duaelfr changed the visibility of the branch 3176488 to hidden.

🇫🇷France duaelfr Montpellier, France

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

🇫🇷France duaelfr Montpellier, France

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.

🇫🇷France duaelfr Montpellier, France

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.

🇫🇷France duaelfr Montpellier, France

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

🇫🇷France duaelfr Montpellier, France

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

🇫🇷France duaelfr Montpellier, France

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?

🇫🇷France duaelfr Montpellier, France

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.

🇫🇷France duaelfr Montpellier, France

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.

🇫🇷France duaelfr Montpellier, France

There you go!
Thank you for your involvement!

Production build 0.71.5 2024