Currently running with a simple setup for PostCSS. We can add more complexity as use cases arise.
Tested and working for D11. Fixed.
jnettik → made their first commit to this issue’s fork.
Tested D11 fixes. Merged.
This works as expected. Will be rolling out a new release soon.
jnettik → made their first commit to this issue’s fork.
Added missing files. Opened MR for review.
Committed. Thank you!
Committed. Marked as fixed.
Ready for review.
Addressed issues outlined earlier and merged. Thank you for the MR!
Added. Marking as closed.
@ananya.k Thanks for the MR! Couple small things need addressed before this can be merged. See above MR comments.
MR ready for review.
I updated this patch so it works against latest dev. Issue is the .info.yml file was trying to modify the packaged version.
The loadPaths idea is a really good one. Pushed that change to the MR.
MR submitted for review.
Also potentially related to the issue in ✨ Component: Teaser Card Needs work
Submitted MR with notes for improvements in the comments.
My two cents after looking at the alpha4 teaser component... I will have to significantly rebuild this on every project I use it on or just avoid it entirely. It's so cover engineered and I don't know what I'd need most of it for. IMO most teasers can be one component if all we're doing is restyling a title, image, optional body, and link. I don't know why it's passing in categories and category colors (set to a random list of pre-defined options?) and tags and dates and times... We don't need this to try and predict every single possible option we may or may not need. Keep it simple and let people build on top of that. As is, this is going to cost time on projects rather than save it.
I just opted to remove those items. If people need libraries for typekit or google fonts, they can create them as needed. I don't think we need that prebuilt.
Opened a MR for this that solves the issue at the block plugin level. It uses a Drupal helper method to check if things are empty. The issue with views specifically is that it returns cache data in the render array and so EEF by default will show that as having content.
Ready for review
I can also confirm the patches here fix the issue. It also doesn't feel trivial to me as well.
I can confirm this patch fixes Entity Browser selections when configured as modals.
MR ready for review.
Setting for review. I almost think this could/should be the pattern followed for all blocks on the site and not just menu blocks so this code could be more generalized too.
Merged. Thank you!
Ready for review in MR
This appears to have been fixed on latest dev. However this is an issue there where you can't delete types without getting an error saying there's existing data. This is because the query is getting executed but the return value isn't being used.
Closing. Released in the 2.0 beta release
Closing. Released in the 2.0 beta release
Closing. Released in the 2.0 beta release
This has been merged. Thank you.
Marking this as a duplicate of #3286793. I've resolved that other issue and assigned credit there.
This looks good. Merged. Thank you!
The patch looks good. Committed. Thanks all!
Closing. Added in latest release 1.0.0-beta3
This looks good and was merged. Thanks!
Looks like this issue got merged a while back. This is in the 4x branch. Closing this issue as fixed. See: https://git.drupalcode.org/issue/prototype-3210541/-/commit/95d16779242d...