@r.van.doorn

We are testing version 2.1 of CKEditor Layouts and we ran into in something that I would describe as buggy behavior.
The focus for layout columns is not what you expect. When clicking on a column the column seems to become draggable for a short instance and then the editor decides what element it should place the cursor in. If it is the first column in a layout, this sort of works. If you click on the second column, the cursor jumps to the first 'editable' element. If there isn't any, again it sort of works and the cursor is placed inside the clicked column. If there is an editable element, the cursor jumps to that element.

To reproduce, add a paragraph with some text and then add a layout with multiple columns and try clicking on a second or third column inside the layout.

The fix seems simple though, just make the column an editable element instead of a container.

Added a new patch for Drupal 10.2.
Like I said in my previous comment, changed the return value of streamUploadData to return the path instead of the originalName.

I'll soon try to make some time to look into how drupal 10.3 affects this issue.

My multipart/form-data upload is still failing with the latest patch.
The Content-Disposition header with filename is now mandatory, which I can somewhat understand. It is just annoying that a different party is using our REST interface and they need to change their code.

But even with the Content-Disposition header set, the upload still fails on trying to move the temporary file. It claims it doesn't exist but that is because it uses the OriginalName to find the tmp file and not the actual path of the tmp file.

In FileUploadResource:
$temp_file_path = $this->streamUploadData($request);

The patch now returns
return basename($file->getClientOriginalName());

Shouldn't it return $file->getPathname();
I would say yes, but as I just glanced at the Symfony class I might be missing something.
It would be a simple fix, so I'm testing it and will upload a new patch soon.

I am a bit worried about Drupal 10.3 though, will look into that soon as it seems to refactor some relevant code and rerolling the patch will probably take a bit of time.

As described above, I've update the patch for 10.1 to check for 'form' format instead of the bin_multipart that was added in previous patches in this issue.

I think the patch needs to be updated, it uses getContentType() to check for bin_multipart. The getContentType is now deprecated and we need to use getContentTypeFormat. That uses format and has a fixed set of keys mapped to mime type.

static::$formats = [
  'html' => ['text/html', 'application/xhtml+xml'],
  'txt' => ['text/plain'],
  'js' => ['application/javascript', 'application/x-javascript', 'text/javascript'],
  'css' => ['text/css'],
  'json' => ['application/json', 'application/x-json'],
  'jsonld' => ['application/ld+json'],
  'xml' => ['text/xml', 'application/xml', 'application/x-xml'],
  'rdf' => ['application/rdf+xml'],
  'atom' => ['application/atom+xml'],
  'rss' => ['application/rss+xml'],
  'form' => ['application/x-www-form-urlencoded', 'multipart/form-data'],
];

So It will always return 'form' in this use-case, so I think we need to use the new method and replace checks for bin_multipart with form.
Since I'm running into this problem for my project I'll see I can put a new patch together.

We recently updated to PHP8.2 and to my surprise our site went down because of small error in this patch.

The error:
TypeError: str_replace(): Argument #3 ($subject) must be of type array|string, null given in str_replace() (regel 494 van /web/modules/contrib/matomo/matomo.module)

Which is where the get parameter 'search'. I've fixed it with a simple nullesce operator to return an array if null.

Looks good to me.

r.van.doorn → created an issue.

I'm running into this problem as well for my project, but weirdly enough not on all environments. So I'm nopt sure it I'm experiencing a different error but I do have a boolean field used to toggle other fields.

I get the following error in the log:
TypeError: array_keys(): Argument #1 ($array) must be of type array, null given in array_keys() (line 238 of /web/modules/contrib/field_states_ui/src/FieldStateManager.php)

So it breaks in generating a notice

if (!isset($target['#field_parents'])) {
  $parents = [];
  $this->logger->notice(
    t(
      '#field_parents key not found. This will may cause problems. If so, please report on the @link. For quickest resolution, please include the element details: @details',
      [
        '@link' => Link::fromTextAndUrl(
          t('Field States UI Issue Queue'),
          Url::fromUri('https://www.drupal.org/project/issues/field_states_ui')
        )->toString(),
        '@details' => var_export(array_keys($element[0]),TRUE),
      ]
    )
  )

I mean, I can easily just patch that the var_export isn't used if $element[0] is NULL and yes then the field_state works as expected.
But I'm guessing the real questions is why $element[0] is NULL in this context. I don't have an answer right now since I haven't debugged it (yet).