thomas.frobieter → created an issue.
@anybody it's already included in the current 5.x beta
thomas.frobieter → created an issue.
thomas.frobieter → created an issue.
Yes! The fix works well (:
thomas.frobieter → created an issue.
I was wrong, it's about the archived option, it's an "opened" webform, but it's archived.
However, still a bug and the message is kind of misleading.
thomas.frobieter → created an issue.
thomas.frobieter → created an issue.
thomas.frobieter → created an issue.
@thomas.frobieter: We must be careful, for Slides the field_image_caption field is labeled "Overlay-Text"!
Should we keep that label?
We should, because the other fields are also named like this and "Caption" would be kind of misleading here.
thomas.frobieter → created an issue.
Yes, this needs a lot of work from my side, this will not be fixed anytime soon.
Now that we'll remove field_image_caption what's the plan for slides?
Since 4.x is backwards compatible, we might need a database update, wouldn't we?
Otherwise, all existing media slide overlay texts are gone.
No output, no styling required ;) Fixed.
@thomas.frobieter: Config was now added in the parent issue. Can this be set FIXED or are styling tasks remaining for you?
Hopefully not, the View which prints the copyright values should be a simple HTML list, so.. this should be fine.
I need to check the output and probably fix the styling, so yes, leave it open for me.
Exactly
@anybody Guess now it's your turn?
Added the link field to:
- media_slide
- media_video (only local)
- media_image
- media_vector_image
- media_audio
Fixed field configuration in our preset.
Added and configured the new field in our preset @anybody, but I can't delete the old field_image_caption because the fields are locked, and I don't want to perform CEX/CIM at this state.
Drush or Devel PHP?
Preset config done.
Ah.. fixed by field tools..
Unable to add field_caption to documents because:
While there is no button to add existing fields, for buggy core reasons I guess..
MHM, seems to be a UI Styles job in 4.x. I would not fix this in 3.x. This was never an important topic on existing projects, and it's easy to solve using our Paragraphs Styles UI if required.
So I move this to BS.
This is already fixed in 4.x because we don't use background images anymore. Instead, we use the absolute positioned field, so we have lazy loading and responsive image.
I would not fix this for 3.x.
I think so.. fingers crossed.
thomas.frobieter → created an issue.
We've removed this from 4.x, but we might re-invent this later, because it's still a helpful user-friendly concept.
However, I'll close this one, and create an new issue in drowl_paragraphs_bs.
Not solved yet.
Partially solved... needs to work on.
Right
About 6 out of 10. Could we add the required fields so we don't have to do database updates later? This should be a 30 min Job? I'll add the required TPL and CSS changes later.
ouh.. mhm.. of course, it is.
Another approach are Paragraphs, but we've discussed this in the past, and I'm going to stick to what I said: This is far too flexible, high potential for error.
So whats the most clean approach here?
I can think of the same settings we already have, duplicate them twice for medium and large devices. Rest is CSS.
- Overlay Direction (probably with limited options on for small devices (only top or bottom, not left or right)
- Overlay Size
- Don't crop Image / Video
and maybe:
- Overlay Color
- Button Color
Maybe we need the same for Media Slideshows, because this is where we configure the slideshow height:
- Slideshow Height
and maybe:
- Autoplay
- Show Arrows
- Show Dots
Yes, this is already fixed.
What we could do here, is use an autocomplete field, so it would be easier to prevent duplicates, if the image is used several times and we could maybe use distinct in the imprint?
To be honest, I can't think of a single time when this has been an issue. Also, link fields with autocomplete doesn't sound like a core feature, so it needs another contrib module?
Much more problematic are the same images in different variations. This would lead to duplicate licence entries. I think views are a better place to prevent this, but with a simple link field we have no reliable way to detect this. So at minimum, we'd need a separate field for the stock photo provider's image ID. So things are getting too complicated.
Conclusion: Ignore duplicates. Nobody cares. They don't cause legal problems.
Works for me!
Done
Yes!
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.
https://git.drupalcode.org/issue/billwerk_subscriptions-3416871/-/blob/1...
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.
thomas.frobieter → made their first commit to this issue’s fork.
Patch #15 aka MR works fine and fixes the forum translation as expected
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.
thomas.frobieter → created an issue.
thomas.frobieter → created an issue.
Fixed, please review.
thomas.frobieter → made their first commit to this issue’s fork.
thomas.frobieter → created an issue.
thomas.frobieter → created an issue.
thomas.frobieter → created an issue.
All fixed.
Yes, I think the dependency makes sense, in theory it's only required on some of the submodules, but.. who cares ;)
Done
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.
Looks good to me, I'll need to replace the Templates afterward 🐛 Replace Foundation Twig Templates with Bootstrap Templates Active .
thomas.frobieter → created an issue.
nevermind, fixed in dev.
thomas.frobieter → created an issue.
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: https://git.drupalcode.org/project/drowl_layouts_bs/-/blob/1.x/drowl_lay...
thomas.frobieter → created an issue.
thomas.frobieter → created an issue.
thomas.frobieter → created an issue.
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? ;)
thomas.frobieter → made their first commit to this issue’s fork.
I agree, let's postpone this.
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.
Yes, we can, many styles are now moved into the modules.
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.