Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Issue
Custom modules, Strongarm configurations and Features are reported on "Failed to get available update data" list
http://example.com/admin/reports/updates
These items are local to the site and will not be available for update.
I suggest to distinguish between modules that are "updatable" and not and to avoid trying to find updates for custom modules and features.
Have you discuss this already ?
Comment | File | Size | Author |
---|---|---|---|
Drupal Update module 1.JPG | 24.43 KB | Refineo |
Comments
Comment #1
aklys CreditAttribution: 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 CreditAttribution: 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 CreditAttribution: 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 CreditAttribution: 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 CreditAttribution: 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 CreditAttribution: 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 CreditAttribution: 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 CreditAttribution: 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 CreditAttribution: quietone at PreviousNext 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 CreditAttribution: quietone at PreviousNext commentedMore information has not been provided here after 8 months.
Therefor, I am closing this issue.