🇨🇴Colombia @camilo.escobar

Patch rerolled for 10.3.

My project was also missing the composer/installers package and I was experiencing the preflight error. In my case, installing composer/installers before upgrading Drupal resolved the issue (I’m using Lando).

lando composer require "composer/installers:^1.0"
lando composer require --with-all-dependencies --no-update 'drupal/core-recommended:^10' 'drupal/core-composer-scaffold:^10' 'drush/drush:^11 || ^12'
lando composer update --with-dependencies
lando drush updb

If composer/installers is installed after the drupal/core-* packages, I encounter additional errors when running Drush commands. So, I recommend installing it first to avoid issues.

I was also facing the error:

Problem 1
    - Root composer.json requires pantheon-upstreams/upstream-configuration * -> satisfiable by pantheon-upstreams/upstream-configuration[dev-master, dev-drupal10].
    - pantheon-upstreams/upstream-configuration[dev-master, dev-drupal10] require drupal/core-composer-scaffold ^9 -> found drupal/core-composer-scaffold[9.0.0-alpha1, ..., 9.5.x-dev] but it conflicts with your root composer.json require (^10).

As @divya.pm mentioned in #11, the issue was due to an incorrect composer.json file inside the upstream-configuration folder. @divya.pm said she had attached her copy of the file, but I’m not seeing it attached here (possibly because .json file uploads aren’t allowed). So, I’m pasting below the content of the file that worked for me:

{
    "name": "pantheon-upstreams/upstream-configuration",
    "type": "project",
    "repositories": [
        {
            "type": "composer",
            "url": "https://packages.drupal.org/8"
        }
    ],
    "require": {
    },
    "extra": {
        "_README": "To make a custom upstream, clone this repository and add any dependencies to be provided by this upstream to this composer.json file. Leave the root-level composer.json file for the exclusive use of each individual site; do not modify it after your custom upstream has been published. See https://pantheon.io/docs/create-custom-upstream for more information."
    }
}

Rerolled for 10.2.x

camilo.escobar → created an issue.

I have chosen to use the patch from the merge request here: https://www.drupal.org/project/drupal/issues/3328425 🐛 CKEditor 5 balloons invisible when CKEditor 5 is used inside a modal Needs work

camilo.escobar → created an issue.

camilo.escobar → created an issue.

Similar to @sassafrass in comment #52 ✨ Implement field permissions per-bundle (field instance) Needs work , I tried the patch 2881776-55--packaged-45-fixed.patch in the latest 1.3 version. It applied, but then when running the database updates, I'm getting:

  Module              Update ID   Type            Description                                                     
 ------------------- ----------- --------------- ---------------------------------------------------------------- 
  field_permissions   8001        hook_update_n   8001 - Migrates existing third party settings and permissions.  
 ------------------- ----------- --------------- ---------------------------------------------------------------- 
 // Do you wish to run the specified pending updates?: yes.                                                             

>  [notice] Update started: field_permissions_update_8001
>  [error]  Adding non-existent permissions to a role is not allowed. The incorrect permissions are "create field_1", "edit field_2", "edit field_3", "view field_4", ( ...)
>  [error]  Update failed: field_permissions_update_8001 
 [error]  Update aborted by: field_permissions_update_8001 
 [error]  Finished performing updates. 

I also tried with the the 8.x-2.x-dev module version and the patch didn't apply.

Patch applied correctly in Drupal 10.2.2. Thank you!

@himanshu_jhaloya,

Update on your patch: It only fixes the problem on line 155, but then line 166 will fail and cause the same error:

TypeError: preg_match(): Argument #2 ($subject) must be of type string, array given in preg_match() (line 166 of modules/contrib/flexslider/templates/flexslider.theme.inc).

Attaching adjusted patch.

Thanks @himanshu_jhaloya.

Your patch would indeed help to avoid the error TypeError: preg_match(): Argument #2 ($subject) must be of type string, array given in preg_match() (line 155 of /home/sitename/public_html/modules/contrib/flexslider/templates/flexslider.theme.inc), since you are explicitly checking that $item is a string.

Per my debugging, I have seen that $item is indeed a string (HTML markup) in the following scenarios:

1. When rendering a view as a FlexSlider, via the "FlexSlider" format
2. When rendering an Image entity field as FlexSlider, using the "FlexSlider" field formatter

In cases like that, $item would be an HTML string like this:

^ Drupal\Core\Render\Markup {#4238 ▼
  #string: """
    <!-- THEME DEBUG -->
    <!-- THEME HOOK: 'image_formatter' -->
    <!-- BEGIN OUTPUT from 'core/modules/image/templates/image-formatter.html.twig' -->
    
    <!-- THEME DEBUG -->
    <!-- THEME HOOK: 'image' -->
    <!-- BEGIN OUTPUT from 'themes/contrib/bootstrap/templates/system/image.html.twig' -->
    <img loading="lazy" src="/sites/default/files/2024-03/my-image.jpg" width="2828" height="4000" alt="." typeof="foaf:Image" class="img-respons ▶
    
    <!-- END OUTPUT from 'themes/contrib/bootstrap/templates/system/image.html.twig' -->
    <!-- END OUTPUT from 'core/modules/image/templates/image-formatter.html.twig' -->
    
    """
}

In scenarios like that, I dare say that the preg_match(): Argument #2 problem does not occur, since $item is definitely a string.

However, when you are rendering an entity reference field using the "FlexSlider (Entity view)" field formatter, $item is not a string but a render array instead, like this one:

^ array:6 [▼
  "#paragraph" => Drupal\paragraphs\Entity\Paragraph {#4471 ▶}
  "#view_mode" => "default"
  "#cache" => array:3 [▶]
  "#theme" => "paragraph"
  "#weight" => 0
  "#pre_render" => array:1 [▶]
]

So far, this is the scenario that led me to reproduce the error and the reason I asked in my comment above if @Christopher Riley was also using that formatter.

If so, then I think the same discussion is taking place here: 🐛 Thumbnail navigation doesn't work with reference fields Active , with an additional proposal rau

As a desired enhancement, I'd like to propose that the "FlexSlider (Entity view)" Field Formatter has a new configuration option to select the field from the entity in question from where the thumbnail image must be taken. And the same for the FlexSlider View's display

I think your patch is good to prevent people using the module from falling into the preg_match error, if they are using the "FlexSlider (Entity view)" field formatter, while continuing to discuss options for supporting thumbnails on sliders created from entity reference fields.

I could reproduce this issue when using the "FlexSlider (Entity view)" field formatter on an entity reference field.
In such a case, the $variables['item'] that arrives to template_preprocess_flexslider_list_item(&$variables) is the render array of the referenced entity, something like the following:

array:6 [▼
  "#paragraph" => Drupal\paragraphs\Entity\Paragraph {#4178 ▶}
  "#view_mode" => "default"
  "#cache" => array:3 [▶]
  "#theme" => "paragraph"
  "#weight" => 0
  "#pre_render" => array:1 [▶]
]

In other cases, as for example when the FlexSlider is selected as the display option from a View, $variables['item'] here will contain HTML markup (I assume it undergoes the rendering pipeline in an earlier state).

Hence, when the entity render array above is attempted to be passed to preg_match():

if (!preg_match("/<img.+?src=[\"'](.+?)[\"'].+?>/", $item, $src)) {
  preg_match("/<img.+?srcset=[\"'](.+?)[\"'].+?>/", $item, $src);
}

PHP triggers the error:
TypeError: preg_match(): Argument #2 ($subject) must be of type string, array given in preg_match() (line 155 of modules/contrib/flexslider/templates/flexslider.theme.inc).

I assume this could be "easily solved" if we first render the array to get its resulting markup, before it undergoes the preg_match(), something like this:

if (is_array($item)) {
  $item = \Drupal::service('renderer')->renderRoot($item);
}

At least it would avoid the preg_match(): Argument #2 error.

However, I feel that grabbing the URL of the thumbnail image from the src attribute of a <img /> tag detected via a regular expression is not the best way to provide support for thumbnail images. It is like a very odd and random way to pick the thumbnails up.

As a desired enhancement, I'd like to propose that the "FlexSlider (Entity view)" Field Formatter has a new configuration option to select the field from the entity in question from where the thumbnail image must be taken. And the same for the FlexSlider View's display.

@Christopher Riley, although you reported this issue almost two years ago and no update has been provided, I'm wondering if the problem was reproducible in your case because you were using the "FlexSlider (Entity view)" field formatter on an entity reference field. If so, then maybe this issue could be marked as a duplicate of 🐛 Thumbnail navigation doesn't work with reference fields Active .

This change makes a lot of sense. A reminder that Drush has its own implementation of batch API (batch.inc) which allows you to harness batch operations when running Drush commands, via drush_backend_batch_process().
It would be very convenient to implement these changes in that file too. I opened an issue in the Drush list and hope to work soon on that patch: https://github.com/drush-ops/drush/issues/5880.
Thanks!

Hi @siva01! Thanks for sharing your solution.

I assume you decorated the service serializer.normalizer.field.jsonapi via an impostor normalizer and overwrote the function normalizeFieldItems(). It's a clever solution, interesting approach.

For other people who want to go down this path, it is important to note that there is another party involved in the implementation of an impostor normalizer (in addition to the links you provided above): a Service Provider class. That's necessary to enable the /src-impostor-normalizers folder to host impostor classes within the \Drupal\jsonapi\Normalizer namespace.

camilo.escobar → created an issue. See original summary → .

Thanks @melvix, you've hit the nail on the head.

Merge Request created. Please review.

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

Thank you @owenbush!

camilo.escobar → created an issue.

camilo.escobar → created an issue.

Thanks Sharique!

Hi, is there any plan to create a new tag for the latest commit in branch 8.x-4.x?
The branch is ahead of the last tag 8.x-4.2 by 3 commits, including the one that was merged here, for Drupal 10 compatibility.

Here is the comparison: https://git.drupalcode.org/project/pet/-/compare/8.x-4.2...8.x-4.x?from_...

Teams working on upgrading to Drupal 10 would appreciate it.

For now, my solution to continue using the module in Drupal 10 is to require the dev branch 8.x-4.x:
composer require 'drupal/pet:dev-4.x'.

Thanks.

@bas123, I see the patch to make the module compatible with Drupal 10 was merged into branch 8.x-4.x in this other issue https://www.drupal.org/project/pet/issues/3329413 📌 Automated Drupal 10 compatibility fixes Fixed . However, no new tag has been created since 8.x-4.2.

At the time of writing this, the branch 8.x-4.x is ahead of tag 8.x-4.2 by 3 commits, including the one that changes pet.info.yml for Drupal 10 compatibility. Here is the comparison: https://git.drupalcode.org/project/pet/-/compare/8.x-4.2...8.x-4.x?from_...

My solution to continue using the module in Drupal 10 was to require the dev branch 8.x-4.x:
composer require 'drupal/pet:dev-4.x'.

I hope it helps.

I created a field enhancer and was also hoping to provide sort of default value when the field han an empty or NULL value, but I found the same: field enhancers doesn't run when the field is empty. It would be useful to make it work to transform empty values as well.

Thanks owenbush and endless_wander!

camilo.escobar → created an issue.

camilo.escobar → created an issue.

This issue is also solved in https://www.drupal.org/node/2982968 →

camilo.escobar → created an issue.

In case someone is experiencing the same exception (InvalidArgumentException: The entity cannot be translated since it is language neutral (und)), but does not have the content_moderation module enabled, it's probably due to this other scenario: https://www.drupal.org/project/paragraphs/issues/3378070 🐛 Source language is not set in nested Paragraphs when transitioning from a locked language (und, zxx) to another language. InvalidArgumentException: The entity cannot be translated since it is language neutral (und). Active .

camilo.escobar → created an issue.

Seems like a duplicate of https://www.drupal.org/project/paragraphs/issues/3082703 🐛 Paragraph translation source language is not set when parent is under Content Moderation Needs work .

I found that when an inheritance is configured for a field of type "List (text)" allowing multiple selections, the resulting inherited values are not exposed correctly by JSON:API. While an array is expected containing all the selected values, only one of the values is exposed as a string.

Steps:

1. Have a field of type "List (text)" allowing multiple selections in both the source bundle and the destination bundle. Example, I created a field on each bundle with the following allowed values:

• option_1|Option 1
• option_2|Option 2
• option_3|Option 3

Results:
The inheritance seems to work well: If I select multiple values (say option_1 and option_3) for the field in the target or the destination entity, I can see the resulting inherited values are correct when they are displayed in the destination entity detail page.

But, when I request the destination entity via JSON:API, I get this:

"inherited_multi_select_list": "option_1",

whereas this is the expectation:

"inherited_multi_select_list": [
  "option_1",
  "option_3"
]

This was an issue until version 6.1.4, where the patch in #16 had to be applied. Updating to 6.1.5 will solve this problem and the patch will not be necessary, since the same issue was tackled with a different approach in https://www.drupal.org/project/webform/issues/3333461 📌 Still exist issues with strpos Deprecated function Fixed and https://www.drupal.org/project/webform/issues/3344996 📌 Fix PHP 8.1 deprecation Fixed .

I also saw the node pages breaking after enabling relative Urls. However, in my case, I have preferred the second fix proposed by @nielsaers: not to use the computed field on view modes, since I'm using this in a headless website and do not want external applications to have to parse the strings to remove the "base:" part.

@nielsaers, are there plans to merge the MR? or at least to provide a patch containing your changes?

Thank you Sharique.

The changes in the MR imply that those notifications that by design are intended to be sent in bulk to multiple recipients, namely those corresponding to the keys below, are not sent immediately as soon as the triggering action occurs, but are added to a queue instead:

• registration_reminder
• series_modification_notification
• instance_modification_notification
• instance_deletion_notification
• series_deletion_notification

It means they don't go through recurring_events_registration_send_notification() immediately inside those foreach loops, but the Queue Worker will start processing them on the next cron run.

In those cases, the line
recurring_events_registration_send_notification($key, $registrant);
has been replaced by:
\Drupal::service('recurring_events_registration.notification_service')->addEmailNotificationToQueue($key, $registrant);

The new function addEmailNotificationToQueue($key, $registrant); is in charge of adding the notification to the queue. The function makes sure of invoking the hook hook_recurring_events_registration_send_notification_alter($send_email, $registrant) to allow modules to determine whether the notification should be sent (added to the queue) to the $registrant in question (the same as recurring_events_registration_send_notification($key, $registrant) does).
Also, the function introduces a new alter hook hook_ recurring_events_registration_message_params_alter($params, $registrant) to allow modules to add data to the $params array that is passed to the mail() function. Developers can use the data of the $registrant entity to set these params. Those $params can be used later as the $message['params'] in hook_mail_alter().

Actions that trigger only an email notification to a recipient (registrant) were left intact and continue to use the function recurring_events_registration_send_notification($key, $registrant), therefore the notification is sent out immediately. Namely:

• promotion_notification
• registration_notification
• waitlist_notification

These changes are my initial solution to overcome a big problem we were facing on our website: when an email event notification (e.g., instance_modification_notification) is triggered to a large number of registrants, the system may fail in those iterations and hit time and memory limits depending on the PHP configuration.

How long it takes for the queued notification list to be fully processed depends on three factors:

1. The number of notifications in the queue
2. How often Drupal cron runs
3. The number of seconds used by the queue worker on each cron run to process the items (it was set to 30)

This is acceptable in our case, since we have a large number of registrants in our events and we are aiming to run the Drupal cron every 5 or 10 minutes.

As I mentioned in the notes in the MR, there is a pending task:

Maybe provide a UI to configure if the system should use Queue Worker or not. People could have a checkbox to decide whether emails for notification types that are sent to multiple recipients should use the queue or send immediately.

@owenbush @podarok I think completing this to-do is important before merging the MR and releasing a new version, as not all the projects using the module may be interested in the queue implementation and may prefer to continue operating as usual: sending all emails immediately.

I know I owed you this technical background of the approach I implemented, and I was honestly expecting a MR review, some feedback and certain back-and-forth discussion before merging the MR. As I'm seeing this was already included in 2.0.0-rc8, I highly recommend to revert that release or to revert the MR and release a new version without those specific changes, since it is crucial that the to-do above is resolved, so as not to affect the normal operations of projects using the module.

@endless_wander, thanks for pointing out the importance of this case, please stick to a module version prior to 2.0.0-rc8, while I work in the above to-do.

I'll be working this weekend and create a new PR to resolve the pending item, so this solution, that can be very favorable in different cases, can be launched. This is what I will do:

1. Add a new configuration option in the Registrant Settings Form to enable/disable the queue of notifications
2. Have the option disabled by default, so that the websites continue operating as usual

The point that @adinac made is important: it is not enough to make the PET entity translatable. All the code involved in sending the emails must be adapted to be able to receive a language parameter, otherwise, just making the entity translatable is useless.
A new issue was created: https://www.drupal.org/project/pet/issues/3366542 ✨ Support sending emails in different languages Fixed

camilo.escobar → created an issue.

camilo.escobar → created an issue.

camilo.escobar → created an issue.

camilo.escobar → created an issue.

camilo.escobar → created an issue.

Patch in #37 🐛 BaseFieldOverride fails to take into account ContentEntityInterface::bundleFieldDefinitions() when invoking onFieldDefinitionUpdate() Needs work worked for me.
I was getting the error below when saving the configuration in the Content Traslation page (/admin/config/regional/content-language). It generated override files for fields of one of the entities provided by the Recurring Events → module.
Then, after exporting the configuration and trying to import it in another environment, I got this:

TypeError: Argument 2 passed to Drupal\Core\Entity\ContentEntityStorageBase::onFieldDefinitionUpdate() must implement interface Drupal\Core\Field\FieldDefinitionInterface, null given, called in /app/web/core/lib/Drupal/Core/Field/Entity/Base  
  FieldOverride.php

Thanks for looking into this and providing the patch.

I've also been experiencing this for a while on Drupal projects built on top of Lando. Every time I run lando pull, the next time I clear the cache via drush, I get the problem.

The aforementioned workaround is working (uninstall devel, clear cache, reinstall devel), however I am aiming to find a permanent solution as well. Despite the variety of ecosystems in which this problem has been evidenced (Windows, Ubuntu, Apache, Nginx, Lando, different versions of PHP, etc), the only common feature that all cases have is that the Devel module is enabled and after applying the suggested workaround, the problem goes.

Therefore, I have added an issue to the Devel module queue that describes the problem and I hope to bring this to the attention of the maintainers, so that maybe they can do a deeper review and find a solution. I invite you to leave a comment on this topic in case you have additional information or give a thumbs up, so we continue to join forces so that maintainers pay attention to this case:

https://gitlab.com/drupalspoons/devel/-/issues/463

Update: Using 2.0.0-rc7 the problem does not occur.
Changing the status to fixed.

camilo.escobar → created an issue.