🇺🇸United States @helianthropy

I tried a combination of enabling/disabling displaying all values in the same row per #1, removing filters per #9 and #10, splitting up the date range field by adding a separate daterange field instance to use as the end date (and the original field for the start date). It stopped showing duplicate date entries during the last test. I started undoing what I’d done but the duplicates were still gone. Adding the filter for date not empty brought back the duplicates. Removing it got rid of the duplicate. This has me suspecting some kind of caching issue if you don’t see results right away after removing all problematic filters?

pameeela → credited helianthropy → .

Helianthropy → created an issue.

Helianthropy → created an issue.

This might need to be a different issue, but I’ve tested the patch from comment #7 and it resolves the issue I had where text was not selectable by mouse pointer nor keyboard. Reporting that here as a review of the patch because it totally salvaged my use of the module.

My one argument to support it:

We have a site that supports using span tags with classes from a Styles list for custom formatting. Pasting from anywhere else litters the content with extraneous span tags (though style information can be stripped).

If support here doesn't make sense (given that this supports a feature no longer in CKEditor), a recommendation for various use cases this module handled would be nice. 🙂 And it looks like one was provided. Linking to documentation for the above mentioned CKEditor 5 General HTML Support. (Though best case would be that we could require elements have specific attributes or be rejected and it’s not clear that this GHS is capable of that level of discrimination.)

I attended.

I attended.

Preparing to take this on, here is the ambitious proposal in a series of three steps. Feedback appreciated.

Proposal:

• User Interface
  • Add checkbox on Webform Content Creator add/edit configuration form: “Automatically create entities.” (default to checked to enable existing functionality)
  • Add "Convert Submission(s)" to Operations menu
  • Add Webform submission selection page with checkboxes on each submission (indicating previously converted if field machine ID was provided), multiple select list to choose fields to display for submission identification, and “Convert to ” button.

Planned steps

Phase 1

Add menu items and links to get started with the starting points for operations. Add forms and form updates to collect needed info for processes.

Phase 2

Add checks for default process to skip automatic entity creation if not indicated. Create connection to process on-demand entity creation.

Phase 3

Add check for previously created entities for conversion form display, revise form display as needed for UX/accessibility. Add batch support. Add update script. Explore integration with Webform submissions operations menu per issue summary.

If a community provided patch were to be offered, would it be accepted into the project? And if so, is there a preferred approach to take to add this functionality? (Any hints at where to implement would be appreciated as well.)

For folks still seeing the description appear at the end of the fieldset despite setting it to "before," check your theme to determine if it’s checking for description_display. Mine wasn’t. I copied the relevant code from my theme’s base theme (stable9 at core/themes/stable9/form/fieldset.html.twig) which uses the following structure:

<div class="fieldset-wrapper">
    {% if description_display == 'before' and description.content %}
      <div{{ description.attributes.addClass('description') }}>{{ description.content }}</div>
    {% endif %}
    {% if errors %}
      <div>
        {{ errors }}
      </div>
    {% endif %}
    {% if prefix %}
      <span class="field-prefix">{{ prefix }}</span>
    {% endif %}
    {{ children }}
    {% if suffix %}
      <span class="field-suffix">{{ suffix }}</span>
    {% endif %}
    {% if description_display in ['after', 'invisible'] and description.content %}
      <div{{ description.attributes.addClass('description') }}>{{ description.content }}</div>
    {% endif %}
  </div>
</fieldset>

I’ve created a patch that resolves the issue for me. It wraps the code in a try/catch block and prints any error to the console. Built against version 7.x-1.5.

I only first noticed this on a test site hosted by Acquia that does not include search. My local site does not have Drupal.ACDB defined, and the issue isn't triggered, presumably since it’s not hosted in an Acquia environment.

Should this be testing for the existence of Drupal.ACDB before assigning a value?

@rmorelli

Looking forward to hearing about the experience. I found that if I set a fixed maximum, it creates that fixed maximum right away.

The duplication is an annoyance, but not being able to remove extra instances is a real challenge.

I’m using billboard.js via CDN and am seeing some javascript errors from it of "f is undefined." Going to try a local library to see if that makes a difference.

I’m experiencing this using Charts with the Paragraphs module on Drupal 9.5 and PHP 7.4 (will test on PHP 8.1). I’ve also noticed this behavior with Address fields (with default values set) in a Paragraphs module under Drupal 7.

Have you tried changing default values for the Charts module to see if that makes it reproducible (I’ve done so in my install—specifically perhaps chart type and definitely the colors)?