Allow profiles to define a base/parent profile [continue of #1356276]

Not sure why the Custom Commands Failed on the 9.5.x branch.

"subsubprofile" is failing cspell. If it's super important to be worded that way I would add to the dictionary file

Also the D10 patch looks like it failed to apply.

Drupal 9.5.3 was released.
https://www.drupal.org/project/drupal/releases/9.5.3 →

📌 CSpell dictionary is out of sync Fixed
🐛 File dictionary.txt is not sorted Fixed

It would be really great if the issue summary was updated to say that this issue is about maintaining the patch for those that need it but that for the many many reasons explained by @nedjo above and by others on the original issue it will never be a part of core. In fact if you starting a build from scratch today using this patch would not be a good choice because you would be taking on the maintenance and tech debt burden of this issue.

@joseph.olstad thank you. Great additions to the issue summary.

@alexpott, thanks for your great work on core and for the recipes initiative, very ambitious and looking forward to it!

Meanwhile, it would be nice to fix the cspell issue, subsubprofile I believe this should be added to the cspell dictionary because it makes a lot of sense for this patch and should be accepted as a proper terminology unless we go with grandsonprofile which could work also or grandSonProfile or grand_son_profile, not sure if the camelcase or snake case is needed/desired in this case. I'd like to see the tests pass on this for 10.0.0 at least so that we can begin our D10 upgrade with confidence.

I tried re-rolling the patch for Drupal 10. But yes this will need more work for the above said comments.

Try to fix CCF #104

#104 has no interdiff yet is 20 kilobytes smaller than #95
#105 has a massive interdiff, 8 kilobytes smaller than #95, no justification/explanation.

Refer to #95 as a baseline.

@joseph.olstad, I can confirm infact that:
#105 isn't a valid patch if applied on Drupal 10.0.3
#104 doen't work (I have a profile which has Standard as parent and any element of Standard Profile seems to be installed)

Re-rolled the most recent 9.5.x patch after this week's 9.5.4 release. Running the code check locally, I'm still seeing the CSpell `Unknown word (subsubprofile)` failure.

Ran into this on Drupal 9. Guessing it is likely that 10.0.x has a similar problem. If no one has a chance to get to it sooner, I'll try to loop back for the Drupal 10 reroll as well.

Here is 10.0.x reroll

In working with the patch from #108 I found that while the patch applies cleanly but the base/parent profile functionality doesn't seem to be working correctly. I'm seeing errors during install similar to what I would see if the patch wasn't applied.

As a result, I went back to the next oldest 9.5.x patch. I'm attaching a re-roll of that patch. I've also tested install with this patch and am not experiencing the same issues. As a result, I've marked the files from #108 to not display.

Also, thanks for the 10.x patch @nicoschi - I plan on testing that soon.

hiding 104/105

@Rajab Natshah please be careful when dealing with patches, not only you introduced unnecessary path header with your personal info , but also you started it based on an outdated patch , which means that the progress between 1356276-688-9-4-x---3266057-95 is lost . This is not acceptable . You need be describe changes you introducing better and start your re-roll from the most recent good patch, which in this case was #78.

@brianperry , thank you for #110, but next time please name the patch accordingly - it should have 9.5.x in it to be clearly visible that it not targeting latest development version. Something like 3266057-110-9.5.patch .

Thanks, Kirill, for the important notice.
Noted; and taken.

It feels that we are working in two tracks.
I agree with you that it is better to have one perfect track.
To continue with your track then.

describe changes for #95

Re-rolled my latest patch from #1356276: Allow profiles to define a base/parent profile →
From comment #866 → in #1356276 →
for Drupal 9.5.x

interdiff--1356276-688-9-4-x---3266057-95-9-5-x.txt →

Working to detach using the sub profile method, in fever of Drupal Recipes → .

Following with#distributions-and-recipes

Re-roll of #88 on the latest 10.1.x branch (3cc755c1) . No interdiff as no changes was introduced except manual merge conflict resolution in the ModulesUninstallForm.php file - grouped the changes from this issue together to simplify future updates.

Hi Joseph,

I believe you got the test case there wrong - we can't uninstall profiles, but can uninstall their dependencies. Fixed in this patch.

@RoSk0, thanks :)

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

This does not mean that the patch needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

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

Rerolled #117 to 10.2.x

Rerolled #120 to 11.x and replaced deprecated function assertObjectHasAttribute.

I tried out the patch in #120. It applies cleanly on the released version of 10.2, but from my experience it seems like there might be a regression in the re-rolled patch. When installing using a profile that has this base/parent relationship, not all of the dependencies from the parent are being installed.

If I have a chance to dig deeper into this I'll follow up here. But wanted to post a comment in case anyone else runs into something similar.

@brianperry, the changes made in the interdiff look incorrect to me, I'd start by redoing the changes related to the interdiff to make it as similar as possible to patch 117.

https://www.drupal.org/files/issues/2023-11-30/interdiff-117-to-120.txt →

I want to depart from this madness completely since I'm on 10.2.2, and there appears to be no patch and also appears it will never be incorporated in core, so I'd rather not deal with the headache of having to keep track of this patch anymore. I have a profile that has the setting of "base profile" set to "standard". How can I go about changing the current custom profile to NOT inherit the base profile? Can I just remove the "base profile" entry and it's good, it will default to inheriting the standard profile modules/themes/etc? Or do I need to go and put those in manually?

This page, https://www.drupal.org/node/1127786#s-details → shows the modules for the standard profile but it looks like it was for Drupal 7 and I can't find any information anywhere else as what dependencies are in the standard profile now.

Any progress on the fix for #122?

I also would love to drop dependency on this patch as @jsweetack has said. I inherited a site that has this patch and I have no idea why it needs it in the first place.

Since we are 6 months since #120 and 10.3 is in RC, am I correct to assume that the only real way forward is to migrate to a new Drupal install without this dependency?

PK2

Nitesh Sethia → made their first commit to this issue’s fork.

Nitesh Sethia → changed the visibility of the branch 3266057-allow-profiles-to to hidden.

Nitesh Sethia → changed the visibility of the branch 3266057-allow-profiles-to to active.

Rerolled #121 to 10.3.x

Same as comment #122. Patch applies cleanly for Drupal 10.2.6

But the issue persists.

Just for kicks I tried upgrading to Drupal 10.3.1 and applying patch from #129. The issue persists but the error I'm getting is with less unmet dependencies as before.

Anyone know how to fix this?

Patch from #129 applies on 10.3.1

But getting warning while I navigate to Add Content:
Warning: Undefined property: Drupal\Core\Extension\Extension::$ancestors in Drupal\Core\Extension\ProfileExtensionList->getAncestors()

Added the below fix on top of the patch and generated a new one.

diff --git a/core/lib/Drupal/Core/Extension/ProfileExtensionList.php b/core/lib/Drupal/Core/Extension/ProfileExtensionList.php
index cbaae106d3..a211365966 100644
--- a/core/lib/Drupal/Core/Extension/ProfileExtensionList.php
+++ b/core/lib/Drupal/Core/Extension/ProfileExtensionList.php
@@ -62,8 +62,10 @@ public function getAncestors($profile = NULL) {
 
     $extension = $this->get($profile);
 
-    foreach ($extension->ancestors as $ancestor) {
-      $ancestors[$ancestor] = $this->get($ancestor);
+    if (!empty($extension->ancestors)) {
+      foreach ($extension->ancestors as $ancestor) {
+        $ancestors[$ancestor] = $this->get($ancestor);
+      }
     }
     $ancestors[$profile] = $extension;

We were able to fix this by moving the config Yaml files in the child profile that were throwing the error to the /config/optional directory.

Just thought to mention this if anybody faces a similar issue.

Do we have patch for 10.3.5 ?

Patch for 10.3.9

Rerolled for 10.4.4

Fix embarrassing copy pasta mistake with last patch.

Is there a realistic chance that this will somehow make it into the core?

No. The issue's description was updated to reflect that...

This issue is about maintaining the profiles patch for those that need it *but* that for many reasons explained by nedjo below and others in the parent issue profiles defining a base parent profile will never be a part of core. Click to find out more about the Recipes, Starter Kits, Distributions strategic initiative,

Distributions are dead. I say this with a certain amount of authority after creating one of the first distribution projects on Drupal.org (2009), announcing Distributions at DrupalCon SF (2010), managing the Packaging Allow List for many years (August 2011-2023), starting the process to #3277250: Distribution packaging sunset in November 2022 → .

Distributions are dead. Long live Install Profiles (and Recipes)!

Use explicit nullable type to prevent deprecation errors with PHP 8.4