🇬🇧United Kingdom @very_random_man

I've come across this problem too. The patch works well but the #states in the form don't work as intended. The problem is that the checked state that exists to automatically check the box when there isn't a URL value also forces the box to being unchecked when a value is filled in. So whilst it works the first time you fill out the form, when you save it the box becomes unchecked even though there is a default value for it.

I don't think it's possible to get #states to check a box under one condition and do nothing for the opposite condition. The only thing I could find online about this was this guy who was trying (and failing) to get the same sort of behaviour.
https://drupal.stackexchange.com/questions/87209/with-states-how-to-unch...

I think this probably needs a bit of custom JS rather than #states to handle the checked behaviour.

Just here to say that I was getting this issue on Drupal 10.2.4 and the workaround in #14 still does the job. Thanks!

Ok. I've added the code to explicitly state that access checks aren't required for the entity count report queries.

very_random_man → created an issue.

This was working well. I've extended it further so that you are only presented with options that are in use by the currently enabled purger plugins. So for example, I'm only using the CloudFront Purger and now I just get Everything, Path and Path wildcard.

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

The patch in #19 is working well for me. Thanks!

That's what that loop / switch statement does.

It is iterating over the filter parameters for the combined facet (e.g. trees) and the first case is replacing the incorrect value with a correct value (e.g. trees:lion with animals:lion). My memories of the second case are a bit hazy but looks like it's removing values that are active but not for the combined facet (e.g. animals:lion when we're dealing with the trees facet).

To give a bit more context to my snippet, i only had two single option facets which i'd combined into one so it was perfectly fine for me to directly reference them. If you are dealing with a variable list of things (e.g. a taxonomy, content types, etc) you'd need to wrap that switch in an additional loop to provide the facet values to check against.

Although I can't say if this approach is valid for the current versions. I see there has been a new major version since I'd created this workaround. Maybe that does things differently?

Hi. Sorry, I've not worked on the project that I used this fix for for a while so I can't really say if it still applies to a more recent version or not. This fix definitely worked for v2.0.2 but that's about all I can say.

The gist of the fix was to examine the list of filters and ensure that the correct facet ID was applied to each parameter instead of the active facet getting applied to all parameters.

e.g. to change it from something like...
trees:lion, trees:dog, trees:maple, trees:oak
to
animals:lion, animals:dog, trees:maple, trees:oak

Patch in #73 works well for D10.2.

very_random_man → created an issue.

very_random_man → changed the visibility of the branch 3336312-23 to hidden.

very_random_man → changed the visibility of the branch 3336312-typeerror-cannot-access to hidden.

Nice one, thanks! That definitely does the job. :-)

Apologies for the terse response. :-)

I'm not sure it's specific to the config. I get the error when just trying to edit the config split entity at /admin/config/development/configuration/config-split/[ id ]/edit

I'm using Config Split 1.9.0 on Drupal 10.2.1.

This is the complete backtrace:

Error: Call to a member function bundle() on null in Drupal\conditional_fields\ConditionalFieldsElementAlterHelper->afterBuild() (line 64 of modules/contrib/conditional_fields/src/ConditionalFieldsElementAlterHelper.php).
conditional_fields_element_after_build(Array, Object)
call_user_func_array('conditional_fields_element_after_build', Array) (Line: 1084)
Drupal\Core\Form\FormBuilder->doBuildForm('config_split_edit_form', Array, Object) (Line: 1076)
Drupal\Core\Form\FormBuilder->doBuildForm('config_split_edit_form', Array, Object) (Line: 1076)
Drupal\Core\Form\FormBuilder->doBuildForm('config_split_edit_form', Array, Object) (Line: 1076)
Drupal\Core\Form\FormBuilder->doBuildForm('config_split_edit_form', Array, Object) (Line: 579)
Drupal\Core\Form\FormBuilder->processForm('config_split_edit_form', Array, Object) (Line: 325)
Drupal\Core\Form\FormBuilder->buildForm(Object, Object) (Line: 73)
Drupal\Core\Controller\FormController->getContentResult(Object, Object) (Line: 39)
Drupal\layout_builder\Controller\LayoutBuilderHtmlEntityFormController->getContentResult(Object, Object)
call_user_func_array(Array, Array) (Line: 123)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 627)
Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object) (Line: 124)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext(Array, Array) (Line: 97)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 181)
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: 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)

Having now had a look in the code, it looks like the `findInlineEntityFormParentsForElement` method is getting confused and incorrectly identifying a checkbox element instead of an inline_entity_form on the basis that it is called 'inline_entity_form'. I would assume that this is because the config split form has a checkboxes for each module.

I think the solution would be to check to see if the parent IEF form is actually a form and not a form element as part of `findInlineEntityFormParentsForElement`, rather than just assuming that is only IEF forms are called 'inline_entity_form'.

This patch in #89 causes the following error when trying to use Config Split to edit a config split setting.

Error: Call to a member function bundle() on null in Drupal\conditional_fields\ConditionalFieldsElementAlterHelper->afterBuild() (line 64 of modules/contrib/conditional_fields/src/ConditionalFieldsElementAlterHelper.php).

Removing the patch allows it to work.

very_random_man → created an issue.

+1 for patch in #19. Thanks guys!

Oh, my bad. Turns out it's related to the MR here: https://www.drupal.org/project/views_ical/issues/3301302 🐛 An infinite rule must have a date or count limit Needs review

I'll fix it there. :-)

very_random_man → created an issue.

I found that i could either use the date_recur formatter or the addtocal formatter. Rather than try to combine them I created a two fields, one of which was hidden from all forms and populated from the other. Then I could use both in the entity display, one as a the formatted date and the other as a dedicated AddToCal button.

The only problem i had was that only the original date was used in the calendar event and the repeating dates were ignored. On further inspection it looks like repeating dates aren't supported by the underlying library (https://github.com/spatie/calendar-links/issues/188).

I used the following code to use the next occurrence date for the calendar event.

/**
 * Implements hook_addtocal_links_alter().
 */
function MODULENAME_addtocal_links_alter(array &$links, array $context) {

  $now = new DateTime();
  $next_occurrence = NULL;

  /** @var \Drupal\date_recur\DateRange $occurrence */
  foreach ($context['items'][0]->occurrences as $occurrence) {
    $next_occurrence = $occurrence;
    if ($occurrence->getStart() > $now) {
      break;
    }
  }

  if ($next_occurrence) {
    $old_addtocal_link = clone $links['#addtocal_link'];

    $links['#addtocal_link'] = \Spatie\CalendarLinks\Link::create($old_addtocal_link->title, $next_occurrence->getStart(), $next_occurrence->getEnd());
    $links['#addtocal_link']->address($old_addtocal_link->address);
    $links['#addtocal_link']->description($old_addtocal_link->description);
  }
}

Seems a bit clunky but it does the job.

+1 to say this MR worked for me on 3.0.0-beta1.

I came across this recently whilst upgrading a site from D8 (using v1 of this module) to D10 (using v2). The solution for me, as I'm doing automated releases, was to disable on the D9 intermediate release and upgrade / re-enable on the subsequent D10 release.

I should also point out that this didn't seem to be a problem until I upgraded to Drupal 10.

very_random_man → created an issue.

I've seen this just now. The issue for me seemed to be with the Help module, which seems a bit random.

The Help module was killing my drush deploy on 'Update aborted by: help_post_update_add_permissions_to_roles' which i believe was related to an 'Adding non-existent permissions to a role is not allowed' issue. I removed the roles and disabled the help module and it seemed to do the trick. I then just enabled directly Help and got this error instead when browsing the site:

Error: Call to a member function access() on null in Drupal\block\BlockAccessControlHandler->checkAccess() (line 124 of /home/deploy/deploy/xxx/xxx_build_2068/web/core/modules/block/src/BlockAccessControlHandler.php).

Again, disabling Help module fixes it.

None of this seems to be an issue on my local so I'm inclined to think it's something peculiar on my dev environment.

Yep, worked for me too. Thanks!

I had a bit of a play around to see better what is happening. If you investigate big_pipe.js there is a processReplacement function which is the bit that extracts the JSON and creates that AJAX commands to perform the replacement.

When it fails it is because this fails to get any text content:

content = replacement.textContent.trim();

Based on the issue mentioned in #33 and debugging, I wonder if there is a problem with the mutation observer change..

I've just run into this problem after upgrading from D9 to D10.2. I get the same sort of results as #41 where the big pipe placeholder span is where the blocks should be. Doesn't seem to matter if i clear the cache or not.

I'm seeing it mostly with Facet blocks on a search_api views page but there are other, less obvious unrendered placeholders on the page. Certain facets seem to come and go as I keep hitting refresh. No errors in browser console or watchdog. Just silently failing to replace the placeholders.

Interestingly, there are script tags at the bottom of the page that appear to have the correct ajax commands to replace the placeholders with block markup.

<script type="application/vnd.drupal-ajax" data-big-pipe-replacement-for-placeholder-with-id="callback=Drupal%5Cblock%5CBlockViewBuilder%3A%3AlazyBuilder&amp;args%5B0%5D=groupname&amp;args%5B1%5D=full&amp;args%5B2%5D&amp;token=PMm7HXc3h6xwp7fdT2QeK23AgPgG_mZIph3vrx5pDhQ">
... AJAX commands JSON .. 
<script>

Is it possible there is a race condition where the first thing rendered is invalidating subsequent tokens somewhere along the line?

I can also confirm that patch fixes the issue. :-)

So based on my last comment, I dug a bit deeper and noticed that the parent NumericFilter class didn't use the correct identifier for group filters. I've created an MR which checks if a filter is a group and uses the relevant identifier.

I suspect there might be other issues relating to this that aren't covered by this MR as that class makes a number of references to what would presumably be the wrong identifier elsewhere. I didn't make any sweeping changes though and kept the MR purely about the bug in this issue. If this is the correct solution to this issue it might be worth moving the code to get the identifier into a separate method and applying that in various places.

As alluded to in #13, these patches are along the wrong lines and mask the actual problem. There is a section in NumericFilter.php which is supposed to put the value into the correct array format.

    // rewrite the input value so that it's in the correct format so that
    // the parent gets the right data.
    if (!empty($this->options['expose']['identifier'])) {
      $value = &$input[$this->options['expose']['identifier']];
      if (!is_array($value)) {
        $value = [
          'value' => $value,
        ];
      }
    }

However, that is failing because the value in the options only contains the default field identifier rather than any other value which might be overriding it from the filter identifier box. I would say the bug is down to whatever is populating $this->options['expose']['identifier'] for grouped exposed filters.

I've created an MR for this. My use case is that I've opened up Layout Builder to certain Group roles. These have no equivalent in the site-wide roles so enabled this module removes all access to them. By enabling the authenticated role, it provides default restrictions which are useable by group users.

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

I had created a separate issue about a typo causing /node/xxx/latest to always be blocked but realised this seemed to be the place to raise it.

https://www.drupal.org/project/gcontent_moderation/issues/3393691 🐛 Typo in LatestRevisionCheck blocks Latest Version route Closed: duplicate

I've made a commit to the MR that fixes the typo.

I'm closing this and moving to the Group 3 issue.

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

On further investigation, that seems to have been introduced when using the fork in the Group 3 version. https://www.drupal.org/project/gcontent_moderation/issues/3381073 📌 Make compatible with Group 3.x Active .

very_random_man → created an issue.

Can confirm that patch works. Thanks!

very_random_man → created an issue.

Can confirm this fix works although it was line 408 for me.

Hi. I've noticed that this patch is actually causing an error if you have focal_point module installed without the migrate module. It looks like it ought to check if the module is enabled perhaps in the event subscriber.

PHP Fatal error:  Uncaught Error: Class "Drupal\migrate\Event\MigrateEvents" not found in web/modules/contrib/focal_point/src/EventSubscriber/MigrationSubscriber.php:20

Just came across this whilst looking for something else and thought i'd leave a comment in case other people find this. You can get around the requirement for nasty nested entity/paragraph doom forms by making more use of sections, custom layouts and the layout options and layout builder restrictions modules.

So for example...

- Create a card block.
- Set up a custom layout for the Card Group section and some layout options (see examples below) so you can add a title and a summary. I used a custom options setting which was pretty simple so i could use stuff like rich text fields.
- You then use Layout Builder Restrictions to restrict usage of the Card block so it can only be placed in a Card Group section.

I find this significantly simpler from a dev and UX perspective and better than the typical 'all blocks in one column with extra helpings of massive nested forms in a small column' approach. :-)

THEME.layouts.yml

card_group:
  class: '\Drupal\layout_options\Plugin\Layout\LayoutOptions'
  label: 'Card group'
  category: 'Whatever'
  path: templates/layouts
  template: layout--card-group
  default_region: main
  icon_map:
    - [ card-a, card-b, card-c ]
    - [ card-d, card-e, card-f ]
    - [ card-g, card-h, card-i ]
  regions:
    main:
      label: Card content

THEME.layout_options.yml

layout_option_definitions:
  card_variant:
    title: Card variant
    description: The card variant applied to all cards in this section.
    plugin: layout_options_class_select
    multi: false
    default: default
    options:
      default: Default
      button: Button
      small: Small
    layout: true
    regions: false
    weight: 1

  section_heading:
    title: Section heading
    description: An optional heading added to the top of the section.
    plugin: MODULE_layout_options_setting_textfield
    default: ''
    layout: true
    regions: false
    weight: -50

  section_summary:
    title: Section summary
    description: An optional summary for the section.
    plugin: MODULE_layout_options_setting_formatted_text
    default: ''
    layout: true
    regions: false
    weight: -40

layout_options:

  card_group:
    section_heading: {}
    section_summary: {}
    card_variant: {}

It was missing for me anywhere i used a single image upload field rather than a media item field. Definitely users and content. I'm pretty sure it was on blocks too. I've downgraded now so I can't check again just at the moment.

This is working for me with media fields but I've just noticed standard image fields are still missing for me when RC3 is installed.

I noticed one of the guys above had a workaround to rename and reinstall the module. In my case i didn't create the module-name.module file until after I'd been using my module for a while. I wonder if that is connected? I seem to remember it wouldn't register the module file until I did a drush cr rather than an admin toolbar Flush All Caches. Maybe there's a clue in that?

I've just run into this issue too on Drupal 9.5.9. I created a custom entity module with drush generate and later added hook_theme and template_preprocess.

If I use drush cr, everything works as expected. If I use 'Flush all caches' in the admin menu, the module's theme entry is missing from the theme registry. My temporary (and very hacky) workaround is to detect if it's missing from the registry in hook_theme_registry_alter and then put it back. Not ideal but needs must. ;-)

I'm experiencing this issue. It looks like disabling 'Allow each content item to have its layout customized.' doesn't remove the dependency on 'field.field.node.CONTENT_TYPE.layout_builder__layout'. If I disable Layout Builder at the same time and then re-enable just that, without the customisation option, the dependency is removed on export.

very_random_man → created an issue.

very_random_man → created an issue.

Yes I'm thinking this might be handy too. At the moment gin_lb is presenting issues with consistency. The main use case is where there are users who do page editing but don't use the admin theme for anything. For example, you may have site admins / editors using the admin theme for both content and general tasks but group editors only editing content and layouts in the front end theme. Gin LB adds loads of improvements that enhance the group editors' experience but the more 'Ginny' bits don't make sense to them.

Another kind of inconsistency is the media browser. It looks great on layout builder pages but none of the benefits are available on other media elements, like node edit forms. This requires a certain amount of effort to figure out how gin_lb is working and how to activate it on non-LB forms.

As mentioned above, the next example I'm dealing with is Toastify. Currently I have toastified messaging on only LB pages and nothing on the rest of the front end. I think it would be a good idea to remove it entirely and maybe just recommend using this module: https://www.drupal.org/project/toastify → which would apply it across the theme by the looks of things. I'll raise this as separate ticket.

Maybe this module needs a broader remit to provide ginnyness to front-end themes as a whole? I'd love to apply some of the normal Gin node editing functionality to the front-end theme, such as having the form actions pinned to the top.

#9 Works for me with images and remote videos.

I just came across this behaviour as I'm using a responsive image style with multiple breakpoints, combining with a number of Focal Point image styles. With the focal point you basically can't use just CSS cropping for anything other than polish unless you go the route of a js focal point library.

I found changing showHideAnimationType to 'fade' (which should look fine with mismatched aspect ratios) with hook_photoswipe_js_options_alter made no difference and the module appears to implement its own zoom function regardless of options, although I didn't dig too far with that.

Anyway in case anyone has a similar problem, the workaround for me was to set the fallback image style on the responsive image to one that was about the same size as the smallest responsive breakpoint focal point style. The fallback style just needed to crop but also preserved the original aspect ratio. No focal point.

The result is that all the focal point image styles are applied in the
tags and are the ones used on the page and the fallback img src is the thumb used when it opens up. :-)

I can confirm this is working for me too.

I was getting this error as the Views preview was attempting to render nodes where a pattern was applied in the content type field display settings but that pattern was defined in the front-end theme.

In case anyone comes across this like I did, looking for a way to to use entity_generate with entity_reference_revisions, here's how you can do it just with some process magic. In the example below I have a phone field from a D7 field source (field_contact_phone) and I'm using that to generate a custom multi_field entity which has separate label and phone fields. The important part is the last bit which looks up the revision ID using an entity_value plugin.

  field_phone:
    - plugin: sub_process
      source: field_contact_phone
      process:
        _linklabel: linklabel
        target_id:
          plugin: entity_generate
          source: phonenumber
          entity_type: multi_field
          bundle: labelled_phone
          value_key: field_phone_number
          bundle_key: bundle
          values:
            label: '@_linklabel'
            field_phone_number/0/value: phonenumber
        _revision_id_value:
          plugin: entity_value
          source: '@target_id'
          entity_type: multi_field
          field_name: revision_id
        target_revision_id: '@_revision_id_value/0/value'

Yep, this works for me. Annoying warnings for unrelated stuff now hidden leaving me in a blissful state of ignorance. Thanks. :-)

This speeds things up dramatically for me. I think Xurizaemon is probably right in that there are still improvements to be made as I'm also seeing delays introduced into unrelated specific migrations but I don't think the prospect of further optimisations should hold this back from being merged as the improvement is huge.

I can confirm this is working for both custom group role reference fields and also on the group membership form (which the previous patch had broken). :-)

I recently came across this whilst recreating a D7 site (yay, token arguments) in D9 (booo, no token arguments). In case anyone is looking for a workaround for dynamic arguments to entity reference view displays whilst this issue gets resolved, you can specify the arguments in a form_alter like this:

  $form['field_something']['widget'][0]['target_id']['#selection_settings']['view']['arguments'][0] = $arg_thingy;

This works for me on 9.5. :-)

The patch in #9 was no longer applying so I've adapted it to work with the new additions.

Looks like some calendar apps choke if there is a COUNT and UNTIL both set in the RRULE. I've updated the MR and also included an updated patch, just in case that's handy. :-)

I've attached a patch that fixes it. I also added the correct mimetype for calendars to the Wizard render.

very_random_man → created an issue.

Actually, I think this is more likely a Field Group issue as it still happens if I remove the Conditional Fields dependencies and use various form hooks to apply #states directly.

Some more detail:
- I have field group tabs and inside one of those I have a checkboxes element and a fieldset containing text fields.
- I have used hook_form_alter to add #states to make one of the text fields required depending on a checkbox value.
- I have used hook_field_group_form_process_alter (and a tried bunch of other similar hooks) to add #states to make the fieldset visible depending on the same checkbox value as per https://www.drupal.org/project/field_group/issues/1053174#comment-14138494 💬 hook_form_alter form state problems Closed: works as designed

What happens is that when there is a #states value on the fieldset, the required state is applied to all the text fields inside it.

very_random_man → created an issue.

I think the problem here is that the row style is based on Fields instead of extending EntityRow which would include a view mode in the config and you could still do the exact same thing in the render except you'd also have the ability to use field formatting / theming. You could hook up the config form to available fields on the entity rather than the ones defined in the view.

Not sure if there's been some user error on my part but I experienced some oddness with that Merge Request where it wouldn't merge. I think I resolved that by updating the issue fork so it would merge cleanly but then the MR patch wouldn't apply. Anyway, I've attached a patch file that does apply in case that helps. :-)

Hey guys. I've fixed this issue so that infinite date_recur fields don't cause an error and I've implemented RRULES. Seems to work for me now. Could you confirm if it's ok with you?

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

very_random_man → created an issue.

very_random_man → created an issue.

very_random_man → created an issue.

On further reflection after having a look at what this actually does and a bit of RTFM, I think the issue is that it is getting foxed by the UTC timezone which has no Daylight Savings Time so it legitimately only has one entry in the transitions array.

very_random_man → created an issue.