In a current project I have had to patch the life out of a few modules (node hierarchy, workbench access and a few more). These modules are now absolutely perfect for the project's needs and are very unlikely to break with future updates to core.

That being said, when the app is handed over the clients will have full (user 1) access to the system and will therefore be warned when these modules have available updates. And they will update them, no matter how many times I beg them not to (oh how easy life would be without clients!).

Is there a way (perhaps in the modules' .info files) to persuade the update manager not to check for updates for these modules?

EDIT

I'm aware of the project status url key that's available for the .info file so I guess I could set that to a non-existent URL but I'd much rather do this in a clean way if possible.

up vote 31 down vote accepted

You need to implement hook_update_projects_alter().

Alter the list of projects before fetching data and comparing versions.

Most modules will never need to implement this hook. It is for advanced interaction with the update status module: mere mortals need not apply. The primary use-case for this hook is to add projects to the list, for example, to provide update status data on disabled modules and themes. A contributed module might want to hide projects from the list, for example, if there is a site-specific module that doesn't have any official releases, that module could remove itself from this list to avoid "No available releases found" warnings on the available updates report. In rare cases, a module might want to alter the data associated with a project already in the list.

The project key from the .info file is added by the packaging script on drupal.org to identify what project the module is from. The primary use is for the Update status module to monitor versions of installed packages and notify administrators when new versions are available.

You just remove or comment this line in .info file and Drupal stop checking for updates of this module.

  • Was this downvoted because it is incorrect or some other reason? – mpdonadio Oct 21 '12 at 19:03
  • This is IMO, the best and easiest way! – AyeshK Jun 6 '13 at 19:02
  • 1
    @MPD Using project manually is discouraged in the docs - that might be the reason of downvotes. – Mołot Jun 21 '13 at 8:59
  • This was the only way I could find to stop checking for a customized version of a Theme. I, of course, would like to do it the "right way" but this worked and reusing npc's coded but with THEMENAME_update_projects_alter didn't. – nedwardss May 28 '14 at 17:02
  • 3
    @nedwardss using MYMODULE_ or THEMENAME_ only indicates the location that this code should be placed. By using this code in a theme function file instead of a custom module, it may be processed at a different stage and may not perform as expected. Themes should be included in the $projects variable. – emc Jan 8 '15 at 19:59

Just providing a code sample to help the chosen answer:

function MYMODULE_update_projects_alter(&$projects){
    unset($projects['slug_of_the_module_you_want_to_disable']);
    //dsm($projects);  // view a list of projects
}

Enter the module name in the $projects[] variable to disable. If you're not sure what the slug is (will be lowercase and underscored), use that dsm() call or print_r() to print out a list of the modules.

  • 1
    One note - slug is simply a technical name of the module which is the same as the name of module .info file. So you don't have to dump projects array just look into the module folder. In most cases the name is the same the name of the module folder. – Nux Jan 16 '15 at 11:50
  • 1
    @Nux "most cases" is counterproductive for the few times that the slug doesn't match the module name. By viewing and using the slug the first time, we both educate the developer and reduce the number of possible problems. – emc Jan 16 '15 at 16:30
  • The term used from Drupal is not slug but machine name. Slug is used from some CMS's as equivalent of canonical URL or path alias, – kiamlaluno Aug 1 at 12:31

You can do it in two ways.

  • drush pm-updatecode --lock=module_to_ignore
  • Use the update_advanced module. It allows you to mark modules that you want to ignore on the module administration page.

In particular, the per-project settings to ignore certain projects or even specific releases, is absent in the core version of the module. The "Update status advanced settings" module restores these settings, and might eventually provide additional functionality for the core "Update status" module.

  • the drush command is exactly what I was looking for, thanks alot! – Afri Jun 21 '13 at 9:11
  • The drush help upc will give this for the --lock help: --lock=<foo,bar> Add a persistent lock to remove the specified projects from consideration during updates. Locks may be removed with the --unlock parameter, or overridden by specifically naming the project as a parameter to pm-update or pm-updatecode. The lock does not affect pm-download. – Yzmir Ramirez Sep 12 '16 at 23:51

I get the same issue with the module updates, I installed the Disable Updates module seems working good.

This is a small administrative module that lets site administrators disable checking for updates on certain themes and modules, by exposing the functionality of hook_update_projects_alter() on the update settings form (/admin/reports/updates/settings). It allows for arbitrary selection of themes and modules as well as auto detection of custom modules, patched modules, and site-specific features modules.

enter image description here

Basically, you made a fork, right? So you should:

  1. Rename it to include your fork mark
  2. In info file, set project status url to your repository of that module.

Last but not least, if it's not supported but was not deprecated in favor of any other module, consider asking to become co-maintainer and share your fixes with community.

  • 2
    Donschoe: maintainer here. I'd be very willing to help you get up to speed if you want. – berkes Jun 26 '13 at 18:06

Your Answer

 
discard

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.