Is there a reason that the base profile's install hook isn't run? If so, that's fine, but if not, I'll happily roll a patch so that the base profile's hook_install is called as well.

From profile_api.inc:

   // Run hook_install() for the install profile.
    global $profile;
    $function = "{$profile}_install";
    $file = "./profiles/{$profile}/{$profile}.install";
    if (file_exists($file)) {
      require_once($file);
    }
    if (function_exists($function)) {
      call_user_func($function);
    }
CommentFileSizeAuthor
#11 profiler.906106-11.patch2.7 KBdixon_
#7 profiler.906106.patch2.75 KBjhedstrom
#2 profiler.906106.patch971 bytesjhedstrom

Comments

yhahn’s picture

yhahn commented
Status: Active » Needs work

Hm, good catch.

I'm wondering whether profiler should include the base profile's .install and .profile files but only call the base profile's hook_install() only if the sub-profile does not implement the hook itself. This would allow the sub profile to "override" the hook much like a class method. It would also be simple enough to call the base profile's hook_install from the sub profile if it wants to inherent and then add to the routine, e.g.

function mysubprofile_install() {
  // Much like parent::install() in an OO structure
  mybaseprofile_install();

  // My extra code
}
jhedstrom’s picture

jhedstrom
Primary language English
Location Portland, OR
commented
Status: Needs work » Needs review
StatusFileSize
new profiler.906106.patch971 bytes

I like the idea of an override. I think it is much more flexible than automatically running the base hook_install(). Here's a patch that checks for the base hook if the sub-profile doesn't define one.

q0rban’s picture

q0rban commented
Status: Needs review » Needs work

I'm not sure I like the idea of an override, as it's pretty unexpected. In this instance it would just be some black magic that only a handful of people would know about, and no-one would intuitively try. I would rather leave it as is, but include the base profile so implementers can call it manually if needed.

yhahn’s picture

yhahn commented

@q0rban: Not sure I understand your comment here? Isn't this what the patch does?

q0rban’s picture

q0rban commented

Ok, I think I misunderstood what you were suggesting then. I think this still may need work though. The base profile should be automatically included so that mybaseprofile_install(); can be called without having to include it manually. Also, this should loop through all base profiles, but I don't see that happening. For example, subsubprofile's base is subprofile who's base is baseprofile. If subsubprofile_install() exists, fine.. If not, check to see if subprofile_insall() exists. If not check to see if baseprofile_install exists. Does that make sense?

yhahn’s picture

yhahn commented

Agreed, so basically:

  • Include all base profiles's code files
  • Only call hookinstall() for the furthest descendant profile (does the current profile implement hookinstall()? if not, does the direct subprofile implement hook_install()? If not... etc.)
jhedstrom’s picture

jhedstrom
Primary language English
Location Portland, OR
commented
Status: Needs work » Needs review
StatusFileSize
new profiler.906106.patch2.75 KB

How about something like this. I moved all the loading of .install and .profile files into profiler_v2_load_config(), and added a function called profiler_run_hook_install() that gets called recursively for base profiles.

jhedstrom’s picture

jhedstrom
Primary language English
Location Portland, OR
commented
Status: Needs review » Needs work

I just ran into an issue with including dependent .profile files. If the dependent profile directory doesn't have the libraries/profiler directory, these lines fail upon including the file:

    <?php
    !function_exists('profiler_v2') ? require_once('libraries/profiler/profiler.inc') : FALSE;
    profiler_v2('yourprofile');

since the libraries/profiler/profiler.inc is a relative path.

jhedstrom’s picture

jhedstrom
Primary language English
Location Portland, OR
commented
Status: Needs work » Needs review

Disregard that last comment, it is a more general problem with Drupal including all .profile files on the very first part of install.php. So it is still a problem, just not as far as this patch is concerned.

dixon_’s picture

dixon_
he/him
Primary language English
Location France
commented

subscribing

dixon_’s picture

dixon_
he/him
Primary language English
Location France
commented
Status: Needs review » Reviewed & tested by the community
StatusFileSize
new profiler.906106-11.patch2.7 KB

I can confirm that this patch works as described in #7. hook_install() of the base profile now runs if the child profile haven't implemented the hook it self. Very useful.

Here is just a reroll of the exact same patch from #7 that only adds the missing newline at end of file :) *code style fanatic*

q0rban’s picture

q0rban commented

Sorry, this patch and issue totally fell off my radar. Is this still something people are interested in?

jgraham’s picture

jgraham commented

I'm definitely interested in this, but rather for drupal 7.

fabsor’s picture

fabsor commented

This is definitely still interesting. We are using this patch in NodeStream for Drupal 6.

q0rban’s picture

q0rban commented
Version: 6.x-2.x-dev » 7.x-2.x-dev

Let's get this for Drupal 7 first, and then backport to Drupal 6.

g76’s picture

g76 commented

still very interesting:) - not trying to negate the follow button, just giving input. thanks for all the hard work.

Anonymous’s picture

Anonymous (not verified) commented

Most definitely. Profiler is a great module but for me a patch for DP7 is really needed.

Anonymous’s picture

Anonymous (not verified) commented

A project that I am working on requires a production and a development installation profile. The production profile is setup as the main base profile and the development profile is simply an extension to the main base.

For this setup to work, I need everything within base_install() to execute in addition to the setup tasks in dev_install (as the development profile 'extends' the base profile).

I've resolved this issue by simply calling the base_install() function within dev_install() which ensures that the development profile extends the base profile instead of ignoring it.

/**
 * Implements hook_install().
 */
function foo_dev_install() {
  // Execute the base setup tasks.
  !function_exists('foo_base_install') ? require_once('profiles/foo_base/foo_base.install') : FALSE;
  call_user_func('foo_base_install');
  
 // Execute additional setup tasks for dev.
 // E.G. Enable UI modules and turn off caching etc...
 
}

I hope this helps anyone else faced with the same problem.

shrop’s picture

shrop commented

@insparrow: Thanks so much for posting your method for running the base_install profile tasks. This worked great. I am also using a drush make include to pull in the base install profile's make file. Profiler's base declaration handles processing the base install profiles .info file.