🇨🇦Canada @leducdubleuet

I was happy to see that new official and updated version 3.3.0 but same problem here, cannot upgrade via composer.

I guess it has to do with the fact 3.3.0 was not properly tagged and released on the repo : https://github.com/droptica/droopler_project/releases ?

Using composer to show the available versions, we get :

composer show -a 'droptica/droopler'

name     : droptica/droopler
descrip. : Droopler installation profile for Drupal 10.
keywords :
versions : 8.3.3.0-rc3, 8.3.3.0-rc2, 8.3.3.0-rc1, 8.3.2.0-rc1, 8.3.1.0, 8.3.1.0-rc2, 8.3.1.0-rc1, 8.3.0.0, 8.3.0.0-rc1, 8.2.2, 8.2.2-rc1, 8.2.2-beta1, 8.2.2-alpha1, 8.2.1.1, 8.2.1, 8.2.1-rc3
, 8.2.1-rc2, 8.2.1-rc1, 8.2.0, 8.2.0-rc2, 8.2.0-rc1, 8.2.0-beta3, 8.2.0-beta2, 8.2.0-beta1, 8.2.0-alpha2, 8.2.0-alpha1, 8.1.4, 8.1.4-rc2, 8.1.4-rc1, 8.1.3, 8.1.2, 8.1.0-beta2, 8.1.0-beta1, 8
.1.0-alpha2, 8.1.0-alpha1, 4.0.x-dev, 4.0.0-alpha3, 4.0.0-alpha2, 4.0.0-alpha1, 3.3.x-dev, 3.2.x-dev, 3.1.x-dev, 3.0.x-dev...

Composer still sees only 8.3.3.0-rc3 as the latest version available.

Thank you for looking into this.

I can confirm the patch is fixing this issue, thank you very much!

Nothing happened since last march and since we cannot migrate from 3.x to 4.x, I wonder what should I do with my sites on Droopler 3.3.0-rc3.

The latest version recommended by the project’s maintainers is still 3.1.0 dating back to 2022 and running on the now unsupported Drupal 9.x...

Will there be future releases for the 3.x branch? Will it be ported to Drupal 11?

Or should we consider Droopler as unsupported and move away from this distribution now?

Don't get me wrong, I really loved Droopler but now I feel a little like I am being let down.

Thank you.

Would it be possible to have an update on this please?

What do you mean? I do not see your point?

Why only a clear cache was needed then and now it won't work?

This version is in beta, shouldn't people expect some potential breaking changes for exception like this one?

The related issue 🐛 Compatibility issue with Address module Fixed had the same fix as this one but did not pose any problem then.

You said in comment #8 of the related issue :

> g089h515r806 commented 3 January 2024 at 01:27
> This change does not need a update path. But people need clear cache if they using this plugin.

Why do this one is problematic now?

Sorry but I will not be using this module after all, thank you.

I can confirm this little patch is working well to fix this issue!

Thanks!

I just tested epp-embedded_forms-3214790-8.patch to set a default value from tokens for a field on a customer profile with Commerce and it is working well!

Thanks!

Nowadays with current versions, the solution proposed here is not working anymore. The $session->migrate() does not seem to do anything when the session is not already started...

In case anybody lands here with that same problem, here is an example of what worked for me :

      // Step 1: Ensure the session is started for anonymous users.
      if ($current_user->isAnonymous()) {
        $session = \Drupal::service('session');
        // If the session is not started, forcefully start it.
        if (!$session->isStarted()) {
          session_start();
        }
      }

      // Step 2: Check if there's an existing cart order for the current user session.
      /* @var \Drupal\commerce_cart\CartProviderInterface $cart_provider */
      $cart_provider = \Drupal::service('commerce_cart.cart_provider');
      /* @var \Drupal\commerce_cart\CartManagerInterface $cart_manager */
      $cart_manager = \Drupal::service('commerce_cart.cart_manager');

      // Get the current cart if any
      $order = $cart_provider->getCart('default');

      // If there's an existing cart order, empty it.
      if (!empty($order)) {
        $cart_manager->emptyCart($order);
      } else {
        // Create a new empty cart if it doesn't exist.
        $order = $cart_provider->createCart('default');
      }

      $checkout_url = '/checkout/' . $order->id();
      $response = new RedirectResponse($checkout_url);
      $response->send();

This starts the session first when it was not already to fix the access denied on the checkout for anonymous users!

The call to createCart() adds the order id to user's cart session, no need to do that manually.

Hope this helps!

Thanks!

Nowadays with current versions, the solution proposed here is not working anymore. Adding the order id to the user's cart session is not enough to make it work.

In case anybody lands here with that same problem, here is an example of what worked for me :

      // Step 1: Ensure the session is started for anonymous users.
      if ($current_user->isAnonymous()) {
        $session = \Drupal::service('session');
        // If the session is not started, forcefully start it.
        if (!$session->isStarted()) {
          session_start();
        }
      }

      // Step 2: Check if there's an existing cart order for the current user session.
      /* @var \Drupal\commerce_cart\CartProviderInterface $cart_provider */
      $cart_provider = \Drupal::service('commerce_cart.cart_provider');
      /* @var \Drupal\commerce_cart\CartManagerInterface $cart_manager */
      $cart_manager = \Drupal::service('commerce_cart.cart_manager');

      // Get the current cart if any
      $order = $cart_provider->getCart('default');

      // If there's an existing cart order, empty it.
      if (!empty($order)) {
        $cart_manager->emptyCart($order);
      } else {
        // Create a new empty cart if it doesn't exist.
        $order = $cart_provider->createCart('default');
      }

      $checkout_url = '/checkout/' . $order->id();
      $response = new RedirectResponse($checkout_url);
      $response->send();

This starts the session first when it was not already to fix the access denied on the checkout for anonymous users!

The call to createCart() adds the order id to user's cart session, no need to do that manually.

Hope this helps!

Thanks!

While I did not review the proposed fix line by line, I can confirm it is working as expected to fix this annoying issue.

Thank you very much!

I can confirm the fix is working as well and quite critical indeed.

Would it be possible to tag a new release including this please?

Thanks

I can confirm the fix is working as expected with version 3.0.0-beta4 and current Commerce 2.40.

Without this patch, you cannot put anything in your cart after enabling the module, this is quite major when using Commerce.

Thank you very much!

Cannot install the module without this patch on Drupal 10.3.6.

Thank you.

This patch is working well and is now mandatory. Would be great to have a new version including it!

Thx

Oups, truly sorry, I went too fast and did miss the important notice in the release notes for 2.0.11 : https://www.drupal.org/project/simpleads/releases/2.0.11 →

Indeed, all is well after enabling the new module. I thought it was possible to automatically enable a module from another...

Maybe showing a warning in the admin dashboard or the watchdog when js_cookie is not enabled would be a good idea?

Thank you

leducdubleuet → created an issue.

@amitnar Thank you for your work!

I reviewed the MR and I believe the code in "dist/js/sidebar.js" should be minified for optimization if I am not mistaken?

Also, as I said before, I think we should rename the variable "isIOS" cause it's misleading as it checks more than iOS...

Thx

I can also confirm the patch "sidebar-resize-overlap-15791901-4.patch" in comment #24 works well on desktops with or without touch enabled screen as well.

I also reviewed the patch and I suggest to rename the isIOS variable to isTouch or isMobile to reflect that it is not only for iOS devices...

Thank you very much!

It would be great to have an option to disable the debug logging set by default in the issue #3400863 📌 mPDF set logger Fixed . Currently, it logs everything like images loading, memory consumption, etc. It can fill up the watchdog pretty fast with useless debug info on normal operation. When disabling the debug log, it could continue to log errors though.

Thank you.

Hello,

I can confirm the patch *sidebar-resize-overlap-15791901-3.patch* is now working on both type of screens with and without touch enabled, good job!

But while reviewing the patch, I noticed some CSS/SCSS modifications that seem unrelated to the current issue, can you confirm they are needed?

Also, shouldn't we have a check for Android as well? Or is the check needed only for iOS devices?

Thx!

It is great to see some advancements in the issue #2546212 which has been around since 2015 in the early days of Drupal 8. With more than ~300 comments, this is one of the longest running issue on d.o to my knowledge. It is currently worked on version D11, one can be doubtful this will ever land in D10 before next June...

So in the meantime, I can confirm the patch "field_group_fix-translations_label_description-3111107-50.patch" in comment #52 works well with field_group 3.6. I would personally qualify these workarounds as smart and realistic instead of "dirty"...

Thank you.

Indeed, the patch "sidebar-resize-overlap-15791901-2.patch" fixes the problem on touch enabled desktop devices but then the sidebar is not resizable anymore on normal desktop without touch screen. So, if we go that way, we need a switch in the code to keep it resizable without touch as well.

In the meantime, I simply use my patch in comment #15 which disables the resizing on touch enabled desktop devices.

Thank you for your time.

leducdubleuet → created an issue.

I modified the title and summary to make it clear this bug happens on desktop size devices with touch enabled screen.

@saschaeggi

Could you have a look at the related bug report issue this sidebar resizing created on touch devices please : https://www.drupal.org/project/gin/issues/3463177 🐛 Resizable sidebar can overlap the save button on touch enabled device Needs work

Thx

Thank you @amitnar!

I agree that disabling the sidebar resizing on touch devices solves the problem but you forgot to keep the following :

document.addEventListener("mouseup", this.resizeEnd)

Also, your patch covers only the sidebar.js inside the "/dist/js" folder and we need to patch the same file inside the "/js" folder as well.

You will find attached a new complete patch "sidebar-resize-overlap-3463177-15.patch" to simply disable the sidebar resizing on touch devices.

I personally was not able to resize the sidebar on a touch device, it only created the current overlap bug so disabling it seems like the way to go for me.

Is disabling the sidebar resizing feature on touch devices the best approach here?

Thank you.

Hello Amitnar, this is great news, let me know when I can help with testing. Thx

I also noticed that the "Bootstrap Paragraphs Webform" module does not delete its paragraph type "bp_webform" when uninstalling. You have to manually delete the "bp_webform" paragraph type before being able to install the "Bootstrap Paragraphs Webform" module again.

I can confirm that the patch fix the issue when installing the module and sub-modules with it. Thanks!

You absolutely need to start from scratch though. Uninstall all modules, add the patch to composer.json, install the modules again.

Be aware that the "Bootstrap Paragraphs Webform" module does not delete its paragraph type "bp_webform" when uninstalling. You have to delete this type manually before being able to install it again.

Thank you very much, I love this module!

Thank you for trying but I'm surprised both of you cannot reproduce this bug. The problem does not show directly when you arrive on the page using the debugger with touch feature enabled. Everything is fine at that point when using a touch screen. But the problem occurs as soon you try to resize the sidebar while being in the mobile view debugger with the touch feature enabled. When resizing the sidebar, it overlaps almost instantly.

I just tested again using all latest versions and the bug is still present unfortunately under Firefox and Chromium. So from my understanding, you did not try to resize the sidebar while being in the mobile debugger with touch enabled in order to reproduce the bug.

Let me know if these details help reproducing the bug?

Thank you

I can also confirm the patch does the job to fix the date checking properly.

Thank you very much!

Using the debugger, I was able to observe that when the sidebar overlap occurs, the local storage variable Drupal.gin.sidebarWidth becomes invalid with NaNpx as you can see in this capture :

@saschaeggi I created a new bug report like you asked : https://www.drupal.org/project/gin/issues/3463177 🐛 Resizable sidebar can overlap the save button on touch enabled device Needs work

By the way, if anybody has this issue when the sidebar overlaps, you can always close it using the Alt-s keyboard combination but this is not intuitive for users.

Thanks

Indeed, when the screen is below 1024 pixels, there is a close button but not on a desktop with a wider screen.

This issue is not for mobile devices with small screen but for normal desktop with higher resolution with touch enabled screens.

As you can see in my second screenshot, there is no close button on higher resolution when the sidebar overlaps.

By the way, if anybody has this issue, you can always close the sidebar using the Alt-s keyboard combination when it overlaps but this is not intuitive for users.

Thank you for looking into this.

LeDucDuBleuet → created an issue.

Well, thanks for your reply but I do not agree with you. I do not want to ask for a new feature when this is clearly this one that created the bug... How can we state this one is "fixed" when it creates a bug for people with touch enabled screen that was not there before introducing this new feature?

This is not working well for desktop with touch enabled screen. When resizing the sidebar, it is possible to loose the save button under the sidebar without any possibility to show it back again. Sorry but this needs more work...

Great job for the quick new release, thank you very much!

Hello Nigel!

Thank you for your reply, no problem for the delay, life happens!

I tested current dev and it is working properly now! Although I still do not understand why the function buildPdfContent() is rendering the content twice now? But it does not really matter, it is working like this so since this is major for people using fieldsets, would it be possible to have a new release with this fix please?

Thanks again for your time!

I can confirm the proposed patch fixes this issue, thank you!

I have done more testing and I found out the InvalidArgumentException happened only when upgrading to 2.0.16 from 2.0.14. Also, I tried to uninstall version 2.0.14 and cleared the cache before installing 2.0.16 and I got the same InvalidArgumentException. So the problem was from version 2.0.14 which should never have been released and I do not have more time to investigate further.

I tested on 3 different sites and I can confirm upgrading to 2.0.16 from 2.0.13 is working like expected so this issue is now "Closed (works as designed)".

Sorry for sounding a little harsh earlier and thank you for a great module!

Although I have to admit, it would be great to have much less advertisements in the config... Just not landing on the login form would make a good difference in my opinion. My 2 cents.

Thank you for your replies, I am back with 2.0.13 for now.

Sorry for jumping to conclusions, I really thought it was something as trivial as my previous issue : https://www.drupal.org/project/rest_api_authentication/issues/3455511 🐛 LogicException: Service 'rest_api_authentication.authentication.rest_api_authentication' for consumer 'authentication_collector' does not implement Drupal\Core\Authentication\AuthenticationProviderInterface. Fixed

I will do more testing on my site later today and come back with more details.

Thanks again both for your time.

LeDucDuBleuet → created an issue.

Can we expect this option to be committed to the theme?

@shashank_thigale

Looks like you missed one when visiting the config page, we now get :

InvalidArgumentException: Class "\Drupal\rest_api_authentication\Form\MiniOrangeAPIAuth" does not exist. in Drupal\Core\DependencyInjection\ClassResolver->getInstanceFromDefinition() (line 37 of core/lib/Drupal/Core/DependencyInjection/ClassResolver.php).

Sorry for asking but are you testing anything at all before doing a release?

I tested the proposed patch in the merge request !6 and I can confirm it is working well.

Version 2.0.14 works with this patch but it would be great to have a new release please.

Thank you.

This historic issue is for the Drupal 7 version and the patch needs to be re-rolled against current dev...

For the 2.x version, I believe you should open a new issue.

LeDucDuBleuet → created an issue.

I can confirm the patch is working properly! Thank you!

@maintainers

This patch has been working for quite a while now.

Would it be possible to have an official D10 release soon please?

Thank you.

This patch has been tested successfully for more than 6 months now on many websites, I can confirm it is RTBC.

@TR
It has been more than a year now, while not ideal, could we have a new release including this patch please?

Thank you very much.

So to replicate this error, you leave the cache on and the view pdf will work only once the first time.

Disabling the cache completely on the view solves this issue for good.

Thank you for looking into this.

I understand what happened, the fix was removed by the patch committed on this other issue : https://www.drupal.org/project/addtoany/issues/3138220 🐛 No link template 'canonical' found for the 'paragraph' entity type Fixed

I believe this fix was not implemented in release 2.0.5 and the exact same bug is back unfortunately when using the layout builder.

Here is a patch to bring back the fix adapted for current release.

Should we open a new issue or this one can be re-opened to be fixed again?

Thank you!

The module Layout Builder Iframe Modal is not required by version 1.1.6 so I removed the last part added to the title ", require Layout Builder Iframe Modal".

Here is a patch that simply put back the code for buildPdfContent from 3.0.2 which works like a charm.

Can somebody have a look at this please, I really believe that version 3.1.2 is broken as it is!

Thank you!

Hello @Nigel Cunningham

I've provided more infos a couple weeks ago, could you have a look into this please?

Thank you!

This is great, I can confirm the patch in comment #34 is working perfectly with the current release without any error and it migrates the focal points with success from Drupal 7!

It would be great to have it committed in a new release!

Thanks to all who worked on this patch!

Same problem here, the configuration page /admin/config/people/accounts cannot be saved on a new opensocial site.

I wonder if this issue should be set to major since we cannot close the site registration by default as it is?

Patch in comment #64 is working on Drupal 10.2.4 under Open Social 12.2.0.

Thank you.

OK, thank you for your quick reply.

I was just asking for now and I will open a new issue for that if need be.

Thanks again!

I agree that at first glance the fieldset seems to be there since its legend is displayed but I assure you, the fieldset itself is not rendered as it is now using 3.1.2.

You can use the custom CSS feature to include some CSS for fieldsets in your print.css for example :

fieldset {
  padding: 30px;
  border-radius: 8px;
  border: 1px solid #ccc;
}

You will then see more easily that the fieldset is non-existent in the generated PDF.

You can also put a \Drupal::logger inside the getOutput function in the file "printable/modules/printable_pdf/src/Plugin/PrintableFormat/PdfFormat.php" like so :

    if ($this->pdfGenerator->usePrintableDisplay()) {
      $raw_content = $this->buildPdfContent();
      \Drupal::logger('buildPdfContent')->debug('buildPdfContent @raw_content', array('@raw_content' => print_r($raw_content, true)));
      ...

You will then observe the following rendered code for example using the buildPdfContent from 3.1.2 with the double rendering:

Version 3.1.2
-----------------------------------------
<div class="field field--name-field-societe field--type-string field--label-inline clearfix">
  <div class="field__label">Société</div>
  <div class="field__item">TEST</div>
</div>

<span class="fieldset-legend">Coordonnées</span>
<div class="fieldset-wrapper">
  <div class="field field--name-field-telephone-principal field--type-string field--label-above">
    <div class="field__label">Téléphone principal</div>
    <div class="field__item">418-555-1212</div>
  </div>
  ...
</div>

And using the buildPdfContent code from 3.0.2, you get the following code which includes the fieldset rendered correctly :

Version 3.0.2
-----------------------------------------
<div class="field field--name-field-societe field--type-string field--label-inline clearfix">
  <div class="field__label">Société</div>
  <div class="field__item">TEST</div>
</div>

<fieldset class="group-contact-details js-form-item form-item js-form-wrapper form-wrapper">
  <legend>
    <span class="fieldset-legend">Coordonnées</span>
  </legend>
  <div class="fieldset-wrapper">
    <div class="field field--name-field-telephone-principal field--type-string field--label-above">
      <div class="field__label">Téléphone principal</div>
      <div class="field__item">418-555-1212</div>
    </div>
    ...
  </div>
</fieldset>

Visiting the path /node/[NID]/printable/print for the same content, we get the fieldset rendered correctly and the corresponding code that renders the content is in the getOutput() function inside the file "printable/src/Plugin/PrintableFormatBase.php" :

  public function getOutput() {
    $content = $this->buildContent();

    $content = $this->renderer->executeInRenderContext(new RenderContext(),
      function () use ($content) {
        return $this->renderer->render($content);
      });
    return $this->extractLinks($content);
  }

There is no double rendering there like it is done in buildPdfContent() now in version 3.1.2.

That is why I believe the buildPdfContent() function should be like it was in version 3.0.2 with the only difference in the rendering between PrintableFormatBase.php and PdfFormat.php being the preg_match call to make images working...

Let me know if you need more details?

Thank you.

LeDucDuBleuet → created an issue.

This is great, thank you very much!

I guess this will be included in the next pre-release version 8.x-1.2-rc2, right?

For a new site, this is perfect but what about existing sites with customers on Stripe already created prior to this new behaviour? I guess we could have some code to update them on our Stripe account from Drupal? Would that possible? Advisable?

Thanks again.

LeDucDuBleuet → created an issue.

This is great and working as expected now.

Thank you very much and keep up the good work!

Indeed : https://github.com/droptica/droopler/blob/8.3.3.0-rc2/droopler.info.yml

Thanks!

I just tried to install a new platform with version 8.3.3.0-rc2 and it only installs 8.3.3.0-rc1.

I used the command :

composer create-project droptica/droopler-project test "8.3.3.0-rc2"

It ran with no error but I am stuck with version 8.3.3.0-rc1 with the same error on that new stack :

composer why-not droptica/droopler 8.3.3.0-rc2

I get :

bower-asset/masonry v4.2.2 requires bower-asset/get-size (>=2.0.2,<3.0.0) 
bower-asset/masonry v4.2.2 requires bower-asset/outlayer (>=2.1.0,<3.0.0)

Did anyone get the same error? Any help would be greatly appreciated.

Thank you!

LeDucDuBleuet → created an issue.

I can confirm the proposed patch is working, it fixes the issue for us. Thank you very much!

I can confirm the proposed patch is working, it fixes the issue for us. Thank you very much!

I can confirm that this issue is fixed with current module_filter 4.x-dev.

So I guess we can close this one as a duplicate.

Thank you all for your work on this!

Just confirming version 4.0.1 still works for D9 as well.

And for D9, there is also the unsupported version 8.x-3.4 which is still working without issue on D9.

@jonathanshaw
Thank you for your feedback.

@maintainers
Would it be possible to see this new feature anytime soon in a new release?

Thanks.

The only site still on core 9.5.11 that I have is on the Droopler distribution. I was using Gin admin theme before and I tried as well with Claro with the same results, the search and radio buttons still do nothing even with the patch. In fact, they do nothing as well on the extensions page not just the update status page... So there is probably something specific to this site in particular or in Droopler causing this... This project is currently being upgraded to 10.2.x so this issue will be a thing of the past soon enough for me.

Thanks.

I can confirm the patch in comment #6 fixes the issue on core 10.2.1, thank you very much!

This patch in 3413467#comment-15392653 🐛 Radio buttons on Available updates report do nothing Active fixes the issue on core 10.2.1.

And on core 9.5.11, the error in the console is gone but the textual search and radio buttons still do nothing.

Yes I see the same error in the console with core 9.5.11 and module_filter 4.1.0.

The radio buttons do not work and unlike with core 10.2.1, the textual search filtering do not work either with 9.5.11.

This is possibly a duplicate of issue 3413467.

I get this error on Drupal 10.2.1 after upgrading to module_filter version 4.1.0.

The textual search filtering works but the buttons under do nothing.

Here is more info from Firefox's console where I masked my domain with xxxxxxxx.xxx :

Uncaught TypeError: t.nodeName is undefined
    val jQuery
    attach https://xxxxxxxx.xxx/modules/contrib/module_filter/js/module_filter.update_status.js?v=10.2.1:118
    jQuery 7
    attach https://xxxxxxxx.xxx/modules/contrib/module_filter/js/module_filter.update_status.js?v=10.2.1:125
    attachBehaviors https://xxxxxxxx.xxx/core/misc/drupal.js?v=10.2.1:166
    attachBehaviors https://xxxxxxxx.xxx/core/misc/drupal.js?v=10.2.1:162
    <anonymous> https://xxxxxxxx.xxx/core/misc/drupal.init.js?v=10.2.1:32
    listener https://xxxxxxxx.xxx/core/misc/drupal.init.js?v=10.2.1:20

And the corresponding lines in module_filter/js/module_filter.update_status.js starting from line #117 :

        $show.change(() => {
          show = $(this).val();
          Drupal.ModuleFilter.localStorage.setItem('updateStatus.show', show);
          Drupal.ModuleFilter.winnow.filter();
        });
        $show
          .filter(`[value="${show}"]`)
          .prop('checked', true)
          .trigger('change');

So it seems the bug comes from the use of "$(this).val()" on line 118 but I have no clue how to fix this...

Thanks in advance for looking into this.

I can confirm that after removing the patch from MR 388 and upgrading to Drupal core 10.2.1, the file upload is working correctly in my custom web forms.

This is great news, thanks to all for your time!

I also tested the file extension validation and it is still working even with the patch so the fix does not completely remove the file extension validation.

It removes the line :

$element['#upload_validators']['webform_file_validate_extensions'] = [];

But we still have :

$element['#upload_validators']['file_validate_extensions'] = [$this->getFileExtensions($element)];

As of this morning, the patch is still needed with 10.2 for the file upload to work properly so yes this is still happening.

Now that the fix in the issue #3385414 has landed in Commerce core 2.37, it would be great to have a new release including this fix please.

Thank you!

Patch worked for us as well, thank you very much!

Been using patch in comment #29 on current dev version for about 2 months now in a couple projects and it is working well with D10.2.x.

So I am placing this to RTBC in the hopes of having an official D10 release soon.

Thank you for a great module!

You are right, this is working perfectly now, thank you very much!

I believe this is ready to release!

We would need to do the same for a specific project so I created a patch adding this feature.

I tested in Stripe test mode and this adds the owner's display name in the customer created on Stripe as intended.

As you know, Stripe simply uses the email as the customer's name when the name is not specified on creation.

I wonder if using the display name might cause some unwanted side effects?

Can someone confirm this is OK to do so?

Thank you!

This issue is marked as fixed but the patch is still not included in the new 8.x-3.16 version.

The status should be RTBC and this needs to be included in a new release please.

Thank you!