Questions answered and minor issues fixed :)
fathershawn → created an issue.
fathershawn → created an issue.
fathershawn → created an issue.
Still trying to fix the anchor link symbol at The proposal
Leaving documentation for others who might come across this issue. There is not an option to remove the message. There is an plugin property to allow display and a required method on plugins
/**
* Check the plugin definition for success_message or return a static value.
*
* @return bool
* Should a success message be displayed to the user?
*/
public function displaySuccessMessage(): bool;
The provided base method defaults to false but plugins can provide their own logic or leave the default.
/**
* {@inheritdoc}
*/
public function displaySuccessMessage(): bool {
return $this->pluginDefinition['success_message'] ?? FALSE;
}
Hello, working use hx-on:click, but use hx-on:intersect not working. Did I make a mistake?
I don't think so. As I said in #4 the intersect event might only work with trigger. If you really need to manipulate the DOM on intersection rather than request the needed markup, I think you will have to build the JS yourself. The core competency of HTMX is adding interactivity between your page and the server.
@nod_ suggested adding my name to the existing list of Ajax subsystem maintainers. I had pictured we were replacing one subsystem with another but it can also be described as replacing everything within the existing subsystem as HTMX is a ajax based library. Changed the issue name to match and opened an MR.
I can give you some direction on how htmx can be part of the edge case that you are building, but first I wonder why? If the content is on the page and you want to reveal it then that is possible with just CSS. A quick search will yield you many resources.
HTMX may save you half the work if you want to trigger some manipulation of the current page. That is you don't have to write and attach the event handler to the element. You do still have to create the javascript that does the manipulation. All the htmx attributes that you use in your example are based around the core competancy of htmx, which is bringing in and using new content from a request.
You may be looking for hx-on* but I don't think the once modifier is available there.
However if you are replacing the element making the call, once may not matter.
<div hx-on:intersect="myMoveDivFunction('#related-links-backup')"></div>
You would have to create and attach the js with the myMoveDivFunction()
. The intersect event is a custom HTMX event described in the docs for hx-trigger
and is stated to be inherently a one time event. I don't know if it works with hx-on*
All tests passing again
Hi :)
There is no request in your second div. `hx-select` selects from the response returned from an htmx request.
Improved \Drupal\KernelTests\Core\Http\HtmxHeaderTest::testJsonTriggers
and added \Drupal\KernelTests\Core\Http\HtmxHeaderTest::testMerge
Steps to review
Copied from a Slack thread
- Check the post applied patches
- Review or run the command to confirm the process
- Spot check a few different ones to confirm the location and copy is correct
Checked the patches. All are cleanly applied unless noted.
✓ 0001-codesniff.patch
✓ 0002-manual-conversion.patch differs only in that visibility is added and a comment is edited in \Drupal\block\Hook\BlockHooks::themesInstalled
✓ 0003-testfix.patch
✓ 0004-deprecationfix.patch
I have my core dev setup running under DDEV so I copied in your command from the snippets page, created a new branch off 11.x and ran your command, responding Y to all options. The result differed only slightly from the MR branch in some comment formatting and the replacement of some procedural calls to t()
with the \Drupal\Core\StringTranslation\StringTranslationTrait::t
method.
Spot checked contents and attribute value of several hooks
It's dynamic page cache I think. The header cache is a good idea. I can see it used in one dynamic page cache entry but I'm still seeing a cached response.
Issue recreated in a test module
The expire time and token in AccessToken are set by the provider using the response from your oauth service.
If there's not expiration date nor refresh token then either they are not provided or you need a more custom provider
fathershawn → created an issue.
@jurgenhaas pointed out that we should call this "fixed" since it accomplished it's purpose!
Tagged new 2.0.2 release → Thank you for the code contribution!!
We should have dropped Symfony 4 when D9 support was also dropped.
Thanks for this! FormAssemblyEntityViewBuilder
uses Symfony\Component\DomCrawler\Crawler
which uses Symfony\Component\CssSelector\CssSelectorConverter
which is how we get to both dependencies.
This problem comes from the Ajax API which we are actively working to replace in 🌱 Gradually replace Drupal's AJAX system with HTMX Active . We decided to further decompose our refactoring of BigPipe, moving the PHP side to 📌 Refactor big_pipe module to remove dependencies on Ajax classes Active . I would still like feedback on the proposal #32 as we will need to render individual messages so that we can return HTML placeholders for messages when it is time to refactor.
Follow-up issue to "un-AJAXify the PHP side" created and linked in the sidebar
fathershawn → created an issue.
Thanks @nod_ for the clear explanation. :)
I'm happy to have learned about the internals of our BigPipe implementation. It was also worthwhile to understand how to remove the dependencies on the PHP side and that if we are to move to an HTML based approach, we need a way of rendering individual messages.
+1 for removing the ajax dependency on the client-side. I'm going to update the issue summary with some of what you wrote and change the issue title to reflect the scope.
MR-12476 communicates to me that I did not understand the limited scope of this issue. I understood that our goal here was remove the dependency between BigPipe and the existing Ajax API. @larowan has stated that to be too much change and @nod_ proposes to leave the dependencies between BigPipe and the four Ajax classes.
My question then is what is the plan and time line to remove these dependencies?
@larowan I've updated the issue summary to give an overview of how we got to where we are and the scope of MR-12295, which is our current MR. This MR combines work that @nod_ and I each did.
\Drupal\big_pipe\Render\BigPipe
and clientside code are strongly connected so it is difficult to tease this apart. However, there is strong test coverage for BigPipe and we went through iterations to pass the tests.
fathershawn → changed the visibility of the branch 3526267-big-pipe-scope to hidden.
fathershawn → changed the visibility of the branch htmx-swap-placeholders2 to hidden.
Nightwatch tests were not visible in the "test only" job. I created a draft MR without the fix. Tests in that MR fail as expected.
fathershawn → created an issue.
Fixed @nicxvan concern about wait time
New tests now pass after adjusting big_pipe.js
.
New test cases fail using beforestart and afterend
On hold pending a bug fix in core
fathershawn → created an issue.
fathershawn → created an issue.
I think the only unresolved feedback relates to message theming and swapping. I would propose that those are handled in the related issues on message theming.
fathershawn → created an issue.
fathershawn → created an issue.
I posted in 🐛 AJAX MessageCommand markup and styling differs from Theme default Active and 🐛 10.3 upgrade now missing status-message theme sugestions Active proposals that would simplify the work in this issue.
I posted the following at #32 🐛 AJAX MessageCommand markup and styling differs from Theme default Active in 🐛 AJAX MessageCommand markup and styling differs from Theme default Active
We use status-message.html.twig to theme individual messages and #theme => 'status_message' when constructing a render array.
If that proposal is agreeable, this issue would be used to add the theme hook core and template to core themes.
We are well on the way to changing BigPipe's placeholder insertion process in 📌 Refactor BigPipe to use HTMX Active . A fundamental difference is that HTMX expects HTML. Which means that we neither need nor want to assemble HTML in javascript for messages. When I commented to @catch that what we really needed was a theme hook for an individual message he sent me here :)
In the refactored BigPipe approach I'm sending messages generated by rendering a placeholder as HTML wrapped in a <template>
. At the moment I still need javascript to find the wrapper element for the messages so they can be moved into place. I think that this work could be simplified down to storing a CSS selector in drupalSettings
. Here's my proposal:
- Core stores the CSS selector for the default wrapper element in settings.
- Themes can store a different selector in their theme.info.yml file.
- If the active theme has an override in replaces the default.
- We use
status-message.html.twig
to theme individual messages and#theme => 'status_message'
when constructing a render array. - Inserting the resulting html dynamically into the designated wrapper becomes very simple
Please add credit for @jrockowitz and @richgerdes who collaborated on test refactoring at the DrupalNYC Contribution Day
Thanks for the issue link in #22 @catch! I'll go there and chime in!
All tests green!
If this approach is good we should open an issue to theme individual messages to provide a server side way for themes to specify message markup
BigPipeRegressionTest
is now completely passing.
`BigPipeRegressionTest::testMessages_2712935` is now passing
Returning to this - we aren't using any headers in 📌 Refactor BigPipe to use HTMX Active
Coming back to this now - we needed the htmx javascript API in 📌 Refactor BigPipe to use HTMX Active but not attributes.
The fix in this issue is also contained in 🐛 Admin Page `admin/config/services/jsonapi` is not loading in test environment Active which also fixes other issues