🇺🇸United States @fathershawn

I also don't see anything unexpected in Gin 3.0-rc14 . Please re-open with more information about how to recreate if I'm missing something.

Cannot reproduce with Claro in D11.0.6

fathershawn → created an issue.

fathershawn → created an issue.

fathershawn → created an issue.

The pushUrl method takes a Url object or a boolean value. This is in line with https://htmx.org/attributes/hx-push-url/. To accomplish what you would like, pass the url that you are calling in https://htmx.org/attributes/hx-get/ in the call to pushUrl

I'm still not sure what Twig was calling, but there is a syntax error in your code. The proper syntax for the method to generate a push url attribute is

.pushUrl(true) or .pushUrl(someUrlObject)

I'll do some testing. I would have expected a type exception with the given Twig expression. The function signature for that method is:

  public function pushUrl(bool|Url $value) {}

I'm not clear why Twig is interpreting your string as a Url object.

fathershawn → changed the visibility of the branch 3485198-tweak-twig-dot to hidden.

fathershawn → made their first commit to this issue’s fork.

Thanks for the extra eyes @nicxvan! I missed a variable change moving some JS over from the HTMX module → . Updated the branch.

The markup format is discussed and decided in 🌱 [policy, no patch] Choose a markup strategy for HTMX POC Fixed

I have a working POC on the Single Config Export form: https://git.drupalcode.org/issue/drupal-3446642/-/compare/11.x...3446642...

Feedback invited!

I'm not sure your requested url can be satisfied, but we may be able to make it nicer by moving page state back to a header.

That is accurate. As we find areas in which a utility or service would help, I've been adding them here in Drupal. I don't know anything about Hotwire Turbo. All of the methods of HTMX enhance and expand on these 5 capabilities:

1. Behaviors are described within the element
2. Any element can issue an HTTP request
3. Any event can trigger an HTTP request
4. Use all the “verbs” of HTTP
5. Target any element in the document for replacement by any element in the response

These enable a rich hypermedia based paradigm.

Please re-open and/or switch to a feature request if more is needed.

fathershawn → created an issue.

The module seems more low level in its goal, in that it doesn't try to progressively enhance the entire Drupal front-end, but rather to enable Ajax-like functionality for designated blocks.

The purpose of the HTMX module is two-fold:

1. Provide a set of tools to make it easy to use HTMX within Drupal.
2. To be an arena of innovation for bringing HTMX to Drupal core.

The HTMX Blocks are intended to be a usable example of developing a solution in Drupal. Both the admin interface and the blocks use HTMX. The module provides the following tools:

1. The latest version of the HTMX library as a Drupal asset library
2. The HtmxAttribute object which builds the data attributes that make HTMX work.
3. JS/CSS asset loading: the same intent as Drupal Ajax - load any CSS or JavaScript in the response that is not already on the page.
4. Render an entity in a given view mode and return the markup
5. A route option to render a simpler html response
6. Views plugins for HTMX displays and pagers

I'm excited that you are inspired to build with HTMX and interested in what you learn, especially any learning that would apply to 📌 [POC] Implementing some components of the Ajax system using HTMX Active .

fathershawn → created an issue.

Absolutely! Happy to help.

It's not possible with the provided checkout panes.

The client that this module was developed to support did not have any commerce beyond donations. After this code was released as a contributed module, donations along side the purchase of actual goods was requested by several users and I built a second checkout flow plugin to support that. However, all the plugins in this module are built to support the dedicated donation OrderItem. OrderItems are always paired with an Order in Commerce which is paired with a Checkout flow. So to support two flows, the checkout panes and the Donation order controller would all need to be configurable as to which OrderItem was expected in each flow. That's not the current state of the code.

"You will need to create extensions of the donation and memorial panes that select for your additional OrderItem type, and use those panes in the checkout flow which you configure to use this second OrderItem."

The included checkout panes, regardless of which setup is used, look for donation OrderItems. Using both checkout routes is an advanced scenario that requires having a second OrderItem type created and then coding checkout panes to look for that type. This can be done by extending the existing pane plugins but the module does not currently offer out of the box for this scenario.

If you have your site configured for Option 2 (standard checkout) as you stated in 💬 Donation checkout flow not being displayed in config Active then the /donate route isn't going to work. That's the beginning of a dedicated checkout process that only does donations.

The default gift type should be single, so try hiding the field?

/admin/commerce/config/order-item-types/donation/edit/form-display/donation

Please confirm that you have successfully completed step 1 in that section:

Before completing this configuration, create or confirm that you have created a checkout flow that uses this modules's donation_multistep_flow plugin. Place the "Add Donation" pane in the first step of the flow, just before the Donation step.

When you browse to /admin/commerce/config/checkout-flows you should see the multi-step checkout flow that uses our plugin.

If you want to use the mixed flow, and add donations outside the checkout flow, some custom work will be needed as I only have that feature for the donations only flow at the moment. The core task is to create and configure for the customer an instance of our Donation order_item. You might look at improving src/Plugin/Block/QuickDonationBlock.php and \Drupal\commerce_donation_flow\Controller\DonationController::quickDonation so that it chooses the proper paths for redirection or build a route of your own that does this task for your setup.

fathershawn → created an issue.

Critical thinking is a valuable means of understanding something new. I recognize that the author of the critique works regularly with HTMX and I'll watch for some of the edge cases called out, but I wonder if there are some a priori assumptions from working in single-page-applications when I read

An attractive future direction might be to re-implement Htmx in React

You would need a route that will render the needed paragraph. If that is the latest revision of that paragraph, then our included route would work I think.

I also added in v1.3 the ability to instantiate an HtmxAttribute object in Twig.

So if you have the needed information in the template for which paragraph to load, you should be able to add htmx attributes to request, select and swap some target triggered by load.

fathershawn → created an issue.

Perhaps I'm missing something but a default pipeline using ImageAPI Optimize and a processor like ImageAPI Optimize AVIF WebP → takes care of this.

fathershawn → created an issue.

Thanks for the feedback! I created an issue to update the documentation.

fathershawn → created an issue.

This module is for the other end of the Oauth communication: when your Drupal site needs to connect to something else using Oauth. It easily allows a developer to generate plugins that create Oauth clients and retain retrieved tokens.

It does not provide an Oauth server. For logging in to Drupal using OIDC, I've personally had some success with oidc → and I believe that there are some others.

Okay - I'm glad you found an approach that works for you!

Leaving a note for any who find this issue after it is closed:

The approach in this module does not use products as the basis of donation, but rather order items. Order items are purchasable, and fieldable. In the cart approach, the donation is added as part of the checkout process and the amount set on the form that adds the donation.

Can you give more details about why you needed a commerce_product_variation? The order_item is also a purchase-able entity and the Donation bundle we provides also holds our fields

Please re-open if this work becomes active again

Thank you @dww for Option D. The scope is definitely noise in contrib as it would be the same for every commit in the project. Even in core, anything not in a module might be scope (core)?

+1 for Option D.

fathershawn → created an issue.

fathershawn → created an issue.

Moving back to "needs work" based on the review in #5

Postponed until Entity Share has at least a dev version for D11.

Fixed in 1.2.0-beta1

Some additional adjustment to FormBuilder is needed, and I could use guidance as to where. The POC is on admin/config/development/configuration/single/export

Here's the problem sequence:

1. Load the form
2. Change the type
3. Select a name
4. Change the type

At this point the form class is called to build the form, but this but doesn't run:
FormBuilder.php:1294

      // Detect if the element triggered the submission via Ajax.
      if ($this->elementTriggeredScriptedSubmission($element, $form_state)) {
        $form_state->setTriggeringElement($element);
      }

so the name is not reset.
Then the code above is executed but the form is not rebuilt.

I feel like we therefore either need to set a rebuild if our request is htmx but I'm not sure the correct place to do that in form builder.

Here is a diff with 11.x of the current state of the work.

From the core issue Remove usages of MigrateSkipProcessException from core process plugins

Rebased on latest 4.x

fathershawn → made their first commit to this issue’s fork.

Updated version and MR

Omitting the validation function so I can address 📌 Rename the payment method add form class Active

fathershawn → made their first commit to this issue’s fork.

A closer look and I have a better answer. There is a small but important difference between the templates.

The template at commerce/modules/order/templates/commerce-order-receipt.html.twig has this block:

{% block payment_method %}
  {{ payment_method }}
{% endblock %}

And the template in this module has:

{% block payment_method %}
  {{ payment_method }}
  {{ payment_instructions }}
{% endblock %}

The payment instruction info is preprocessed in commerce_purchase_order_preprocess_commerce_order_receipt. I've changed the template in this module to a clear twig block override. Please would this have saved you time?

@jsacksick Please review and comment on the MR above.

This is a bug. The feature was contributed and I missed this in the review. Further, manual testing shows that the Purchase order output is not useful or accurate when a file is used. Fixing that too.

The core of this issue is that the logic about what information is needed in PurchaseOrderGateway::createPaymentMethod is not correct.

fathershawn → made their first commit to this issue’s fork.

Commerce 3.x is not released but this is ready for when it is.