Ignore previous one. This is now compatible with D10 and v1.9
This patch is now D10 compatible
Rerolling this patch to make it D10 compatible, since the eventDispatcher dispatch function arguments are different now
The jquery once is deprecated in D10 and thus, the js needs to be updated. Adding a patch for this.
I've fixed it
Any idea how to solve this?
I am reopening this since I made a mistake in my test. This is still not working and I had to resort to the patch to get the generic filter to appear
For some reason, it's not working with Drupal 9.5.11.
But let's close this since I've updated to D10 and it's working fine now.
This patch is not needed on the latest version. It has now been fixed.
I was just coming to update my issue to say that is browser cache related but you got to it before me :) Everything works as designed.
I still don't understand one thing though, why is it that on my local, the new file loads fine but for the other servers, I need a hard refresh on the file?
Adding a workaround to allow exposed filter to appear for now. But I think this needs a better fix.
Here's a workaround
Here's patch to fix this.
Actually, there is a nag. I only need this for media entities because we are gettting media files from the backend. But as for other links, they need to stay relative so that it continues work on the frontend. When I use the pathologic module, everything becomes absolute and the issue is if we have links that's supposed to work on the frontend, they stop working since they are now pointing to the backend.
I tried the Pathologic module and it does fit my use case. Thanks for showing the way :)
Added dependency injection and fixed code standards.
I am not sure if this is the best approach but adding this patch as a workaround.
Adding a temporary path to atleast allow html email to be sent out
Adding temporary patch to get the absolute url for now
Fixed typo
Fixed failing tests
Fixed phpcs and tests
Improved the patch and added dependency injection
Here's a workaround
Adding a patch to fix this on the beta5 release. It will then work as follows
query SearchContent($search_text: String, $page: ID) {
entityById(entityType: VIEW, id: "search_content") {
... on View {
executable(displayId: "default") {
... on ViewExecutableSearchContentDefault {
execute(
searchApiFulltext: $search_text
page: $page
) {
rows {
id
label
}
total_rows
}
}
}
}
}
}I've added a path to fix this.
Here's a quick fix but this is based on the assumption that integers will always be spaced out in the fields' machine names.
Adding a patch to get around this
In my case, the pdfs are generated on the file. I was thinking maybe we have some config form in the backend where we are able to add paths patterns for those urls that we still want to be accessible on the backend
I was able to get around this by implementing a hook_ENTITY_TYPE_access and checking the views access level for the user.
function mymodule_view_access(View $view, $operation, $account) {
$route_name = \Drupal::routeMatch()->getRouteName();
if ($operation === 'view' && $route_name === 'graphql.query.core_schema') {
return AccessResult::allowedIf($view->getExecutable()->access('page_1', $account));
}
return AccessResult::neutral();
}Re-rolling a patch for the 3.0 version