🇮🇹Italy @gambry

@Zoocha Will here you go.

Drupal Wordmark (blue)

Drupal 10 (blue)

I'm not sure what format you need them, however higher resolutions can be found/obtained here: https://drive.google.com/drive/folders/13XdLr2kvN7GrvYC0tUtxSwLXqE4nfcA4

I do agree to keep Druplicon, and adding the new logo and/or the "DRUPAL (TM)" options.

@Zoocha Will I'm not a designer, but I'll try to come up with a Drupal 10 alternative.

gambry → created an issue.

fathima.asmat → credited gambry → .

smustgrave → credited gambry → .

Mention support for custom payload, card or event is now supported for Dialogflow. https://www.drupal.org/project/api_ai_webhook/issues/3333883#comment-149... ✨ Response with custom payload / richContent Fixed

Fixed! Thanks a lot!

Fixing the test.

While tests run, a bit of documentation.

There are two main ways custom payload or event can be added to the fulfilment:
$this->response->getFulfillment()->addMessage()
$this->response->setIntentRespose()

Let's kick tests.

@dotist I'll post it in here too, in case you haven't seen it.

Based on your PR, I created this one: https://github.com/gambry/dialogflow-webhook/pull/3
Please have a look if it has got everything you had in mind, so I can merge it and we finish working on this issue.

Thanks!

@dotist thanks for your work. The patch can be accepted as it is, most of the changes are not really needed (all comments, creation of unused variable, dockblock not needed).

+++ b/modules/chatbot_api_apiai/src/IntentResponseApiAiProxy.php
@@ -80,8 +80,17 @@ class IntentResponseApiAiProxy implements IntentResponseInterface {
+  public function setIntentResponse($response, string $type = 'messages') {

This is a risky change of API. If committed, integrations may break until developers upgrade their code.
What about something like setIntentResponse($data, string $type = 'text') {}, with text being the default. So we make this backcompatible?

We need to make sure we don't break things and new code is tested.
I'll comment changes to gambry/dialogflow-webhook in its own PR.

Thanks!

Adding the correct tag for Drupal Global Contribution Weekend 2023.

Adding the correct tag for Drupal Global Contribution Weekend 2023.

Adding the correct tag for Drupal Global Contribution Weekend 2023.

Adding the correct tag for Drupal Global Contribution Weekend 2023.

Adding the correct tag for Drupal Global Contribution Weekend 2023.

Adding the correct tag for Drupal Global Contribution Weekend 2023.

Adding the correct tag for Drupal Global Contribution Weekend 2023.

Adding the correct tag for Drupal Global Contribution Weekend 2023.

Adding the correct tag for Drupal Global Contribution Weekend 2023.

Adding the correct tag Drupal Global Contribution Weekend 2023.

Adding the correct tag got Drupal Global Contribution Weekend 2023.

Adding the correct tag got Drupal Global Contribution Weekend 2023.

Adding the correct tag got Drupal Global Contribution Weekend 2023.

Adding the correct tag got Drupal Global Contribution Weekend 2023.

Adding the correct tag got Drupal Global Contribution Weekend 2023.

(leaving the original one though. Plz remove it if not needed for internal use)

Swapping with the right tag: ContributionWeekend2023.

Re-testing #93. Also adding other DB types to validate this is not a DB type and we haven't tested this patch against other DB types for almost 1 year, so to create a newer baseline.

Trying to resurrect this at Drupal Global Contribution Weekend.

Applying and running the test locally, to see what can be done.

Swapping the Drupal Global Contribution Weekend 2023 tag with the correct one.

Swapping the Drupal Global Contribution Weekend 2023 tag with the correct one.

Swapping the Drupal Global Contribution Weekend 2023 tag with the correct one.

Hey @scott_euser have you seen work on the related issue?
Can we merge the two issues, and close the duplicate?

Wonderful work, well done everyone!

Below my feedbacks.

1. +++ b/core/modules/file/src/Element/ManagedFile.php
   @@ -352,8 +353,17 @@ public static function processManagedFile(&$element, FormStateInterface $form_st
   +    // Add states to ajax wrapper so states.js can potentially attach this
   +    // element as a Dependent.
   +    $attributes = '';
   +    if (isset($element['#states']) && !empty($element['#states'])) {
   +      $attributes = new Attribute([
   +        'data-drupal-states' => json_encode($element['#states']),
   +      ]);
   +    }
   +
        // Prefix and suffix used for Ajax replacement.
   -    $element['#prefix'] = '<div id="' . $ajax_wrapper_id . '">';
   +    $element['#prefix'] = '<div id="' . $ajax_wrapper_id . '"' . $attributes . '>';
   

   $attributes is first a string, then an Attribute() instance. Why don't we make it an Attribute() instance since definition, and maybe we create it with [id=$ajax_wrapper_id] and so print all prefix element attributes in the same way?

2. +++ b/core/modules/file/tests/src/FunctionalJavascript/FileManagedStateTest.php
   @@ -0,0 +1,60 @@
   +  protected function setUp() {
   +    parent::setUp();
   +  }
   

   I don't think this is needed then, as it's overriding the parent::setUp() just to call it. :D

3. +++ b/core/modules/file/file.js
   @@ -36,6 +36,10 @@
   +      $(document).trigger('state:visible');
   

   This looks to handle only the visible, so I tried some other states and something looks broken. Apparently all states are applied to the parent wrapper and not to the input element itself. So some states work (visible, invisible, disabled) but other like required don't.
   States changes should affect the element and not the parent.