I'm no stranger to Drupal, but I have no experience with custom installation profiles.

First, are custom installation profiles supposed to be overwritten when core is updated?

I've inherited a Drupal 7 site that has a pretty complex and very custom installation profile complete with modules dir (contrib and custom) themes dir, custom libraries, etc... it looks like they tried to fit an entire drupal site structure in here. Let's say that one is called Custom1.

Another installation profile Guardr is also in the profiles directory. Guardr is actively community supported.

The Drupal documents for distributions state that only one profile can be installed at a time and cannot be combined with other profiles.

Yet the hook_install function of Custom1, the first thing it does is call !function_exists('guardr_install') ? require_once 'profiles/guardr/guardr.install : FALSE; call_user_func('guardr_install');

That doesn't feel right given what I've come to understand about installation profiles. Moreover, in the /Profiles/Custom1/modules/contrib directory, there has to be 100 of the most popular contrib modules here, like addressfield, ctools.... (and sites/all/modules/contrib is empty) I can understand a profile requiring a certain set of modules, but isn't that the job of the dependencies[] array in the profile.info file?

In any case, my understanding is that an installation profile is called at the very beginning of the installation process and once it's finished, it's a 'typical' Drupal site that I can manage, update, etc, from that point on.

Now when I call drush up the profiles directory is overwritten and only standard and minimal profiles are there. This completely breaks the site because 90% of the functionality is tied to the modules, libraries, themes, and other files in both the Custom1 and Guardr profiles directories.

It's either the case that this is an example of perhaps not the best way to use installation profiles, or I don't understand profiles well enough to manage a site that has them deeply embedded.

If it's the latter, how do I upgrade the site so that it doesn't fubar it?

  • And you are sure it's not Composer managed?
    – leymannx
    Commented Jun 1, 2021 at 19:57
  • 1
    definitely not composer managed. It was built during early 2011 before composer really had a foothold.
    – blue928
    Commented Jun 1, 2021 at 20:13
  • Which version of Drush? But I think that doesn't matter.
    – leymannx
    Commented Jun 1, 2021 at 20:17
  • One tactic could be to move the profiles to somewhere else on the server and then move them back (or symlink back) after update. This could even be scripted. Or follow drupal.org/docs/7/update/core-option-2 or drupal.org/docs/7/update/core-option-3 to update manually.
    – leymannx
    Commented Jun 1, 2021 at 20:19
  • drush version 8.4.5, but you are correct. I've tried 8.1.16, 8.3.3. I have not tried 9.x, but then again, I have the composer issue since 9 requires the Drupal site to be composer managed.
    – blue928
    Commented Jun 1, 2021 at 20:28


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Browse other questions tagged or ask your own question.