🇨🇦Canada @LeDucDuBleuet

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!

I can confirm the merge request !5883 fixes the issue for me as well on 10.2.0!

Thanks!

Same problem here. I guess this could be considered a duplicate of Exposed filter values ignored when using batch 🐛 Exposed filter values ignored when using batch Needs work ...

We are facing the same issue once upgraded to Drupal core 10.2, the batch results are not filtered anymore.

I tried the patch in comment #3 and it fails to fix the issue for us unfortunately.

We get the same unfiltered results with and without the patch.

I am re-opening this issue since I just noticed a side effect that the latest patch introduced.

We are loosing the primary tabs on the edit entity form when the "Primary tabs" block is placed in the default "Header" region.

Moving the "Primary tabs" block in the "Pre-content" region solves the problem but this is not a good solution since by default the primary tabs won't show when editing an entity.

Sorry for not catching this sooner...

This patch is still needed for the new 2.0.0-alpha2 release.

Here is a new simpler version of the patch based on 2.0.0-alpha2.

It would be great if this could be included in a new release please.

You were right, I tested right before the b1762dc7 commit.

So I tested again on Firefox and Chromium with success! The header is now sticky again with its shadow following properly and the right column displayed. I tested on desktop and mobile with and without toolbar access and all is well now!

Thank you very much for you time, I believe this fix is ready to be included in the next release.

Same result as before, the sticky header is not sticky.

Also I do not think devel module should be added in composer.json require section?

OK, now with the new commit, the right column is back and the shadow is still in its right place but the sticky header is still missing when scrolling down without toolbar access as you can see in this new screenshot :

And all is well when the user has toolbar access.

Thanks again!

OK, the patch with the new commit corrects the issue in comment #12 when the user does has access to the toolbar, all is well now with the secondary toolbar. But we still have the same behaviour as before when the user does not have access to the toolbar reported in comment #11. We loose the sticky header when scrolling down with the shadow at its right place and the right column is not shown at all.

We're getting there, thank you!

I did not notice at first but the patch also makes the secondary toolbar disappear when we have access to the toolbar and it leaves some empty space in the header.

Screenshot of the dev version without the patch :

Screenshot of the dev version with the patch :

Ok the dev version did the trick, now the patch applies cleanly with the .diff extension and the .patch extension as well.

Now the shadow sits where it should but the header is not sticky anymore and we loose the right column content.

Thanks!

@kksandr This sounds great but I am not able to apply the patch from the MR like I usually do with other modules.

In my composer.json I put :

            "drupal/gin": {
                "Issue 3403123 Sticky shadow position without toolbar":"https://git.drupalcode.org/project/gin/-/merge_requests/340.diff"
            },

I run :

composer update --prefer-source drupal/gin

And I get the following error:

Could not apply patch! Skipping. The error was: Cannot apply patch https://git.drupalcode.org/project/gin/-/merge_requests/340.diff

Am I doing something wrong?

Or could you provide a standard patch here that I could include more easily in my composer.json please?

Thanks!

@swatidhurandhar Thank you very much, we're getting there!

Now with this patch, the header does not get cut off and shows correctly but the sticky shadow is still too low as you can see in this screenshot :

We are facing the same issue for users without access to the toolbar but with access to the admin theme.

Here is a screenshot of the result :

To reproduce, simply give access to the admin theme without access to the toolbar.

Thanks for looking into this.

I am facing the same issue where we need the billing profile information to be recorded in Stripe for reference especially the customer name.

I see the card name is recorded in Stripe but sometimes people use a company card and we really need the name on the order.

Thank you for looking into this.

It is weird because if you followed the update.md instructions, you should have version 3.2.0-rc1 instead of version 3.1.0 in your upgrade status messages and it should say it is installed...

Well, this issue is indeed a duplicate of mine. But I do not have an exact solution to show the sidebars since I chose not to use Droopler for the project I needed them for. Sorry, as you can see in my issue, I asked for more information but never got a reply.

I know this has been committed already on dev for a while but we would need a new release please for Drupal 10 now that Drupal 9 is EOL.

Thank you!

I can also confirm this fix is working as well.

Will there be a new release with this fix included?

@TR
I understand that you want it clean with the testing and all but Drupal 9 is not supported anymore and we really need a functional D10 version of this module. It has been more than 8 months and no work has been done on the other issue #3155325: Improve image detection...

So I am asking if it would it be possible to release a D10 version even if the band-aid solution is not ideal please?

Did you solve your issue with the upgrade?

We can see in your screenshot that the conflict was caused by the Devel module at version 4.x which is not supported in D10.

You should use version 5.x :

composer require 'drupal/devel:^5.0'

And then try again...

Maybe you already know but you can also use the Upgrade status → module to better plan your upgrade.

I believe this is a duplicate of an issue I filed last spring : https://www.drupal.org/project/droopler/issues/3359701 →

OK, I found a way to put back my titles as required quite easily.

I exported my configurations using "drush config:export" and then I edited the corresponding title yml files to put them back as required.

For example, for the page content type, we edit the file "core.base_field_override.node.page.title.yml" and modify the line "required: false" to "required: true".

And then I imported back my configurations using "drush config:import --partial --diff".

TaDa! The titles are now required as needed!

In a project, the title field was required in Drupal 7 for my content types. Once migrated to Drupal 9 and now 10, the title field is not required anymore causing the same integrity constraint violation stated here.

I looked in the config table and there is no entry overriding titles so I am left with content types without required titles causing the error when saving with an empty title.

How can I have the titles back as required like it was in D7?

I tested again and it seems the module is working properly in D10 with the patch in comment #29.

I am truly sorry, it seems there was something wrong with a cache on my server that was preventing the log out and the redirection...

So I am placing back this issue to needs review, it would be great if someone else would test this as well.

Thanks!

@mkalkbrenner
Thanks a lot for the band-aid in comment #4, it helps going forward while the other issue is worked on!

@TR
I'll have a look at that other issue to see if I can help.

I tested the patch in comment #29 using Drupal's Lenient Composer Endpoint → and it applied cleanly but it does not work as expected in D10.

First I tested without "Global Restrictions" using only an IP restriction for a user. When logging in from an IP that is not allowed, the user can log in and seems logged in at first but we get an access denied when visiting any site url. We do not get redirected to the configured "Login denied error page". And in the recent log messages, we see "Session opened for Employe.Bidon." followed by "Login denied from 185.213.80.89 for Employe.Bidon." so the log in was effectively denied but allowed first.

When using "Global Restrictions", the user cannot login from a global IP that is not allowed and we do not get redirected to the configured "Login denied error page" as well. And in the recent log messages, we see "Session opened for Employe.Bidon." followed by "Login denied from 185.213.80.89 for Employe.Bidon." so the log in was effectively denied but allowed first.

When using "Global Restrictions", the user can login from an allowed global IP even though that IP is not allowed in that user's IP restriction.

So we are getting there but there is still some work to be done...

We really need this module to be functional in D10 so let me know when there is a new patch to test!

I am bumping this issue as major since the Drupal 9 EOL deadline is coming up soon!

Thanks for a great module!

This is exactly what I was looking for so the module works like it was in Drupal 7. The template should not introduce any whitespace other than the one(s) specified in the parameters.

So this patch applies cleanly and works really well, thank you very much to JeroenT!

Would it be possible to commit this patch into the next release please?

Thanks for this great module!

I can also confirm the patch still applies cleanly and works like a charm!

Referencing users by email simplifies things a lot when needed.

It would be great if this little patch could be merged into the module for the next release please.

Thank you for a great module!

Hello maintainers!

Would it be possible to have a new release including this patch for Drupal 10 in the near future please?

Thanks in advance!

I can confirm the patch in comment #5 does the job!

Thanks!

In this current issue, the patch in comment #7 is using the following for line 45 in the file src/Plugin/Mail/Maillog.php:

$record->subject = mb_substr(iconv_mime_decode($record->subject, ICONV_MIME_DECODE_CONTINUE_ON_ERROR), 0, 255);

And in the #3331181, the MR is using the following for line 45:

$record->subject = mb_substr($record->subject, 0, 255);

So in #3331181, the decoding with iconv_mime_decode was completely removed instead of continuing on error in the patch here in #7.

I tested both patch and they work for me.

But which one would be best to cover all use cases?

Thanks to all contributing to this great module!

I had the same issue, the views_pdf was exporting to PDF only the first time and clearing the cache made it work again but only once.

I tried the patch in MR!3 but it was creating an error on the return $response...

So I disabled the cache on the PDF view and now it is working well everytime!

I had the "Tag based" and using "No caching" made it work.

I can confirm this patch fix the problem, thank you very much!

I can confirm as well that the changes proposed in the merge request https://git.drupalcode.org/project/ds/-/merge_requests/13.diff are functioning as intended.

@Rishi Kulshreshtha Thanks for the code snippet to put in composer.json until this gets committed!

I believe this to be a duplicate of : https://www.drupal.org/project/ds/issues/3331674 🐛 Notice: Undefined index: #entity_type in ds_preprocess_ds_layout() Fixed

So I am closing this one as a duplicate since the solution is the same on both issue and the other one has a MR.

Feel free to reopen it if I am mistaken...

Thanks!

I can confirm the proposed solution is working well. Thanks!

@srinivasraod Great, glad I could help!

So I also reviewed and tested the merge request !25 with success and I think it is safe to put this issue to RTBC.

Thanks!

@srinivasraod I believe you did not apply the right patch. Can you try this one?

https://git.drupalcode.org/project/permissions_by_term/-/merge_requests/...

No problem, sorry for closing it in the meantime.

@ChrisSnyder Indeed, this may explain why I could not go from 1.10 directly to 2.0.1. To make it work in my site, I had to upgrade to 1.11 and then to 2.0.1...

But I found the source of my specific problem!

For some reason, I had 2 conflicting entries in my composer.json.

One for the captcha module :

"drupal/captcha": "^1.10",

And one for the image_captcha module :

"drupal/image_captcha": "^1.9",

I have no idea why it was like that... :-|

Once the second extra one removed, I updated the module again from 1.10 to 1.11 and then to 2.0.1.

All is well now, sorry for the lost bandwidth, it seems my problem was not directly caused by the upgrade.

Thank you for a great module!

LeDucDuBleuet → created an issue.

This is great, thanks for committing this!

But since this is quite major, will there be a new official release including this fix?

I have tested the new patch 3361048-11.patch and it does not work work here on 3.0.0 and current dev.

But the patch printable-pdf2.patch in comment #6 still works well on 3.0.0. and current dev.

So the already reviewed patch is still valid, I believe we should hide the new one and commit printable-pdf2.patch if the maintainers agree that it is ok with the original intended purpose.

Thank you.

I believe this is a duplicate of issue 3361048 : https://www.drupal.org/project/printable/issues/3361048 🐛 Error on Printable PDF configuration page Fixed

I reviewed the commit 4d8c5c7a - Fix token_args rendering and it does not work. No error on the page but the token link is not functional.

With the complete patch printable-pdf2.patch in comment #6, all is well and the token link displays correctly.

Thank you!

Here is an updated patch against current dev that asserts that the item is not empty or that an array is not empty.

Hopefully the tests will pass now and this can be included on the next release.

Thanks for this module!