To save some code load on every page, we can and should move update_requirements to update.install.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Dave Reid’s picture

Assigned: Unassigned » Dave Reid
Status: Active » Needs review
FileSize
12.76 KB

I didn't change any t()'s to $t() since this code runs during runtime and never install.

Status: Needs review » Needs work

The last submitted patch, 669556-update-requirements-D7.patch, failed testing.

Dave Reid’s picture

Status: Needs work » Needs review
FileSize
12.76 KB

Oops. No failing tests this time.

dww’s picture

The only tiny issue I have with #3 is that it includes an unrelated bug fix. I just moved that to #669714: Remove unnecessary menu_rebuild() from update_uninstall(). Rerolled to remove the 1 line change...

dww’s picture

Status: Needs review » Reviewed & tested by the community

Even though it's technically my patch, I'm going to call #4 RTBC, since a) it's overwhelmingly Dave's code in the first place, I just moved a single line to a different patch and b) it's mostly just moving a few functions from one file to another.

Historical note: I originally put this code in update.module instead of update.install since I was thinking that since we load this via hook_help(), it'd be better to just have it in the .module file than to pull in all of .install, too. However, that was admin-centric thinking. It's true that on admin/*, this patch pulls in slightly more code, but we save a lot of code on all the paths that aren't admin/*, and those are vastly more frequent and important.

webchick’s picture

Status: Reviewed & tested by the community » Fixed

This works for me. Best practice, afaik, is to always put hook_requirements() in .install since phase == 'install' code will only run there anyway.

Committed to HEAD.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.