Properly determine project name

Another example of this (less popular) is https://www.drupal.org/project/breakpointsjs whose module name is breakpoints_js.

Another, more popular is google_analytics (googleanalytics in system table).

One approach in drd_server would be to use the folder name, not sure if that's feasible with regard to Windows or not.

Maybe this?

field_group and fieldgroup causes the same issue. We are not being notified of security updates in these instances, so I'm upgrading this to critical as the distrust in the system makes the entire system unusable. Is this project abandoned? Should we not be using it?

Incidentally my patch probably stinks; however, I did look at how the core update module determines it; as it turns out, the project name is entered into the info file by the Drupal packaging script. That is, for googleanalytics.module, the googleanalytics.info file contains project = "google_analytics" in it, and that is the key that should be used to check for updates.

Sorry @cwells, I still can't reproduce your problem. Using the fresh security update for field_group, that is showing up in my dashboard for 9 different Drupal installations, see attached screenshot.

The project itself is absolutely under active maintenance and we're about to move the main dashboard to Drupal 8 and a lot of things will be much better there than on D7. Of course, the remote sites can still be D6, D7 and D8.

Is it possible that you're having a completely different problem?

I've just checked and found out that all the following projects do exist:

https://www.drupal.org/project/google_analytics
https://www.drupal.org/project/googleanalytics
https://www.drupal.org/project/field_group
https://www.drupal.org/project/fieldgroup

So, if you have something like "googleanalytics" or "fieldgroup" in your project list, then those are projects that do exist on drupal.org but most likely haven't seen any updates recently.

Thank you so much for the response! So I jumped the gun on field_group. For that module, the project name is field_group, and the module file is named field_group - I got confused because it's different on D6 sites. So the only reason this one isn't showing up is because I don't think cron has checked for updates yet on my dashboard site (when I do either check for updates OR check for updates including disabled, it does start to show up as a security update). So apologies there.

However, I still seem to have the issue when the module name does not match the project name, i.e. google_analytics/googleanalytics.

My understanding of the table relationships for updates is this:

1. drd_domain has a key, did.
2. drd_project has a key, pid. it stores the project name, i.e. "google_analytics" data [12 | google_analytics | module | Google Analytics]
3. drd_project_release stores all the release information about a project, so has a foreign key of pid (the relevant project). also a primary key rid, the release id
4. drd_project_release_domain joins releases to domains (rid <=> did).

So when I query drd_project, the google_analytics pid key is 12.

select rid,pid,version from drd_project_release where pid=12 and version like '7%';
+------+-----+---------+
| rid  | pid | version |
+------+-----+---------+
|   16 |  12 | 7.x-2.1 |
|   17 |  12 | 7.x-1.4 |
|   97 |  12 | 7.x-1.3 |
| 3597 |  12 | 7.x-1.2 |
+------+-----+---------+
4 rows in set (0.00 sec)

So then I would say "OK, which sites have one of these versions installed?"

mysql> select * from drd_project_release_domain where rid in (16,17,97,3597);
+-----+-----+
| rid | did |
+-----+-----+
|  16 |  13 |
+-----+-----+
1 row in set (0.00 sec)

...the only one I see in there is the one site where I applied my patch from above. But EVERY one of my D7 sites has Google Analytics installed (7.x-2.1).

The reason I believe this is happening is because in the drd_server code in function drd_server_status(), the db_select that occurs to return the projects that are enabled gets the "name" column from the system table, which is "googleanalytics," the name of the module from the info file. What it SHOULD be returning for projects_enabled from drd_server_status() should actually be the "project" key from the module's info file (that is, "google_analytics").

So the fact that field_group and fieldgroup both exist is probably additionally bothersome to this.

You analysis is quite right. The correct project name should not be read from the name column in the system table but from the project key in the info column.

As we are currently spending hundreds of hours to migrate the main DRD module over to D8 where it will be monitoring remote Drupal sites of D6, D7 and D8, I wonder if it's worse fixing this one here as we strongly recommend to move to the new dashboard. It comes with ZERO dependencies, so it should be quite fun for everyone to have a D8 site at least for the purpose to monitor remote sites.

What do you think?

I'm definitely excited for the Drupal 8 version, and I think your focus is well-spent in that area. However, now that I know the right approach, I'm wondering if you couldn't just reivew/incorporate a patch if I came up with it?

That's OK with me @cwells. So this should be addressed in the drd_server module and you may want ot have a look into the _update_process_info_list() function which is part of core, that does exactly that: determine the $project_name.

Thanks for helping out with this.

Haven't forgotten about this! Here's a patch which uses update module to get all the projects. This seems to work for me with some cursory testing. Do you have any feedback?

Thanks @cwells for the patch. I've had a first looks which raised some questions:

• Is update_get_projects() returning all relevant projects including core and themes?
• As the if clause is not changing the $projects array, the first query is redundant and should probably move into an else clause, shouldn't it?

Yes, I confirmed with an outdated version of Zen, Google Analytics, and Drupal core.

Here's an improved patch incorporating the other suggestion - we only need to do one or the other, it doesn't make sense to do the other query first just to overwrite it.

Two last things:

+++ b/drd_server.module
+  module_load_include('inc', 'update', 'update.compare');
+  if (function_exists('update_get_projects')) {

The file update.compare.inc is part of the update module so we should better test the condition module_exists('update') and then load that include file. You don't have to test for the function any more because it will be there.

And finally you don't have to initiate the $projects variable before the if clause and also can get rid of the $all_projects variable by directly using the function call in the foreach clause.

Got it. I still think I need to initialize the $projects array inside the if, however, because it's possible that update_get_projects() COULD iterate nothing (although unlikely that it would return nothing, it does provide an alter hook so theoretically someone could erase everything) and so never be set.

Thanks @cwells I've committed this to the dev branch.