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

Comments

Assigned:Unassigned» jonhattan
Category:support» bug

I'm not sure. Drush builds this field from the extension's "label". Just printing that out shows:

drush @wk.dev ev '$e = drush_get_extensions(FALSE); return $e["googleanalytics"]->label;'
'Google Analytics (googleanalytics)'

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?

Version:7.x-5.8» 8.x-6.x-dev

Oh, same behavior on 8.x-6.x; should be fixed there first.

I was looking at the wrong function result in #1; updatecode is based on projects. Therefore, we have:

$ drush @wk.update ev '$e = drush_get_extensions(); $p = drush_get_projects($e); return $p["google_analytics"];'
array (
  'label' => 'google_analytics',
  'type' => 'module',
  'version' => '7.x-1.2',
  'status' => '0',
  'extensions' =>
  array (
    0 => 'googleanalytics',
  ),
  'path' => 'sites/all/modules/google_analytics',
)

The 'label' for 'devel' is 'Devel (devel)', so this appears to be a problem in drush_get_projects.

Status:Active» Needs review

The 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.

Here is the patch.

Yeah, the shorter form seems to work too.

Assigned:jonhattan» Unassigned
Status:Needs review» Fixed

All tests passed, so committed to 8.x-6.x and 7.x-5.x.

Status:Fixed» Needs work

+++ b/commands/pm/pm.drush.inc
@@ -487,7 +487,7 @@ function drush_get_projects(&$extensions = NULL) {
-        'label' => isset($extensions[$project])?$extensions[$project]->label:$project,

We 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

Status:Needs work» Closed (works as designed)

Indeed 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.

Issue summary:View changes

Updated issue summary.

Status:Closed (works as designed)» Needs work

That'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.

#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.

Ah, 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.

Status:Needs work» Needs review
StatusFileSize
new1.23 KB

My 2¢. If project has only one extension but machine name doesn't match, pick its name.

StatusFileSize
new1.62 KB

#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.

Status:Needs review» Fixed

Yes, $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.

Title:Why does Google Analytics not show it's human name?Why does CCK (Drupal 6) not show it's human name?
Status:Fixed» Needs review
StatusFileSize
new1.99 KB

Here's a version that works for cck.

Status:Needs review» Reviewed & tested by the community

It looks good.

Status:Reviewed & tested by the community» Fixed

Committed to 8.x-6.x.

Status:Fixed» Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

Issue summary:View changes

A