🇨🇦Canada @endless_wander

wrapping new condition in ListPlugin.php with an isset() fixed my error. New patch here for 10.4

patch from 114 works for me but produces this error as well:

Warning: Undefined array key "styles" in Drupal\ckeditor5\Plugin\CKEditor5Plugin\ListPlugin->getDynamicPluginConfig() (line 99 of core/modules/ckeditor5/src/Plugin/CKEditor5Plugin/ListPlugin.php)

For anyone finding this issue here, the MR from #11 above along with patch from #3 in Layouts Paragraph issue here -- https://www.drupal.org/project/layout_paragraphs/issues/3352822#comment-... 🐛 Paragraph parent entity property is empty when adding new paragraphs Needs review -- makes `getParentEntity()` work with Layout Paragraphs as well.

Patch from #3 works for me when used with MR #11 from this Paragraphs issue -- https://www.drupal.org/project/paragraphs/issues/3255456#comment-15924468 🐛 Cannot access parent entity in hook_entity_create Needs review

Now Layout Paragraphs have `getParentEntity()` working when added new to a page.

There has been some updates on this issue from Paragraphs module. I tested the MR and patches there and they do work for regular Paragraphs field formatter, but not for Layout Paragraphs formatter -- https://www.drupal.org/project/paragraphs/issues/3255456 🐛 Cannot access parent entity in hook_entity_create Needs review

My problem comes from using Layout Paragraphs module it seems. Switching from Layout Paragraphs field formatter to default Paragraphs (stable) formatter and I can see `getParentEntity()` returning value as expected. Switching back to Layout Paragraphs formatter and `getParentEntity()` value is gone.

Adding link to the related issue in Layout Paragraphs queue 🐛 Paragraph parent entity property is empty when adding new paragraphs Needs review and will update over there as well with presence of new patches.

I encountered this issue also when trying to use a form alter to change the paragraph's form based on its parent. I could do it for existing paragraphs but not when adding new ones.

Using module 1.19 and Drupal 10.4

Tried patch from #14 and it cannot be applied.

Tried patch from #11 and it applied.

In neither case, however, could the parentEntity be loaded when adding a new paragraph.

This works great for me upgrading to Drupal 11 with this module. Would be great to get merged.

upgraded to 4.3.4 and this issue is present on my view. in my case, one view is an attachment on the same URL as a page view, above the main view. checkboxes are not visible for the attachment

Is it possible for a maintainer to take a look at this and merge?

Had new install of Views Aggregator and got this error on first attempt to create a view. In my case, some fields being aggregated were empty and returning FALSE. Using patch in MR27 worked for me.

Could another solution be updating the return type from just string to something like string|bool. Note this has to be done in getCell() as well, which fails if string is not returned.

I think you can hook into the registration form instead and add your own redirection callback. The $form_state class will have a setRedirectUrl() method you can use.

chrisla → created an issue.

This happened to me during the update but with an exposed date filter. Updated title of this issue.

Patch from #9 fixed for me.

@tednacip -- see custom code at https://www.drupal.org/project/entity_print/issues/3202847 ✨ Possibility to alter http headers when we generate PDF Postponed: needs info and not that it has to be X-Robot and not X-Robots

Would be awesome if this could be added directly to the module, but it seems like nobody is paying attention here.

this patch helped me and works in my testing

I'm going to keep this personal submodule going for myself but stop updating it here. Maintainers can pursue other solutions.

This was discussed in https://www.drupal.org/project/recurring_events/issues/3090286 ✨ Configuration options for registrant email address Active with no resolution.

I propose since email address is required for registering and triggers errors if not present, it makes sense to make it required. More functionality can be added for custom solutions where email is not required.

This was stalled but in the meantime, having no email address present causes errors when registering. See https://www.drupal.org/project/recurring_events/issues/3478268 🐛 Fatal error when registering for event without entering email Active

I think requiring email address for now is best way forward to resolve the immediate concern of existing code throwing errors. Custom solutions could modify the registration form to remove that required status.

attached patch does what I suggest. please advise if a different way of throwing the exception is recommended.

chrisla → created an issue.

chrisla → created an issue.

This old issue has been resolved I believe as I see this field is available for views now.

chrisla → created an issue.

New patch for me re-rolled against 2.0.2

New patch works against 2.0.2. Sorry can't get access to make MR right now.

@maintainers, could this get merged into 2.0 branch?

I have tested against 2.0.2 version of module and found this solved this bug of upgrading.

I would suggest future fixes like this are tested and merged into both branches perhaps, rather than just release for the 3.0 version that won't be released for a while. Could this be merged into 2.0 branch as well so a patch is not required?

Heads up this will no longer apply against latest 2.0.x branch

If anyone else lands here, I had similar issue with Bootstrap Barrio theme, where its alert/messages system doesn't play well with Webform's. I override some templates like webform-message.html.twig to get what I want -- https://www.drupal.org/project/bootstrap_barrio/issues/3497104 🐛 Webform message setting "Allow users to close the message" not respected Active

Webform outputs messages via webform-message.html.twig, which acts as a wrapper for what is output in status-messages.html.twig

Here's what I did in my subtheme to have the Bootstrap Barrio close button respect the Webform message element setting:

1) created my own webform-message.html.twig template in subtheme and changed its output, changing

{{ message }}

to:

{% include '@weaver/misc/status-messages--alerts.html.twig' with { message_list: message_list, show_close_button: show_close_button } %}

2) added hook_webform_message_preprocess() to my subtheme to pass the right message_list and the new show_close_button variable

function mytheme_preprocess_webform_message(&$variables) {
  // allows Webform alerts to respect the Webform close button settings
  // see also webform-message.html.twig and alert.twig
  $element = $variables['element'];
  $variables['message_list'] = $element['#message']['#message_list'];
  $variables['show_close_button'] = $element['#message_close'];
}

3) finally, updated alert.twig to show/hide the close button according to show_close_button

      {% if show_close_button == true %}
           // HTML for button
     {% endif %}

The Webform javascript close button still appears and I just used CSS to hide it.

This is all kinda hacky but I just wanted a quick fix for now. Perhaps some unity can be found in matching Bootstrap Barrio's alerts with how Claro and core use them.

Webform messages are using status-messages--alerts.html.twig template, which in turn uses the code in alert.twig component

Webform theming in WebformMessage::preRenderWebformMessage() adds the close button as part of the first message and not appended to each message, which is a big difference for this functionality.

Enabling the Webform-powered close button creates two close buttons, then. One added by Webform and one added by Bootstrap Barrio via alert.twig

Not sure best way to proceed as this seems a case where both Webform module and BB theme are providing the same UI but via different methods and one needs to get out of the other's way. I would prefer to preserve the BB theme to keep all templating in the same place, but still have it respect the "Allow users to close the message" option in Webform.

chrisla → created an issue.

I think this can't be done until https://www.drupal.org/project/bootstrap_barrio/issues/3496694 🐛 Discrepancies between new alert.twig component and messages.js Active is resolved because both alert.twig and messages.js are providing the content for alert messages at this time.

see https://www.drupal.org/project/bootstrap_barrio/issues/3496694 🐛 Discrepancies between new alert.twig component and messages.js Active as well.

I think this is part of a larger issue where the template for alerts has deviated and there are now two versions -- one in new alert.twig component and one loaded via messages.js

chrisla → created an issue.

chrisla → created an issue.

simple patch fix

chrisla → created an issue.

Looking into the code and when waitlisted registrants are retrieved, they are retrieved in order of entity ID, not in order of creation date. RegistrationCreationService calls $results = $this->storage->loadByProperties($properties); to get the Registrants where maybe an entityQuery with sort set to created date is more applicable. What do the maintainers think?

My proposed change would be as attached.

These patches also add the new created datetime field into the advanced area of the form

Here is a patch for 3.0.x branch in case above doesn't work

Here is a patch for 2.0.x branch that adds the functionality I need

chrisla → created an issue.

I believe there is a typo in my code from #8 -- should be "X-Robots-Tag" and not "X-Robot-Tag"

This is still happening for me and appears to be happening on a high-profile Drupal site as well london.gov.uk

https://www.google.com/search?q=site%3Alondon.gov.uk%2Fprint&rlz=1C1GCEA...

Any ideas for preventing this?

chrisla → created an issue.

This is only happening with my theme, so false alert. May be an issue with parent theme and not this module.

I also had date_popup module enabled, but uninstalling it does not change the behaviour.

chrisla → created an issue.

If I enable "Make filter options collapsible" then the behaviour you describe is what happens, so I think this is working by default.

E.g., set a filter to "Make filter options collapsible" in the filter UI of the view. Save the view.

Go to the view on the site and see that the filter is collapsed.

Expand the filter and set a value. Submit the filter form.

See that the filter is expanded with the filter value visible.

Do you expect something different? Perhaps your description of your issue needs better explanation.

There appear to be multiple issues in Select2 issue queue:

• https://www.drupal.org/project/select2/issues/3482698 🐛 Select2 Plugin is not compatible with BEF plugin Active
• https://www.drupal.org/project/select2/issues/3450644 ✨ BEF 7.0 compatible RTBC
• https://www.drupal.org/project/select2/issues/3474793 🐛 Declaration of Select2::defaultConfiguration() must be compatible with FilterWidgetBase::defaultConfiguration() Active

I wonder if updates to BEF module should be tested against Select 2 module compatibility if it is very common to use the combination of the two.

The MR/patch proposed in https://www.drupal.org/project/select2/issues/3482698 🐛 Select2 Plugin is not compatible with BEF plugin Active changes code in BEF module and fixes the problem for me.

Patch in https://www.drupal.org/project/select2/issues/3482698#comment-15827078 🐛 Select2 Plugin is not compatible with BEF plugin Active fixes this issue for me in BEF 7.*

Patch in https://www.drupal.org/project/select2/issues/3482698#comment-15827078 🐛 Select2 Plugin is not compatible with BEF plugin Active fixes this issue for BEF 7.* for me

Another solution for anonymous users could be to load the register button via ajax. I've successfully used this for elements on a page that need to be outside of cache context for anonymous users.

Perfect, I have time planned at the end of the month and early November. I just wanted to make sure we were addressing D11 compatibility in 2 branch as well.

Thanks for starting this. I would like and need a D11-compatible version without any other feature changes or updates as I will be migrating our sites to D11 very soon. Other modules have been creating minor updates introducing the bare minimum for D11 compatibility. I was planning on spending some time this month to see how much this module needs for that minimum compatibility and it would be great if we could have at least one release still on the 2 branch without needing to check on updating a whole ton of stuff just for D11 compatibility.

Maybe I'm not understanding because you also say that a registration cannot be made for more than the number of spaces remaining:

"If there are not enough spaces left, the user can reserve max. the remaining spaces."

So if there were only 3 spaces left, a family of 5 could not reserve 5 spaces, only 3?

Re-reading some of the discussion above from the origins of this issue and it's really the waitlist system that is the hard call here. Another potential and complex scenario:

- a family event and multiple families of different sizes register to be on the waitlist, assuming we've modified the site to allow the waitlist to accommodate multiple registration spaces
- Family 1 is first on the waitlist with 5 people in the family. They just missed successfully registering by 1 hour when the last spots were taken, one month before the event.
- Family 2 registers on the waitlist one week before the event with 3 people
- Family 3 registers on the waitlist 2 days before the event with 2 people

Two spots open up at 9am the day before the event (we always see the highest number of cancellations the previous day or same day as an event). Family 3 immediately and automatically gets moved from the waitlist to the registration list to fill up those 2 spots.

Five minutes later, another family of 3 cancels and so Family 2 moves into those 3 spots.

No more spots open up so Family 1 never moves off the waitlist, even though technically there were 5 spots that opened up since the day they registered and they've waited the longest.

What could be a "fair" way to handle this?

- I think "Seats" is a strange term to use. Rest of the module uses "Spaces" so maybe should stick to that to keep language the same and meaningful. "Attendees" maybe for public-facing copy?

- Same thing with "If there is no room" should be "If there are no spaces"

- Regarding use of Profile module, it seems like it could be overkill if Registrants are not also users on the site. If I'm not mistaken, Profile module also requires site editors who want to edit fields to be editing the Profile entities, which for our users is a step above their skillset and permissions levels. It is hard to predict what kind of solution woudl work with such limited information about who is using the module for what purposes. It would be amazing to do some kind of survey and get this info. I would be happy to take that on.

- "Previously when creating or editing a registrant as an event manager you had the option to either put the registrant on the waitlist, or not. I added a new option to handle this automatically depending on current availability. Then the event manager doesn't need to check if there are still enough places available"
- I think this should be its own issue so that people not following this one will be aware of the change, or at least make sure this is announced very clearly if these features go into a release

- In gneeral, for me, these changes are not helpful because we would no longer be able to track information per guest. In other words, under the proposed changes, all guests will have the same name and email address as the single "main" Registrant. For our purposes, we require guests to have some different information from the "main" Registrant. For example, some of the guests will receive notifications about the event via their email address. Or some guests will receive notifications in a language different from the main Registrant.

- Another potential case that neither of our solutions solves but comes up frequently. for us... what about people who want to register a certain number of people exactly -- let's say it's a family event and family of 4 wants to register. There are 2 spots left, so the options for them are:

1) simply not to register at all -- lame for organizer because they will have no idea what real interest in event is if all groups decide not to go on a waitlist

2) register 2 spaces out of 4 now and add two more to the waitlist -- pain for the person registering to register three times and also if a spot never opens up, those 2 spaces will be wasted because the family will only go all-or-nothing. if they're nice, they'll cancel at last minute. if not, they will just no-show

3) ideal but most complicated -- family is able to register 4 spaces and the two available ones are reserved with an asterisk in the system saying the Registrant actually wants 4 spots -- if a spot is emptied and they were first on the list, family's 3rd member is added... if another spot empties, then 4th is added. if not enough new spots empty, then perhaps X amount of time before event, organizer can choose to either add spots for this family or cancel their 2 spots to let next 2 individuals on the waitlist into the event instead... anyway, it quickly gets complex but this is a real situation faced by our client where the choice to register as a group is all-or-nothing. Right now, they don't have an accurate way to guage interest in the events

Yeah, thank you for taking a look. We have been using this custom feature for a while now.

For our purposes, we do not allow guests for every event so we could make sure number of seats is maximum 1 per registrant unless guests are allowed. I think originally we thought we would make guests an "inferior" type of registrant with settings to do things like allow only the "main" registrant to receive email notifications or have certain registration questions appear for the "main" registrant and not for the guests. In practice, our clients haven't done any of that yet.

I still would like to reserve the ability to collect information for each guest rather than have all the information under one Registrant. Perhaps this is also related to the use of different Registrant types to collect different information.

Maybe there would be some weirdness for the waiting list if single Registrants took up multiple Registrant slots?

Thanks for these ideas. It's an interesting way to grow to use the Registrant entity in more ways for the module. Either here or in https://www.drupal.org/project/recurring_events/issues/3477247 ✨ Add new registrant type through the UI Active , would you be able to include some use cases for Registrant types and how the increased visibility and prominence of the Registrant entities could be infused into the existing registration process?

It would be really awesome if anyone from the community of module users could share how they are using Registrant types as well, if they are.

For our site, we have a group of event programmers that would not be able to edit entity fields and manage that aspect of a site. We have a wide variety of events and many one-off custom events that require their own fields for each registrant. As an example, some events let a parent register and enter the number of children and their names in another custom field. Some other events have fields so that registrants can note their prior experience with a subject. And some other events ask for languages spoken.

Right now, we use a system by adding all of the fields to a single Registrant type (a site admin does this step) and then allowing event programmers to choose from a list of possible fields when creating their events. So site admin creates a "What is your age" field for the Registrant entity and this becomes an option in a checklist when event programmers are creating a new Event Series. The choices in this checklist control what fields end up appearing to the registrants when registering.

It's not an ideal system because we have about 15 fields where only 1 or 2 are used per event. However, I'm not sure if I would like to have a new Registrant type for each configuration of fields either as we would maybe end up with 10+ Registrant types.

In my dreams, the registration forms could work via Webform module and save registrant info as Webform submissions rather than fields on an entity. Creating and editing webforms is much easier for my client's users to grok and the Webform interface also provides a ton of useful options such as conditional fields, a wider variety of fields and the ability to craft a layout for the form. I would be curious to know what other solutions people might envision. Perhaps this is the right time to think about how handling registration forms could be improved in general? Or some kind of Webform integration could be an alternative if someone had the time to work on it.

Please let me know what you think and what your overall vision is for the use of Registrants in the module.

Amazing... really excited to help make this module grow and become even more awesome.

I agree with all you said and really happy to see the work you're doing. For our sites, as an example, we had some important features that broke when a recent update to the module changed the registration service to no longer be aware of the current event series and instance by default. We had to roll back and stay at a previous version and change our custom code to work with the new version of the module. I mean this only as an example of how some backend updates can still have an impact on the site. In this case, I believe the change would still pass all tests, but still have an impact on how sites were using the module. So I would advocate for more than just unit testing but human testing by as many participating sites as possible (which I guess is ideal for any module). But maybe we can get a bit more community input before moving big changes into the main releases?

My North American clients much prefer 12-hour time with am/pm option. I know, it's weird, but so many North Americans just get super confused by 24-hour time. Can we have both as options please?

I just want to thank pfrenssen for working on the module. It's very appreciated. I am trying to find some time to contribute to testing updates more often.

For me, because this module is very central to my clients' websites, I would just like to make sure all changes are thoroughly tested before getting merged. If any changes involve major departures from current functionality, perhaps we can always make sure that these changes are optional and require site admins to opt in rather than being enabled immediately?

I'm not able to test the changes. Adding to my site temporarily using generated patch with 2.0.1 module installed. Do your changes here require some of the changes in your other issues?

My own preference is that it would be nicer to have all the possible registration email settings on the main Registrant Settings page at /admin/structure/events/registrant/settings so that they are all visible and editable in a single place. Easier to compare them and update multiple ones at the same time.

@pfrenssen could you post a description or screenshots of what this change does?

@pfrenssen is the bug caused by change in https://www.drupal.org/project/recurring_events/issues/3452632 🐛 Registration creation service leaks data Fixed do you think?

Attaching a patch that merges all changes from this issue and solves the problem of the RegistrationCreationService no longer providing event data for the guests.

Note that this updates the reported issue and also an issue that would be caused for the registrant contact form submit function as well. The RegistrationCreationService was used there as well to get event data.

Suggested changes in a merge request. First time merger here so let me know please if I did something incorrectly.

chrisla → created an issue.

Inside Registrant::getCacheTagsToInvalidate(), $this->getEventInstance() is always returning NULL for me.

getCacheTagsToInvalidate() is called via invalidateTagsOnSave(), which happens in entity's postSave() method. During postSave() I can see $this->getEventInstance() does return the expected value.

At some point EntityBase::getCacheTags() is called, which also calls getCacheTagsToInvalidate(). If getCacheTags() is commented out, the error is no longer triggered. This seems to be the problem point.

If I provide the eventinstance and eventseries directly to either getCacheTags() or getCacheTagsToInvalidate(), then the error is not triggered. For now, this patch stops the error from occurring, but this seems like a weird, unnecessary fix and badly coded so this is just a stopgap solution for me to keep working.

This error does not happen without custom Guests submodule enabled so I believe this is related to https://www.drupal.org/project/recurring_events/issues/3257502#comment-1... ✨ Allow registrations to be for multiple people -- e.g., adding guests or "plus one" Needs review which was caused by the registration creation service no longer sharing the event details by default -- https://www.drupal.org/project/recurring_events/issues/3452632 🐛 Registration creation service leaks data Fixed

I am experiencing this error when registering for an event instance:

Error: Call to a member function getCacheTagsToInvalidate() on null in Drupal\recurring_events_registration\Entity\Registrant->getCacheTagsToInvalidate() (line 397 of modules/contrib/recurring_events/modules/recurring_events_registration/src/Entity/Registrant.php).

This line refers to:

$this->getEventInstance()->getCacheTagsToInvalidate(),

The event instance is not being found. Checking getEventInstance() and see it is just return $this->get('eventinstance_id')->entity; which means that the eventinstance_id must not be getting set for the registrant.

Steps to reproduce bug from#23:
- update to Recurring Events 2.0.2
- create an event with Registration enabled and Number of Guests set to > 0
- register for an event instance for the new event and add guests
- on add registrant page is where error occurs -- e.g., /events/EVENTINSTANCEID/registrations/add

Warning: Attempt to read property "recurring_events_guests_per_registrant" on null in Drupal\recurring_events_guests\Service\GuestService->getGuestsPerRegistrant() (line 111 of modules/contrib/recurring_events/modules/recurring_events_registration/modules/recurring_events_guests/src/Service/GuestService.php).

CKEditor maintainer responded that they will not add this feature and checkboxes can only be added in "disabled" state

@carolpettirossi I will take a look soon as I will need to upgrade as well.

I have created an issue with CKEditor. An easier way to check that CKEditor is creating disabled checkboxes by default is to go to their full feature example at https://ckeditor.com/docs/ckeditor5/latest/examples/builds-custom/full-f... and check the source when adding a to-do list.

@dolszewski I'm not sure what demo page you are referring to

Understood. On the example page for the CKEditor plugin, the checkboxes do not insert as disabled however: https://ckeditor.com/docs/ckeditor5/latest/features/lists/todo-lists.html

MR from #5 works for me. Thank you very much for adding that. The solution feels a bit strange still. What is the use-case for adding disabled checkboxes to a page? I wonder if having the checkboxes be enabled shouldn't be the default? What would be amazing is if the checkbox button within CKEditor had its own option for disabling the checkbox so that both options are available for all users directly from the editor.

Tested on my Drupal 10.2.7 local site and the reported console error goes away.

I used this functionality successfull to add headers for my use case of wanting X-Robot-Tag added to every PDF generated by the module.

Here is an example

added to module services.yml:

my_custom.events:
    class: Drupal\my_custom\EventSubscriber\MyEventSubscriber
    tags:
      - { name: event_subscriber }

Then in the modules/custom/my_custom/src/EventSubscriber/MyEventSubscriber.php:

namespace Drupal\my_custom\EventSubscriber;

use Drupal\entity_print\Event\PrintEvents;
use Symfony\Component\EventDispatcher\EventSubscriberInterface;
use Symfony\Component\EventDispatcher\GenericEvent;

/**
 * Add custom headers.
 */
class MyEventSubscriber implements EventSubscriberInterface {

  public static function getSubscribedEvents() {
    $events[PrintEvents::CONFIGURATION_ALTER][] = ['onEntityPrintConfigurationAlter'];
    return $events;
  }

  /**
   * React to an event fired when retrieving a Print engine configuration.
   *
   * @param \Symfony\Component\EventDispatcher\GenericEvent $event
   *   Generic event containing the print engine configuration.
   */
  public function onEntityPrintConfigurationAlter(GenericEvent $event) {
    $configuration = $event->getArgument('configuration');
    $configuration['headers']['X-Robot-Tag'] = 'noindex,nofollow,noarchive';
    $event->setArgument('configuration', $configuration);
  }
}

This was enough for me to have the headers appear on every PDF.

endless_wander → created an issue.

endless_wander → created an issue.

It would be nice to specify in the instructions that the command is for a 256-bit key, especially since 128-bit is the default setting when creating a key

endless_wander → created an issue.

When configuring a text_format using patch from #80, I was getting this error:

Warning: Undefined array key "styles" in Drupal\ckeditor5\Plugin\CKEditor5Plugin\ListPlugin->buildConfigurationForm() (line 61 of core/modules/ckeditor5/src/Plugin/CKEditor5Plugin/ListPlugin.php).

Same as in #91, this is fixed by adding an isset()

New patch added with this fix

New patch based on #80 with isset() added to stop error warning.

Patch from 80 ✨ [upstream] Use CKEditor 5's native and UX Needs work is working for me in the editor and saving content, but produces an error message on editing page where CKEditor appears:

Warning: Undefined array key "styles" in Drupal\ckeditor5\Plugin\CKEditor5Plugin\ListPlugin->getDynamicPluginConfig() (line 99 of core/modules/ckeditor5/src/Plugin/CKEditor5Plugin/ListPlugin.php).
Drupal\ckeditor5\Plugin\CKEditor5Plugin\ListPlugin->getDynamicPluginConfig(Array, Object) (Line: 316)
Drupal\ckeditor5\Plugin\CKEditor5PluginManager->getCKEditor5PluginConfig(Object) (Line: 934)
Drupal\ckeditor5\Plugin\Editor\CKEditor5->getJSSettings(Object) (Line: 81)
Drupal\editor\Plugin\EditorManager->getAttachments(Array) (Line: 100)
Drupal\editor\Element->preRenderTextFormat(Array)
call_user_func_array(Array, Array) (Line: 111)
Drupal\Core\Render\Renderer->doTrustedCallback(Array, Array, 'Render #pre_render callbacks must be methods of a class that implements \Drupal\Core\Security\TrustedCallbackInterface or be an anonymous function. The callback was %s. See https://www.drupal.org/node/2966725', 'exception', 'Drupal\Core\Render\Element\RenderCallbackInterface') (Line: 859)
Drupal\Core\Render\Renderer->doCallback('#pre_render', 'element.editor:preRenderTextFormat', Array) (Line: 421)
Drupal\Core\Render\Renderer->doRender(Array, ) (Line: 240)
Drupal\Core\Render\Renderer->render(Array) (Line: 475)
Drupal\Core\Template\TwigExtension->escapeFilter(Object, Array, 'html', NULL, 1) (Line: 89)
__TwigTemplate_ab337cfa89a1457340e8d67a133a7335->doDisplay(Array, Array) (Line: 394)
Twig\Template->displayWithErrorHandling(Array, Array) (Line: 367)
Twig\Template->display(Array) (Line: 379)
Twig\Template->render(Array) (Line: 38)
Twig\TemplateWrapper->render(Array) (Line: 39)
twig_render_template('core/themes/claro/templates/form/field-multiple-value-form.html.twig', Array) (Line: 348)
Drupal\Core\Theme\ThemeManager->render('field_multiple_value_form', Array) (Line: 480)
Drupal\Core\Render\Renderer->doRender(Array) (Line: 493)
Drupal\Core\Render\Renderer->doRender(Array) (Line: 493)
Drupal\Core\Render\Renderer->doRender(Array, ) (Line: 240)
Drupal\Core\Render\Renderer->render(Array) (Line: 475)
Drupal\Core\Template\TwigExtension->escapeFilter(Object, Array, 'html', NULL, 1) (Line: 44)
__TwigTemplate_815234656e4a4de144202255a926142d->doDisplay(Array, Array) (Line: 394)
Twig\Template->displayWithErrorHandling(Array, Array) (Line: 367)
Twig\Template->display(Array) (Line: 379)
Twig\Template->render(Array) (Line: 38)
Twig\TemplateWrapper->render(Array) (Line: 39)
twig_render_template('core/themes/claro/templates/node-edit-form.html.twig', Array) (Line: 348)
Drupal\Core\Theme\ThemeManager->render('node_edit_form', Array) (Line: 480)
Drupal\Core\Render\Renderer->doRender(Array, ) (Line: 240)
Drupal\Core\Render\Renderer->render(Array, ) (Line: 238)
Drupal\Core\Render\MainContent\HtmlRenderer->Drupal\Core\Render\MainContent\{closure}() (Line: 627)
Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object) (Line: 239)
Drupal\Core\Render\MainContent\HtmlRenderer->prepare(Array, Object, Object) (Line: 128)
Drupal\Core\Render\MainContent\HtmlRenderer->renderResponse(Array, Object, Object) (Line: 90)
Drupal\Core\EventSubscriber\MainContentViewSubscriber->onViewRenderArray(Object, 'kernel.view', Object)
call_user_func(Array, Object, 'kernel.view', Object) (Line: 111)
Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher->dispatch(Object, 'kernel.view') (Line: 186)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 76)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1) (Line: 58)
Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1) (Line: 48)
Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object, 1, 1) (Line: 28)
Drupal\Core\StackMiddleware\ContentLength->handle(Object, 1, 1) (Line: 32)
Drupal\big_pipe\StackMiddleware\ContentLength->handle(Object, 1, 1) (Line: 106)
Drupal\page_cache\StackMiddleware\PageCache->pass(Object, 1, 1) (Line: 85)
Drupal\page_cache\StackMiddleware\PageCache->handle(Object, 1, 1) (Line: 48)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1) (Line: 51)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1) (Line: 36)
Drupal\Core\StackMiddleware\AjaxPageState->handle(Object, 1, 1) (Line: 51)
Drupal\Core\StackMiddleware\StackedHttpKernel->handle(Object, 1, 1) (Line: 704)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)

endless_wander → created an issue.

What camslice describes in #54 happened to me and my client as well. about 30 days of data is gone after the update was made

Thank you for this cool group of plugins. I was encountering a similar issue using just a single instance of CKEditor in combination with the Layout Paragraphs module.

When adding a Paragraph via the Layout Paragraphs interface, CKEditor would not load. Console log gave same error as OP TypeError: null is not an object (evaluating 'this.wordCountWrapper.appendChild')

Using merge request from #10 solves my issue as well.

Patch #25 did not work for me using Layout Paragraphs where a field within a Paragraph has Select 2 enabled for form display.

Patch from #17 works in this scenario for me.

@webberly I tried this out with a regular node using the Conditional Fields module

I set an image field on a custom node content type. I added a checkbox field called "Show Image" to the content type. I used Conditional Fields to set the image field as a dependency on Show Image being checked.

On a normal node creation page, when I check the Show Image field, the image field appears. When unchecked, the image field disappears.

In an inline form, my image field appears no matter whether the Show Image field is checked or unchecked.

This is the same behaviour as with Recurring Events conditional fields. It seems like the problem is with the Inline Entity module not respecting any #states for any content ?

Confirmed. Looks like this when creating content where all the frequency options are visible, for example:

@webberly could you provide a little bit more information about how exactly to reproduce?