🇺🇸United States @fathershawn

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.

Add link to issues in review

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.

See https://htmx.org/attributes/hx-select/

Improved \Drupal\KernelTests\Core\Http\HtmxHeaderTest::testJsonTriggers and added \Drupal\KernelTests\Core\Http\HtmxHeaderTest::testMerge

Steps to review

Copied from a Slack thread

1. Check the post applied patches
2. Review or run the command to confirm the process
3. 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:

1. Core stores the CSS selector for the default wrapper element in settings.
2. Themes can store a different selector in their theme.info.yml file.
3. If the active theme has an override in replaces the default.
4. We use status-message.html.twig to theme individual messages and #theme => 'status_message' when constructing a render array.
5. 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

I still need to deal with Messages and Redirects, but this approach is simpler and over a 10 request sample results in a mean time of Load of 178.6 ms compared to 185.4 ms for the existing 11.x branch.

Here's an MR into @nod_'s branch moving the bigPipe command JS into bigPipe scope. It looks like the test setup scripts don't like MR's into a feature branch. The tests generally pass locally - 2 failures involving noJS exceptions. Not sure if that's a false negative as all of these changes are in JS.

If this is an acceptable direction then I think the next level of refactoring is to create the needed bigPipe Command classes to replace the AjaxCommands and update BigPipe.php to work without the Ajax API classes.

fathershawn → changed the visibility of the branch 3526267-bigpipe-with-htmx to hidden.

We need this only if if there is an existing capability we cannot implement using the tools provided by htmx - let's keep it a placeholder.

All green is super - nice work! This is direction really simplifies the changes in big_pipe.js and that’s a real plus.

Because bigPipe as we have it re-uses existing javascript from the ajax system, to remove the ajax system we need to replace that.
@nod_ had this list in a Slack discussion:

We need the equivalent of those 3 commands to implement bigpipe

• use Drupal\Core\Ajax\MessageCommand;
• use Drupal\Core\Ajax\RedirectCommand;
• use Drupal\Core\Ajax\ReplaceCommand;
• Add_css/add_js and the settings but that’s mostly available already

I think we need to identify the pieces of this list that htmx is not going to do, and implement those in general scope. Then the items that htmx does just fine in an ajax context, we need to have as helper methods in big_pipe.js and leverage the htmx api where we can.

I'm going to take them in order.

MessageCommand
In the ajax context, I would have implimented this in HTMX using a header and a custom event handler that calls our Drupal.Message function. This is actually the example in the trigger headers documentation.

HX-Trigger: {"showMessage":{"level" : "info", "message" : "Here Is A Message"}}

One thing that Drupal.Message does client-side is determine the selector for the message container. If there is a way to do that server-side then this could also be implemented as an extra out-of-band swap on the response without any additional javascript.

We do need a helper method for this that we can use in big_pipe though.

RedirectCommand
HTMX has both the HX-Redirect and HX-Location response headers. We don't have a response so we need a function for that in bigPipe.

ReplaceCommand
We also just need the bigPipe use case for bigPipe. This is one of the core competencies of htmx in an ajax request context.

addCSS and addJS
In the ajax context using htmx, these feel like out of band swaps as well.

We agreed in Slack to pause on this builder while we work on 📌 Refactor BigPipe to use HTMX Active using headers that are "hand-rolled."

We agreed in Slack to pause on this builder while we work on 📌 Refactor BigPipe to use HTMX Active using attributes that are "hand-rolled."

fathershawn → created an issue.

What ever we implement, if there is configuration we should collect in via \Drupal\dynamic_yield\Form\FeedSettingsForm and store it in the general settings.

We already to not load DY on admin routes. The presenting issue is that some pages often use the admin theme, such as entity edit forms. This seemed like a simple way to exclude certain path patterns.

We could programmatically detect the active theme, get then name of the admin theme and compare to exclude DY.