I meant in the sense of content meant to be consumed by AIs, not content being generated by AIs. I feel that publishing AI generated content in that category would kind of defeat the purpose of the whole thing.
When I first read the blog post I thought "case studies for code".
How about we add a new type of case study instead of a new type of project ? The goal is knowledge transfert, leading by example right ?
You don't expect a working solution from a case study, you get to see what's possible, what people do, and how. If they want to seriously
I have some questions, like the expected effort it should take to publish something, what's the minimum useful thing we can have ? Is dumping undocumented code without a summary or explanation of the dependencies/context of what it does useful ? What's the sweet spot of complexity we target between a gist and a distribution/install profile/recipe ? Is it mainly a dumping ground for AI to consume Drupal code or for humans to look through ?
If it's ai dumping ground case studies might not make sense, if it's human centered that would be more suitable, we already have some infrastructure for case studies so that might be easier to make happen too
For the future there is some discussion at the http level of adding a new verb: QUERY, essentially a GET with a body: https://httpwg.org/http-extensions/draft-ietf-httpbis-safe-method-w-body... not an immediate fix but could be useful in a few years.
I think it's a reference to the browser cache, not drupal's right?
adding a related issue
Agreeing with #5, a css-only patch caused the bug, a css-only patch should fix it to make sure we don't create a regression for contrib
Committed and pushed 42d82bf6192 to 11.x and 4167c87cde7 to 11.3.x. Thanks!
The point left seems to be about behaviors not working nice with a boost page navigation.
We have many behaviors that do not detach cleanly, this might be one of the reasons why it's not working very well.
After quite a bit of back and forth in the related issue, boost with a special attribute it is.
changed my mind, keeping the full page by defaut on all requests, to use the special drupal output you need to opt-in, hopefully that will prevent folks from being tripped up by this and we can just use that in core when we need it.
For default I went with only main response when using ->get/post/patch/etc. and the full page when using ->boost() not sure it's a great idea to have different default but that seemed reasonable.
Once again should have listened to @fathershawn earlier 😂 in #31.
Reversing the attribute default. This should behave more as expected.
Could you try 📌 Improve url management of the Htmx object Needs work , this should resolve the ajax_page_state ending up in the browser history.
We need to wrap the library to some extend because of a few things:
- Some scripts are not safe to load twice, the whole library system depends on Drupal loading a dependency only once. In some case that might be fine but with the default behavior it should not be possible to load a library twice on the page, hence we needed
ajax_page_state[libraries] - When requesting a page to figure out what is needed to display the content we need the theme, so we need
ajax_page_state[theme]andajax_page_state[theme_token] -
There are also other things that need opt-out, for example attaching behaviors. There might be situations where a developer needs to apply very specific attachment of behaviors.
So this is the kind of expectations we need to define, and I'm very glad to see other people using this so we can discuss :)
This is the slippery slope that granted us all the features of the Ajax framework, very powerful but complex and underused. I wouldn't want to add a way to have "Drupal-wrapped" htmx and "regular" htmx. I think we can make it so our htmx implementation does not break the expectations of regular htmx in most cases.
Makes sense, htmx does have an exception for the body when using outerHTML, we could do that too. I'm not super happy with how we figure out what is the element passed to attachbehaviors but I don't have better to propose.
And the tests caught it so we do have some test for this somehow :)
CSS changed a bunch after 🐛 Front-end theme styles can bleed into Navigation Active needs updating
Works for me. Conceptually makes sense that everything us pushed by the sidebar
unfortunately the workspace top bar overlaps with the navigation sidebar, inner menus are fine, we did the same as earlier in this issue 😂
Committed and pushed 806d39ed793 to 11.x and 716c43f73d0 to 11.3.x. Thanks!
Ok, that was me who didn't empty my cache… sorry about the noise.
We're compliant with the spec, not the practice of attribution in git trailers.
We can open an issue to adopt the attribution practice and go over the email topic, gitlab quality of life features around this more in depth. It'll be an opportunity to list the various attribution options, see how far we're willing to go, what should be the project maintainers responsibility vs. DA automation. and we definitely need to know what it does when our commit messagers are published on github.
Committed and pushed ae8ac5ed60c to 11.x and 82a36af1315 to 11.3.x. Thanks!
This is now deployed and there is nothing more to discuss in the scope for this issue. For all the name/email, co-authored-by discussion we already have open issues.
This issue was meant to unblock/sidestep hard problems around the commit body so we can move core to the new format sooner rather than later. Core has now switched to the new format, this issue is fixed.
An unforseen side effect of using @xxx syntax in the commit log is that the mirror on github also parse the usernames and link/notify users. The gitlab and github users do not match so we've been sending notifications to random people on github for a few days. For example, gitlab @catch here is not github @catch.
We can't @ people since we publish on different systems. The concern about different git hosting was raised earlier here, but not as the immediate issue it is today and I missed it.
Thanks to this things are really clear about what we can do: no @, no email, same username as on d.o. We're going with the same information we always had in commits, with a different format.
did you disable css/js aggregation or clear the cache? it's on by default with umami
The no/js version used to interfere with the navigation on the website but it seems ok now, priority normal is fair.
I suggested the @ to keep some level of gitlab integration when not using the name + email pattern.
If it gets more in the way than a "simple" By: d.o_username let's just go with that and not have any special integration with gitlab on the commit message viewing (I'm sure we could find a way to make a gitlab plugin to do it if that's really important)
- Wrapping styles in the extra specificity selector to force the style to be applied: OK
- extra-specificity-hack/extra-specificity-trick: extra-specificity-hack. We have a long history of CSS using "hack" to find workaround for browser support
I hear the concerns, so what should we do? name + email is a no-go per previous discussions.
What would be useful: d.o usernames without @, actual d.o URL to the user, a link to the credit record?
Problem with stying, the rules order changed and messed up the table headers style.
Committed and pushed d5dcae6c048 to 11.x and b187cc5e743 to 11.3.x. Thanks!
There was a new version like an hour ago, but let's get using this plugin for now it's up to date enough for our purpose.
Committed and pushed 703e5d41895 to 11.x and 256c05ea65a to 11.3.x. Thanks!
Committed and pushed e19de46381d to 11.x and aeae5fd1c0e to 11.3.x. Thanks!
I think task is valid, fix carry the meaning that something is broken. Some follow-ups are not fixes, features, or chores. Like adding additional tests for a feature would qualify as a task for me
Got an assist from @latent with the code: https://gist.github.com/MichaelWest22/7ca5b715b368ec1289352d4eeb310182
This moves the code to an htmx extension, and we might be able to use an extension to declare new swap styles to manage modals and messages.
worked out the problems to get things working with that new branch. This is now behaving like our current ajax framework. Assets needs to be loaded before DOM replacement happens.
Committed and pushed 2592e8ba422 to 11.x and ea0226fd568 to 11.3.x. Thanks!
Committed and pushed f7e7f3efe42 to 11.x and c4340b27c61 to 11.3.x. Thanks!
haha yeah views is a good way to know if we broke the JS usually.
We already take over jquery ui _focusTabbable to make it use focusable library: https://git.drupalcode.org/project/drupal/-/blob/11.x/core/misc/dialog/d... how is this MR different?
Let's go with that then. We're reformating the informations we already have.
And we can discuss the trailer format once we use the gitlab ui to do the commits.
nod_ → changed the visibility of the branch 3543076-simplify-agreed-commit to hidden.
Correct, and the discussion did not take into account that the goal of Co-authored-by is to either compensate for a lack of proper crediting tools or when commits logs are the whole crediting tool, and neither applies to us.
also where did the brackets come from around the nid? that's something you'd use for jira-style ticket names since there are no defined delimiter, which is not our case.
Removing the brackets, not using co-authored-by because we have a proper credit system in place for that kind of informations and not to confuse tools that might rely on an email being present, we're left with:
feat: #123 something something
By: @nod_
By: @dww
By: @cmlara
We're all happy with that?
Concerned were raised in ✨ Simplify agreed commit format Active about the fact that we're not following conventional commits spec and is proposing to move the issue ID after the commit type information.
nice example in #61, thanks.
To avoid going in circles I'd like to point out that Co-authored-by is not a conventional commit spec/requirement. It's a practice started by github/gitlab to compensate the lack of attribution tools in their system (we tried to help them get better tools, it didn't work out). On our end we have very powerful attribution tooling so the technicalities of how Co-authored-by works are not a concern for us, since this is not how we give attribution, or even show how someone contributes to the community, that happens on the d.o user page, not the gitlab interface. To me the commit message is to help when I do a git blame, not much more.
If there are scripts that expect Co-authored-by to have an email, then we don't use that and use "By" as we've been using for 2 decades.
We used to have
Issue #123 by nod_, dww, cmlara: something something
, and very quickly we could have:
feat: #123 something something
By: @nod_
By: @dww
By: @cmlara
Same exact user information just presented differently. Can we get that resolved and move on?
My main objective with htmx and forms is to make sure htmx and regular requests follow the same code path, unlike what's happening with Ajax today. I'm thinking most uses of htmx will be in the context of a form (for now at least) where it makes sense to add the wrapping format by default. Even if we query an htmx route, adding the wrapper format parameter shouldn't be a problem.
All that to say I think we should keep the default as adding the wrapper format.
+1 to the simplification but it seems like we're loosing some informations as to why it's not necessary when using ckeditor. Can we get more of the comment ported to media in addition to the logic?
for the tooling litteraly any tool saying they support conventional commits would work. We talked about using well formatted commits to generate changelogs and such. I would expect some tests with anything in here https://www.conventionalcommits.org/en/about/ and maybe more specifically tools that claim to help generate changelogs like this one: https://github.com/marcocesarato/php-conventional-changelog
might not be used in core but could be used in contrib.
Change record should explain a bit where that is used (not used in core yet) administrative uis of drupal canvas and display builder for examples.
Also SDC do not stand for 'Structured Data Component (SDC)', so some work to the change record wouldn't be bad
reverted original issue. I'll let you decide if we keep this one open to fix the underlying issue of alignment here or in the original issue
I'm going to need people to actually try some tools and report back here with the results before we talk about re-decide anything regarding that first line commit text.
I found unexpected behaviors testing the usernames in #46 so let's not assume what would or wouldn't work with existing tooling. I'd try all the variations (for the first line) of 🌱 [policy] Decide on format of commit message Active and see what actually comes out.
Main reason was to get the contributors out of the first line, so any variation would achieve this. Now if the rest of contrib moves to this format, let's make sure the tooling they'd be likely to use gives something useful
Thanks for finding the history on this one
Committed cff1082 and pushed to 11.x. Thanks!
We need a 11.2.x version of the MR since it doesn't cherry pick cleanly
I don't think this warrant a change record, i won't publish it.
Committed 4f4ff21 and pushed to 11.x. Thanks!
small conflict to resolve in core/profiles/demo_umami/tests/src/FunctionalJavascript/AssetAggregationAcrossPagesTest.php
Committed and pushed adddba60e2b to 11.x and d5fe4c8715d to 11.2.x. Thanks!
MR looks good, a bit worried about adding more drupal specific logic to the attributes object, and more drupalism to SDC but that's a tradeoff that looks worth it
seems like the last commit undid a bunch of things on the MR (including the fix to make sure we don't have "- Select -" in the push url).
reapplied the fixes and used the new method to get the trigger name.
Hey a HTMX issue I can commit, yay!
Committed 5edaa75 and pushed to 11.x. Thanks!
Committed and pushed 09656a796c7 to 11.x and e0f3aad5bab to 11.2.x and 3c7cc933c02 to 10.5.x and 4f88d508615 to 10.6.x. Thanks!
Tried it out and that is the appropriate fix. Even if it's not in a noscript element it just makes sense to check if the element exists before trying to run things off it.
About #34 and #39, adding a @ in front of the user name would link to the user in the gitlab UI: https://git.drupalcode.org/project/drupal/-/commit/6ba27a8298b3bdf05bab4...
[#122312] feat: something something
By: @nod_
Would transform to a link to my user when reading the commit message, just like in MR comments. I tested the standard format and pictures are broken for some reasons as you can see here, and what gitlab links to is a mailto link, not even the user profile: https://git.drupalcode.org/issue/drupal-3548100/-/commit/4ef708e0473351b...
So either we keep it as bare username or prefix them with @. The actual standard format doesn't look very helpful for us.