Add "open by default" option

UPDATE: I am testing the v2.1 alpha version of the module with CKEditor 5. Unlike in CKEditor 4 / v2.0.3 where the open state of the details widget in the editor was preserved a node was published, all detail widgets created with CKEditor 5 are default closed, regardless of the open state in the editor. I would like to see the previous behavior preserved to give content authors the option to have the details widget default to open.

Since there hasn't been any response to this request in many months, I am trying to do it myself.

The update I am looking to make will expose a toggle switch when a details widget is selected in the editor, allowing the using to indicate if the details widget should be open by default or not.

If anyone's interested, I am working on the CKEditor part of this update outside of Drupal. This allows me to focus on the functionality of the CKEditor plugin without worrying about the Drupal integration. The code-in-progress is at https://github.com/aaronpinero/cke5_dev

I may have been successful in adding UI for the CKEditor Details widget allowing users to set the default open state of the details element.

With the update to the module, if the user clicks on the details widget in the editor, the user will see a balloon popup with a switch button. The switch button is labeled "open by default" and the switch is default off. If the user toggles the switch, the details element will be open by default when the content is viewed.

The balloon popup will not be displayed when the user is editing the summary or text within the details wrapper element. The user needs to click on the grey area surrounding the summary and wrapper for the balloon to appear.

Thank you for this! I'm having trouble with "open" being accepted in source editing, so fingers-crossed this solves my problem.

@jacobupal TBH I never actually tried applying the change as a patch. I had only been testing the modified version of the module. However, you are correct. I also was unable to apply the patch.

If I had to guess, the part of the patch that's the problem is the change to js/build/detail.js. The change is essentially a replacement of the existing file. However, I suspect patch is trying to identify the existing line of code (one huge line in a minified JS file) and replace it with the new line of code (another huge line in a minified JS file). There could be little trivial differences in the minified code that are functionally insignificant but are throwing off the diff. Or maybe that one line of minified code is just too long.

Not sure how to resolve that one. It would be better to just get this merged and have a new release. But obviously some RTBC needs to be done first.

Thanks @aaronpinero, I will hold tight.

I am known to move a module to my custom directory, manually compare files and apply patches line by line but this can wait!

I created a patch for testing this by outputting a diff as follows:

% git diff 2.1.0-alpha1 3314213-add-open-by > ckeditor_details-3314213.patch

The problem with the current MR is that the merge request is for merging into 2.x (or maybe 2.1.x) and so the plain diff of the merge won't work for patching if you've installed the 2.1.0-alpha1 release of the module. The attached file worked for me when applied via composer where the plain diff of the MR did not. This should allow folks to test this change by patching the current module release.

One note: after patching the module, I found it necessary to re-save the text input format that is using the details widget. For some reason, the open attribute of the details element doesn't get immediately added to the allowed tags for the input format. After saving (with no changes) it was added and then the option to be open by default was available.

This worked for me on Drupal 10.2.5 using CKEditor 5 and CKEditor Detail Accordion 2.1.0-alpha1 patched with the attached patch via composer.

I'm not sure every site will want the element to work this way. Could we make this configurable?

I would say that targeting the 2.1.x branch is the right idea, and an MR would be preferred over a patch. Thanks for all the work so far!

On the question of making the behaviour configurable, I did find this in a Drupal slack thread, from Wim Leers:

So now instead, each CKE5 plugin must have its own configuration. This configuration must be exposed in a buildConfigurationForm() method in the CKEditor 5 plugin on the Drupal side. And the getDynamicPluginConfig() method can then map the Drupal-side configuration to the corresponding CKE5 JS-side configuration.
For example: \Drupal\ckeditor5\Plugin\CKEditor5Plugin\ListPlugin::getDynamicPluginConfig()

  public function getDynamicPluginConfig(array $static_plugin_config, EditorInterface $editor): array {
    $static_plugin_config['list']['properties'] = array_merge(
      $static_plugin_config['list']['properties'],
      $this->getConfiguration()
    );
    return $static_plugin_config;
  }

@mandclu making this configurable makes sense. I will work on that.

Seems this branch needs a rebase.
The patch and the diff form the MR are not applying anymore.

I updated the patch to be able to apply for the 2.1.0-beta1 module version.