Account created on 27 December 2008, over 15 years ago
  • Web Developer / UI Designer at 

Merge Requests


Recent comments

Fixed classnames, I won't add any styling to the module, as it leads up to massive time consumption, while I don't see any benefits for us.

There is no parent wrapper "billwerk-component-subscription", so all "billwerk-component-subscription__x" classes are wrong.

I cannot access the subscription page of the current project because of "GuzzleHttp\Exception\ClientException: Client error [...]", so I can't check where these elements go and what the correct names are.

Oh, the issue is on our side, the block needs to be translated. Wherever the global "No, thanks!" string belongs to.

Sorry for the noise.

All fixed.

Yes, I think the dependency makes sense, in theory it's only required on some of the submodules, but.. who cares ;)

We should probably make all responsive_image.styles.x configurations optional, or remove them if possible. This is a huge rabbit hole we should not go down in this module.

Responsive image styles can be project-specific, they depend on a set of breakpoints (provided by modules or themes, in our case the drowl_base theme) and many image caches.

So adding all this as configuration to DROWL Media will bloat its configuration a lot.

So, I'd vote to ignore this, remove the affected configuration and let the responsive image formatter use its default/fallback value.
Maybe we can add an entry to the status page or a message to dblog, if no responsive image format is configured.

But I think a simple hint on the module page will do the job.

Of course, the affected field can't be locked, as the user needs to be able to configure it.

The layout_options.yml in drowl_paragraphs_bs_type_layout_slideshow should be the only one in drowl_paragraphs_bs.

Another one is located in drowl_layouts_bs:

I think putting the active class on the input is the Drupal standard. But from a theming perspective, I'd vote for the second class on the wrapper. But this should be "form-item--active".

Not sure how to merge the two forks... so would you be so kind? ;)

Oh, so maybe a simple text field with some JS validation would be a good choice here?

Or we need another field to let the user choose the frontend decimal delimiter.

I've thought about this several times in the past... the option still seems necessary, but perhaps the default was not well chosen. But default options is still an open topic for UI Styles... so this might be blocked for now.

Yes, we should add this as a UI style if the existing border + spacing options are not enough.

Not sure why this should be a Paragraph type and not a layout .. mhm.. I'll move this to DROWL Layouts BS. Should be easy to solve using Layout Options.

Oh, this is quite easy. I killed the whole bundle as it's useless ;D Using a text paragraph and a list style in CKEditor is much more comfortable and linking items is also possible.

Already fixed in BS, all types with a button now have the button color UI Style.

We need a whole new UI for the UI styles in DROWL Paragraphs BS and the layout options in DROWL Layouts BS, so I think we can close this here and add new issues.

LB is no longer that relevant to us, so we shouldn't spend too much time on it.

Done, but with a shorter "[DROWL]" instead "[DROWL Layouts]" group prefix. We don't provide similar named layouts with different DROWL modules.

This is already fixed in BS using Layout Options . Its not on the settings page, it's in the layout options YML file, but that's fine.

Image + Video are removed in the past.

I considered renaming this.. but didn't find a better name. So let's leave it as Image + Text. I have removed the option to have the image and text in two separate columns (what could be easiliy achieved using a layout), so it's only limited to the special skills of this type:
- floating images into text
- cropping floated images with clippy, so the text follows this path

OK, I've added the config. I need to fix the template when we have an instance up and running again.

It is still an issue, but as I said, it is not our issue. I think we can close this. CK or Core will have to fix this.
The content area of the UI dialogs is scrollable, so it's not that problematic.

Correct, we still need to fix this, I wasn't aware of this issue, but I've already left a comment in the code to replace it. Good to know we have already found an alternative.

Guess this is now pretty easy to achieve using the existing UI Styles options on a layout + content Paragraphs in it.

No, it's not. Maybe we can hook into the UI Styles fields and control this by bundle. We need to check this.
Maybe worth a feature request on , seems to be a useful submodule.

We have a width option for some specific Paragraph bundles, using UI styles. I need to check if we need this on further types.

No, but we have a new approach on other linked Paragraph types that we should use here too. I move it over.

Still not working for me. Changing something in layout_paragraphs still causes this issue randomly.

Created a Quickfix for this, using position: sticky and flexbox to have basically the same experience (while it doesn't look that perfect, but it works).

I thought about this feature again, and while there are cases where this approach makes sense, the example given (button paragraph) works well with the existing Micon link formatter.

So let's postpone this for now.

@ayush.pandey, note that only official icoMoon packages from "" are supported. The package you linked will throw additional errors, as the folder structure severely differs from packages on

To be more precise: packages generated with the app. The provided package is also made by icomoon, but does not follow its generated package structure.

Are you aware of ?

You don't have to switch to the whole UI Styles ecosystem to use this, and it's a really great approach.

If I remember correctly, you are able to define defaults in the yml, and while the individual Paragraph instance has not overridden the style, you are able to update the default value globally.

Sure, it's not at field level, it's set on the paragraph itself, but this is more common practice.

Yes, nice, works perfectly fine for my case. Sorry, my search criteria were probably not so good.

You guys did a great job with these modules ❤❤❤

Thank you!

ui_styles already has a "category" attribute, so maybe just extend that. I like the idea to additionally define a category type like tabs.

Production build 0.62.1