Visually display a warning if there are version mismatches within a single project

Perhaps my feature request to show the directory would play into this?

Note that it is not just version strings that have this problem, but also datestamps (see http://drupal.org/node/227644).

Actually, I just checked that this occurs in Drupal 6 core too, and it does.

Feel free to change back if you disagree, but I think this qualifies as a bug. If I am running (for some stupid reason) a "mixed" version of Drupal, with some modules up to date and some modules out of date and potentially insecure, Update Status should not tell me that everything is OK -- it should tell me that there's a problem. What happens now is that it picks one module from the project at random (I think it uses the one that comes first alphabetically) and uses that module to assign the overall project version number. It really should check all of them to be safe.

So am I correct that the following is the desired behavior?

• Check all modules in the project and use the earliest version string it finds as the project's version string (same thing for the datestamp, just in case).
• If all modules don't have the same version, display that on the available updates report, as above.

Hm, I had intended to write a patch for this weeks ago.. but better late than never ;)

The attached patch is for 7.x and does two things:

1. Assigns the overall project information based on the oldest module it finds, to maximize the chances of catching out-of-date code. (And if several modules have the same datestamp, it attempts to choose between them by picking the one with the "earliest" version string.)

2. If there is any version mismatch, all the version strings get printed out on the update report.

In the vast majority of cases, the version mismatch will also generate an error on the update report, since the older module will be out of date. In a few edge cases, though, I think you could still get the "up to date" checkmark telling you the project is OK (for example, if your project contains modules from two separate supported versions of the project, e.g., 6.x-1.0 and 6.x-2.0). I'm not sure it's really worth the effort required to deal with that, though.

As for eventually porting this to 6.x, I think the first part of the patch is undeniably a bug fix that should be backported.... right? But the second part (printing the version strings to the screen) is less so.

Here is a new patch using theme_update_unknown_version()... definitely a good idea, thanks.

About breaking t() strings, I figured that since this patch is for 7.x, we don't need to worry about that (??). If this gets backported to 6.x, then I agree, we should definitely get rid of the <strong> tags (but I'm not sure that part of the patch will get backported anyway?). The <strong> tags certainly aren't crucial either way, but it's a little bit nice to have it highlight for you which of your modules is the one causing the version mismatch, I think.

For CVS Deploy, I reviewed the code a bit, and I think this patch won't have any effect on checkouts of official project releases. For dev versions, it looks like the changes it makes to the datestamp calculation will make the bug at http://drupal.org/node/227644 appear more often than it currently does. (My hope was to fix that bug after this one anyway, though.) I think this might be inevitable, though... for a CVS checkout, a project's datestamp really should be set to the newest one it finds in all the sub-modules, but here, we want the exact opposite behavior. So I think CVS Deploy would just need to be patched to override what is happening here and do its own calculation of the overall project datestamp.

The change with %includes to !includes should not be that big of a problem, there were such small changes before. As long as the usability / correctness of the information is worth it (and it looks like it does), such small changes are workable IMHO.

I agree that this would be nice to have. I haven't tested the patch yet, so it is not clear how well the information is presented.

Here is a screenshot showing what this patch currently does. If we did it without breaking strings, the screenshot would look exactly the same, but the offending module(s) -- in this case the comment module -- would not have their version strings in bold.

Note that the versions only get printed for sites which have a mismatch, but the string breakage would happen for everyone, so that might be something to keep in mind for Drupal 6.

Thanks for the screenshot, David. That is really helpful.

I think it looks good, but I'm not sure it is 100% intuitive. That said, it is better than nothing, and I'm not sure how else to present this information.

I think it is good with the bolding even if that brakes this short string, as it is important to show there. We broke such short strings before.

Dries, I agree it isn't quite perfect yet. Here are a couple things I can think of that might make it more intuitive (any of these would be very simple to implement):

• Add more text at the beginning, something like:
  This project includes modules with conflicting versions: Block (6.2), Color (6.2), Comment (6.1).....
  This would involve adding a new string rather than breaking an existing one.
• Print the project name along with the version:
  Includes: Block (Drupal 6.2), Color (Drupal 6.2), Comment (Drupal 6.1).....
• Make the whole module name bold, as in @dww's original post:
  Includes: Block (6.2), Color (6.2), Comment (6.1).....

Or possibly some combination of the above...

Fine with me.

Done.

Oops, there's a (minor) problem with this patch. I realized that theme_update_unknown_version() is not particularly "themeable", since its output gets run through check_plain() somewhere inside theme_update_report().

Maybe the simplest solution is just to not have it be a themeable function; we could change it back to update_unknown_version_name() or something like that...

New version attached; this makes the function non-themeable again and also fixes a minor code style issue that was lurking in there.

Otherwise this is the same as the previous patch.

Two more comments:

* While I think this is an improvement, I wonder why we don't put the conflicting modules in red? To me, that looks more conflicting than bold. (This is not a requirement for the patch to get committed.)

* Many users will scratch their head and try to figure out how to resolve the conflict. Usability 101 tells you to explain your users how to fix this.

Can we massage this a little bit more?

Talked with dww on this and discussed how I felt this should be more centered towards a status report warning if there are version mismatches found since we put important potential-site-breaking things there. However, this is also relevant to the update status page since it affects if and which version is available to upgrade to.

Subscribing since this happens in sub-themes often.

Don't really get what this patch does.

Resurrecting this one after discussion with @dww in Slack. FWIW I don't think this is a bug, rather a task to handle an edge case. Updated the issue based on my testing with a suggested approach to address this.

I won't update the issue category but if anyone else agrees, please do.

I just asked for some feedback on the direction to take here from #ux.

@ainsofs, @pameeela, @quietone, @Seth Hilder and I discussed this at Drupal South

Whilst we agreed that this can put your site into a bad state, based on lack of activity and changes to how people update modules now (much higher composer use) as well as the level of effort that would be required to fix this edge case that this would be at best on minor, so we decided to change the priority.

However we also felt that the 'bug' here is not on behalf of Drupal but rather on that of the user, or documentation on how to update your site properly.

So as a result we felt this was better classified as a task.

However if you disagree @dww feel free to move it back in your capacity as update module maintainer