New York
Account created on 23 October 2009, over 15 years ago
#

Merge Requests

More

Recent comments

🇺🇸United States fathershawn New York

Questions answered and minor issues fixed :)

🇺🇸United States fathershawn New York

Replace the table with an unordered list

🇺🇸United States fathershawn New York

Still trying to fix the anchor link symbol at The proposal

🇺🇸United States fathershawn New York

Fixing anchor link symbol location

🇺🇸United States fathershawn New York

This is a an un-reviewed page

🇺🇸United States fathershawn New York

testing menu links

🇺🇸United States fathershawn New York

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;
  }
🇺🇸United States fathershawn New York

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.

🇺🇸United States fathershawn New York

@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.

🇺🇸United States fathershawn New York

Add link to issues in review

🇺🇸United States fathershawn New York

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*

🇺🇸United States fathershawn New York

All tests passing again

🇺🇸United States fathershawn New York

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/

🇺🇸United States fathershawn New York

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

🇺🇸United States fathershawn New York

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.
&check; 0001-codesniff.patch
&check; 0002-manual-conversion.patch differs only in that visibility is added and a comment is edited in \Drupal\block\Hook\BlockHooks::themesInstalled
&check; 0003-testfix.patch
&check; 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

🇺🇸United States fathershawn New York

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.

🇺🇸United States fathershawn New York

Issue recreated in a test module

🇺🇸United States fathershawn New York

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

🇺🇸United States fathershawn New York

@jurgenhaas pointed out that we should call this "fixed" since it accomplished it's purpose!

🇺🇸United States fathershawn New York

Tagged new 2.0.2 release Thank you for the code contribution!!

🇺🇸United States fathershawn New York

We should have dropped Symfony 4 when D9 support was also dropped.

🇺🇸United States fathershawn New York

Thanks for this! FormAssemblyEntityViewBuilder uses Symfony\Component\DomCrawler\Crawler which uses Symfony\Component\CssSelector\CssSelectorConverter which is how we get to both dependencies.

🇺🇸United States fathershawn New York

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.

🇺🇸United States fathershawn New York

Follow-up issue to "un-AJAXify the PHP side" created and linked in the sidebar

🇺🇸United States fathershawn New York

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.

🇺🇸United States fathershawn New York

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?

🇺🇸United States fathershawn New York

@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.

🇺🇸United States fathershawn New York

fathershawn changed the visibility of the branch 3526267-big-pipe-scope to hidden.

🇺🇸United States fathershawn New York

fathershawn changed the visibility of the branch htmx-swap-placeholders2 to hidden.

🇺🇸United States fathershawn New York

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.

🇺🇸United States fathershawn New York

Fixed @nicxvan concern about wait time

🇺🇸United States fathershawn New York

New tests now pass after adjusting big_pipe.js.

🇺🇸United States fathershawn New York

On hold pending a bug fix in core

🇺🇸United States fathershawn New York

fathershawn created an issue.

🇺🇸United States fathershawn New York

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.

🇺🇸United States fathershawn New York

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.

🇺🇸United States fathershawn New York

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.

🇺🇸United States fathershawn New York

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
🇺🇸United States fathershawn New York

Please add credit for @jrockowitz and @richgerdes who collaborated on test refactoring at the DrupalNYC Contribution Day

🇺🇸United States fathershawn New York

Thanks for the issue link in #22 @catch! I'll go there and chime in!

🇺🇸United States fathershawn New York

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

🇺🇸United States fathershawn New York

BigPipeRegressionTest is now completely passing.

🇺🇸United States fathershawn New York

`BigPipeRegressionTest::testMessages_2712935` is now passing

🇺🇸United States fathershawn New York

Returning to this - we aren't using any headers in 📌 Refactor BigPipe to use HTMX Active

🇺🇸United States fathershawn New York

Coming back to this now - we needed the htmx javascript API in 📌 Refactor BigPipe to use HTMX Active but not attributes.

🇺🇸United States fathershawn New York

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

Production build 0.71.5 2024