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.
I wonder why it's not listed as Google Analytics (googleanalytics)
. If there is anything I need to fix in GA, please let me know.
Update status information on all installed and enabled Drupal projects:
Name Installed version Proposed version Status
Administration menu (admin_menu) 6.x-1.8 6.x-1.8 Up to date
Advanced help (advanced_help) 6.x-1.2 6.x-1.2 Up to date
Drupal 6.28 6.28 Up to date
google_analytics 6.x-3.5 6.x-3.5 Up to date
jQuery Update (jquery_update) 6.x-2.0-alpha1 6.x-2.0-alpha1 Up to date
Comment | File | Size | Author |
---|---|---|---|
#16 | drush-1916356-16.patch | 1.99 KB | greg.1.anderson |
#14 | drush-1916356-14.patch | 1.62 KB | greg.1.anderson |
#13 | drush-1916356.patch | 1.23 KB | jonhattan |
#6 | 1916356-show-correct-title-in-updatecode-6.patch | 630 bytes | greg.1.anderson |
#5 | 1916356-show-correct-title-in-updatecode.patch | 724 bytes | greg.1.anderson |
Comments
Comment #1
greg.1.anderson CreditAttribution: greg.1.anderson commentedI'm not sure. Drush builds this field from the extension's "label". Just printing that out shows:
In one Drupal site I have, google_analytics and features_extra show their project name instead of their title and project name, which is what is usually in 'label'. Drush gets this right as some points, as shown above; I'm not sure where or how it loses it. @jonhattan: any ideas?
Comment #2
greg.1.anderson CreditAttribution: greg.1.anderson commentedOh, same behavior on 8.x-6.x; should be fixed there first.
Comment #3
greg.1.anderson CreditAttribution: greg.1.anderson commentedI was looking at the wrong function result in #1; updatecode is based on projects. Therefore, we have:
The 'label' for 'devel' is
'Devel (devel)'
, so this appears to be a problem in drush_get_projects.Comment #4
greg.1.anderson CreditAttribution: greg.1.anderson commentedThe attached patch for me.Forgot to attach patch. :(Explanation:
Drush, like many humans, is confused when a project "foo" does not have at least one module that is also called "foo". In this particular case, Drush is using the module name as a project name; if these are the same for at least one of the enabled modules, then Drush gets the correct label. This, however, is unnecessary, as Drush already has access to the correct label in the $extension object.
This might even be simplified to just:
'label' => $extension->label
, but I did not test.Comment #5
greg.1.anderson CreditAttribution: greg.1.anderson commentedHere is the patch.
Comment #6
greg.1.anderson CreditAttribution: greg.1.anderson commentedYeah, the shorter form seems to work too.
Comment #7
greg.1.anderson CreditAttribution: greg.1.anderson commentedAll tests passed, so committed to 8.x-6.x and 7.x-5.x.
Comment #8
jonhattanWe proceed this way to try and assign the main extension label to the project label.
With your change, it will assign the label for the first extension found.
Example: commerce
Comment #9
jonhattanIndeed is was done this way to avoid picking a freaking label as "Text (text)" for a project like cck. There're no t ests for this. CCK is old d6 but the rules to name projects and modules have not changed.
Reverted #7 and committed docstrings: http://drupalcode.org/project/drush.git/commit/2933160
For GA: problem is that project name and module name doesn't match.
Comment #9.0
jonhattanUpdated issue summary.
Comment #10
hass CreditAttribution: hass commentedThat's why drush need to show
Google Analytics (googleanalytics)
. Than everyone is able to enable GA from drush. I'm not able to change ga module name before D8 or later and drush should handle this. The rules you are talking about are created later than the module name.Comment #11
greg.1.anderson CreditAttribution: greg.1.anderson commented#5 and #6 were just dumb; sorry, and thanks for backing it out.
Unfortunately, the premise in #10 is not quite correct either. The problem is that in Drupal, projects do not have human-readable names; only modules do. Therefore, displaying "Google Analytics (googleanalytics)" in the pm-updatecode update status table is not correct, because the update status table contains project names, and the project name for Google Analytics is "google_analytics". Regarding Drush's need to show the module name so that users will know what to enable, it does do this once when you download the project, so we are at least nominally covered here.
I still think we could do slightly better here. If we have, for example, a project called "user_confusion", and it contains a module named "__use_r___con_f_usio_n___", then we could probably find the later by doing an iterative compare that ignores non-alphanumeric characters in the project and module name, for all of the modules in the project. This would result in a label of "User Confusion (user_confusion)" in the update status table, which would be more or less correct. We do need to be careful not to be too loose with our project-to-module mapping, though; if there was some other module called "user_confusion_kit", and it contained modules called "tuna_fish" and "brightlycoloredmachinetools", then I don't think we'd want to show "Brightly Colored Machine Tools (user_confusion_kit)" in the status table, because on some other site, it might show "Tuna Fish (user_confusion kit)" instead.
I'll submit another more conservative patch shortly.
Comment #12
hass CreditAttribution: hass commentedAh, sorry - you are correct "
Google Analytics (google_analytics)
" is correct and once it has been installed it need to show "googleanalytics
" so users are able to know what modules are inside the package.Comment #13
jonhattanMy 2¢. If project has only one extension but machine name doesn't match, pick its name.
Comment #14
greg.1.anderson CreditAttribution: greg.1.anderson commented#13 had a typo; you were counting $project['extensions'] == 1 (misplaced end paren). Fix attached.
This is okay with me. It does seem that $project['extensions'] is fully initialized, regardless of whether the modules inside it are enabled or not, so the examples in #11 will not occur (that is, you will always see "user_confusion kit", and never "Brightly Colored Machine Tools (user_confusion_kit)", regardless of which modules are enabled).
I can't think of a good way to find, for example, "Content (content)" for cck, so that we could build "Content (cck)" instead of "Text (cck)". The only improvement I can think of in this regard is to hard-code the mappings for common projects such as cck, but I don't think we want to go there. I think this is probably the best we can do for now, and it does at least work for one common example, so I'm in favor of it.
Comment #15
jonhattanYes, $project['extensions'] contains all modules. We need them to find the project path.
A way to identify "Content (content)" as the main module for cck is to intersect all project extensions' dependencies but it doesn't worth it for just a human name.
Ok. Committed #14.
Comment #16
greg.1.anderson CreditAttribution: greg.1.anderson commentedHere's a version that works for cck.
Comment #17
jonhattanIt looks good.
Comment #18
greg.1.anderson CreditAttribution: greg.1.anderson commentedCommitted to 8.x-6.x.
Comment #19.0
(not verified) CreditAttribution: commentedA