🇮🇹Italy @finex

finex → created an issue.

Hi @jsacksick, you were very fast :-) Thank you very much!

It seems that toc_api (specifically the TocBlockBase class) has an issue with Layout Builder. The getCurrentToc() method returns a null value. Additionally, the getCurrentNode() function checks the route name but doesn't account for Layout Builder paths.
I've reported the issue on the toc_api module: https://www.drupal.org/project/toc_api/issues/3520464 🐛 Layout builder fatal error Active

finex → created an issue.

I also confirm that the patch fixes the fatal error, but the toc block is missing. Moreover, the toc_api seems to have an issue on LB as well, so I don't know if the missing block is due to a bug in toc_api or toc_filter. I'm investigating.

finex → created an issue.

Hi, I'm using the following patch since last year on at least a dozen of website without any problem.

Consider the patch as an example because assumes that an image style called default_preload exists.

I'm also attaching an example of the image style settings.

Hi, after some testing I can confirm it works. Thank you.

Hi, I've at least two use cases where a dynamic crop would be useful.

Example 1:

In my first scenario I've a text block near an image. The image needs to be cutted on top and on bottom in order to have equal height to the text. Using CSS it works fine (grid + object fit cover) but the real image size is bigger in one dimension or in the other.

I don't know the image ratio because it depends from the text len. Simply scaling or using a "backound" option on drimage is not correct in this particolar case.

Example 2:

I've another use case: a gallery with columns with different sizes and on each row the images needs to have the same height. Let's explain better: consider a css grid with columns like 1/6+1/6+2/3, the images heights are 100% to the grid with object-fit cover. Now imagine that all the images are in landscape, let's say a common 16:9 format, the third one will be scaled and the quality will be fine, the first two instead, with the current implementation (and using "scale") will be scaled to a correct size but, due to the height 100%, the quality will be poor because the aspect ratio is very different.

My current solution (work in progress):

I'm trying to implement a new option called "Dynamic aspect ratio crop". It is simply a copy of scale but with el.offsetHeight().

The initial tests are fine and it allows me to cover all the cases.

I'm also using all the existing modes in other cases and they works very well. This is the last feature to cover all my needing :-)

finex → created an issue.

Hi, did you close the issue because the module is compatible with image_widget_crop? What do you think to make it compatible also with focal_point module without image_widget_crop?

Hi, patch https://www.drupal.org/project/drupal/issues/3348037#comment-15223547 💬 TypeError: Illegal offset type in Drupal\Core\Entity\EntityStorageBase->load() Active solved the problem I've got updating the DB. It was stuck on "Post update configured views for entity reference argument plugin IDs." (update from D10.2 to 10.4). Thank you!

I'm very sorry, I thought it was automatic. I've just edited the release description message!

I'm very sorry, I thought it was automatic, I'll do a new release with the credit as soon as possible!

finex → created an issue.

Hi, the "reset sequence" is available on the UI. I think this issue can be closed.

Hi, I came here because I'm having an issue with SVG media thumbnails. Here's my case: on the media management page, some SVGs appear huge even though the view settings are set to display 100x100px thumbnails. Now I'm forcing a custom CSS to make the thumb smaller but it's not a good solution.

Do you need a patch for the template, or would you prefer to simply extend the documentation? Let me know.

I've created a library override on my theme redefining the JS and CSS using flexbox to improve the responsiveness (I'm using libraries-override to completely remove the module js/css because I've also refactored the js without jquery and fade it/out effects).

finex → created an issue.

finex → created an issue.

Hi @megachriz: what's the status of 2.1.x? if you'll release a new version based I'd like to test it. Thank you very much.

I agree with @megachriz to reverse the option label.

finex → created an issue.

finex → created an issue.

A more updated module is: https://www.drupal.org/project/unpublished_404 →

A more updated module is:  https://www.drupal.org/project/unpublished_404 →

Thank you @ahmad khader.
I will try the new MR.

Hi, I've tried the MR2. It looks promising but I've to report a couple of issues:

Translation of key values should not be allowed

Field key values should not be translated. For example I've a block with a custom field called "image position" with three values: top, left and right. The field is translatable because (using AT) the image position could be different between languages.

The MR2 translate the value of the field while it should not.

Key field values should not be translated. For example, I have a block with a custom field called "image position" that has three possible values: top, left, and right. The field itself is translatable because, using AT, the image position may vary between languages.

However, MR2 translates the field’s values when it should not, as these values must remain unchanged.

Extreme duplication of records

Another major issue I've encountered is the extreme duplication of records. I tested this on a trilingual website by creating a basic page with a custom layout. The layout contained twelve sections and 26 blocks. Before the translation process, the block_content table had exactly 26 records, one for each block. However, after translating the page into the other two languages, the table grew to more than 40,000 records.

I'm still having the same problem using 8.x-1.7 on D 10.4.3.

I was experiencing this bug: the "create new revision" checked and disabled and the log message input form not available (with content moderation enabled). I've fixed going to the content type settings page (admin/structure/types/manage/XXX) and pressing the save button.

The content moderation module should automatically save the "new_revision" option of the content types managed by a workflow.

finex → created an issue.

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 → .