It is generally best practice to make the custom profile self-contained, so it can be used without any default/standard profiles. This will help with adoption in the BOA stack (Octopus).
It is generally best practice to make the custom profile self-contained, so it can be used without any default/standard profiles. This will help with adoption in the BOA stack (Octopus).
Comments
Comment #1
drozasThanks omega8cc,
We were not aware of this best practice, we'll keep it in mind for the next release.
Comment #2
drozasHi omega8cc,
I have been looking at the code of other installation profiles to try to implement this best practice, but I have not been able to find any. Could you provide us some example of an installation profile in which this is implemented?
Thanks a lot!
David
Comment #3
omega8cc commentedHi David,
Basically all distros we support in BOA use self-contained profiles which never depend on the default/standard profiles and even use core patches to be able to hide all standard profiles to avoid confusion during site installation. The only other installation profile I could find which used dependency on the core standard/default profile was the old Acquia D6 which included 'default' profile to be able to re-use its code/functions, which is technically incorrect and doesn't follow Drupal API.
If you will take a look at any other installation profile, you will see that they simply use all functions with profile specific prefixes to those functions without any includes.
In this cause you should simply replace:
with:
I hope this helps.
Grace
Comment #6
drozasComment #7
drozasThanks Grace!
This was actually based on code from the Patterns installation profile I looked at originally while creating this installation profile, which did not follow this best practice neither. There was no need for an install file at all, so I have just simply removed it completely.
Best,
David