🇮🇹Italy @finex

Thanks for the MR. I've updated the code.

Updated patch, the previous had a typo on a couple of filenames.

Hi, I've created a patch with the following features:

- Add a settings page to define the colors palette.
- Add a widget settings to allow entering a custom hex code on the box widget.
- Load the settings palette colors as default value when the field is configured of if the field settings value is empty.

Hi, this feature is no more available on D8+ version.

finex → created an issue.

Hi, I've had the same error followed by another (which is probably the cause):

attempt to perform an operation not allowed by the security policy `PDF' @ error/constitute.c/IsCoderAuthorized/426

It's an error on the server imagemagick policy.

I suggest to catch the error and display a message to inform the user to update the imagemagick settings.

Hi, I'd also like to remove the "Back to top". Currently I'm overriding toc-back-to-top.html.twig

Hi, should the patch also works with "Layout Builder iFrame Modal"? I've tested #19 and it seems not. Thank you.

Thanks for suggesting the Custom Filter module (now it's also available on D10) but I still prefer this lightweight module. Even if it's a "won't fix" I've updated the patch :-)

Hi, #66 and #74 solved the problem. Thank you very much :-)

I also confirm: patch #121 works correctly. Thank you.

Hi, I've checked the code and it looks correct. Thank you.

Hi, after updating to Drupal 10.3, the CkEditor inside Layout Builder iFrame Modal works fine and I don't need anymore this patch.

Hi, thank you for the patch. It works correctly. Tested on three websites without any issue.

Hi, the MR 34 fixed the problem. Thank you very much.

Hi, I've tested the proposed patches and it works fine. Thank you very much.

Fixed typo.

Fixed typo in title

Uniformed formatting and added missing link.

Added missing "()".

Hi, will this feature will be backported on current stable 6.x version?

The proposed merge request only partially resolves the bug. If the window is wide enough it works, but below 1024px it does not.

Hi, until the bug is not solved please add a warning on the description in the module page. Thank you.

Hi, the patch works fine. Thank you.

FiNeX → created an issue.

Hi, I'm experimenting with an hardcoded JS workaround. I've created two "background" crop types (landscape and portrait). If on the field formatter one of those preset is enabled, then on the JS i simply check the window size and eventually swap the crop type.

This is a simple example code I've put on drimage.js on Drupal.drimage.renderEl before setting the imgUrl variable:

if (iwc == "crop_landscape_background" || iwc == "crop_portrait_background"){
  if (window.innerHeight < window.innerWidth) {
    iwc = 'crop_landscape_background';
  }
  if (window.innerHeight > window.innerWidth) {
    iwc = 'crop_portrait_background';
  }
}

This approach is quite simple and it only needs a "portrait crop style" setting on the field formatter in order to be more dynamic instead of hardcoded.

What do you think? It could be an easy solution until a more flexible solution will be implemented. Let me know.

Hi, the proposed patch just add some comments and does not modify anything relevant. It does not look as an improvement. Do you plan to create a valid patch to the issue? Thank you.

Yeah, I know: when the revisions are enabled the procedure I've developed breaks the revisions system.

The main problem I'd like to solve is when you have to delete a block type but you can't delete a node. In this situation the orphaned entry will prevent to delete the block type. You have to delete all the old revisions and after delete the block instance from the database.

Hi, I'm also interested on a solution to enable different crop types based on screen size/orientation.

FiNeX → created an issue.

FiNeX → created an issue.

FiNeX → created an issue. See original summary → .

Hi, the patch works fine. Thank you very much.

FiNeX → created an issue.

FiNeX → created an issue.

Hi, I confirm that PNG format works fine, it should be added the option to set the background color when using jpg format instead of using the black default color.

Hi, after a bit of testing I realized that, in my case, the problem was related to twig debugging. In fact, in the development environment I have twig debugging active and therefore the empty fields are also visible, while in production, with debugging deactivated, the empty fields are correctly hidden.

@robcarr: the search works fine except it is not integrated with options like "Jump directly to the first search result even when there are multiple results"

Hi, I'm also experiencing this bug.

Hi, with latest release (1.2.0) I'm not able to reproduce this issue anymore. Probably with the new API the type is always available. I've tried all custom types from Brevo and now it's ok.

In my opinion this should be a configurable behavior. We should let the site owner to decide how to manage this situation. It should be an option on the handler settings: allow or deny submission when data is already present on Brevo. If the user is allowed no warning are shown, it should simply be logged on watchdog. With the deny option instead it should be printed a message and blocked the redirect.

Fixed on release 1.2.0 → . Now the module uses getbrevo/brevo-php which is fully compatible with latest PHP8/D10.

Fixed on release 1.2.0 → .

Fixed on release 1.2.0 → .

Fixed on release 1.2.0 → .

Fixed on release 1.2.0 → .

Duplicate of https://www.drupal.org/project/seo_hreflang/issues/3148736 →

Hi, I've created the following issue with a patch to also solve this problem: https://www.drupal.org/project/sendinblue_api/issues/3432945 🐛 Module does not work out of the box. Update to Brevo API and fix Webform handler Active

FiNeX → created an issue.

Hi, I've found a couple of related issues which could be considered when fixing this request.

• https://www.drupal.org/project/drupal/issues/2978727 🐛 Use current time setting for the timestamp widget Needs work
• https://www.drupal.org/project/drupal/issues/2978467 →

Hi, I've seen a 3.x version. Is this issue still valid?

FiNeX → created an issue.

Hi, I cannot reproduce the bug on the latest version. Maybe it has been solved on 2.x version?

I've updated the patch, the previous was incomplete.

Hi, I've updated the patch.

Hi, the patch works for me. Thank you.

Thank you for the patch. Will be included in a stable release?

Hi, could this patch considered as "safe" for production environment or is still under development? Thank you very much.

Hi, I'm also experiencing this issue. Changed field type from blob to mediumblob temporary fixed it. A

Hi, I've recorded a quick video with a demonstration

Hi, patch #3 works fine on D10.2.2. Thank you very much.

Hi, I confirm the bug is no more reproducible on D10.2.

FiNeX → created an issue.

FiNeX → created an issue.

Yes, on Gin theme it works as expected.

FiNeX → created an issue.

FiNeX → created an issue.

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

I've tested the patch and it looks fine. Thank you.

FiNeX → created an issue.

FiNeX → created an issue.

Hi, this solution works fine for new installations, but what if meanwhile I've updated the paragraph after the installation? The "config/install" yml are parsed only at module installation. To update paragraph settings you're forced to use hook_update_N() which is quite convoluted especially if you add a lot of fields.

Thanks for the patch. It works on D10.1

Hi, the patch works fine with "unformatted list". Do you have a plan to fix the "HTML list" format too?

Hi, I've created a new clean site and the option works fine. I'll check again the other site to find the differences. Thank you.

Hi, the patch works fine. Thank you!

Hi, I'm sorry but I'm not using mailchimp anymore so I can't test this issue.

FiNeX → created an issue.

FiNeX → created an issue.

Parent content if I remember correctly.

I like the patch, +1 :-)

Ok, done :-)

@mmbk: hi, I did not see your comment. The patch is the same. So we can close this bug as duplicate ok?