🇧🇪Belgium @robindh

robindh → created an issue.

robindh → created an issue.

Apply code formatting

Hack the related content autocomplete to create a link to the project page

Add project link

Page structure tweaks

Fix the image upload

I encountered a very similar issue, but with elasticsearch connector 8.x-7.0-alpha4. This actual problem was my mapping not being imported.

When navigating to /admin/config/search/search-api/index/myindex/fields and saving the form, I noticed this error:
Failed to parse mapping [_doc]: unknown parameter [fielddata] on mapper [myfield] of type [keyword]

At this point my index mapping is basically empty. When executing a query the response is:
Text fields are not optimised for operations that require per-document field data like aggregations and sorting ...

Presumably, this happens because elasticsearch doesn't map text fields as fielddata by default.
Fixed it by only adding fielddata mapping to text fields, since other fields don't support it.

Attaching a patch for version 8.x-7.0-alpha4

Added initial Utility::itemIdToEntityUri() test cases that should fail

robindh → changed the visibility of the branch 3473055-views-area-plugin to hidden.

robindh → created an issue.

Remove punctuation after button

Clarify "front-end developers"

I've renamed to $message service to $messenger, so it matches the class variable

robindh → created an issue.

This change seems to have caused some very specific regression within the ckeditor linkit widget.
When a link to a specific item was made, and you try to add that same link again; it will not be selected.

Steps to reproduce:

1. Create a node to link to, title example: "My page"
2. Create a link to "My page" in any ckeditor widget; via the linkit autocomplete selection, it will automatically be replaced to /node/1.
3. Enter "My page" again in the autocomplete widget. After selection, it will not be replaced to /node/1. The autocomplete search query will stay in the link field. Any other autocomplete result will work just fine, however.

When using linkit 6.1.2, this works as expected.
When using 6.1.2 + this patched diff (or 6.1.3), I'm seeing the above described behavior.

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

I'm getting the error on the latest version of the module (8.x-10.1-beta3).

After some commit digging - it seems like this was originally fixed in https://git.drupalcode.org/project/bat/-/commit/213f90bbf51d3265800699f6... (8.x-10.1-beta2), but later accidentally reverted in https://git.drupalcode.org/project/bat/-/commit/af1067581774ea0182de72d7... (8.x-10.1-beta3)

robindh → changed the visibility of the branch 2.x to hidden.

robindh → created an issue.

robindh → created an issue.

Fix *.libraries.yml formatting to avoid confusion

robindh → created an issue.

Ran into the same problem today. The attached merge request fixes the issue, moving to RTBC

The test was actually already included in the merge request, since I've removed the $method !== 'DELETE' conditionals from existing tests (testOnResponseWithCacheableResponse & testOnResponseWithUncacheableResponse).

This will make the existing assertions for the other request methods trigger for DELETE method requests too.

Avoid global t() function calls

Looks good to me - tested all features on a local d9 site

I've reformatted the issue summary and attached a patch containing a test that should fail.
It mocks a DELETE endpoint rest plugin (no _format route requirement defined), where some content is returned.

Steps to reproduce on a clean drupal install:

1. Enable the core rest module
2. Create custom resource plugin with a DELETE method, this function will return a ResourceResponse with content:
   

   /**
    * Provides an example resource.
    *
    * @RestResource(
    *   id = "example_resource",
    *   label = @Translation("Example resource"),
    *   uri_paths = {
    *     "canonical" = "/api/example/{id}",
    *   }
    * )
    */
   class ExampleResource extends ResourceBase {
   
     /**
      * Delete an example entity based on ID.
      *
      * @param string $id
      *   The example ID.
      *
      * @return \Drupal\rest\ResourceResponse
      *   The resource response.
      */
     public function delete(string $id): ResourceResponse {
       return new ResourceResponse(['test123'], 200);
     }
   
   }

3. Configure & enable the plugin:
   

   status: true
   dependencies:
     module:
       - example_module
       - serialization
       - user
   id: example_resource
   plugin_id: example_resource
   granularity: resource
   configuration:
     methods:
       - DELETE
     formats:
       - json
     authentication:
       - cookie

4. Send delete request to /api/example/123
5. Returns statuscode 500; log: TypeError: Symfony\Component\Serializer\Encoder\ChainEncoder::getEncoder(): Argument #1 ($format) must be of type string, null given, called in /var/www/html/vendor/symfony/serializer/Encoder/ChainEncoder.php on line 49 in Symfony\Component\Serializer\Encoder\ChainEncoder->getEncoder() (line 80 of /var/www/html/vendor/symfony/serializer/Encoder/ChainEncoder.php)

I don't really understand the assumption where DELETE requests cannot contain a response body; according to https://www.rfc-editor.org/rfc/rfc9110.html#section-9.3.5-4, it should be allowed to return a 200 status code with extra information in the response. It's also possible to use statuscode 204, and omit the response body.

Any maintainers willing to weigh in on this?

In https://www.drupal.org/project/drupal/issues/3277148 → , documentation was added to indicate _format requirement must always be present when returning a ResourceResponse.

Created a merge request that will add the _format requirement to DELETE routes, to check which tests will break

So I Just ran into the same issue, when I wanted to return a validation message after failing to delete an entity.

I'll summarize some debugging in case anyone else stumbles onto this issue:

ResourceResponseSubscriber::getResponseFormat() will determine the format to return the response in.
This will check the route requirements that are dynamically generated by the rest module; e.g. _format & _content_type_format.
For delete routes, format NULL is returned, since dynamically generated DELETE routes do not contain _format or _content_type_format requirements. This is intentional, according to documentation in ResourceResponseSubscriber::renderResponseBody().

The symfony serializer does not seem to support this (anymore?). Also, the $format parameter is string typed now, so passing a NULL value as format now throws Symfony\Component\Serializer\Encoder\ChainEncoder::getEncoder(): Argument #1 ($format) must be of type string, null given in there. Not just a NotEncodableValueException, like in the original issue report.

For now, I have fixed the issue on my project by using a RouteSubscriber that alters the dynamically generated route by the rest module. Example snippet:

class RouteSubscriber extends RouteSubscriberBase {

  /**
   * {@inheritdoc}
   */
  protected function alterRoutes(RouteCollection $collection) {
    // Alter the dynamic delete route.
    if ($route = $collection->get('rest.example.DELETE')) {
      $route->setRequirement('_content_type_format', 'json');
      $route->setRequirement('_format', 'json');
    }
  }
}

This will make sure a format ('json' in this case) is passed to the symfony serializer; and avoid the fatal error from being thrown.

The easier solution seems to be expanding the array of request methods in ResourceRoutes::getRoutesForResourceConfig() to include the delete method, not sure yet if this will break some functonality.