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.As it is currently in HEAD:
This version is incompatible with the 7.0-dev version of Drupal core.
I just had a user think that a module was incompatible with Drupal 6.9 specifically, whereas the module wasn't compatibile with 6.x at all. This *almost* turned into a security issue, as he thought he instead had to install some older point revision of Drupal 6. As modules cannot specify a specific version of core, I'm going to suggest that the text be changed to the following:
The version of this module is incompatible with Drupal 7. To use this module, replace it with a version which is compatible with Drupal 7.
This removes the confusing language (the world typically puts version numbers after the project name), and removes the use of "core" which means nothing to outsiders (unless we reame "drupal" to "drupal core"!). Also, it gives help text to provide next steps for users who may not know about upgrading contributed modules.
Thoughts?
| Comment | File | Size | Author |
|---|---|---|---|
| #29 | module_incompatible_368006_take2.png | 14.06 KB | lisarex |
| #29 | module_incompatible_368006_take2.patch | 1.81 KB | lisarex |
| #14 | after368006_theme_compatibility.png | 75.65 KB | deviantintegral |
| #14 | after368006_module_compatibility.png | 23.9 KB | deviantintegral |
| #14 | module_incompatible_368006.patch | 1.92 KB | deviantintegral |
Comments
Comment #1
lisarex CreditAttribution: lisarex commentedSounds sensible to me.
Comment #2
deviantintegral CreditAttribution: deviantintegral commentedThe attached patch changes the text for modules to:
And for themes:
!api_version is the major version number exploded from the VERSION constant.
Comment #3
lisarex CreditAttribution: lisarex commentedApplied the patch and looks good.
What do folks think of revising the copy slightly to say "This module is not compatible with Drupal 7. To use this module, replace it with a version that has been created for Drupal 7." (since they may not realise modules must be upgraded to work with Drupal 7)
Otherwise, it looks great! (Screenshot attached)
Comment #4
deviantintegral CreditAttribution: deviantintegral commentedI'm not sure I like the word "created" as it implies a new module from scratch. The text needs to be applicable to both modules for previous Drupal versions and for future Drupal versions.
If "is compatible" isn't good, how about "works"? "This module is not compatible with Drupal !api_version. To use this module, replace it with a version which works with Drupal !api_version."
Comment #5
lisarex CreditAttribution: lisarex commentedYep, Andrew, I'd go with your revision in #4.
Comment #6
lisarex CreditAttribution: lisarex commentedOK, rerolled with comments from #4 (but used 'that', rather than 'which')
Comment #7
deviantintegral CreditAttribution: deviantintegral commentedThanks Lisa - looks great, both in screenshot and in patch form.
Comment #8
webchickCool, I like the UI improvements here. But I think it would be better to just re-use DRUPAL_CORE_COMPATIBILITY (e.g. "7.x") here:
1. It would clean up that kinda messy array_shift(explode(...)) logic that's repeated twice there.
2. In lots of places on Drupal.org, we refer to 7.x, 6.x, etc. For example, the "Filter by core compatibility" at http://drupal.org/project/modules and on the module version numbers on the project pages.
3. It clearly indicates we mean "Any version of Drupal 7" as opposed to "Drupal 7"
What say you? :)
Comment #9
deviantintegral CreditAttribution: deviantintegral commentedThat's fine by me. The initial rationale was that in speech, most users seem to refer to it as Drupal 5/6/7, but I agree that matching online documentation is better.
This update removes the string parsing and directly uses the DRUPAL_CORE_COMPATIBILITY constant.
Comment #10
lisarex CreditAttribution: lisarex commentedApplied patch ... looks good to me! Screenshot attached.
Comment #11
deviantintegral CreditAttribution: deviantintegral commentedThanks Lisa; one more review perhaps then RTBC?
Comment #12
webchickThis looks great, except for one last little nit-pick.
The old string said !core_version, the new string says !api_version. I think !core_version made more sense, as that's what we're really talking about here.
So if you could put the placeholders back to how they were, this is ready to fly.
Comment #13
lisarex CreditAttribution: lisarex commentedPer feedback from webchick in IRC, replaced !api_version with !core_version
Comment #14
deviantintegral CreditAttribution: deviantintegral commentedReroll due to #491214: implement the top level Appearance / Choose Theme admin page, which renamed $description to $output. Attached screenshots to show the change on the theme selection page.
Comment #15
xmacinfo... To use this module, replace it with a version that works with Drupal ...Looks nice, but I would wrap the module name with the proper link to the module page on Drupal.org. The admin/reports/updates page already wraps module name to their project page.
We could also color code this link in green if a D7 version is available and red if not.
Comment #16
deviantintegral CreditAttribution: deviantintegral commentedWe have a link to update existing modules and themes at the top of the page (since themes and modules may not be on drupal.org), so I think repeating the project link would be more clutter.
Comment #17
greg.harveyAs far as I'm concerned, #14 is good to go. This issue has been batted about for a while, most people are happy with the patch without xmacinfo's suggestion (though thanks for input =) and while I'm not actually adverse to the idea of a project link, deviantintegral's defence of current patch seems reasonable to me and we'd rather just see this committed without starting a new discussion at this late stage.
To get this in for the alpha1 release, marking R&TBC (I just applied it, it looks fine).
Comment #20
aspilicious CreditAttribution: aspilicious commentedRetest, code has changed a lot
Comment #21
greg.harveyOk, but I did just successfully apply it to the latest dev snapshot of D7. =)
Comment #22
webchickHm. This could use eyes from the UX team. In general, they've been on a big push to remove
uselesstext from the UI. If this isn't clear enough as-is, they might want a briefer way of saying the same thing, as currently the string seems to repeat itself repeat itself a bit. ;)Comment #23
Bojhan CreditAttribution: Bojhan commentedAny reason why we are saying - To use this module, replace it with a version which is compatible with Drupal 7.x ? I am not sure if that is solving the problem that was proposed.
Comment #24
greg.harveyHm, with that in mind maybe it should be more like:
Could "downloaded" be "local", or is that too far for non-technical users? Not sure how to hint they should go and download another version. Perhaps that does it? Or perhaps it's not even necessary to worry about it?
Comment #25
webchickHm. Do we need to get that explicit? Presumably, if they get themselves into this situation, they've had to download a module in the first place in order to do so; core certainly doesn't ship with modules incompatible with itself. :)
Comment #26
deviantintegral CreditAttribution: deviantintegral commented@Bojhan: Are you suggesting we remove the suggested action entirely? The text mentions replacing it with a 7.x version as that's the version number listed on a drupal.org download page.
I think "local" is more technical and possibly confusing, as users may think local means their local machine, not the web server. I'm not sure downloaded works either as that may imply a local machine ("download" to your desktop, "upload" to the server). I agree with webchick that it's too specific.
Comment #27
greg.harveyI was looking for a word like "installed", but NOT installed because the module is not installed - it's simply "available", but that feels clunky and confusing too.
But then the original issue was raised around the use of "7.x core" or something like that. So perhaps it can be as simple as this:
As webchick points out, they've already downloaded a module and got it in to a modules folder, so they can't be total idiots. Realising that the version reads 6.x-x.x (or whatever) in the adjacent column didn't ought to be beyond them. ;-)
Comment #28
xmacinfoThe message is essentially displayed for upgrading users, if they leave an older module in their site, a incompatibility message is displayed.
This message should be short and sweet:
“Not compatible with Drupal 7.”
Comment #29
lisarex CreditAttribution: lisarex commentedHow's this?
"This version is not compatible with Drupal !core_version and should be replaced."
Comment #30
jhodgdonwebchick just complained on another issue that we aren't supposed to use the word DRupal in user-facing text. This patch does...
Comment #31
lisarex CreditAttribution: lisarex commentedUp in comment #12 webchick said it was OK... maybe it's Drupal on it's own that objectionable, or maybe I misunderstood #12...
webchick?
Comment #32
Bojhan CreditAttribution: Bojhan commentedOh.. well - I guess Drupal is not too bad here.
Comment #33
Bojhan CreditAttribution: Bojhan commentedRTOBC
Comment #34
Dries CreditAttribution: Dries commentedCommitted to CVS HEAD. Thanks.