+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.
started to go another way in 📌 Ajaxify the user interface translation forms Active
Instead of handling that in the backend, the query string is added from the front and we have an extra drupal-specific attribute that controls it
I think I found the sweet spot for using/cleaning the extra parameters in 📌 Ajaxify the user interface translation forms Active . If wrapper format is not a problem we still have to manage ajax_page_state.
Also if we avoid dedicated endpoints for views, we should be able to simplify the backend too.
I agree that using _format is a bit of a stretch so I don't mind a dedicated key.
I'm leaning towards using boost with a drupal-specific attribute to control the wrapper format, ajax page state and push url.
Seems like it! the boost attribute does more than I need though,
Checked it out more closely, we kind of have nested attachBehaviors call, that isn't idea.
Instead of that we can just try to call the function "safely". So doing
$(document).on('drupalContextualLinkAdded', (event, data) => {
Drupal.ajax?.bindAjaxLinks(data.$el[0]);
});
and keeping the backend code that conditionaly load core/drupal.ajax should be enough
Oh nice, and the perf test looks great with 27k of JS removed :D
Tests are green, since we never used fetch directly in core before the test framework didn't know how to wait on it.
We should be able to find a way to make the ajax contextual link not a dependency. Does anyone has a example of this being of use? was it for quickedit back in the day maybe?
This MR builds on 📌 Improve url management of the Htmx object Needs work , 📌 [PP-1] Refactor ConfigSingleExportForm to use HTMX Postponed , 📌 Ajaxify the user interface translation forms Active , which is why the diff is important.
To test, toggle the "use ajax" setting on the view you want (I only tested the /admin/content table and exposed filter at this point).
Instead of a custom _htmx_route, maybe we can use _format: drupal_htmx or _format:htmx in the route definition.
See how lupus_renderer handles that, creating a new _format:custom_elements for api responses.
The new tests are still passing and it makes sense based on upstream code,
updated the version in the change record, it'll be 11.3
Committed c8dae79 and pushed to 11.x. Thanks!
I don't think that warrant a change record, it will just work™ now
Committed 103108a and pushed to 11.x. Thanks!
should be good to go, maybe comments needs some work? not good at that.
Played with the patch a bit, the attribute stuff I'm doing with htmx doesn't break. And things seems in order in the admin UI. I asked @grimreaper to test it with ui_patterns/display_builder since they might do more complex things with twig than core. Maybe we need to test twig_tweak too?
got the pagination working but it's not limited to this form, I don't know what else it might break
Got it sort of working but there are problems:
- Pager links are very broken, they get all the form stuff added to the query string and since we exclude the libraries trying to navigate to them is just not working.
- The session values never gets updated so default filtering stays at what it was. When the page is refreshed we don't get the last filtered thing.
We should be able to deal with it here, need to try a few things where we might have to refactor the backend a bit
Now that we have htmx in core it could be a bit easier to manage that. We don't use htmx for exposed forms but that should be something to look into
Sorry late to the follow-up. Since we have different rules between 10.x and 11.x I'd rather avoid the inconsistency and not backport this.
Thanks for the dedicated MR though!
not backporting to 10.x
Committed and pushed 3a9f2bab7e5 to 11.x and 17f7df3e200 to 11.2.x. Thanks!
Committed and pushed 2c8c0a2efb2 to 11.x and 2042dcf3a4f to 11.2.x. Thanks!
Committed and pushed 61e09f28155 to 11.x and 8d86de67efe to 11.2.x. Thanks!
I have a problem with this line, There is not a finite amount of values for $definition['provider'] passing that through t() is not a good idea.
$definition['category'] = $this->t($this->getProviderName($definition['provider']));
The rest is fine.
@fathershwan: it sure will, that's the point and that's why we filter out the Drupal specific pieces out of the get parameters. We need that for TranslateFilterForm at least.
If we have another method in the Url object or somewhere else that does this I'd be happy to remove this chunk of code from the Htmx object, but I don't have a good place for it somewhere else
that's my mistake, #3546670: Missing module version in 2.x branch → .
Thanks for the lightning fast reactivity!
That's my bad, I was on a dev version and when upgraded to the beta the release was not picked up, it used the git version of the source files.
Sorry about the noise!
I think the problem is that there is no module at the root of the repo and the packaging script maybe doesn't recognize that so it doesn't add the version automatically?
I do not know how to fix is, I asked on slack. Since the layout of the files is a bit different maybe it needs to be ignored?
This issue removed the version for the module, now there is a warning for country_path because there is a version constrain on domain and domain doesn't have a version a Drupal website understands anymore.
I attached the push url to the form itself, since it's not about the field itself it's more about the whole form. And refactored a bit to make only one call to the pushUrlHeader.
I've spent days on this form and an other version of this form is used in the Htmx tests so I'm confident we got everything working. it's also an improvment compared to before because we can use the back button of the browser now :)
I'm not happy with that static method being the only way to add the wrapper format.
We can add the static method but I want to add the htmx wrapper format by default to the Urls the Htmx class handles, and provide a way to opt-out when necessary. The wrapper format is an implementation detail of Drupal, people using Htmx in Drupal shouldn't have to know about this.
Making a test harder to write, and in exchange we won't have to explain anything about wrapper formats to users is a good compromise to me.
very eager to get that in but a few things to fix first
planning a post today or tomorrow, the more the merrier :)
Because of how these forms work we need 📌 Improve url management of the Htmx object Needs work before
created a follow-up to make it easier to use this wrapper format: 📌 Improve url management of the Htmx object Needs work
depends on 📌 Return htmx responses as SimplePageVariant Active
small change, we can declare the settings in drupalSettings in the library definition, that will make sure we have that available on the frontend side of things:
drupalSettings:
# These placeholder values will be set by xxx::preRenderPlaceholder().
contextual:
theme: null
excellent :)
I'm hopeful we won't much more htmx specific code in the backend side of things.
What I have in mind with regard to htmx: make the form work without JS and make htmx the ajaxify-ier of that form. We're currently looking at some ways to keep the callback mechanism of the ajax framework without the whole separate processing on the PHP side. I'm almost sure we could have that type of callbacks for non ajax forms, need to look into it more, in any case if it makes form processing more complex we're not going the right way. Fun times ahead :)
Can someone confirm which MR is the one RTBC (12460?) and that the comments from MR 7008 are addressed in the latest MR?