Contrib.social

Add a non blocking batch runner

Open on Drupal.org →
Created on 11 July 2024, about 2 months ago
Updated 23 July 2024, about 2 months ago

Problem/Motivation

When a batch is submitted, the batch runner completely takes over the user interface, preventing any other operations. An example of this is when you install Umami via the installer UI, and the config translation sync runs after submitting the site information form, taking an extra 15-30 seconds to get the site installed.

Instead, if we have the information required already, we could add a batch runner to the site information form page itself, then config translations would download while you're filling out the form. It might still need to block submitting the form until this completes, but it would probably be done by the time you get to the end anyway.

Steps to reproduce

Proposed resolution

This needs concepts and capabilities which currently don't exist in the batch API, we'll need to decide whether we try to extend the existing API or make this part of an overall task to replace it.

The user-facing part is a batch runner element, which can display a progress bar, and fires off AJAX requests to a batch callback (possibly system.batch_page.json, possibly a new one), which can be used to run a batch instead of having to redirect to /batch and then redirect away from it again or using _batch_page() directly as the installer does.

The js supporting this batch element might need to prevent link clicking and form submits, or maybe we can do a similar thing to the status messages system, and continue the batch AJAX running on the next page if there is a batch in $_SESSION. This would allow batch operations to be completely non-blocking and complete in the background (still with a progress status shown to the user).

It would also be useful if it was possible to tell the batch runner to run a queue API queue down to zero - this might let us move some long running tasks into queues - then sometimes you might want a progress bar to run the queue down fast, and sometimes you might want to let cron handle it, but without having to do two or more implementations. Most things which are re-entrant and possible to trigger again from the UI could move to queues then. This could be implemented as a generic batch that takes a queue name probably.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

✨ Feature request
Status

Active

Version

11.0 🔥

Component
Batch  →

Last updated 17 days ago

Created by

🇬🇧United Kingdom catch

Live updates comments and jobs are added and updated live.
  • Needs product manager review

    It is used to alert the product manager core committer(s) that an issue represents a significant new feature, UI change, or change to the "user experience" of Drupal, and their signoff is needed. If an issue significantly affects the usability of Drupal, use Needs usability review instead (see the governance policy draft for more information).

Sign in to follow issues

Comments & Activities

  • Issue created by @catch
  • Comment about 2 months ago →
    🇬🇧United Kingdom catch
  • Comment about 2 months ago →
    🇭🇺Hungary Gábor Hojtsy Hungary

    IMHO this sounds fantastic. For its use in the installer, but also in other cases, I think its important that it actually runs through, which is what may be hard to ensure. I guess you can already leave the page when a batch is running but now that it would be less evidently running, people may leave the page even more. That said, it would be fantastic if we would not block the user doing something just because we also need Drupal to do a lot of things in the background.

  • Comment about 2 months ago →
    🇬🇧United Kingdom catch

    I guess you can already leave the page when a batch is running but now that it would be less evidently running, people may leave the page even more. That said, it would be fantastic if we would not block the user doing something just because we also need Drupal to do a lot of things in the background.

    Yes this is going to be one of the harder pieces. We can probably cover a lot if we keep track in the user's session that they started a batch (probably the batch ID), check the session on every page request to see if we need to show the batch element, and then the element resumes where it left off if there's a batch still running. Then finishing a batch needs to clear $_SESSION['active_batches'] or similar.

contrib.social Blog FAQ Discussions
Production build 0.71.5 2024