Problem/Motivation

As it currently stands, install profiles cannot insert their own requirements during the install phase.
drupal_check_profile grabs the info file from the install profile, and loops through all the dependencies to check for requirements, however it forgets to check its own requirements.

Supplied patch adds the profile to the end of the dependency array (temporarily) to check itself for requirements.

Proposed resolution

https://api.drupal.org/api/drupal/core%21includes%21install.inc/function...

Remaining tasks

Write a test for this to prevent regressions in the future.

Contributor doc on writing tests: https://drupal.org/contributor-tasks/write-tests

User interface changes

API changes

Data model changes

As it currently stands, install profiles cannot insert their own requirements during the install phase.

drupal_check_profile grabs the info file from the install profile, and loops through all the dependencies to check for requirements, however it forgets to check its own requirements.

Supplied patch adds the profile to the end of the dependency array (temporarily) to check itself for requirements.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

xjm’s picture

Version: 7.22 » 8.x-dev
Priority: Major » Normal
Issue tags: +Needs tests, +Needs backport to D7

Thanks @japerry! :)

Moving to 8.x first and tagging for backport, as per our backport policy.

star-szr’s picture

Assigned: japerry » Unassigned
Issue summary: View changes
Status: Needs review » Needs work
Issue tags: +DrupalWorkParty

Tagging to create a new patch for this against 8.x. If possible it would be nice to test if this is still an issue on 8.x as well, and the test coverage can be worked on as well.

Docs for writing automated tests: https://drupal.org/contributor-tasks/write-tests

@japerry if you want to work on this just reassign.

Riaan Burger’s picture

Tested the issue using Drupal 8; It is still an issue; Tested as follows:

git clone of 8, added this code:

  if ($phase == 'install') {
    $requirements['testing_foo'] = array(
      'title' => 'Testing Foo Error',
      'description' => 'Intentional error in ' . __FILE__ . '.',
      'severity' => REQUIREMENT_ERROR,
    );
  }

To file_requirements() in core/modules/file/file.install which resulted, as expected, in an error during install.

Added the same code to a new function in core/profiles/standard/standard.install as follows:

function standard_requirements($phase) {
  $requirements = array();

  if ($phase == 'install') {
    $requirements['testing_foo'] = array(
      'title' => 'Testing Foo Error',
      'description' => 'Intentional error in ' . __FILE__ . '.',
      'severity' => REQUIREMENT_ERROR,
    );
  }

  return $requirements;
}

Expected a new error during install but did not get one.

Manually applied the patch to core/includes/install.inc which resulted in expected behaviour.

The issue is still valid and the patch still solves the issue.

Unless you are on it japerry, I'd like to try to tackle this one...

Riaan Burger’s picture

Assigned: Unassigned » Riaan Burger
Riaan Burger’s picture

Riaan Burger’s picture

Status: Needs work » Needs review

Status: Needs review » Needs work

The last submitted patch, 5: install_profile_requirements_on_install.patch, failed testing.

AjitS’s picture

Status: Needs work » Needs review
FileSize
546 bytes

Applied the tests as mentioned in #3, above. The patch seems to solve the problem.
Re-rolling it again.

AjitS’s picture

FileSize
546 bytes

Wrong issue name in the patch.

The last submitted patch, 8: I2108339.patch, failed testing.

Riaan Burger’s picture

AjitS, this was my first try at working on core stuff. Does this mean (I'm guessing from that you did) that the patch should be named after the issue node ID? Was that what caused all the patches above to fail.

AjitS’s picture

Riaan Burger,
As far as I know, patch name doesn't have any impact on its "passing" or "failing". However, generally some standards are recommended to be followed while naming a patch. It is generally in the format
[issue_name]-[short-description]-[issue-number]-[comment-number].patch

More reading about Submitting patches.

Riaan Burger’s picture

AjitS, do you have any idea why the first patches failed then? It looked to me like it was because of the file name initially (containing install.patch in the name). The patches do look the same to me, the failed and successful ones. Thanks for helping.

Daniel Bornman’s picture

Status: Needs review » Reviewed & tested by the community

Also tested with the code from #3 above and confirming the patch solved the issue.

star-szr’s picture

Status: Reviewed & tested by the community » Needs work

Great! It should be possible to write a test for this so we can prevent regressions in the future.

Contributor doc on writing tests: https://drupal.org/contributor-tasks/write-tests

mgifford’s picture

Version: 8.0.x-dev » 8.1.x-dev
Assigned: Riaan Burger » Unassigned

This still a concern in D8? Unassigned issue too.

no_angel’s picture

Issue summary: View changes
no_angel’s picture

nils.destoop’s picture

Not completely similar, but very close to it :)

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.0-beta1 was released on March 2, 2016, which means new developments and disruptive changes should now be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

David_Rothstein’s picture

It's possible this patch needs additional work - see #2486083-21: The following module is missing from the file system: standard and subsequent comments for a bug that this patch causes (at least the Drupal 7 version of it... not sure about Drupal 8).

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.0-beta1 was released on August 3, 2016, which means new developments and disruptive changes should now be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

scott_euser’s picture

Thanks for the work on this! Helped me solve an issue. The installation profile I used was missing declaring it's dependencies so the patch still failed for me.

Perhaps rather than just loading the dependencies from the profile we can double check that the module object is loaded and if not, throw an error that helps the user know what dependency is missing so they can update their installation profile accordingly?

Attached patch as an example.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.0-alpha1 will be released the week of July 31, 2017, which means new developments and disruptive changes should now be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.0-alpha1 will be released the week of January 17, 2018, which means new developments and disruptive changes should now be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.6.x-dev » 8.7.x-dev

Drupal 8.6.0-alpha1 will be released the week of July 16, 2018, which means new developments and disruptive changes should now be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

quietone’s picture

Status: Needs work » Closed (outdated)
Issue tags: - +Bug Smash Initiative
Related issues: +#2309731: drupal_check_profile() does not invoke the profile's hook_requirements()

This was a bugsmash triage issue a few days ago. At that time lendude commented that it was probably fixed by a later issue, #2309731: drupal_check_profile() does not invoke the profile's hook_requirements(). Today, I read that issue and the associated change record. I now also think this was fixed in that issue.

Therefor I am closing this as outdated.