All remarks in the MR diff.
Great work and not far away from making this work 100%!
Yes, an alter hook invoked from __construct() with cached output should be fine. We'll need to think where to cache it though (or maybe don't cache it?)
Hmm, the situation is exactly the same with A360 Xapi activities. The only way to alter the statements would be using a proxy with an alter option but that's an additional middle step which means performance drop.
By resources you mean lessons and activities?
graber → changed the visibility of the branch 3467618-admin-group-take-access to hidden.
Closing this, looks like our override of pressButton() does the job. Wondering why the core issues went so silent but.. fixed nevertheless and the solution from here is linked there.
Merging with the new plugin.
graber → created an issue. See original summary → .
I'll add the new field plugin.
There's one unresolved comment from Joel on the MR, tiny, just a variable rename request but still.
Ok, merging this so we have one logic that controls course navigation including going back. Let's wait for more feedback on how course free navigation and lesson backwards navigation options should work exactly, for now both do what I'd expect but may be just me..
Thanks!
Answers don't have a route provider so there's nothing like answer/1 currently.
Yes, we could add a group permission but postponing this until there'll be a use case.
Ok, adding that link field requires rewriting results with a link and adding additional fields just to have user ID and group ID which will be a bit annoying and will litter the view. Maybe a separate field plugin will be nice to have after all.
I think we'll need a separate Views plugin for the results link.. On the other hand it's so simple to create such a link without any plugins in Views.. It's more about informing site builders that the results page exists, maybe it'll be enough to update the default view config by adding such field?
This issue was recently heavily affecting Drupal LMS → tests where my test plan was one long JS test to improve performance and avoid setting up multiple times and.. there are lots of buttons pressed so it's a very good example.
Here's what we came up with (thanks to @catch for finding all the issues with partial solutions that work combined with a bit of my own logic): https://git.drupalcode.org/project/lms/-/merge_requests/82/diffs#e8d889b...
That combines waiting for a change in page HTML after pressing the button and checking the document.readyState.
Hope that helps, we could implement something similar in core.
Merged, I'll keep the issue open for some time as those fails are very random and it may be we missed a place or 2.
joelpittet → credited graber → .
At the very least, I would recommend that we change the key/label of the "Default" option — neither the key (i.e.: an empty string) nor the label ("Default Behaviour") describes what it does very well.
Yes but from what I remember there may be more conditions. Should check first.
Yes, makes sense, merged.
Thanks!
graber → made their first commit to this issue’s fork.
graber → changed the visibility of the branch 3483647-automated-drupal-11 to hidden.
Setting to needs review.. this may affect theming though so not sure.
Let's try to change all addWhereExpression to addWhere and see what will be the result. Just remembered search_api Views query also doesn't have addWhereExpression.
Also updated composer.json, all pipelines green now, thanks!
Thank you both, updated the formatting a bit & merged.
graber → made their first commit to this issue’s fork.
Lowering to normal as this will not be an issue on most instances.