Install profile is disabled for lots of different reasons and core doesn't allow for that

The Needs Review Queue Bot → tested this issue. It either no longer applies to Drupal core, or fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

Apart from a re-roll or rebase, this issue may need more work to address feedback in the issue or MR comments. To progress an issue, incorporate this feedback as part of the process of updating the issue. This helps other contributors to know what is outstanding.

Consult the Drupal Contributor Guide → to find step-by-step guides for working with issues.

Moving to an MR and hidden all the files.

Actually hiding files.

So the failure from DrupalCI seems like it could be legit to the issue. But gitlab pipeline is all green?

Haven't heard otherwise so assuming DrupalCi still needs to pass?

Also don't think this will be backported D7 at this point.

@smustgrave I think the fail is definitely related to this issue - it's not failing locally so this is really odd.

Those are the most fun! This is the first I’ve seen passing gitlab but failing drupalci

@smustgrave FWIW it has failing on gitlab too in the same way. But the fact it fail on one and not the other is v interesting.

I've opened 🐛 Config saved during import does not have correct initial values set Needs review to fix one of the bugs this has found in the ConfigImporter.

So this is blocked on landing 🐛 Config saved during import does not have correct initial values set Needs review as that adds a test & fix for the bug found by this issue. But this issue is definitely ready for review.

Seems the blocker landed!

Change makes sense.

Only string that seemed odd.

The install profile %profile is not in the list of installed modules.

but guess that is right? But seems odd phrase.

I have some concerns wrt the use of type: ignore. 😅

Updated the issue summary to reflect the state of play. Need to write a change record too.

alexpott → credited phenaproxima → .

Thanks for the review @phenaproxima - I've tried to address everything

There's one important thing that's not yet consistent and that's making a review tricky. But … this issue seems totally within reach now! 👍😄

Bumping to given how important this is for the Recipes initiative.

See #2876001-14: Installerless Drupal → , I believe that this issue has the potential to unblock a completely new Drupal capability: trying a complete Recipe without even installing Drupal 🤯

Addressed @phenaproxima's excellent review - the spot of missing detecting if the profile supplies a theme that is being used was great.

I don't have anything to complain about here but I don't quite feel comfortable giving the RTBC, just because I'm not as familiar with the extension system as some, and I've almost certainly missed something important.

Then again, RTBCing this would be a great way to get it looked at by the Venerable Elders of Drupal Core, so I'm gonna do just that. Besides, it will be a distinct honor to be (hopefully) among the names credited when we finally close this thirteen year old issue! (Happy bar mitzvah!)

I asked for a few clarifications, and mostly confirmations that I understand it correctly. But there's also one bit that AFAICT should be validated more strictly.

Opened two follow-ups to address out-of-scope stuff spotted in the reviews:
📌 Improve core.extension:profile validation Postponed
📌 Never return NULL from DrupalKernel::getInstallProfile() Active

No complaints about the code; NW for a change record.

Oops! I opened 📌 [PP-1] Add validation constraints to core.extension Postponed with a draft MR … so I closed 📌 Improve core.extension:profile validation Postponed (I first read the MR comments).

Draft CR created: https://www.drupal.org/node/3432357 →

Attempting to sort out issue credit on this one. Apologies for an mistakes made, this one is hard.

I have credited contributions to the discussion and patches (not rerolls) that helped people. I have not credited rerolls, me toos, subscribes, X patch works.

Committed/pushed to 11.x and cherry-picked to 10.3.x, thanks!

Have to admit I had more or less given up on this ever happening, 2011 was much closer to the original 'install profiles as modules' patch landing than we are now. So really nice to be able to commit it now!

A follow up was asked for in this comment and it has been created, 📌 Use a tagged service iterator for uninstall validators instead of individual lazy proxies Needs review .

Tagging for 10.3.0 release highlights, the number of times I've had to switch a site to a different profile because the one it was installed on was umaintained is quite high, being able to just uninstall it would have been great.

Automatically closed - issue fixed for 2 weeks with no activity.