🇪🇸Spain @unstatu

Added a patch to make the exception management more generic.

unstatu → created an issue.

wow! that was fast. Thanks!

Implemented the fix in the MR.

Attached the patch as well.

unstatu → created an issue.

Used the entity repository to load the translated version of the entity based on the context.

unstatu → created an issue.

Thanks for the contribution. Merged!

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

unstatu → created an issue.

Thanks @akalam. I have reviwed and merged the MR.

Hello,

I had the same problem but the solution provided in #5 was not working for me. It was appending the language prefix to the URL.

So, with #5, the assets were being loaded from `domain.com/en/sites/default/files/...` instead of `domain.com/sites/default/files/...`.

I have slightly modified the URL generation to avoid this problem.

Giving you credit @akalam

Thanks you for the fix!

I have implemented a first version of this feature.

In order to use it you will have to create a media type using the "Remote file" source plugin. This "Remote file" plugin is provided by this patch.

Then, you should be able to create media entities from the entity media form itself and also from the media library widget.

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

I messed up with the paths.

This version has the same code but with the correct paths.

I have improved the approach taken by #29 in order to only remove the inputs existing in the exposed form from the URL used by AJAX.

I did this because I found a problem using the media library with this patch applied. The steps to reproduce the problem are the following :

- Open the media library modal of a field widget
- Use the exposed form in the media library modal and send the form to filter the results
- Select any media and click insert
- You will get the following error: "The opener ID parameter is required and must be a string."

This happens because the patch in #29 is removing the query parameters required by the media library (in addition to the ones present in the exposed form) when the AJAX call is done.

I confirm that #29 fixes the issue.

Fixed usage of wrong variable

Added a guard clause.

Hello @Berdir,

Does your proposal still valid? Does it worth to put effort on this?

In that case I could invest some time to try to push this issue.

The pipeline finally passed. This patch matches the latest state of the MR https://git.drupalcode.org/project/drupal/-/merge_requests/8707 with the pipeline in green.

Created a new MR based on 11.x and fixed the bot reported problems: https://git.drupalcode.org/project/drupal/-/merge_requests/8707

I have changed the base branch from the issue. I'm going to change the base dev branch from the MR as well

Thanks for the feedback, smustgrave. On it.

Adding a patch with the latest status of https://git.drupalcode.org/project/drupal/-/merge_requests/8706

I have created a new MR (https://git.drupalcode.org/project/drupal/-/merge_requests/8706) with the following changes:

- Changed the test to return different tokens depending on the passed entity so we don't rely on the onConsecutiveCalls() approach. IMO the new approach is more consistent.

- Reseted the $alias_tokens_mapping array on the inner loop as suggested in #82

unstatu → changed the visibility of the branch 1920688-support-multiple-instances to hidden.

unstatu → created an issue.

Thanks @mark_fullmer for the feedback and for writting the documentation. I have added the url_embed.api.php file with the documentation.

Hello everyone,

I have been struggling with the same problem that was mentioned by stamina in https://www.drupal.org/project/default_content/issues/2698425#mr14-note2... 🐛 Do not reimport existing entities Needs review .

The way to reproduce the problem is:

- Create a layout
- Place an inline block_content with an entity reference field to one or several media images
- Export the node where the layouts was created (including its dependencies)
- If you try to import the node in a different environment, the block_content loses its references to the media entities. Media entities are created correctly but the entity_reference field in the block_content entity is empty.

I have created a patch file based on the current status of the MR!14 adding the fix that he suggested.

Pushed the patch from the MR diff.

I have been able to reproduce the bug with the following configuration:

- Create a Search API index
- Create a facet (configure the facet to be a exposed filter (possible since Facets v3))
- Create a view listing the content
-- Add the facet as a exposed filter
-- Configure the view to work with BEF and select the Links widget for the facet exposed filter
-- Configure any replacement in the "Rewrite the text displayed" option

With this steps, you can reproduce the error.

In addition, I can confirm that applying the patch avoids the Type error but also the "Rewrite the text displayed" feature works as expected.

Fixed the variable name.

Changed the version by mistake.

I have tested the latest version of the MR and it works well in Drupal 10.1.7

Uploading the latest version of the MR in a patch.

This should be possible after https://github.com/spatie/calendar-links/issues/188 is merged

unstatu → created an issue.

jlbellido → credited unstatu → .

Forgot to add the patch.

Thanks @Berdir. I have updated the patch to use the ->alter() method. Good point.

Where should I document the hook usage? In the readme file?

I have applied a small change on the MR in order to improve the detection of the logic that should happen when destination parameter is found in the URL.

Instead of using strpos (that is too generic), I have changed the implementation to use a regex.

I have done that because I found a problem with the following situation:

- Create a page with the following alias /user/my-user-info
- Login with the following URL /user/login?destination=/user/my-user-info
- After login, Drupal redirects to /user/ instead of /user/my-user-info because `strpos` detects the "user" word in the destination parameter

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

I cannot reproduce the problem any more. It seems that https://git.drupalcode.org/project/group_content_menu/-/commit/20cb949fc... fixed the problem.

I have researched the problem without success but I implemented a VERY HACKY AND UGLY fix for it. Just to have the configuration manager system working again.

I let the solution here just in case is useful for someone.

Hello all,

I have approached the problem in a completely different way. Sorry for adding a divergence here. If you want, I can create a separate issue for this even if the objective is the same.

I agree with the latest comment of Berdir when he stated that this issue is getting too complicated. Maybe I am missing something but I think that the approach followed in this MR https://git.drupalcode.org/project/entityform_block/-/merge_requests/3 is much easier.

This is a PoC that needs more work:

- Only allow the users to select the form modes that belong to the selected entity type (probably the Form mode field should be loaded via AJAX)
- To test it

Also, there is something that I don't understand about the block context and the edit/delete permissions. I don't know why we have to care about this in this issue if we are not caring about it (AFAIK) when displaying the default form mode. Is not Drupal core checking the permissions when showing the form? Even if it's not the default one?

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

I have detected that the block preprocess functions are not triggered for the exposed filter blocks when using this patch.

The problem appears because of this file changes

--- a/core/modules/views/src/Plugin/Block/ViewsExposedFilterBlock.php
+++ b/core/modules/views/src/Plugin/Block/ViewsExposedFilterBlock.php
@@ -32,15 +32,17 @@ public function getCacheContexts() {
    *   context of current view and display ID.
    */
   public function build() {
-    $output = $this->view->display_handler->viewExposedFormBlocks() ?? [];
+    $output = [];
+    $build = $this->view->display_handler->viewExposedFormBlocks() ?? [];
     // Provide the context for block build and block view alter hooks.
     // \Drupal\views\Plugin\Block\ViewsBlock::build() adds the same context in
     // \Drupal\views\ViewExecutable::buildRenderable() using
     // \Drupal\views\Plugin\views\display\DisplayPluginBase::buildRenderable().
-    if (!empty($output)) {
+    if (!empty($build)) {
       $output += [
         '#view' => $this->view,
         '#display_id' => $this->displayID,
+        'content' => $build,
       ];
     }

It seems that adding the block render array inside the `content` key avoids to trigger the preprocess functions.

Thanks for the issue. It helped me a lot.

I think this is an issue that should be fixed with a more generic solution, don't you? If this problem affects to each place in the codebase where several users are updated, it could be anywhere.

I have implemented a solution that fixes the problem via an EventSubscriber. I'm not sure if this solution has any side effect. I don't understand why the \Drupal\ldap_user\Processor\DrupalUserProcessor reset is not managed directly in the `ldap_user_user_update` hook, for example. It could be done in purpose by the module maintainers because of any reason that I am not aware of or it may be a bug. If someone could clarify, would be great.

In any case, here you can find how I fixed the problem in a more generic way.

namespace Drupal\MY_MODULE\EventSubscriber;

use Drupal\ldap_user\Event\LdapUserUpdatedEvent;
use Symfony\Component\EventDispatcher\EventSubscriberInterface;

/**
 * Event subscriber for the LDAP related events.
 */
class LDAPSubscriber implements EventSubscriberInterface {

  /**
   * {@inheritDoc}
   */
  public static function getSubscribedEvents() {
    return [
      LdapUserUpdatedEvent::EVENT_NAME => 'userUpdated',
    ];
  }

  /**
   * Takes actions after the user is saved.
   * 
   * Fixes https://www.drupal.org/project/ldap/issues/3196170.
   *
   * @param \Drupal\ldap_user\Event\LdapUserUpdatedEvent $event
   *   The user updated event.
   */
  public function userUpdated(LdapUserUpdatedEvent $event) {
    \Drupal::service('ldap.drupal_user_processor')->reset();
  }

}

Don't forget to declare the services in the my_module.services.yml file:

services:
  Drupal\MY_MODULE\EventSubscriber\LDAPSubscriber:
    tags:
      - { name: event_subscriber }

@lind101 thanks for your comments. As you mentioned, the group_content label depends on the GroupContentEnabler that manages it.

I have slightly modified the MR code (https://git.drupalcode.org/project/group/-/merge_requests/34/diffs?commi...) so we check that the GroupContentEnabler generated label does not match with the group_content stored label before saving the entity. This mitigates the performance problem when the user did not change the target entity label.

Although we still having a problem if the target entity changes the label and has many group_content entity associated with it. It can take a lot of time to save all the related group_content entities. However, I don't think this is something that can be solved. If you have any idea regarding this, I'll be happy to implement it.

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

I have created the MR that fixes the error.

unstatu → created an issue.

As workaround, the issue can be fixed by doing something like:

function hook_views_data_alter(&$data) {

  //Fixes: https://www.drupal.org/project/search_api/issues/3359351
  if (isset($data['INDEX_ID']['FIELD_ID']['filter']['vocabulary'])) {
    unset($data['INDEX_ID']['FIELD_ID']['filter']['vocabulary']);
  }
}

unstatu → created an issue.

Veeeery happy to see this hapenning. Thanks to all!

e0ipso → credited unstatu → .

Just read the points made by @micropat in #20. Not sure if this work has been done already on the dev branch. Are them still applicable?

Moving back to Needs work.

Rerolled #22 aganist 1.18.

Changed the status to "Needs review"

I have checked that the bug persists on the version 3. I have updated the MR for this version.