There's been some talk this year about asset-packagist reliability:
See:
https://www.sitback.com.au/insights/article/working-with-javascript-in-d...
& https://github.com/darvanen/drupal-js/tree/main
While I'm not really loving the proposed way that works, it may be worth chasing the rabbit and seeing if there is any more consensus on external JS inclusion methods?!?
Agreed, would it also be sensible to have the links for version 11 as:
https://unpkg.com/swiper@latest/swiper-bundle.min.css
Or does it need to be fixed to a specific known working version?
If I remember right, the unpkg links didn't work with version 11 (no idea why) so I grabbed links from the official Swiper docs for the CDN. My ultimate goal was to just get the version working as it was being really buggy with the incorrect version.
So yeah, I selfishly didn't consider those with it already setup, but considering it was really buggy, they would have needed to change the local file in their library anyway as the module doesn't do that part.
PNG version uploaded :)
dreamleaf → created an issue.
Hi leslieg.. svg version without module name uploaded.
Ooops sorry, accidentally made the changes in the 1.0 branch, replicated in correct issue branch.
dreamleaf → created an issue.
dreamleaf → created an issue.
@ahsannazir I notice you went for a smaller padding increment of padding-block-start: var(--admin-toolbar-space-8); - to my eye this still looks uneven between the top and bottom of UL. It's very minor, and probably needs a space of 10, but the variables increment in 4's, so neither is 100% correct.
As my original issue, I would still recommend using the 12 padding size.
@Meeni_Dhobale Apologies, I'll add this to the issue, but I spotted this in the experimental version on a 10.3.1 install.
I assumed that due to the requirement to work on issues on the highest version, it would have been backported if fixed.
dreamleaf → created an issue.
Changes made in:
core/modules/link/src/Plugin/Field/FieldType/LinkItem.php
core/modules/link/src/Plugin/Field/FieldWidget/LinkWidget.php
core/modules/link/tests/src/Functional/LinkFieldUITest.php
Setting to Needs Review
There is also another http:// reference in web/core/modules/link/src/Plugin/Field/FieldType/LinkItem.php - this is non-exposed to the user though, but should be worth a consideration.
There are a lot of uses of http:// in the tests as well, but as there is no strict requirement on using https this is not a problem.
Apologies - I appear to have committed to the main repository instead of a new branch!
dreamleaf → created an issue.
I can also confirm the combined patch in #16 is working, this is a really great module and one of my only blockers to updating some sites to D10.
Any chance of getting a working release out with the patch rolled in please? If there are sub issues (such as the IE polyfill stuff) can these get put as active issues so people can help out and get this module fully kick ass.
Thanks for the feedback, please let me know if any revisions/edits needed/desired and I'll hop on it.
how would they be done so they can be re-used in different contexts? i.e. the media browser card shouldn't be media-specific, or possibly not even entity-specific?
What would be really nice is a system that used pseudo-variables (or placeholders) within a SDC component. I don't even know if something like this is easily achievable with Twig but maybe the fields/variables are declared either within the json config or directly in the twig file (like we set attributes). Then when it's overridden, those declarations could easily be swapped out - and if the content was noticeably different from the original style - that is then amended within the component.
The only other way it makes sense in my head would be to expose the component as a view mode, which would still require some form of pseudo variables that can be hot-swapped within the fields UI.
Or along a similar line, also pull field_group into core, and have components exposed in there ..... obviously this is probably not going to happen and would be a contrib project, but it would be cool.
Two more variations, with a bit of zing.
Couple of similar ideas to get the ball rolling on this one.
V1 - basically based on a mind-map, which is how my brain thinks of component structures (leads leads to this, extends this, links to this).
V2 - bit more abstract, but could be seen as "beaming" or sending a signal.
Both featuring the @ symbol which is the method of declaring the twig namespace.
I see the logic and thinking behind this, but is this not effectively making Drupal harder to work with?
The ability to subtheme means that a person doesn't need to understand everything a base theme is doing, to sometimes just make trivial styling changes. I get that Olivero is intended to be a showcase of what is possible and that's great, but it's also a bit misleading if that is the face of Drupal and people can't easily customise it without knowing the nuts and bolts.
Starterkit goes some way to providing an abstracted version of a theme, but it still doesn't solve the barrier to entry issue - which subtheming provides.
Agency and enterprise will likely be creating themes from scratch, and have no need for subtheming - unless they are avoiding reinventing the wheel (ie using bootstrap or another framework base theme).
The introduction of Single Directory Components ✨ Add Single Directory Components as a new experimental module Fixed (if this gets approved) could also go some way to providing a respectable answer to disallowing subtheming while still allowing overriding of components. So, assuming that goes ahead, maybe there should be a suggestion that if a theme is disallowing subtheming, it still provides a method for customisation.
+1 for trying to get this in as an experimental module.
Standardisation
As with every aspect of Drupal, there are many ways to achieve an end result, but that doesn't mean there shouldn't be strong, opinionated examples within Core of how to make the system more cohesive and standardised. We already have coding standards, and I see SDC much like "use 2 spaces instead of a tab" - there is a reason to do it that benefits the whole ecosystem.
The concept of components is already heavily ingrained in Drupal, we have a block system that allows us to create custom blocks that are used sitewide, Paragraphs is used on over 200k sites (that are reporting... so many more) and there are countless other examples in use and in previous versions (Panels etc) that have sought to offer an organised approach to the component framework.
What we don't currently have is a recommended and approved core concept of expressing this at the theme level, and this is the important part for me. If SDC or something like became "core", it solves the challenge of everyone having to devise their own way of implementing structure - although, they would still be free to do so if they wanted without breaking anything. So it's a win on all sides, with the only downside being that someone else may see a different approach as preferable and therefore think "their way" should be in core.
Adoption
As mentioned in other comments, education is key to adoption. Drupal is very good at providing developer docs, but not so great at the bringing people into the ecosystem/reasons why they should. I don't mean pandering to poach from other systems, but providing a simple, clear walkthrough of how and why we do certain things so people can make an informed decision and know what to expect before jumping in.
We have to consider as well, that Drupal's long term future is dependent upon getting new blood as well as rewarding time-served contributors. There is nothing abnormal about the SDC approach in the wider landscape, a lot of the people who would use it will already expect there to be some kind of "Drupal Way", so if provided it just needs to be clearly delivered as part of the package.
Why now?
Introducing SDC would also tie in with other initiatives that are in the pipeline. The first one that springs to mind is the
Recipes →
initiative. Having a standardised approach to that, which can then be easily altered/customised is essential to make that work. When I first heard about the recipes stuff, I had this initial thought that it would become dependency hell - relying on a specific theme or other functionality - SDC inclusion here would eliminate that doubt AND increase adoption levels of both SDC & Recipes.
You could apply the same thinking to any contributed module that makes itself easier to work with. Which leads me to my final thought:
Wider Ecosystem
This issue mentions CLServer and CL Block as examples of further expansion within the ecosystem - and while not specifically relevant to this issue I thought I'd throw in a couple of thoughts.
1) I love the concept of Storybook - and CL Servers integration is cool. But, I'm not inclined to want to introduce another tech stack to my Drupal work without substantial benefits. I can see how external integration can be an easier transition for larger agencies, but one of the reasons people love Drupal is because they aren't chasing the "newest love child framework". SDC doesn't have this mentality per se, but the education and adoption could be affected if people believe this is a subtle way to move towards those "proper" (included sarcastically) frontend frameworks.
2) CL Block - Early days I know - but a casual glance at that gives me a little niggle. Using the UI to input twig code just feels wrong :) Maybe a better thought could be along the Patterns approach where you could create a suite of default components (not tied to specific fields) and then use that as a formatter for whatever is created. As I write this, I realise that I just explained "view modes" - so yeah, a view mode that picks up on a specific SDC default.
My belief has always been that if you have to bring code into the front end, either the backend isn't working or you're providing a tool that is only usable by the few.