🇺🇸United States @mediabounds

I think this got moved to the wrong project--the problem didn't manifest itself in the Milvus VDB Provider (for the exact reason you stated).

The problem manifested itself when extending AiVdbProviderClientBase for another provider. The base class was attempting to call a method directly on the client which, in my case, didn't have a deleteFromCollection method.

(This may be a non-issue in the 2.x branch--I'm still working from 1.2.x.)

https://git.drupalcode.org/project/entity_normalization/-/merge_requests/4 seems to work well (MR5 seems to be against an older version of the code).

A Drupal 11-compatible release has now (finally) been pushed up!

Yep! 🐛 Backwards compatibility is inadvertently discarding $options Active

mediabounds → changed the visibility of the branch 6.0.x to hidden.

mediabounds → created an issue.

Thank you! This was included with ✨ Support Drupal 11 and simpleoauth 6.x Active which has been merged and included in a 3.0.0 release.

Thank you! A new 3.x release has been created with these changes.

The change in 6.1.2 to be backwards compatible is inadvertently discarding any $options provided as the third argument to the constructor.

If the MigrateExecutable constructor is invoked with the old method signature (three arguments with the third as an array), the value passed to $keyValue will not be copied over to $options and will be lost.

When an array is provided as the third argument, the code is checking whether $options is already set:

if (!isset($options)) {
  $options = $keyValue;
}

But this is problematic because $options defaults to an empty array so it will always be set. $keyValue is updated to be the KeyValueFactoryInterface and the options array passed to the constructor is lost.

mediabounds → created an issue.

If the goal is to get Drupal to cache the response, then I think the entire changeset is necessary.

If the goal is to only make the response theoretically cacheable, then I am willing to revert the changes related to $is_daylight_saving_time and open a separate issue to address the PHP notice.

Fair enough--thank you!

Would there be any interest to this module to override the Filter HTML plugin to allow for the style attribute?

Thinking out loud--it seems like the plugin definition for the filter_html plugin could be altered to override the FilterHtml class so that the process implementation retained the style attribute. (It could also do some basic filter to avoid url() in the inlined style.)

Certainly that's not as secure as just removing the style attribute altogether...but maybe the trade off would be worth it for some folks.

The removal of the style attribute seems pretty core to the Xss filter used by the Filter HTML plugin. But I couldn't find documentation on the module page either stating an incompatibility with the Filter HTML plugin or suggesting a required configuration. So I'm hoping I'm missing something.

mediabounds → created an issue.

Thanks!
I've written a draft CR for this change:
https://www.drupal.org/node/3522784 →

mediabounds → changed the visibility of the branch 8.x-4.x to hidden.

mediabounds → changed the visibility of the branch 3518018-cached-certificates-are to hidden.

mediabounds → created an issue. See original summary → .

I'm not familiar enough with the contribution process to know if I should write a draft of the change record before sending this back to "Needs Review" or if responding to the MR comment is enough and the "Needs change record" tag needs added.

This patch no longer applies on 4.3.4, but it appears like the issue may have been resolved with 🐛 4.2.6 loses checkboxes on some views. Active .

Since the response of this controller is based on the path arguments, then the only cache context needed is route.

Additionally, I needed to add logic to set $is_daylight_saving_time to -1 if it was not specified in the route parameters. Otherwise, NULL was passed to timezone_name_from_abbr which generated a PHP notice and impacted the cachebility of the response (due to a message being added to the messenger service).

I'm going to take a look today during DrupalCon Atlanta's contribution day.

I am still periodically running into this problem on Group 2.x when the group relationship for the deleted entity is already in the in-memory cache. Attaching a patch with the same approach as #13 for Group 2.x.

mediabounds → changed the visibility of the branch mobile_app_links-3324654-3324654-add-support-for to hidden.

mediabounds → changed the visibility of the branch 3324654-shared-credentials to hidden.

mediabounds → changed the visibility of the branch 3324654-add-shared-credentials to hidden.

mediabounds → changed the visibility of the branch 2.0.x to hidden.

The patch in #14 works for me.

Previous comments requested being able to use path arguments as tokens if a custom redirect path is specified, but that is already possible (though not obvious).

For example, if you had a redirect path of /users/%uid/submissions/export and wanted to redirect to /user/%uid/export-complete, you could specify the following in Custom redirect path:
/users/[current-page:url:args:value:1]/export-complete

FWIW, I was torn whether to submit a patch to devel or to page manager on this. Devel needs to be able to generate routes and makes a mostly reasonable, albeit broad, assumption about the format of the edit link template. This works in most cases...unless an entity type changes their edit link template to have additional route parameters like how page manager UI does.

So either devel has to have page manager specific code or page manager needs devel specific code to resolve this. Since page manager UI is altering the convention used by most entities for an edit link template, it seemed reasonable to have it also fix the devel route, if devel was present.

In Devel 5.1.x, Devel wouldn't try to alter the entity info due to how Page manager has a custom link template for editing the Page entity.

Devel 5.2.x changes that logic to always generate a Devel link template for the devel-load route. The route parameters in the custom edit link for the Page entity do not align with what Devel expects which ultimately is what causes this exception.

The attached patch updates the page_manager_ui module to alter the link template used by devel-load (if Devel is present).

@AaronBauman -- absolutely, though I think it would be recommended to update to 4.3.2 of this module which has this issue addressed.

That being said, attached is the backported patch to apply to 4.3.1.

In addition to applying the patch, you will need to update the version of solarium to 6.3.5 (while the patch updates the referenced version in composer.json, you probably still need to do the update manually).

Also for good measure, you may need to go through your exported config and disable buildOnCommit.

Here's a patch doing what I propose of reinitializing the ViewsBulkOperationsViewData service before rendering the form. This mitigates the problem we're seeing.

mediabounds → created an issue.

I believe the fix is as simple as casting the group number to an int. Patch attached.

mediabounds → created an issue.

If we're talking about the same issue--the lack of a base table on a relationship is not a bug. It is the expected behavior of some relationship types in Views. The Trash module needs a change like the patch in #4 to handle scenarios when the relationship has no base table.

This patch updates the access check in MessageUiContextualLinkEditMessage.

mediabounds → created an issue.

mediabounds → created an issue.

I followed up in the issue on Simple Oauth module 💬 [PP-1] Revoke refresh tokens Needs work to just let them know of the existence of this module.

Thanks for letting us know about that issue--I don't think I would have ever stumbled across it on accident!

We don't have plans to add a session logout as that's not directly part of the RFC 7009 spec. Though we did just release an update to the module to better conform to that spec.

If it's helpful to others, we recently updated the Simple OAuth Revoke → module which just adds the /oauth/revoke route as outlined by the RFC 7009.

(Note: The patch in this issue also adds an /oauth/logout endpoint; that's not part of the RFC 7009 spec so it's not in the Simple OAuth Revoke module.)

Hi, Ali3A,

We just released version 2.0.0 of the module which improves conformance with RFC 7009. We've also updated the project description to provide some better guidance of how to get started with the module.

To more directly answer your question:
This module only provides the /oauth/revoke endpoint for revoking tokens previous provided by the Simple Oauth module. Requests to this endpoint must be authenticated. As of the latest release (2.0.0), there are three ways you can authentication:
1. The client_id and client_secret being provided via Basic authentication in the Authorization header.
2. The client_id and client_secret being provided in the body of the POST request.
3. A valid access token provided in the Authorization header.

Thanks!

I encountered this issue and determined it's caused by a view using a relationship that has no base table; the taxonomy_index_tid_depth view argument from core is a good example.

Best I can tell, in this scenario, we should just skip over that relationship since the module wouldn't know how to alter the query for it anyway.

The attached patch avoids attempting to alter relationship queries if they have no base table.

Thanks, mkalkbrenner!

I "backported" the patch so it applied to the current release of the module 4.3.1, updated Solarium, and disabled buildOnCommit in our index configuration. Cron appears to be working and there are no Solr errors in watchdog; it appears like the suggester is correctly getting rebuilt during cron if content changed since the last cron run.

This should be resolved with the changes in 🐛 Register Form throws TypeError error if email or name fails constraint check Fixed .

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

Yes, we do use suggester.

In our Search API server settings, we currently have the timeouts configured as follows:
- Query timeout: 5 seconds
- Index timeout: 10 seconds
- Optimize timeout: 10 seconds
- Finalize timeout: 30 seconds

As of 4.3.0, the addition of the suggest.buildAll query during cron is using the Query timeout. I would have to increase that to over 130 seconds to avoid an error during cron...but I don't want all queries to be given that long of a timeout, so that's a no-go.

buildOnCommit seems to be working fine in that I'm not seeing errors in the log and the suggester index seems to get updated.

Nevermind--while preparing a patch, I realized this was caused by an outdated patch from 🐛 Twig\Error\RuntimeError: The callable passed to the "filter" filter must be a Closure in sandbox mode. Needs review .

mediabounds → created an issue.

mediabounds → created an issue.

The patch in #7 is a re-rolled version of the patch from #2 so that it applies to 4.x.

It appears like it contains the changes in #3 because 🐛 Using multiple auth providers results in all auth data being wiped for a user [simplesamlphp_auth] Fixed has been fixed in release 4.0.0 of the module.

I believe patch #2 is still correct if you have version 8.x-3.3 of this module.
Patch #7 is what you'd need if you have version 4.0.0.

Re-rolled the patch for 4.x version of the module.

Attaching a patch to fallback to FileSystemInterface::realpath if a file URI has no scheme.

mediabounds → created an issue.

The attach patch will always remove rows from the ID mapping but will only call rollback on the destination if the row had a destination; this is consistent with how core works during rollback.

mediabounds → created an issue.

We're also encountering this issue essentially with same the steps as in #5 (although for us it as with nodes).

I'm attaching a slightly different version of the patch in #6.

When processing the entity IDs, if it encounters one that doesn't exist, it just skips over it. This seems (to me) to be consistent with how Drupal core works on entity reference fields.

mediabounds → created an issue.

mediabounds → created an issue.

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

This appears to be caused because the callback function in the JS library is expecting to receive an HTMLInputElement as its first parameter, but is instead receiving a jQuery object. Attaching a patch so the change handler on the scheme dropdown passes an HTMLInputElement.

Patch in #2 resolved the issue for me!

I re-created the merge request based on the latest state of the 2.0.x branch.

Attaching a patch of the suggested change from the description.

I encountered this issue while using the simple_oauth module on a Drupal site that had requests routed through fast-proxy. A recent release of fast-proxy (https://github.com/fastify/fast-proxy/releases/tag/v1.8.0) removes instances where there are 2+ subsequent slashes in the URL--regardless of where they happen in the URL. The callback URL used by OAuth2 during authentication was getting a slash removed by the proxy. By encoding the query parameters, the issue was mitigated.