Remove the automatic cron run from the installer

MR is green, but the previous run had 5+ random fails, and the JS one I can reproduce locally (sometimes), but also on 11.x I get that error there.

Still, that's a lot of bad luck, wondering if the removed cron somehow increaess the chance of those random fails.

I have been seeing multiple random fails on many core MRs recently, up to four jobs failing but that pass on retry, so not sure this is any worse.

This also fixes 🐛 Theme hooks not found warning on Umami install Active

I tested this against 3491780 which is why I found this old issue.

The issue there is that during install we don't load all theme hooks, but this is an issue during cron because items are rendered.

I think @longwave's comment has been addressed, feel free to put it back in needs work if you think it needs more discussion.

This looks really good. I had assumed Drupal CMS included automated_cron but it looks like it doesn't, opened 📌 Add automated_cron to base recipe Active .

I think it would be good to manually test (unless we have exact test coverage) that installing umami or standard via the UI and cli, and then visiting the site, and then getting to admin/reports as quickly as possible via the admin menu, doesn't result in warnings on the status report that would be solved by running cron. It should not be possible, but it would be good to confirm.

Did some manual testing, with the UI installer, rushing through the configure page as quickly as I can.

On standard, it works well, I when I click on reports => status as quick as I can tells me that cron did run 8-10s ago and update status is there. Also no message on admin/config. Based on the timing of 8-10s, I suspect that cron already runs during the installer?

Umami is a bit slower because it has quite a bit it needs to index. I don't see a message on admin/config but the status report then is a bit confused. Cron is reported as having run also some 10s ago, but update module reports that it has no data. waiting a bit and refreshing then shows data. Maybe cron runs before update.module is enabled? I first thought that maybe the timestamp is set before the cron actually runs, but that doesn't seem to be the case.

It's only a warning and only on the status page and you have to be fairly quick to get there, I feel like that's an acceptable tradeoff?

Based on the timing of 8-10s, I suspect that cron already runs during the installer?

I have a feeling it would run on the install_configure_form step since we have Drupal fully installed at that point, but haven't verified this.

FWIW, I would not be surprised if automatic cron took some time to run, after it gets installed. In other words, I think it would be fine if it did nothing at install time. Its OK that module information would be unavailable for a bit.

I have a feeling it would run on the install_configure_form step since we have Drupal fully installed at that point, but haven't verified this.

I checked this and we don't because we are relying on the terminate event and that is not called during the installer. It's only called by index.php and not be the request handling in install_drupal() ... so we only hit automated cron on the redirect to the frontpage from the installer. Which oddly feels good considering the update module is enabled on install_configure_form submission and we don't have an email address yet - as user 1 is configured there too.

OK yes that seems ideal actually and probably consistent with @berdir's 8 seconds - it would include the entire request + browser rendering of the front page which is likely to be at least a second with caches being built etc. + some human clicking time to get to the reports page, plus the loading time of that page.

That covers the manual testing I think.

No wait we should fix the message in CronForm, not sure the test is really necessary but the grammar fix would be good..

We already have test coverage of the form, and it explicitly checks that we don't show 'years' on the page for when cron has never run, so it needs to be adapted anyway.

I have been running the installer repeatedly lately, making side-by-side recordings comparing Drupal 11.1 and Drupal 11.2, and I noticed a lot of time was spent on Cron.

So I was glad to find this issue, since the patch gets the Standard install down to around 5 seconds -- a big improvement, slicing even more time off, Drupal 11.1's 15 seconds and Drupal 11.2's 10 seconds.

Don't run Cron during install

Tentatively tagging for release highlights.

I think this is ready now, I think @berdir answered @alexpott's concern.

I was a little unsure about 33-34, but I think @catch was saying the text change was correct and I agree.

Just to confirm 33-34 I think that's all OK now yeah.

Saving issue credit

Committed 32a1337 and pushed to 11.x. Thanks!

Looks like it needs follow-up as help is not shown after install