🇧🇪Belgium @ludo.r

I have a content type with 150+ custom fields and some nodes that have dozens of revisions.
When loading revisions when exporting, this causes memory issues and also a long time to export.

Changing this (in modules/single_content_sync_revisions/src/ExportSubscriber.php):

      // Second step is exporting those revisions.
      /** @var \Drupal\Core\Entity\ContentEntityInterface $revision */
      foreach ($storage->loadMultipleRevisions($revision_ids) as $revision) {

to:

      // Second step is exporting those revisions.
      foreach ($revision_ids as $revision_id) {
        /** @var \Drupal\Core\Entity\ContentEntityInterface $revision */
        $revision = $storage->loadRevision($revision_id);

solves the memory issues and makes the process much faster.

Here's a version that works with 1.0.2

It seems, my custom URL processor is being called event when the facet source is set to use the default one.

Anyone encountered this issue?

And here's the patch.

ludo.r → created an issue.

Thanks for the help, I managed to do it by extending the leaflet prototype:

/**
 * @file JavaScript
 */

(function ($, Drupal, drupalSettings, L) {

  Drupal.behaviors.MapLeafletInteraction = {
    attach: function (context, settings) {
      if (typeof Drupal.Leaflet !== 'undefined' && typeof Drupal.Leaflet.prototype.create_feature !== 'undefined') {
        // Save the original function that we will override.
        var originalCreateFeature = Drupal.Leaflet.prototype.create_feature;

        // Override the original create_feature function.
        Drupal.Leaflet.prototype.create_feature = function (feature) {
          // Call the original function.
          var lFeature = originalCreateFeature.call(this, feature);

          // Add sidebar to the lFeature.
          this.feature_bind_sidebar(lFeature, feature);

          return lFeature;
        };

        /**
         * Add sidebar feature to the Leaflet Feature.
         *
         * @param lFeature
         * @param lFeature
         *   The Leaflet Feature
         * @param feature
         *   The Feature coming from Drupal settings.
         */
        Drupal.Leaflet.prototype.feature_bind_sidebar = function(lFeature, feature) {
          let entity_id = feature.entity_id;
          lFeature.on('click', function(e) {
            loadNodeContent(entity_id);
          });
        };
      }
    }
  };

  function loadNodeContent(entity_id) {
    const endpoint = `/ajax-view/node/${entity_id}/overview/en?_wrapper_format=drupal_ajax`;
    const ajaxSettings = {
      url: endpoint,
      event: 'click', // This event type is required but won't be used
      progress: {
        type: 'throbber'
      },
      wrapper: '#map-sidebar' // Target div selector
    };

    // Create a new Drupal.ajax instance and execute it immediately.
    const ajax = new Drupal.ajax(ajaxSettings);
    ajax.execute();
  }

})(jQuery, Drupal, drupalSettings, L);

And I have a custom controller that returns the response.

ludo.r → created an issue.

I fixed a bug when text is empty, based on patch #46.

Patch #31 seems to work on our side (Using version 4.1.0).

I also agree with suggestion in #28, to have both options (white/black-list).

We're experiencing this issue also on Drupal 10.2.8.
Seems also that when this happens, content is lost upon save.

I think this should be major issue.

ludo.r → created an issue.

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

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

https://www.drupal.org/project/menu_link_field_attributes/releases/2.0.0... →

Added some code in MR:

• Initialize options column to an empty array instead of NULL when installing schema
• Update all menu_link related tables (including revision tables) to an empty array when value is NULL

I'm using this module that I copied as a custom module and just changed the version in the info file if I remember correctly.

My guess (and I bet), that there's a good reason for that.

Imagine a seach page (99% a views page), where you come with a specific parameter in the URL for Facet A.
Facet B has no result with param for Facet A.

If you have an ajax view and uncheck param in Facet A, you might need to show results in Facet B.
That's a good reason to use the hidden class rather than not showing the block at all.

Btw, IMHO, I think the hidden class can be used by anyone (theme, contrib module), it's feature of Drupal.

This could be a solution as well: #3222997: Allow disable non translatable fields on translation forms →

ludo.r → created an issue.

Just tested patch #6, it indeed returns an empty block.

However, I removed the patch, as I see that the default behavior of facets module is to show the block but add the hidden class.
So I think there must be a reason for that.

In the end it's just our theme that overrides the hidden class, we'll fix it with css and respect when hidden is being added.

See https://git.drupalcode.org/project/facets/-/blob/3.0.x/facets.module?ref...

Ludo.R → created an issue.

Patch in comment #18 works on my side with version 2.0.7

Here's the patch.

Ludo.R → created an issue.

Ludo.R → created an issue.

Patch #7 works with Drupal 10.2.7

Patch #11 works, however it seems there's an issue with the form option.
It doesn't get saved as expected (gets saved with null value).

I had to set myself the render_source property to FALSE in the config.

MR !19 works for me on 8.x-2.9

Ludo.R → created an issue. See original summary → .

I did succeed to make it work by using a custom module just to handle AJAX loading of webforms.

See:

• https://www.drupal.org/project/drupal/issues/2934463#comment-12863925 🐛 Ajax is broken in forms built within an Ajax callback Active
• https://www.drupal.org/docs/contributed-modules/webform/webform-cookbook... →

Basically you need a custom module with a custom route, and then trigger the AJAX loading through javascript.

Hello,

Patch #17 works fine.

For the ones like me who didn't know how it works:
This patch creates a new field under the file entity itself called "Search API attachments: extracted file".

This is Node => Paragraph => Media => File:

field_downloads:entity:field_files:entity:field_media_file:entity:search_api_attachments_extracted_file

Ludo.R → created an issue.

I confirm that https://git.drupalcode.org/project/webform_rrn_nrn/-/merge_requests/5 does add the required attriibute to the input.

And here's the patch.

Ludo.R → created an issue.

I confirm patch #3 works.

I confirm it works.

And here's the patch ;)

This patch is the same as #7, but adds an update hook to udpate:

• Patterns using the old token, to replace it with the new one
• Pathauto settings safe tokens to the old token with the new one

Add missing menu_trail_by_path.services.yml, do not use patch #15.

Totally agree, didn't know about this module, just tested it and it works for my use case.

Closing the issue.

Here's the patch with test coverage, this is now against Drupal 11.x, functions are typehinted.

Will create a MR.

Here's an updated patch with PHPCS fix.

@smustgrave, what new functions are you referring to?
All functions in there are inherited, or documented in interfaces. Also I don't see any example in https://git.drupalcode.org/project/drupal/-/blob/11.x/core/modules/node/..., which is was my example.

Code is exactly the same, just fixed some typos in comments.

Here's the new plugin.

This plugin should work without any problem with D10/D9.

Ludo.R → created an issue.

Ludo.R → created an issue.

Patch that combines following patches:

• https://www.drupal.org/project/menu_trail_by_path/issues/2870738#comment... 🐛 Wrong active trail with multiple menu items with the same path Needs work
• https://www.drupal.org/project/menu_trail_by_path/issues/2914746#comment... 🐛 Fatal error after installing the module (incompatibility with Context & Menu position module) Needs work

Works with menu_trail_by_path 2.0.1.

Previous patch was missing a use statement, don't use #24.

Patches in #19 and #20 do not pursue the same goal.

I'm re-rolling patch #19 for version 2.x-dev.

Patch re-rolled against 8.x-2.x-dev

Patch #5 works for version 8.x-3.6.

However if you work with an older version of PHP (7.3 in my case) it's broken.

Here's a version where I remove the typed property to make it work: protected ?int $depth; => protected $depth;

Ludo.R → created an issue.

Fixed by d.vandoninck

Fixed by d.vandoninck

This has been fixed on 1.0.x

Ludo.R → created an issue.

@AnjaliPrasannan,

You won't be able to reproduce unless you have API credentials for this service. And I don't think they provide free access.

Ludo.R → created an issue.

Ludo.R → created an issue.

Ludo.R → created an issue.

#27 works for me on Drupal 9.4

Re. #27

I just ran into the same issue, I guess modifying MenuBlock::getDerivativeActiveTrailIds() should be enough.

  protected function getDerivativeActiveTrailIds() {
    $menu_id = $this->getDerivativeId();

    // => If menu_id = "multiple_menu_block", then do custom logic.

    return array_filter($this->menuActiveTrail->getActiveTrailIds($menu_id));
  }

In the meantime I'm using classic Menu blocks (from core) and not the multiple one.

This works!

Ludo.R → created an issue.

For me it worked like this:

Add this to composer.json

    "extra": {
        "merge-plugin": {
            "include": [
                "[web-root]/modules/contrib/ckwordcount/composer.libraries.json"
            ]
        }
    }

And then

composer require drupal/ckwordcount and not composer require drupal/ckwordcount w8tcha/ckeditor-wordcount-plugin.

I have the same issue as @yannickoo

Patch #43 seems to work correctly.

An option to skip failed items would nice too :)

Ludo.R → created an issue.

Here's an adapted version of #19 that fixes the <html><body> issue, however I'm sure there is a safer/better way to do this.
This should still be improved IMO.

Using patch #19 (didn't try more recent patches) is producing incorrect HTML.

It ends up with <html><body>[processed text here]</body></html>.

Patch from the merge request on #27 didn't work for with version 4.0.0-beta4.

I adapted the patch.

Turns out I had to rename the files from d7_webform.yml to migrate_plus.migration.d7_webform.yml.

It solved the issue in my case.

Strange thing: just tried to import config through the UI (by copy/pasting the exact same config) and this works.

Ludo.R → created an issue.

I'm getting the same error :/

It appears that this happens with content_moderation module enabled, on the moderation_state field.

For now I circumvented this issue like this:

    // Clone the field.
    $original_field = $data['field'];
    if (method_exists($original_field, 'createDuplicate')) {
      // Do stuff.
    }

Ludo.R → created an issue.

Patch #9 works for me.

Tested with patch #14 on D10, seems to work without any problem, with all submodules enabled.

Patch providing D10 support.

Remarks:

• The module doesn't work as-is, you need this patch to make it work: https://www.drupal.org/project/delete_all/issues/3284891#comment-14706744 🐛 Too few arguments to function Drupal\delete_all\Controller\DeleteControllerBase::__construct() Fixed
• This patch drops support for D8.7 and lower. If support for those older versions is still needed then we need to create a condition to include the files in delete_all.module
• Tested and works on D10

It seems the only change left is the version requirement in .info.yml file.

Tested on D10, everything looks fine.

As per https://www.drupal.org/node/3126004 → , method has been changed from guess() to guessMimeType().

As recommended, I added a condition to make it work with both D8/9 and D10.

This patch should solve the problem.
There might be more underlying issues to solve but it will get the translated titles to be displayed.

#20 works on my side and my use case, but I guess it's worth to mention that it does not exactly what the option claims:

Use the current entity language to generate a url (rather than the language of the referenced entity)

In fact it just gets the current language page rather than the referencing entity language.
This might be a problem if you want to show items in other languages than the current page language.

Although PHP7.4 is not recommended, it is still supported by Drupal >= 9.4: https://www.drupal.org/docs/system-requirements/php-requirements#versions →

IMO, support for PHP version should follow Drupal core's support.

@tra.duong,

Thanks for pointing this!

Regarding the core version, I left the old core property so that I can work with older D8 versions:
core: 8.x
core_version_requirement: ^8 || ^9 || ^10

For the menu_link module, I guess we'll have to wait for the D10 release: https://www.drupal.org/project/menu_link/issues/3322201 📌 Drupal 10 compatibility Fixed
So indeed, the module cannot be installed on D10 yet because of the dependency.