Show suggested replacement for obsolete modules

Sure! :) Mind to create a patch, including views_bookmark/flag?

subscribing. It'd be really nice to know about other modules that have been discontinued, but have been replaced with other modules, such as default filter being replaced by better formats.

Most such modules don't really have a way of denoting that information though, so something like #620714: Denote modules which are in D7 Core would have to be done, right? You could have data like

$projects['default_filter']['defunct_since'] = '6.x'; //project doesn't exist after drupal 5.
$projects['default_filter']['defunct_note'] = 'Better formats replaces this module, see http://drupal.org/node/222497';
$projects['default_filter']['suggested_replacement'][0]['name'] = 'better_formats';
$projects['default_filter']['suggested_replacement'][0]['comment'] = '5.x';

The [0] is because a defunct module might have multiple replacements.

I don't know how this info should be added. Would it have to be hard coded, or could there be a list that can be updated separately to the module, that could be downloaded when needed?

Should we introduce UPGRADE_STATUS_DEPRECIATED and just list out the modules like we did for UPGRADE_STATUS_CORE?

I don't know of any D7 modules that fall into this category.

#2 pretty much cuts it - deprecated needs to differ between (entirely) discontinued (but which is actually the same as not ported yet) or discontinued in favor of one or more better replacement(s).

I only recommend doing this when the maintainer specifically notes the replacement module. Can we do something like:

$discontinued = array (
  "old" => "new";
  "ed_readmore" => "read_more";
  "tinymce" => "wysiwyg";
)

Then instead of checking the depreciated module for releases, we would check the replacement. Then output the status text as "Depreciated" or "Discontinued" with the background and icon matching the status of replacement module. So if there is a stable D7 replacement, the icon and background would be green. If the replacement is still being developed, the background would be yellow.

Further thoughts on this:

- There can be multiple valid replacements for a deprecated/discontinued module.

- Having thought about this a bit more, I don't think that there really is a "discontinued" module state in Drupal. If you need a module for a new Drupal major version, then you can always port it yourself, and if required, also take over the project and maintain it in the future.

- We probably want to limit our hard-coded assignments to modules that actually provide an upgrade path from the discontinued module.

- It would be totally awesome if we additionally checked the availability of the replacement modules. ;)

- We may need a new color, as such modules neither really fit into the current error nor the warning color categories. Replacing a module with a different, on top of a upgrade, is usually lots of extra work.

- There can be multiple valid replacements for a deprecated/discontinued module.

I don't think we should make any assumptions about replacements. That will make maintaining this module very hard. Let the maintainer of the depreciated module make the decision and post it clearly on the modules page. I consider this functionality a need when two module combine forces, which is common during the porting phase.

- We probably want to limit our hard-coded assignments to modules that actually provide an upgrade path from the discontinued module.

I don't think that is as important as having clear understanding that this module is dead, but another is alive and kicking. I leave that into the "nice to have" category.

- We may need a new color, as such modules neither really fit into the current error nor the warning color categories. Replacing a module with a different, on top of a upgrade, is usually lots of extra work.

I think the more stuff you add to the interface, the less clear the interface becomes to understand. We don't want to provide a key to understand the color scheme.

Now, I'm no longer sure I understand your proposal. Isn't #5 a hard-coded list of suggested replacements? But in #7 it sounds like you specifically don't want to do that, but leave the actual replacement announcement to the project page? Which would mean that we would only mark a project as deprecated + perhaps output a note to find further info on the project page. I'd agree with that.

Sorry, I should have been more clear. We should maintain a hard-coded list in this module.

I just think the hard-coded list should be directly based on an announcement on the project page. We don't want to get into a situation where we have to assume things. For example, I expect issues to be submitted saying something to the effect of "this module hasn't been updated for a year, this other module is better, so add the old module to the list."

We need to have a clear criteria for the list so it can be easily maintained. I think using an upgrade-path as a criteria is too specific, because some module don't have much to upgrade. So that is why I suggest basing it off an announcement.

Well drupal.org calls them "Obsolete" so maybe we should follow suit.

Here is a list of obsolete D6 modules sorted by usage

Another good criteria for such a list is usage. Is only 10 people are using the module, is it work the code change? What that number should be, I don't know. More than 25?

This is very tough topic.

Yes, we don't want to do presumptions or overrule module maintainers in any way. Thus, the most flexible and ideal approach would be to defer the replacement suggestions to the project maintainers themselves. The most simple way for them to announce replacements would be the project page - which is what most projects that are tagged as obsolete are actually doing. While we could just note that a module is deprecated, the community can easily edit the replacement info at any time, without touching this module's code.

But then again, there are also even well known projects like Buddylist, which is not even tagged as obsolete yet, and also contains no replacement info at all - although most people in the community know that there are 2-3 valid replacements, from which some are even providing a upgrade/migration path from Buddylist.

While automatically retrieving the info from drupal.org sounds awesome, I don't think it will work. For starters, if projects like Buddylist don't even manage to update their project page, then expecting a commit change the .info file is even more far away. Second, auto-suggesting a repository and accessing and parsing info from CVS is a complete nightmare, which would have to be added on top of the already performance-heavy release fetching and comparison process. Third, adding replacement project information to Project module as well as project release XML data is unlikely to happen.

We really have 2 issues here:

- Display an upgrade status for obsolete module. (Instead of "No available releases found" it should say "Obsolete")
- Show the replacement (if available) for obsolete modules.

I think with cases like Buddylist, we might start running on too many assumptions. Although, specifically with Buddylist, it's obvious it was replaced by Buddylist2 by the same maintainer and on the new project page the maintainer recommended using Friendlist for D6.

Personally, if I had module that was assumed obsolete installed, I wouldn't like upgrade status to telling me about a replacement because it would require a bunch of research regardless and since it is based on assumptions upgrade status could end up being wrong. But if the module maintainer is confident he is no longer developing that module and has a suggestion for replacement, that could be a huge time saver to display in Upgrade Status.

Display an upgrade status for obsolete module. (Instead of "No available releases found" it should say "Obsolete")

I still don't think that this type really exists - a module either has not been ported yet, or it will most likely not be ported, because better replacements exist, or it won't be ported because it's in core. I.e., an "obsolete" on its own, without replacement or movement into core, does not exist.

Your right. I'm writing "Obsolete" but I'm meaning "Abandoned".

Such is the case with:
http://drupal.org/project/qamodules

Ideally, we'd have the folks at Drupal.org Webmaster create a nice XML view of all modules categorized as Obsolete or Abandoned then we can use that to generate the proper status message and perform a check against the hard-coded list of replacements.

I'm wondering if it might be useful for this issue to have a separate taxonomy for modules on drupal.org giving their current development status (eg. alpha, active, hiatus, abandoned, etc.). Would such a taxonomy be accessible to Upgrade Status? If so, I'll open another issue.

Subscribe. I have two modules which are moving namespaces for D7:
nodewords -> metatags
path_redirect -> redirect

i will contrib, in time, and when i have time, a huge list of alternative modules and their replacements (within 6.x and 7.x)

for the time being, check my topics here at similar module review ;)
http://groups.drupal.org/similar-module-review

IMO, note some possible definitions bellow...
measurement of portability:
- some modules are not ported, but became part of a new version core (like ImageCache in D7)
- some modules are ported backwards (ie, backport from D7 to D6)
- some modules are ported forwards (ie, ported from D6 to D7)
- some will be ported (as per project page)
- some won't be ported at all
- and for some, we might not have information
measurement of activity (relation to how probable is a module to become unsupported):
- some are active and supported
- some are supported, but not in active development (though functional)
- some are unsupported (no developers around by various reasons, like lack of time, lack of interest)
- some are abandoned (marked as abandoned by the developers)
- some are deprecated in favor of others, within same version (ie, in D6 - Filefield Insert and Insert)
- some are deprecated in favor of others, within different versions (ie, in D7 - jCarousel and Carousel, Thickbox and Colorbox)
- and for some, we might not have information
measurement of priority:
- some would be required or optimal to have/upgrade
- some are entirely optional to have (yeah, maybe the module should provide other info than just upgrading ;))
- some would be critical to have or critical to remove, due to security risks
- and for some, we might not have information
measurement of versioning:
- some are stable (1.0, 2.0, 3.0, etc)
- some are unstable (1.0-alpha1, 1.0-beta1, 1.0-rc1, etc)
- some are in development (1.x-dev, 2.x-dev, etc)
- and some do not say the version (custom modules)
general:
- again, don't forget those without information... (maybe deleted or never had a project page)

so i'm thinking that modules should have thereof, the following tags:
- versioning: stabe, unstable, in development, no info
- priority: required, optional, critical, no info
- activity: active, supported, unsupported, abandoned, deprecated, no info
- portability: in core, ported backward, ported forward, being ported, no port, no info

have fun brainstorming ;)

i trowed everything in this new issue

my brain is probably busted now because it's 10am and i didn't sleep :P

been contacting some developers through their project issue queue... posting some info on modules
administration modules:

• admin_menu has a D7 port. it's the best top menu module i know of, but has 2 D6 alternatives: toolbar and simplemenu. it's also more flexible than D7 core toolbar module.
• simplemenu has a D7 port. admin_menu is a more suitable alternative. after pressing the developer, he stated that it won't be deprecated or merged with admin_menu or other similar modules.
• toolbar is an unofficial D7 backport of toolbar to D6, with no D7 version obviously. but admin_menu is a more suitable alternative.
• controlpanel has no info yet on a D7 port. has no direct alternative yet and integrates well as blocks in total_control.
• total_control will have a D7 port when Panels and Ctools are stable enough. there is no better, more complex solution than this, and it clearly is more functional that D7 core dashboard, though slower and more complex.
• managesite likely will not have a D7 port because the feature is in D7 core dashboard. but is a simple alternative to total_control in D6.
• udashboard will not have a D7 port. the module will likely be deprecated in favor of the alternatives: total_control and managesite.
• admin has a working D7 port. it's an optional alternative to navigate.
• admin_tools has a working D7 port. it integrates with admin.
• navigate will have a D7 port. it's an optional alternative to admin.
• supernav has been deprecated in favor of navigate.
• admin_dashboard has no info yet on a D7 port. there is better alternatives:
• admin and navigate.
• filter_perms has no D7 port. it doesn't overlaps with the other permission modules; it allows filtering permissions. should be merged and i have notified them.
• permission_select has a D7 port. there is no attempt to merge it with the other 2 modules, but i have notified them. (this module is slow)
• check_heavy_ui is abandoned and has no stable promoted release, only a unpromoted dev release. there is no attempt to merge it with the other 2 modules, but i have notified them. (this is the faster module)
• allperms has no D7 port. there is no attempt to merge it with the other 2 modules, but i have notified them. (this module is slower)
• better_perms has no D7 port or any news on that. it doesn't overlaps with the other permission modules; it allows collapsing/expanding permissions. should be merged and i have notified them.
• module_filter has a D7 dev port. it's a good working module that allows vertical_tabbing module groups and searching/filtering with autocomplete, though a bit slow when there's a huge list of modules.
• enabled_modules has a D7 port and is a fit replacement for used_modules.
• used_modules developer agreed to list enabled_modules as alternative, and will when he has time, decide or not to deprecate his module.
• fixcore has no replacements/alternatives and probably will have a D7 port accordingly to the developer, because one main feature did not got in.
• util will likely also have a D7 port, noted in the project page.
• drupal_tweaks has no info yet on a D7 port, but the developer has said he will look into a merger with util.
• db_tweaks has been deprecated in favor of drupal_tweaks, which incorporated all of the functionality.
• mini will likely not have a D7 port because many of the features are part of D7 core, but is looking into a merger with one of the above modules.

LPCA - I think your missing the point of Upgrade Status. We want to help site builders answer one question:

Is my site ready to be upgraded to the next major version of Drupal?

Manually tagging every module on drupal.org isn't valuable enough to answer that question. Not to mention the insane amount of work involved to catalog every module. It's hard enough to keep the wiki pages of Similar Module Review up to date with module development. Adding a issue and patch workflow to keep the information update to date will only make things worse.

LPCA - Also, this issue is to address the problem where modules will not be ported because the maintainer has either specifically announced a replacement (such as comment #18) or possibly in cases where a module is clearly abandoned and the community has identified a clear replacement.

Another issue should be created if you would like to discuss adding a "Similar Modules" feature.

okay, i'll do that ;)

not sure is has been added, but ImageField replaces Image and is in D7 core.

administertooltip,
contextual and
contextual by swentel (no longer developed)

are examples of modules that could replace completely or partially these older ones:
- block_edit
- admin_links
- fasttoggle
- admin_hover

some of these are somewhat abandoned.
administertooltip is the more complete (and heavier) of the triad

all D6
--------------------

password replaces phpass, which might be deprecated soon.
salt is also replaced by the two above, as it is effectively unneeded (and officially deprecated) with stronger hash methods (it was pointed that way for D7 password.inc method)

all D6 too

deck replaces 2 modules:
- cck_teaser_field (looks abandoned) EDIT: developer marked it deprecated after i contacted him
- cck_teaser (looks abandoned)

deck is currently maintained, works, and behaves a bit like Drupal 7 core teaser's feature.
it adds a separate field (stored in cck) to input the teaser... or optionally computes it from the body, the standard behavior

if that hasn't been noted yet:
- insert deprecates filefield_insert
- filefield_sourcesdeprecates imceimage

mvf replaces money

read more: http://drupal.org/node/959996, http://drupal.org/node/960000

This thread appears to have lost its way a bit here. The original proposal was excellent. I maintain http://drupal.org/project/gmaplocation which has had a namespace change to http://drupal.org/project/locationmap in D7. I was considering releasing a D7 version of gmaplocation that just displayed a system message to admins instructing them to install locationmap module, so that the module would not appear in Upgrade Status to be still awaiting upgrade. However, hard-coding this link into Upgrade Status would be a much better approach and would be a boon for users. This'd be great to see added.

Role Weights deprecates Role Weight

read here: http://drupal.org/node/421624

WYSIWYG Fields deprecates WYSIWYG ImageField

http://drupal.org/node/252938#comment-3104796
link-to-content replaced by linkit.

Taking this issue back again to its roots, I think we can safely start here with totally non-controversial replacements, where the module maintainer themselves has edited the project page and said "Go use X instead in D7."

For the top 50 modules, those would be:

fckeditor -> ckeditor
nodewords -> metatags

While fckeditor arguably *should* be replaced by wysiwyg, this isn't the recommendation of the maintainer. It's not Upgrade Status module's place to be opinionated about this; it should respect the wishes of the maintainer.

While lightbox2 has many, many modules that do somewhat the same thing, there isn't (currently) a recommendation on the project page to use something else. Therefore, we keep it as "No available releases".

Going to see if I can whip up a patch for this.

Ok here's a basic stab. Still needs lots of work.

Notes:
- I went with 'obsoleted_since' and 'replaced_by' as the properties, like:

+    case 'fckeditor':
+      $projects[$project]['obsolete_since'] = '5.x';
+      $projects[$project]['replaced_by'][0]['name'] = 'ckeditor';
+      break;

As outlined above, replaced_by is a multivalue field. I figure that can be handy for modules like CCK which are replaced by fieldgroup, references, and a few others.

- Added a new constant UPGRADE_STATUS_OBSOLETE, which I defaulted to 5001, which was pretty much a shot in the dark, since I have no idea what the numbering scheme there should be.

- The row colour for obsolete modules atm is green. I couldn't figure out how to search for the replacement module in question and get its upgrade status info, but I'm also tired. :P

- There are some minor cosmetic changes that should probably still happen. For example, linking the name to the project page. Maybe adding a notes field too, not sure.

Could project pages on d.o have an optional "deprecated by" module auto complete field? Then this could all be done automatically, no?

They could, in a completely and utterly separate issue. ;)

But since Upgrade Status is your "one-stop shop" for "Is my site ready to go yet?" I think there's value in putting that information here.

Sorry, but I'm -100 to fckeditor_upgrade_status_obsolete_alter(&$projects) {. Because...

1. The upgrade_status_moved_into_core() already introduced this "switch on project name" pattern (presumably for some of these reasons), so the precedent's been established; we're just repeating it again here.
2. The whole point of this patch is that these modules are obsolete. :) Therefore, by and large, they're not getting commits/releases anymore, so such patches would just sit there forever. FCKeditor is a perfect case-in-point.
3. So unless a user has both the latest version of Upgrade Status and X patches against Y modules, they aren't getting a full picture of the upgrade status of their site. That makes this module useless. :\
4. But even if we did the workflow of submitting a patch and then if it stalls out, put the patch in upgrade status instead, the second you've upgraded Nodewords after it finally accepts the patch, but have not upgraded Upgrade Status at the exact same time, BOOM your site dies with a fatal error. :(
5. Furthermore, even in a case such as nodewords where the module is maintained on a nominal basis in the previous version, such a hook would require a module developer to introduce code into their critical path (hooks have to go into .module files, which are loaded on every page load) for a page at one URL on 0.000001% of sites. I can't see most of them doing it.
6. A hook would also prevent #1220536: Show status of disabled modules on admin/reports/updates/upgrade, which would allow providing a nice automated report on module porting without community members having to manually compile this list themselves periodically.

So, no. Let's please not do that. :) There's tremendous value in having a single, curated source for this information, and as long as visibility around this module is increased (also on my todo list), it's a wash for a module developer to provide a patch to their own module to add a hook_upgrade_status_obsolete_alter() or just provide a patch here.

Oh, but fair enough on the wording change and the whitespace fixes. I'll try and get to this on Monday.

While @nedjo's idea and proposal initially sounded nice to me, @webchick's counter-arguments are very compelling and dominant. ;)

+++ b/upgrade_status.compare.inc
@@ -303,8 +303,16 @@ function upgrade_status_calculate_project_data($available) {
     else {
-      $projects[$project]['status'] = UPDATE_UNKNOWN;
...
+      // US: Check if the project is obsolete.
+      if (upgrade_status_obsolete($projects, $project)) { ¶
...
+      else { ¶
+        // US: Darn. Out of luck.
+        $projects[$project]['status'] = UPDATE_UNKNOWN;

We can skip the second US-comment for UNKNOWN by turning the wrapping else into an elseif, and thus, retain the original else as-is. If that makes sense. ;)

In other words: Leave the final unknown case alone, just inject an elseif for the obsolete check.

+++ b/upgrade_status.module
@@ -27,6 +27,11 @@ define('UPGRADE_STATUS_STABLE', 5);
+define('UPGRADE_STATUS_OBSOLETE', 5001);

IIRC, the CORE constant was crafted after the STABLE constant (which is the same value as UPDATE_CURRENT, since these are "technically" the same), so

5 = current/stable
5000 = even more stable, 'cause in core ;)

Thus, for the obsolete case, we should do the same...

3 = UPDATE_NOT_SUPPORTED = "Current release is no longer supported by the project maintainer."
3000 = UPGRADE_STATUS_OBSOLETE = "Project has become obsolete by another module."

At least I think those two would be closest.

Wow, that took awhile to get back to. Sorry about that. Here's an updated patch incorporating sun's feedback.

That patch breaks some indentation and some other things, so it still needs work.

However, here's a before/after screenshot so you can see what it does currently.

Before:

After:

This is not quite right either, though. Ideally, we'd have the full project info for those replacement projects and set the table row colour based on that. While both Profile2 and CKEditor have stable D7 releases, http://drupal.org/project/metatags does not and it should be yellow.

Hey! How about one that actually applies? :P

Whitespace fixes too.

Things that help: Uploading the correct patch.

Grumble, mutter. I'm getting pretty turned around in the code flow here.

My idea to solve this was to inject the replacement projects into the $projects array so I could hinge off the stuff that grabs project data from Drupal.org.

I first tried to do this with a hook_update_projects_alter(). But this is no good, as it affects the Update Status module information as well, which you don't want.

I next tried to do this in _upgrade_status_refresh(). That worked, and it was able to fetch the replacement projects' XML data and cache it in the upgrade_status_available_releases bin. So far so good.

However, when upgrade_status_calculate_project_data() runs to populate the upgrade_status_project_data cache bin, it calls update_process_project_info() (the function which determines the project status), which is looking for .info file information, which I don't have, since the module doesn't actually exist in my local tree. This in turn makes it impossible to determine the porting status (dev etc.) for these modules. Hrm. :\

Ok, here's about as good as I can get for tonight. I'm sure this needs more streamlining since I re-wrote it like 50 times. It'll also currently show false positives because it just makes all obselete ones "ok".

But, this is what it looks like:

See also #1277032: Identify possible alternative modules where I've split off some of the other questions in this thread.

For the next re-roll, path_redirect -> redirect.

@webchick: I'm sorry to have to change this (we did it as soon as we could) but 'metatags' is now 'metatag' as the shortname. Feel free to hate me forever.

LOL. :) no problem. I'll make the update early next week.

Here you go... Stay classy.

What ever happened to this issue? It's going to be useful again soon, for D8.

Not as soon as we'd hoped, but yes.. I like the idea and there are lots of obsolete modules...

Here's a re-roll of the patch from #51, It still needs data about D8 to be useful though :(

Still applies and doesn't appear to cause any problems.

Can someone tell me what all of the comment prefixes "US: " mean? I was tempted to strip these, but they were already in the code so I figured they're there for a reason unbeknownst to me.

Just adding some D8 data...

All done for now. Please open new issues to add/edit/delete data.