Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
General settings should be plugins, as there can be more settings which would need implementation later, like nodejs.
Currently it is hardcoaded in the general settings form.
Issue #2692781 Should be merged before this ticket for the test to pass.
Comment | File | Size | Author |
---|---|---|---|
#6 | settings_as_plugin-2708789-6.patch | 37.66 KB | abhishek-anand |
#2 | settings_as_plugin-2708789-1.patch | 41.89 KB | abhishek-anand |
Comments
Comment #2
abhishek-anand CreditAttribution: abhishek-anand at Acquia commentedComment #4
abhishek-anand CreditAttribution: abhishek-anand at Acquia commentedThe test will pass only after https://www.drupal.org/node/2692781 is merged.
Comment #5
abhishek-anand CreditAttribution: abhishek-anand at Acquia commentedComment #6
abhishek-anand CreditAttribution: abhishek-anand at Acquia commentedComment #8
abhishek-anand CreditAttribution: abhishek-anand at Acquia commentedComment #9
abhishek-anand CreditAttribution: abhishek-anand at Acquia commentedComment #10
abhishek-anand CreditAttribution: abhishek-anand at Acquia commentedComment #11
BerdirI did not port those settings plugins more or less on purpose.
As far as I see, it adds a ton of complexity and a huge amount of functions and methods to forward many hooks to our plugin classes. That seems over-engineered to me, that code can just implement those hooks.
this hook doesn't exist anymore, as mentioned in the other issue, queue processing happens in \Drupal\ultimate_cron\UltimateCron::run(). If we need more than that, then we should just implement it there.
This hook also doesn't exist anymore.
What this basically seems to do is expose each queue implementation as a cron job, so you can customize how often they are called.
That sounds useful. I think that's what the other queue task should do. Some notes on that:
* to get queue plugins, we need $this->queueManager->getDefinitions()
* Discovery and definition of cron jobs is currently in \Drupal\ultimate_cron\CronJobDiscovery::discoverCronJobs(), we could implement the queue logic there.
* We need to extend the cron job entity somehow to be able to call a queue. I'm not exactly sure yet how, we currently only have a callback. We could support arguments for that callback and pass in the ID of the queue plugin.
I suppose that's what this code is doing. This would then live.. somewhere, possibly on its own service, see \Drupal\Core\Cron::processQueues() for the current core implementation.
Comment #12
Berdir#2704543: Implement cron queue processing did a lot of this now, see issue summary there. The remaining parts are currently not a high priority, so lets wait until someone has a use case for this.
Comment #13
Berdir#2728873: Ensure that cron jobs can have services as callbacks, refactor queue worker to one on the other hand would be a nice issue to have someone working on :)