What you are proposing would create dependencies between the confirmation and waitlist submodules that we don't want, forcing users to always enable both. We can't do that, they have to be separate, waitlist functionality must go completely in the waitlist submodule and confirmation similarly completely in its submodule.
Alright, I will modify both modules then. Moving all confirmation code to registration_confirmation module would mean, that user could easily enable/disable all confirmation functionality by enabling/disabling that module, registration_waitlist itself would not be dependent on it (if i understand it correctly).
I spent some time studying the module design, so that my code fits in.
And I have some questions:
It seems to me, that notification code triggered by registration to waitlist currently present in registration_waitlist module might make more sense in event subscriber placed in registration_confirmation module (subscribing to RegistrationWaitListEvents::REGISTRATION_WAITLIST_WAITLISTED event). This would centralize all notification code in this module.
I also think it makes sense to introduce a MailNotification class in registration_confirmation module, so we can easily reuse the code now placed in RegistrationEventSubscriber for both use cases and keep things clean.
What do you think about this, please?
Thanks for the answer and suggestions. I agree that it makes sense to extend registration_confirmation submodule.
I believe that admin confirmation could be different from the one sent to the user quite often - on our site it contained info entered by the user into the form (whereas we sent further instructions to the user). So I'm going to create a separate message field for it. Perhaps there should be a checkbox (by default checked), allowing to send either a copy of the user confirmation message or a separate message?
This can become unwieldy - perhaps the long-term solution could be integration with https://www.drupal.org/project/message → and its ecosystem? Or maybe https://www.drupal.org/project/workbench_email → , given that there's support for workflow?
I need this, so I'm going to code it. Would you consider incorporating it as a submodule? I believe others might expect this feature - for example I've used https://www.drupal.org/project/social → before, where this works out-of-the-box.
Isn't this basically a duplicate of https://www.drupal.org/project/registration/issues/2312277 ✨ Provide cc option to admin for registration confirmation Closed: won't fix ?
If this is mostly supported, it would be good to document this feature. For now I can see ho I can add available spaces as a field, but the filter still seems to be not implemented. Should I create a new issue for this?
This patch to be working fine for me t LB+ 3.1.8
Should be ready for review now.
Basic working version is in the MR, I still need to fix the issue mentioned above and check if link rendering is handled correctly.
milos.kroulik → created an issue.
This is merged already, thanks @kaszarobert
The patch no longer applies to the latest commit of 1.3.x branch, so I rebased it.
Please review and create a new release, as this is a critical issue for some of us.
milos.kroulik → created an issue.
Thanks a lot for your answer. To add a bit of context - our NGO is currently considering whether we should continue to use Drupal or switch to some WP-based solution. Of course, I'd like to continue with Drupal, so I need to present a strong demo. Do you you have a roadmap, please?
milos.kroulik → created an issue.
milos.kroulik → created an issue.
milos.kroulik → made their first commit to this issue’s fork.
So, I've created a MR with the code from #2. There's at least one issue for my use case - I would like to specify Masonry options in a data-attribute, which can contain a JSON like this: https://masonry.desandro.com/#initialize-in-html
So I removed the CSS identifier validation for now - perhaps there should be a way to specify expected value of the attribute in the definition?
milos.kroulik → made their first commit to this issue’s fork.
The MR should contain the same change as https://www.drupal.org/project/inline_entity_form/issues/3033241#comment... 🐛 Cannot update the order weight using complex form widget Needs work
This needs a patch for the 3.x branch.
milos.kroulik → created an issue.
It seems to be working fine. There's an understandable gotcha - if access is disable for an element and it's rewritten in views, there's no output even if the other element accessed there is accessible.
It's also inconvenient in case we have a lot of elements in the webform but we want to make accessible only small amount of them, which means we need to manually disable access to the rest. It would be good if it was possible to make it other way around.
I would also like to test this, since I'm also experiencing https://www.drupal.org/project/webform_views/issues/3346013 🐛 Check view access for this field isn't working Active . Can you add the testing instructions, please?
So it seems there's some issue with the name of the branch 2.0.x, because it's a release branch. So I created a new branch and new MR, which seems to be working correctly. I'm going to test it tomorrow.
milos.kroulik → created an issue.
milos.kroulik → created an issue.
milos.kroulik → made their first commit to this issue’s fork.
milos.kroulik → made their first commit to this issue’s fork.
milos.kroulik → created an issue.
I'm not sure why, but this seems to have no effect for me:
- I've applied patch in this issue and also the one in https://www.drupal.org/project/layout_builder_iframe_modal/issues/3348594 🐛 Custom route to open in modal is restricted Needs review
- I've enabled opening Manage block attributes route in the /modal at admin/config/content/layout_builder_iframe_modal
- cleared the caches
- it still opens in the offcanvas sidebar
- added the route to the textarea manually to be really sure and cleared the cache again
- it still opens in the offcanvas
Did I miss anything?
milos.kroulik → created an issue.
Should I create a MR?
Unfortunately, patch from #62 does not apply on Drupal 10.3.2. I will try to investigate further shortly.
I tried to use the patch, but it results in an error on adding a new block to LB section, because I've missed instructions in "Steps to reproduce". There needs to be a better error handling for case, when there is no reusable content block of type selected in "Automatically add reusable content blocks by bundle" checkboxes.
I can confirm that MR !24 seems to solve the issue. The core issue seems to be fixed, but I wasn't able to find a solution for Drupal 10.3.x.
Perhaps we could import custom functions in _init-scss directly below @import "~bootstrap/scss/functions";? Looking at https://getbootstrap.com/docs/5.3/customize/sass/#importing I believe it should be fine. Helpres probably aren't needed, after all.
milos.kroulik → created an issue.
milos.kroulik → created an issue.
This apparently has been solved in bootstrap4_modal module here: https://www.drupal.org/project/bootstrap4_modal/issues/3457776 ✨ Update events triggers Active
FYI: There's now a module which claims to provide this feature until this is merged: https://www.drupal.org/project/conditional_rendering →
I can confirm observations made in #17. So I'm going to create a combined patch.
It looks like this can be an inspiration for cache busting in hook_library_info_alter(). But this is something we can't do in the theme...
All the change requests seem to be addressed here.
Or maybe https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Core%21Render%21... (but it looks like it can be implemented only by the module.
Perhaps https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Core%21Render%21... could be used?
milos.kroulik → created an issue.
I've created a simple patch fixing the issue for me.
milos.kroulik → created an issue.
milos.kroulik → made their first commit to this issue’s fork.
milos.kroulik → created an issue.
milos.kroulik → created an issue.
milos.kroulik → created an issue.
milos.kroulik → created an issue.
milos.kroulik → created an issue.
The very basic version in MR works, but it's entirely non-configurable and dependent on assumptions. Further work is needed.
milos.kroulik → made their first commit to this issue’s fork.
Explain default prop value in more detail.
There's at least one more use case where component CSS and JS files aren't imported - when the component is included (or embeded) in views fields that support twig. Perhaps it would be good to mention, but it's the SDC issue, not something specific to radix.
I think that the missing piece is how to add a component into an HTML textarea using the WYSIWYG.
This could be addressed by https://www.drupal.org/project/embedded_content_sdc → , unfortunately, the development is not very active lately.
page-navigation component is fixed, others should be checked and modified as needed.
milos.kroulik → created an issue.
Unfortunately, the patch from #27 doesn't seem to be working for me, as the "sub-widget" still doesn't allow SVG.
Based on the patch in #6 it looks like this is actually a duplicate of https://www.drupal.org/project/menu_link_attributes/issues/3331630 🐛 Compatibility with other modules, options being overwritten. Fixed , which is already RTBC. Can we close this one?
milos.kroulik → made their first commit to this issue’s fork.
The basic form of MR is submitted, it works for my use case.
milos.kroulik → created an issue.
milos.kroulik → created an issue.
Thanks a lot. Just today I learned that there are cases when no container should be set (https://getbootstrap.com/docs/5.3/layout/gutters/#no-gutters).
milos.kroulik → created an issue.
Can you provide up-to-date instructions, how to make things work with Drupal 10, please? After applying the latest patch I went through docs at https://www.drupal.org/docs/contributed-modules/image-replace/integratio... → , but when I upload a new image using the media library, there's no way to select alternative images during the second step, like I can see at https://www.drupal.org/project/image_replace/issues/3048691#comment-1390... ✨ Support core media module Fixed
I will try to reproduce the issue on a completely new installation when I have a bit of time.
milos.kroulik → created an issue.
milos.kroulik → made their first commit to this issue’s fork.
milos.kroulik → created an issue.
milos.kroulik → created an issue.
Rate your excitement about SDC in core: 1 ... 10 | N/A
10
Rate your excitement about potential contrib extending SDC: 1 ... 10 | N/A
10
I'm thinking of
https://www.drupal.org/project/ui_patterns →
2.x here
Rate our documentation: 1 ... 10 | N/A
N/A Didn't read enough, yet.
Did you 1️⃣ refactor existing template into a component, or did you 2️⃣ write a component from scratch? 1 | 2
2
I chose a theme (Radix 6.x) because of that
Rate the helpfulness of error messages encountered: 1 ... 10 | N/A
6
I have a limited experience here - the error message helped me fix the issue quickly, but then it turned out that there's probably a better way to do that fix.
Have you tried the Storybook integration? Yes | No
No
It still looks like a non-straightforward procedure for the time being.
Any thoughts you would like to share? The sky is the limit
Thanks you. I really hope that SDCs can help us find front-end developers willing to work with Drupal even in non-decoupled manner.
It looks like it doesn't work without specifying event name for SectionBuildRenderArrayEvent (at least in Drupal 10.2), such as
const SECTION_BUILD_RENDER_ARRAY = 'section.build.render_array';
I will update the MR shortly based on this.
The CSS approach for the MR is not the way moving forward
Sorry, is there any developer documentation I can study to do better next time?
having !important for anything should be a last resort
I know, I used it purely because Bootstrap uses it for text-muted class and I don't know how to handle it differently.
I tried to fix the found issue. I will re-activate issue, if I will find something else.
I've created a MR with the fix described above, the only difference is that label_display is set to expected value visible.
The issue seems to be no longer present with the new subtheme generated from the latest commit.
It looks like you're right. The issue seems to be no longer present with the new subtheme generated from the latest commit. Thanks a lot.
milos.kroulik → created an issue.
milos.kroulik → created an issue.
milos.kroulik → created an issue.
milos.kroulik → created an issue.