🇺🇸United States @mediabounds

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.