Closed (works as designed)
Project:
Drupal core
Version:
11.x-dev
Component:
update.module
Priority:
Normal
Category:
Feature request
Assigned:
Unassigned
Reporter:
Created:
1 Sep 2011 at 12:50 UTC
Updated:
30 Mar 2024 at 11:11 UTC
Jump to comment: Most recent
Comments
Comment #1
aklys commentedFor custom modules you can implement hook hook_update_projects_alter and hide project from update list.
Example for module called "mytest":
After creating this function Drupal update manager is not checking for updates of module "mytest".
Comment #2
sheena_d commentedThe solution in #1 does not, predictably, work for themes. Is there any suggestion for hiding a custom theme from the Update Manager?
Comment #3
the_g_bomb commentedIMHO I don't think that the solution in #1 is the right way to go about things anyway. Update should automatically ignore custom modues, features etc, as I see it.
Having to include a function in every custom module and feature just so that update ignores it seems to me to be the wrong approach.
From the quick look I had, I think the
function _update_process_info_list()in the file: modules\update\update.compare.inc
needs to have some logic to determine whether the module/theme needs to be checked then skipped if appropriate.
For example changing:
to:
Would check to see if the drupal.org packaging script has set a datestamp and then excludes features and custom modules from the available update report as it won't have, not that I am suggesting using the datestamp as a signifier, but just to highlight that if something more reliable is available then it could work.
Comment #4
the_g_bomb commentedJust for clarification the solution in #3 does fix the issues I'm experiencing with update.module and also the issue I'm experiencing here #1307198: Features not to be reported on "Failed to get available update data" list
edit: wrong issue linked
Comment #5
Refineo commentedI reassign this to 8.x-dev so it maybe gets more notice and discussion as new features are implemented in D8 first and then down-ported.
Comment #6
shark commentedThe change in #3 worked for me (in that by hiding the modules, the system does not appear broken).
But +1 for showing local modules in their own section, with a comment like "These items are local to the site and will not be available for update" as was mentioned in the description.
Comment #7
wylbur commentedWe tested the fix in #3, and while it excludes modules like features that do not have a datestamp value, it seems to suppress the notice that Drupal Core needs to be updated.
I toggle the change, and with the new code I don't get the Drupal core notice. But with the original code I do get the core update notice.
Besides that, this does work to avoid reported errors with feature modules failing to retrieve updates.
Comment #8
the_g_bomb commentedI have the suspicion that this method may not work with git deployed modules as well, but I haven't looked into it any further, to be honest.
As mentioned in #1307198: Features not to be reported on "Failed to get available update data" list perhaps the update url is a better indicator as to whether the update module should look for update information.
Comment #21
quietone commented@ Thank you for reporting this problem. We rely on issue reports like this one to resolve bugs and improve Drupal core.
Is this issue still a problem?
There has been no activity here for 10 years.
Since we need more information to move forward with this issue, I am keeping the status at Postponed (maintainer needs more info). If we don't receive additional information to help with the issue, it may be closed after three months.
Thanks!
Comment #23
quietone commentedMore information has not been provided here after 8 months.
Therefor, I am closing this issue.