Posted by Anonymous on July 15, 2012 at 11:05pm
To date I have found no quick way to determine which Drupal 6 contributed modules have been ported to Drupal 7.
This information is critical to version selection, and to site building.
Do you know of one, such as an automatically-updated table that provides this information?
Thanks in advance,
Bob
Comments
A 4000+ entry table? Doesn't
A 4000+ entry table? Doesn't seem very useful. Also, it might not capture some key metrics, such as wither the D7 version actually has an upgrade path from the D6 version!
There is a group here for discussing this exact topic, however: http://groups.drupal.org/contributed-module-status
This existing module will try to give you that info on a site-by-suite basis if you enable it within a D6 site: http://drupal.org/project/upgrade_status
The Upgrade Status module
The Upgrade Status module gets me part of the way there. Thanks.
That group appears to have gone silent 2 years ago.
drush command
I'm trying to write a drush command that could take a list of projects from an existing site and return the releases available for them in a new major version.
Pretty easy, actually, except for the fact that calling:
drush pm-releases views-7.xfrom a Drupal-6.x codebase will still return releases for D6...
First take if you're interested
https://github.com/eporama/drush-project-updatestatus
That's a drush command, if you save it in your ~/.drush directory, you can call it from a D6 docroot or site alias and it will report on all available extensions and the result of a pm-releases for the project on D7.
It's not pretty yet, but it may help in some of these situations.
Setting things stright
Bob's confusion is common. Bob did the right thing by popping in here and asking questions.
Far too often i hear the complaint that "SO many D6 modules aren't ready for D7" OR "So many D7 modules are in Alpha orBeta" Etc, Etc...
Here's the scoop...
Major sites are being built on D7 today and have been all through out this year and even earlier. I can think of absolutely no good reason to start any new project in D6. The odds of a module you need NOT being available in D7 are very slim. But let's say it happens. Let's say it happens twice even. If some is so unlucky that they find they need two modules that have not been ported to D7 yet, I say do the right thing. Start your project on the better platform of D7 and spend your development costs upgrading those 1 or 2 modules then contribute them back. You could even ask the maintainer if you could sponsor the upgrade.
There is virtually no excuse for starting a project today on a version of Drupal that came out 4 years ago and will be [to one degree or another] no longer supported by August 2013.
Bob... As you look into this I would be very curious to see what you find. Are there indeed modules that you're depending on that are not D7 ready?
thnx!
Very true. I choose D7 even
Very true.
I choose D7 even though Commerce was still a very "new" module. The capability was worth the hassle. Plus the time it has taken me to build this site has allowed a lot of development time for contributors. And I'm ready to start contributing back via documentation :)
Brady
@fastglassllc
@derailedonline
To clarify, Doug, I am not
To clarify, Doug, I am not confused when it comes to choosing D7 over D6 for a greenfield project.
However, for a complex D6 project that makes important use of numerous contributed modules, the question of whether or not to port the site to D7 does not have an obvious answer. The task becomes a bit easier now that I have learned about the Upgrade Status module. It allows me to easily hone in on those contributed modules I use on D6 that have not been ported to D7 or are in the process of being ported.
Of course, speaking as a Drupal information architect and site builder -- and having come to Drupal with lots of experience in Java enterprise framework architecture and hands-on engineering -- the overarching problem here is Dries' attachment to not mandating and ensuring that Drupal core supports 'backwards compatibility' between major version releases. This stubbornness will in time bite many large Drupal deployments in the butt, especially once the owners of those sites look into the costs and uncertainties of upgrading their now-old Drupal projects to Drupal's latest major version. I see a major backlash coming in the future. It also creates a disincentive and oft-expensive hurdle for contrib module maintainers to upgrade their projects for each major version release. Etc.
[My other major gripe is Drupal's lack of proper, complete separation between content plus other usage data, on the one hand, and configuration state on the other. This is the primary root cause of the many obstacles to clean, robust, and easily repeatable Drupal process, namely cycles of local development by individual team members <-> merging of their work plus conflict identification and resolution <-> team testing, manual and automated <-> deployment to production.]
My 2 cents.
Cheers,
Bob
Two quick points
The backwards compatibility problem has been brought up before, and there's some consideration for re-thinking it (http://groups.drupal.org/node/210973) but probably not until after D8 due to the major re-architecting that's going on right now.
If you're considered about content vs configuration make sure you're using Features and exporting everything, that's the first step towards sanity, the second is installation profiles, the third is update scripts.
A couple of questions
My understanding is that exports and Features are supported pretty much across the board by D7 projects. Yes/no?
With D6, is there documentation on how to make non-exportable modules exportable?
Is it true that Drush make supports both the creation and use of installation profiles? Are there other mechanisms out there? Any recommended documentation on creating and using install profiles?
Thanks, Damien.
D6 vs D7
It's less that D7 has universal exports, just that more modules are being updated to support exportables as part of their D6->D7 updates, and thankfully much of this effort is still being backported to D6. Many modules have added support for exportables in the past two years, and ones that don't often have patches available for you to try (check their respective issue queues).
Drush make can help managing features, but building an installation profile is super simple - just list the modules you want in the profile's .info file as a dependency and they'll be automatically enabled when the installer runs; take a look at profiles/standard/standard.info for a good example.
I'm going to be doing a series on building sites with Features and installation profiles for the Keene meetup, if you'd care to come over :)
Damien
Thanks again. Do you have
Thanks again.
Do you have screen sharing and voice set up for the Keene meetups? Its quite a haul from Portsmouth and back.
Bob
Not currently, but we'll see
Not currently, but we'll see if we can work something out for the next one.
And I may have figured that out
just need a call to:
drush_set_context('DRUSH_BOOTSTRAP_PHASE', DRUSH_BOOTSTRAP_DRUSH);drush pm-releases
To spot check, you can just tack -7.x to a pm-releases call for any project.
$ drush pm-releases upgrade_status-7.xNo release history available for upgrade_status 7.x. [warning]
No valid projects given. [ok]
versus
$ drush pm-releases apachesolr-7.x------- RELEASES FOR 'APACHESOLR' PROJECT -------
Release Date Status
7.x-1.x-dev 2012-Jul-11 Development
7.x-1.0-rc2 2012-Jun-21 Supported, Recommended
If you're not sure which project a particular module comes from, you can also use
drush pm-info$ drush pm-info textExtension : text
Project : cck
Type : module
Title : Text
Description : Defines simple text field types.
Version : 6.x-2.9
Package : CCK
Core : 6.x
PHP : 4.3.5
Status : not installed
Path : sites/all/modules/cck/modules/text
Schema version : no schema installed
Requires : content
Required by : features_test, nodereference, userreference
Fixed group
This post was erroneously added to the Drupal Association group as well. I have removed it from that group. Please be careful when selecting groups that you don't start flooding the inboxes of people who are not involved. Thank you.
I didn't know we needed
I didn't know we needed fixing? :)
Hey, you look an awful lot like Dick Tracey...