If a module is installed with git (either via composer or not) it does not include the relevant elements in info.yml for update.module to detect updates.
The d.o packager currently adds a number of items, for example:
# Information added by Drupal.org packaging script on 2015-08-09
version: '8.x-1.x-dev'
core: '8.x'
project: 'devel'
datestamp: 1439140152
The core element should be added by module developers anyway. The project element seems to be the "key" here as it matches the module to the d.o project name, without this nothing will show on the updates page. version and datestamp are the two elements which are used to determine the version currently being used.
This issue needs a lot of discussion about possible solutions. One would be for module maintainers to add all the items, however I'm sure there are better solutions.
Update: due to complexities of getting the module version this issue has digressed to initially just getting the project element, this can be derived from the name in compoer.json.
| Comment | File | Size | Author |
|---|---|---|---|
| #14 | interdiff-7-14.txt | 1.28 KB | timmillwood |
| #14 | parse_composer_json_for-2559313-14.patch | 5.62 KB | timmillwood |
Comments
Comment #2
timmillwoodLooking at all the possible options it seems that getting git deploy module into core would be the best option.
The module is only 102 lines long and that's doing a "alter" via hook_system_info_alter(), therefore an integration into the core update module should be even simpler.
Comment #3
dave reidIf all modules have a composer.json, then all the basic information at least should not be necessary in the .info.yml files. And we could still report installs of Git-installed modules, but maybe just report an 'Unknown' version number back to Drupal.org?
Comment #4
dave reidAlso, Git Deploy makes things very slow. I would not want it in core currently.
Comment #5
timmillwood@Dave Reid - Thanks for the heads up on the performance issues. I was hoping for a solution that will cover more than just the composer installed modules, but any modules without the required information in the info file.
Comment #6
timmillwoodLooking into this further for the last hour I think all we can derive from composer.json is
$info['project']but the version and datestamp will need to come from git.I'm going to create two new core services, composer_parser and git_parser which will allow us to return all the info needed.
Comment #7
timmillwoodThis patch adds the ComposerParser service to parse a module's composer.json. The name in composer.json (eg drupal/devel) is then exploded, if the vendor namespace is drupal the project name is used.
Comment #8
drummGit deploy shells out to execute git, http://cgit.drupalcode.org/git_deploy/tree/git_deploy.module?h=8.x-2.x#n41. I wouldn't want it anywhere near a production website. There may not be known security issues, but it is a nice target.
Comment #10
isntall commentedThis patch to breaks qa.d.o testbots.
Comment #13
timmillwood@drumm - Thanks for the input, I think for now I am just going to focus on getting the project name from composer.json, this will at least allow the module to show on the update status page, even if this is as "unknown".
@isntall - I think I know the issue, will work on a updated patch today.
Comment #14
timmillwoodAdded some more ifs to mitigate issues, also added "version" to the mix just incase it's set in composer.json.
Comment #17
timmillwoodAwesome, passing now.
Comment #22
timmillwoodIt seems testbot is really confused by this patch.
Comment #28
cilefen commentedI found other issues working on the same problem.
Comment #30
meramo commented_system_rebuild_module_data is deprecated in Drupal 8.5.0, also the patch is failing
Seems like we have to rework it, changing status.
Comment #35
longwaveThe modern solution here would be to bring https://www.drupal.org/project/composer_deploy into core, right? This seems like a good idea if we are expecting most users to use Composer nowadays.
I have a site where a dist download failed during composer install some time ago and Webform was installed from source instead. This now means that Webform is missing from the available updates list following the recent security release - but there is no notification that this is the case or even that there might be a problem here. It even took me a while to track down what the actual issue was, it's not visible anywhere in the UI that there is something different about the Webform install compared to other modules.
Comment #36
colanI just marked #2755745: Add packaging info to .info.yml files for extensions managed by Composer, allow Update module to work as a duplicate. If there's any work there that's not covered by what's happening here, please post it here. I marked that one as a duplicate because it's newer.
Comment #38
pasqualleFor me the correct solution is to use https://packagist.org/packages/drupal-composer/info-rewrite as it does its magic at composer install.
It is a must have package when using dev releases with composer.
Comment #43
xjmA followup issue from the great git migration got marked outdated recently, which, fair enough. The remaining scope of it was that dev versions od modules deployed with git deploy and then composer did't work with
update.php. This looked like the modern home of that although this seems to only about naming, rather htan version numbers, abd to be yet another duplicate in a chain?Is there an infra issue for #38?
Comment #44
xjmMy clever retitle of one of the related issues is a little misleading about just what old technical debt this is, and that the issue has survived not only multiple deployment best practices but also multiple d.do packaging systems and even core version control systems. 🤫
Comment #45
xjmRemoving circular issue references.
Comment #46
xjmAnd, if I'm reading the issue right and the scope was reduced, does that mean this was reduced to the project name only, and not supporting the version number problem?
https://packagist.org/packages/drupal-composer/info-rewrite seems to support only Composer 1 and 2.
Comment #47
drumm#3489066: Add tracking for when recipes from Drupal.org are applied might have this implemented in
ComposerHelper::getPackageName(), not hooked up to update module yet.