🇺🇸United States @lpeabody

lpeabody → created an issue.

This patch applies cleanly for me on 6.0.4.

This is still happening for me with Drush 12, and the patch doesn't apply.

@dago.aceves is correct. My local site was behind a Traefik reverse proxy. For my local site configuration I just had to set this to fix the issue:

$settings['reverse_proxy'] = TRUE;
  // Reverse proxy is handled by Docker Traefik container. Set the expected
  // addresses.
  $settings['reverse_proxy_addresses'] = [$_SERVER['REMOTE_ADDR']];
  $settings['reverse_proxy_trusted_headers'] = Request::HEADER_X_FORWARDED_FOR | Request::HEADER_X_FORWARDED_HOST | Request::HEADER_X_FORWARDED_PORT | Request::HEADER_X_FORWARDED_PROTO | Request::HEADER_FORWARDED;

This is fine for a local setup.

Hiding patch with bad paths.

lpeabody → created an issue.

+1 for this, this would be a really nice UX improvement.

Simplify title of issue per Sam152's recommendation.

@aaron.ferris yes if you have content_translation enabled and you mark the changed field as untranslatable on content entities then you can run into the scenario where it becomes impossible to ever edit the entity again without repairing the database. I opened this related issue a while back https://www.drupal.org/project/drupal/issues/3170926 → . It's a sticky problem but basically with how things are currently implemented in core, I think it should be at least posting warnings somewhere that changed should never, ever be flagged as untranslatable because at some point you will become unable to edit your content (obviously a massive issue for a CMS) due to EntityChangedConstraint.

I get an error that looks like this in my console:

Mixed Content: The page at 'https://drupal-site.traefik.site/node/23/layout' was loaded over HTTPS, but requested an insecure form action 'http://drupal-site.traefik.site/layout_builder_iframe_modal/redirect'. This request has been blocked; the content must be served over HTTPS.

Looks like it shouldn't be setting an absolute URL, or else risk protocol mismatch when folks are behind a reverse proxy that routes to http? Use a relative URL for the form action is perhaps a resolution?

As an FYI this error is resolved in the case of the Geofield Map module in version 3.0.15 https://git.drupalcode.org/project/geofield_map/-/compare/3.0.14...3.0.1...

This is one of those things where it would be nice for Drupal core maintainers to come up with JS contracts similar to the way they have developed Interface contracts for swappable Symfony services and public data members and functions.

We ran into a similar issue where we are dependent on Facets checkbox list selections to determine state of a form element on the page. The state logic lives on the form element, so every time Facets re-creates its blocks via AJAX we need to rerun the States API behaviors on the form element. This stopped working after the previously mentioned Core update to the States API.

Before

1. Page loads.
2. Form button is default disabled (becomes enabled if one of three Facets checkbox list blocks contains any checked elements).
3. Facets blocks initially loaded with list of links (Facets later transforms these to checkboxes in custom JavaScript https://git.drupalcode.org/project/facets/-/blob/2.0.x/js/checkbox-widge...).
4. Facet behavior checkbox JS runs and converts links into checkboxes for each checkbox widget block on page. Part off this behavior invokes Drupal.attachBehaviors for each instance of the converted Facet block, passing the Facets checkbox list block as the context, along with Drupal.settings.
5. In our custom JS, we have a behavior whose attach function looks at the context and determines if it was a facet checkbox list, and if it is then it re-runs Drupal.attachBehaviors() to ensure that the States API re-applies state information on the form element who has these checkbox value depenencies.

Workaround to account for new once usage in States API

Our workaround was to remove the added once attribute on the pertinent form element, which might be how this needs to be handled going forward.

1. Page loads.
2. Form button is default disabled (becomes enabled if one of three Facets checkbox list blocks contains any checked elements).
3. Facets blocks initially loaded with list of links (Facets later transforms these to checkboxes in custom JavaScript https://git.drupalcode.org/project/facets/-/blob/2.0.x/js/checkbox-widge...).
4. Facet behavior checkbox JS runs and converts links into checkboxes for each checkbox widget block on page. Part off this behavior invokes Drupal.attachBehaviors for each instance of the converted Facet block, passing the Facets checkbox list block as the context, along with Drupal.settings.
5. In our custom JS, we have a behavior whose attach function looks at the context and determines if it was a facet checkbox list, and if it is then it first removes the data-once value that was added to the form element, then it re-runs Drupal.attachBehaviors() to ensure that the States API re-applies state information on the form element who has these checkbox value dependencies.

I couldn't find a better, documented way to handle this situation. I feel at the very least the bugfix issue ( https://www.drupal.org/project/drupal/issues/3347144 🐛 Form API #states property/states should use .once() to apply its rules (Can cause failures with BigPipe and possibly other situations) Needs work ) could use a change record to indicate what changed and why it changed, and perhaps also document workarounds to account for the changes given the use-cases presented in this issue.

Is the issue list in the summary still representative of what it would take to get this module stable?

Wouldn't only Onomasticon being replaced be the expected functionality if you configured the filter to only replace the first encountered instance of the glossary term, regardless of capitalization? The word means the same thing, regardless of casing. I opened another issue that describes this as a bug.

lpeabody → created an issue.

I think this is two separate issues:

• AJAX support
• All results support

I propose re-purposing this issue for the AJAX support and spinning off another issues for All support.

Bump for review from maintainers.

I think MR11 is actually ready for review now. In a nutshell, it:

1. Checks the install hook to see if a sync operation is happening, and if it is then it does not bother with modifying configuration (since it is expected this will be taken care of when configuration synchronizes, after modules have been installed).
2. Adds configuration dependencies to the derived action plugins, including dependencies on the related digest interval and email flag.
3. Adds an update hook which re-saves all previously installed action configuration entities, which will ensure that dependencies are recalculated for each.

With that in place if someone updates the module and then subsequently exports configuration, the exported action config entities which were previously causing a problem will have their dependencies updated and exported correctly. When installing from config again, the added dependencies will result in the action entities being synchronized in an order that will not generate any errors (because the dependencies have already been synchronized and generated the plugin that the action is dependent on).

Yes, but not like you've described, because the only valid dependency types are config, module, content, and theme. Since profile is not in that list, it is not valid configuration. If you're using profile module, and my_profile is a profile type, you likely want something like:

dependencies:
  enforced:
    config:
      - profile.type.my_profile

The additional errors are coming from when the configuration sync process kicks in (after modules are installed) system action configuration is being synchronized but the plugin the action references does not have a definition as yet. So, really the only solution to this is making sure the definition exists before the sync process attempts to add the action configuration. I'm not sure at this point what it would take to ensure that.

lpeabody → created an issue.

Re-opened because the patch in #17 was re-rolled against the 5.x branch and the feature request is still valid (5.x doesn't support all-day functionality for a single day).

I'm running into this, but not because I've removed a relationship, but rather the Bundle filter is trying to access relationship information before I've had a chance to tell it what relationship to use through the UI. This happens because the Bundle filter invokes ::getEntityType in the init function, which fires as soon as you add the filter and before you're prompted with the configuration screen, which is where you would typically specify the relationship.

Below is my hook_views_data implementation. I'm just exposing a simple table called user_entity_visits with uid, entity_id (currently assumed to be only nodes), entity_type (again, hardcoded to node right now), and timestamp columns.

The table itself is not a base table for an entity type, it's just a tracking table which denotes the latest point in time a user has visited a node page.

function harborlife_user_tracking_views_data() {
  $data = [];
  $data['user_entity_visits'] = [];
  $data['user_entity_visits']['table'] = [
    'group' => t('User Tracking'),
    'provider' => 'harborlife_user_tracking',
  ];
  $data['user_entity_visits']['table']['join']['node_field_data'] = [
    'left_field' => 'nid',
    'field' => 'entity_id',
  ];
  $data['user_entity_visits']['table']['join']['users_field_data'] = [
    'left_field' => 'uid',
    'field' => 'uid',
  ];
  $data['user_entity_visits']['entity_id'] = [
    'title' => t('Node ID'),
    'help' => t('Node ID visited by a user.'),

    'relationship' => [
      // Views name of the table to join to for the relationship.
      'base' => 'node_field_data',
      // Database field name in the other table to join on.
      'base field' => 'nid',
      // ID of relationship handler plugin to use.
      'id' => 'standard',
      // Default label for relationship in the UI.
      'label' => t('Visited node'),
    ],
  ];

  $data['user_entity_visits']['uid'] = [
    'title' => t('User ID'),
    'help' => t('User that visited a node.'),

    'relationship' => [
      // Views name of the table to join to for the relationship.
      'base' => 'users_field_data',
      // Database field name in the other table to join on.
      'base field' => 'uid',
      // ID of relationship handler plugin to use.
      'id' => 'standard',
      // Default label for relationship in the UI.
      'label' => t('User who visited node'),
    ],
  ];

  $data['user_entity_visits']['timestamp'] = [
    'title' => t('Timestamp'),
    'help' => t('Timestamp of when a user visited a node.'),
    'field' => [
      'id' => 'date',
      'granularity' => 'second',
    ],
    'sort' => [
      // ID of sort handler plugin to use.
      'id' => 'date',
    ],
  ];

  return $data;
}