nod_ → created an issue.
Since there are upgrade path concerns, tagging for RM review
+1 for this, validated that in #3404409-99: [Plan] Gradually replace Drupal's AJAX system with HTMX →
Crediting htmx maintainer for resolving the security policy issue
doesn't cherry pick to 10.5.x, need a MR for that one
Code is good to go for me, we can RTBC once the security issue is managed. To be more accurate the status should be postponed since we're waiting on external third party for a reply :)
I'm happy with that
few comments on the MR
Variants are not the only concepts, we also have styles and themes/modes. Next step is ✨ Add a style utility API Active and XB will need something like https://www.drupal.org/project/ui_skins → sooner than expected too.
So you're right that variant are not the only dimension, it's just that the other dimensions are not at the component level, they're a higher level concern.
@joseph.olstad: I asked for a simplification and you posted an even longer text, this is not really helping me understand your point. I'll assume the simplification are the last 4 bullet point and I won't engage with the rest of the comment.
So you think the current strategy is good and it's "just" missing the last 4 points you outlined or should the strategy only be the last 4 points you mentioned? Help me make sense of what you mean. If it takes even longer to explain, take a step back and simplify please, otherwise I'm afraid I'll have to ignore it. I'm looking for something like "I agree with the strategy but it's lacking X,Y,Z" or "I do not agree with the strategy because X,Y,Z".
The PDF document represents days (possibly weeks) of meetings, I'd appreciate if you had the curtesy of applying this same spirit of concision to your feedback.
@jonathanshaw: Thanks for the feedback. It's true that AI was not really a topic we discussed in depth in the various meetings. As we can see with the vibrant activity around AI, Core does not seem to impede progress on the topic?
I agree with you that the points raised are not really about the strategy. It seems to me like you don't find the strategy bad, but that there is not enough mentions of AI in there ?
Points 1 and 2 of the core section in your comment would definitely help humans too, for 1. we do have a plan it will be made more explicit later this year as there are other things to adress before that. for 3 core could do that, but it can be started way, way (way) faster in contrib and as far as I understand speed is important in that industry :) Core is neither enabling nor preventing progress. If it is, point me to issues and I'll have a look. For 4, personally I'm keeping my head in the sand for a while longer, I'll let others tackle that for now :)
On a more semantic note, I find that talking about war on the topic of CMS priorities a bit misplaced given what's happening in the world. I understand the feeling but yeah, I don't feel great about the term used.
@all: To frame the discussion as I said in #7, for now the focus is on the overall strategy. First do you agree with the goal? it might not look like it but it's a pretty big change to become a CMS builder (and not "just" a site builder). Did we miss anything in the "where will drupal core play" section? any worries about the realignment of Drupal Core with regard to Drupal CMS, with the CMS market, or even with the broader open-source and commercial world. Does the "how will we win" section make use of all the strengths of Drupal in general, are we missing something to achieve the goal? Thanks!
Did you mean to comment on a different issue? This is not the place for Drupal CMS feedback.
I didn't quiet get why we're talking about tinymce in this context, could you simplify your point? I can't tell if there is a relation to the core strategy or not.
We're still eager to hear from folks about the new strategy document. Maybe some things are clearer after DrupalCon Atlanta, Dev Days, and maybe there are new things to worry about!
Let us know :)
Looks good to me but outside my scope
reverted for now, thanks for finding the issue!
can't apply as a patch or rebase the MR from the UI, need some manual rebase/merge
There is a merge conflict
Instead of a test I'd be happy with a comment. The suggestion I made in the MR is not good enough but it's a start.
Welcome onboard!
Committed and pushed 119097957c2 to 11.x and 299c60c7f65 to 10.5.x and 18f2872e543 to 11.1.x and 3b341184245 to 10.4.x. Thanks!
The value of htmx for us is in the dom api, not really the implementation or js api. So the magic of other libs will not help us much. We're sticking to lower level stuff in core to make sure we don't artificially limit what you can do. Also less magic translate usually to less code to maintain and happier update paths.
Dom attributes have good DX (from mavo.io that share a similar philosophy) I tried to use that for Drupal a few years back but it's not a good match, it's a CRUD layer, htmx is "just" the http layer with a similar DX and that is very useful for us since the crud part is very much handled in our case
Our ajax api is not intuitive. I have no clue how declare an ajax enabled form element without looking at the docs... HTMX is better than what we have in that regard.
Thanks so much for updating the credits, I was worried about it :)
Spent time reviewing this and I'm going to need a few things:
- Steps to reproduce. I could not replicate the problem on the 11.x branch adding 2 exposed filter on the same page with the same ID, both worked with and without the patch. Not sure how to replicate the problem.
- From what I understood, the test is checking if we can use form 1 and have some results, and check if form 2 gives the same result, I would expect the results to be different, otherwise how can we be sure that form2 worked?
- We should avoid changing
Drupal.views.ajaxView.prototype.attachExposedFormAjaxbecause of bunch of themes overwrite it, let's not make it hard on contrib since it seems doable without changing it
Committed 9bde009 and pushed to 11.x. Thanks!
There are still tabs in the twig file instead of spaces
These issues are going to be obsolete with XB and/or display builder, and in the case of the responsive layout builder it seems that the feature isn't necessesary given the lack of contrib solution for that
#3067700: Bring block class module to core →
#2875935: Add Components Module to Drupal Core →
✨
Add field grouping to core
Needs work
🌱
[META] Add editable responsive layouts to Drupal core
Postponed
#1822950: Add responsive layout builder to core →
#1813910: Add region module to Drupal core (for editable responsive layouts) →
With all the CSS improvements over the years, this is probably unnecessary these days
updating links
we're trying to remove preprocesses so let's find another way, title and icon callback somehow, like how breadcrumbs are manage maybe?
by now hyphenate-limit-chars is now supported on firefox, still not safari.
we could add a rule for german specifically to address the issue without impacting other languages
Thanks for taking additional responsibilities :)
updated permissions
welcome to the team :)
Committed and pushed ab74acc51db to 11.x and 28c4197d572 to 11.1.x and 89375226b40 to 10.5.x and ae2f7f07d26 to 10.4.x. Thanks!
Hello @dan paul your comment looks like an AI prompt, please check the rules for using AI while you contribute to Drupal → .
It should be disclosed that AI is being used and the content reviewed. For example, there is no search feature in the dropbutton. The patch you uploaded is the same, or at least looks identical to the code snippet in the Issue summary. We're not using patches anymore, just Merge requests.
I would prefer not changing the user input since that wouldn't solve the use case of a bad translation. Good news is that the tests shouldn't need to be changed, we only need to change how it's solved :)
A problem in the translation can create issues like 🐛 CKEditor 5 toolbar configuration not show buttons in spanish installation Active .
Also the issue summary and the solution are not the same.
Committed 286ab21 and pushed to 11.x. Thanks!
We're trying to move away from template suggestions so not sure it makes sense to add more for everyone to use, I mean the issue is more than 10 years old no sure it's worth adding something we're trying to move away from.
I'm still seeing 'blacklist' in navigationblock, The change record should present the new option name for the autocomplete as well.
Committed and pushed 0fbf14f118c to 11.x and 02db80612a9 to 10.5.x and 6abbb8516ca to 11.1.x and 709e987ee9f to 10.4.x. Thanks!
The css is not added to pages with a table, something doesn't work here. I checked /admin/content with olivero as admin theme.
The file needs to have the deprecation dance: see https://www.drupal.org/about/core/policies/core-change-policies/how-to-d... → for an example you can check 📌 Move resize CSS into its own library Active
Committed 80adfea and pushed to 11.x. Thanks!
Committed and pushed 9256fc107f3 to 10.5.x and 9f025d2e68c to 10.4.x. Thanks!
That should be in 10.5.x and 10.4.x actually, the cherry pick is not clean so needs dedicated MR
Committed and pushed 96c70753fe5 to 11.x and a9c54fca064 to 11.1.x. Thanks!
Committed 19a37c3 and pushed to 11.x. Thanks!
Committed and pushed 14d9ea360df to 11.x and 78e726c8342 to 11.1.x and 21b84efee99 to 10.5.x. Thanks!
I'll put that at least to NW, it's possibly a won't fix situation depending on how much exists out there that could help with the situation.
So the fix here is to add a space between all tags, this breaks pretty fast, for example:
<strong>test</strong><sup>nospace!</sup>
Here we would not expect a space to be added. Whitespace in HTML is very complex, see https://blog.dwac.dev/posts/html-whitespace/ so hand crafting rules by hand is not a reasonable solution. We could parse the string as HTML and use textContent property from DOMNode and hope it does things correctly with html5.
hiding patch files
some problems in the D10 git checkout locally, not sure why the tag is not fetched by the bot, maybe an unfortunate timing + caching on the d.o endpoint
umm, sorry about that not sure what's wrong with the bot
Can you make a MR? Add your name to the Theme API, Single-Directory Components along with pdureau and e0ipso and I'll be happy to +1
You can probably add XB to the list too :)
We're talking about adding something optional for which the only existing/current need is accordion/accordion_item. From there we assume things will get more complicated and try to come up with a solution, that doesn't sound like a plan that will address our users needs. In that situation where the needs are not clearly defined, contrib will implement it, battle test/refine the requirements and we get it in core once we know more about how it's used.
On the technical side of things It's totally possible for XB to add an extra yml file to SDCs that it will use (and maybe other modules can end up using the file too), core is not blocking anything except for this annoying restriction with finding SDC yaml files: 📌 Make DirectoryWithMetadataDiscovery generic and reusable Active . As wim said in that very same issue: "In Drupal core, we generally only introduce an abstraction once there's >=3 uses for it." From what we talked about here, we're not there yet.
To me this issue should be postponed on XB implementing this, finding what works and what doesn't and we get the parts that are actually needed and helpful then.
SDC provides just that :)
Agreed