Problem/Motivation

Currently Drupal does not support partial dependency information. That is: Module A depends on Module B to work. This is insufficient and necessitates userland solutions (views recommending advanced_help via a drupal_set_message, og recommending og_views via bold text on the module page).

The bulk of participants in this thread agree that including this extra metadata would be useful, the main debate forms around the keywords used. The current proposal is suggests and enhances) is backed by the debian package keywords, and the following real world examples (the examples also demonstrate that relationships are NOT bi-directional):

The Debian package keywords are: depends, recommends, suggests, enhances, breaks, conflicts. If we adopt suggests and enhances then:

  • "recommends" is just a weak "dependency" and will confuse users.
  • "enhanced by" is covered adequately by suggests.
  • "depends" is covered already.
  • "breaks"/"conflicts" are problems for another issue.

Real world examples:

views and advanced_help:
- CORRECT: views suggests advanced_help.
- INCORRECT (advanced_help shouldn't have to know this): advanced_help enhances views.

regcode and role_expire:
- CORRECT: regcode suggests role_expire, its functionality is enhanced through a series of if(module_exists('role_expire')) checks. This relationship is important.
- INCORRECT (this relationship is meaningless): role_expire enhances regcode.

path and pathauto:
- INCORRECT (path won't know about pathauto): path is enhanced by pathauto.
- CORRECT: pathauto enhances path.
- CORRECT: pathauto suggests transliteration.

views_bulk_operations and views:
- INCORRECT (views shouldn't have to know about vbo): views is enhanced by views_bulk_operations.
- CORRECT: views_bulk_operations enhances views.

Proposed resolution

Adding two new supported keywords (suggests and enhances) to module.info files, with the following definitions:

  • module_a suggests module_b: module_a's functionality is significantly improved with module_b is enabled. This tag is recommended only when module_a has "module_exists('module_b')" in its code.
  • module_a enhances module_b: module_a was written specifically to extend the functionality of module_b.

Remaining tasks

  1. Write a patch implementing this behaviour for D8 (see #68).
  2. Backport this functionality into http://drupal.org/project/module_supports
  3. Write patches for the project module so this information can be displayed on project pages

User interface changes

The modules page will display suggests and enhances besides the existing dependencies.

API changes

The following variables become valid instructions in a .info file:
suggests[] = ...
enhances[] = ...

Original report by Myke

I am proposing an addition to the .info module files for Drupal:

Some modules have optional dependencies that enhance the function of the module. It would be very nice if Drupal were to report these, through a field such as:

enhanced_by = "cck views"

In a similar fashion to how the dependencies are shown.

This would allow Drupal to notify administrators when a module can further be enhanced by installing a module they may not already have.

Comments...?

-Myke

Notes

1. STOP DEBATING THE KEYWORD NAMES IF YOU HAVEN'T READ THE WHOLE ISSUE - YOU ARE REHASHING LINES OF ARGUMENT THAT HAVE ALREADY BEEN DISMISSED. If you have a suggestion for different keywords, then provide pros and cons and real world examples.
2. STOP TALKING ABOUT BREAKS/CONFLICTS. Yes, this is needed, but let's address that in another issue: #92233: Modules in conflict - conflicts[], breaks[], brokenby[] field in modules .info file.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

myke’s picture

Another side effect of this, Drupal could notify someone if the enhanced by module is available, but NOT enabled, that enabling the module will enable additional functionality in the module.

-Myke

Dave Reid’s picture

This is a nice idea, but I feel this is something that should be up to the contrib maintainers to have documented in the project pages and README.txt files. I think this has the ability to get too complicated and overly informative, so if this were to move forward, we need to be careful to keep things simple and understandable.

eaton’s picture

I think there's value in separating the "requires" and "supports" concepts in module info files. While README files are certainly useful, it's metadata that we can put to good use, with very little overhead. Being able to track the number of modules that support but don't require Views, Token, and so on would give us better ideas of where critical interactions lie when it comes time to upgrade, as well.

It's also important to keep in mind that nothing prevents module authors from adding 'supports[]' lines to their module info files right now...

myke’s picture

I agree, this information SHOULD be in the project pages, README.txt files, and any other documentation. But I also believe having it as an attribute in the module could be useful in multiple ways, some of which probably haven't even been thought of yet.. =)

As far as keeping things simple and understandable, it would basically be just like the dependencies, except for the fact that the module would still install if the optional components aren't installed.. It would just have another field that can be added under admin/build/modules for each module.. Seems simple enough.. we just need the correct variable name so it's clear what the purpose is.

-Myke

myke’s picture

Do you think supports[] adequately describes the purpose of this variable?

I think something more like:

optionally_supports[] could be a better choice, as it more clearly describes the purpose of that variable.

But let's discuss what to call this, and the specifics of it, in hopes of getting it into core.. I'd love to see this feature implemented and it doesn't seem very complicated to implement..

-Myke

Michelle’s picture

I like this idea. It's a nice way of seeing what modules work well together.

I wonder if the reverse would be worthwhile? There are some modules that conflict with each other. I'm not sure there are enough of those to warrant making a special notation for them, though.

Michelle

myke’s picture

I think that could become a whole other feature request, a conflicts_with[] variable.. =) Plus there is the possibility of conflicts being mentioned in only one module and not the other, as the first module would have been released before the conflict was found..

-Myke

myke’s picture

Also, having that ability in core, if a core modules functionality was enhanced through the actions of the particular module, it could show that fact.. (With a link to download it, as in with the updates module...)

-Myke

myke’s picture

Here is some code that can be added in to system.admin.inc in the modules/system folder, to enable the enhanced by field. This should be added after the dependencies section.. I will test it out for Drupal 7.x and post a patch, this was made in Drupal 6.6.. But seems to add the enhanced by field with no problems.

	$supports = array();
	// Check for modules this module is enhanced by
	  if (is_array($file->info['supports'])) {
      foreach ($file->info['supports'] as $supported_module) {
        if (!isset($files[$supported_module]) || !$files[$supported_module]->status) {
          if (isset($files[$supported_module])) {
            $supports[] = t('@module (<span class="admin-disabled">disabled</span>)', array('@module' => $files[$supported_module]->info['name']));
          }
          else {
            $supports[] = t('@module (<span class="admin-missing">missing</span>)', array('@module' => drupal_ucfirst($supported_module)));
            $disabled[] = $filename;
            $form['disabled_modules']['#value'][$filename] = FALSE;
          }
        }
        else {
          $supports[] = t('@module (<span class="admin-enabled">enabled</span>)', array('@module' => $files[$supported_module]->info['name']));
        }
      }

      // Add text for supported modules.
      if (!empty($supports)) {
        $form['description'][$filename]['supports'] = array(
          '#value' => t('Enhanced by: !supports', array('!supports' => implode(', ', $supports))),
          '#prefix' => '<div class="admin-dependencies">',
          '#suffix' => '</div>',
        );
      }
    }
phdhiren’s picture

I really like the idea of 'optionally supports'
+1 to be included in core D7.

myke’s picture

My theory, is that module authors could vote for this by adding supports[] into their .info files.. =)

-Myke

Dave Reid’s picture

I just created a contrib module for this feature: http://drupal.org/project/module_supports. D6 release should be available shortly.

myke’s picture

Wouldn't Drupal 5 be using the old module system?

As in, instead of using:

dependencies[] = content
dependencies[] = views

Wouldn't it use this setup for Drupal 5?

dependencies = content views

Just wondering.. I didn't test any of that code out for Drupal 5..

-Myke

Dave Reid’s picture

The code in #9 will only work for D6+. Different code would be required for D5.

myke’s picture

...And I don't see a lot of people back porting this into their Drupal 5 modules.. so I think we should stick with Drupal 6+

-Myke

Dave Reid’s picture

This feature itself can only make it into D7 since that is the only version that can accept feature requests. D6 and D5 are locked for bug fixes only. If we want this feature for D6 and D5, we have to use a contrib module, which I provided in #12.

myke’s picture

Thank you for putting it into a module for D6 btw.. =)

Thanks
-Myke

rszrama’s picture

Nice idea... now I wonder if I should put supports[] = module_supports in my .info files for D6. ; )

We'll update Ubercart 2.x-dev for this if it tests well.

myke’s picture

Now about getting this into Drupal 7 core.. =)

-Myke

webchick’s picture

Dave Reid’s picture

Component: base system » system.module
FileSize
5.4 KB

Here's my first stab at this. Removed some left-over obsolete code from system_modules() as well. Should this also work two ways like dependencies (dependencies + dependents)? Something like 'supports' and 'enhanced by' for the supported modules?

Dave Reid’s picture

Status: Active » Needs review

Forgot to change status...

catch’s picture

Nice idea, if we had this, we could also use the information on Drupal.org like in http://groups.drupal.org/node/11998

conflicts[] is a good idea, but also another issue.

apt sometimes recommends packages that aren't actually dependencies when you install something, this seems pretty similar to me.

myke’s picture

So you mean, show modules that a module enhances, not just the ones that are enhanced by, in a very similar fashion to how required by / requires ?

I think this may be a good idea as well..

=)

-Myke

Dave Reid’s picture

Maybe we should use 'integrates' since that can work both ways. Trying to work out enhancers and enhancees seems like it would make this too complex.

myke’s picture

So "Integrates with" if the module will enhance the module currently being listed, and "Integrates into" if the module will enable additional functionality within the module listed?

Or did you have something else in mind?

-Myke

webchick’s picture

Could we see a screenshot of the modules page with this patch?

I'm fearful that it might make that even more like "information soup" and am curious how that's being handled.

moshe weitzman’s picture

Yes, I've wanted this for a long time ... I looked at core modules and didn't see a good place to use this. No matter - contrib will love it.

aside: You'd be a hero if you refactored the dependency checking stuff out of the form handling so it could be used in drush and plugin_manager

Wim Leers’s picture

Yes, please! :)

HS integrates with … 7 modules at the time of writing. I think it would be very helpful for users if they had a single, central place for seeing which modules integrate with other modules.

Dries’s picture

This patch seems to use conflicting terminology; support vs enhanced.

Also, it seems like this information would be more useful on the d.o download pages than in the module admin page. On the module admin page this translates to a regular dependency IMO. If A enhances B, then well, A is dependent on B. It is not clear to me what is broken?

Not sold yet.

moshe weitzman’s picture

Dries - the main benefit is if you only have B installed. You need to know that your site will become much more powerful if you install A.

Just one example - OG is enhanced by token, rules, trigger, ... I know that many site admins are unaware of this.

webchick’s picture

Actually, Dries raises a good point. This sounds a lot more like a drupal.org tool rather than a .info file tool. I'd like to know a module is enhanced by rules/triggers/etc. before I even download it to try it out.

Michelle’s picture

I'm admittedly coming at this from a perspective of not having looked at the patch but my impression from reading the issue is that this info is going on the modules page? Maybe it would be better if it generated a new report along the lines of update/upgrade status for "Improve your site status". Yeah, ok, needs a better name. But the point would be to have a page that lists the status and links to all the modules that your existing modules suggest would make them better.

Michelle

catch’s picture

If it's in .info files we can use it in core/contrib if there's a use for it and also parse them and use on Drupal.org too along with real dependencies (assuming that code gets written). It'd be easy enough to do things like nodereferences just on Drupal.org though if we absolutely can't think of a use case for Drupal sites themselves.

myke’s picture

I've also thought of using this to enhance the Updates section, having an enhancements section..

-Myke

myke’s picture

There are modules, that work with other modules, but don't necessarily require them.. this is where this would come in..

-Myke

webchick’s picture

Status: Needs review » Needs work

Yes, myke. We understand the feature being proposed. The question is whether it belongs in Drupal core or on Drupal.org module pages. It seems to me the latter would be more appropriate. This way people can tell *ahead* of time that a module integrates well with others, before they actually download it. The added benefit too would be that we could roll this out as soon as it's implemented, rather than having to wait until Drupal 7+ which is probably another year away from being used "in the wild."

If you're still convinced it needs to be in core, then let's see a mockup of what this looks like and what enhancements it would provide being within Drupal itself. Otherwise, please move this issue over to the Drupal.org infrastructure queue for discussion.

catch’s picture

Worth looking at is this issue against Project module: #102102: Parse project .info files: present module list and dependency information - since D6 modules can do this already, I'd be tempted to say that we should get support for it for contrib and D6 on Drupal.org itself - since undoubtedly this is where it's most useful. Use a similar syntax as what's in the patch, but since core modules don't really enhance each other very much, it'd only be a UI that we'd be putting in.

dman’s picture

and... just before I hit the end of the thread and make a post, catch provides the link to the related topic I was thinking of.

Anyway.
Yeah, this is a d.o. 'enhancement'. A list of modules that extend a given module would be great in a project tab. Finding the dozen modules that actually do extend image.module would be better than trawling the topics and searching through alternative image galleries and imagefield extensions.
Gives a great bit of feedback on usage also.

There is less that can be done on a local system admin/modules page, as the relationship between available modules is why you downloaded them in the first case, and your system doesn't have knowlege of external add-on modules. The patch here is fine, but doesn't really hit the purpose of the feature IMO. Unless the remote status update started feeding out that info also ;-) !
If it was saying "If you had this extra module, you could do more" is interesting (the first time anyway).
Currently it can only say "You've already got this module available, why not turn it on?"
How useful is that?

OK, Here's a question.
How does this glue together with multi-module projects? The dependancy/enhancement map works fine on a 1:1 module.info basis, but gets grey when relating projects to projects :-/
... A bit of a diversion there, but it does make d.o/projects handling different from admin/modules parsing.

moshe weitzman’s picture

I can't find the link, but when we were talking about adding .info files, I stated that they were an ideal place for module metadata that would be re-used by drupal.org. I gave then example that we should display dependency info and 'enhanced by' information on both the drupal admin and on drupal.org. In fact, we should be removing some fields from the project node and relying instead on .info. I explained this so nicely that Dries credited my explanation and asked us to proceed with plain text .info files instead of a PHP array. I had stated that PHP is unsafe for drupal.org to parse, so we should use plain text. Perhaps Dries recalls these posts.

My point is that we should not get tripped up on whether something is better displayed on drupal.org or on admin/build/modules. We should use .info files so that the data resides near the files and is easily edited by the people who write the module. Thats the best case for timely maintenence. A project module add-on can and will read .info information from the repository and make use of it on drupal.org.

webchick’s picture

@moshe, Yep, I agree with all of that. What I don't understand though is what this looks like being displayed in the admin interface *in core*, which is why I've asked for screenshots/mock-ups... three times now. ;)

dman hit the nail on the head when he said:

Currently it can only say "You've already got this module available, why not turn it on?"
How useful is that?

If this doesn't affect the Drupal core UI, then it's merely about adding properties to .info files that Project module can parse, and the issue can be handled entirely in the Project*/Drupal.org infrastructure queues.

Dave Reid’s picture

Here's a basic idea of how and what kind of information that this patch would display.

Dave Reid’s picture

I'm still not decided on what would be the proper one-word terms for:
1. this module enhances module x. For a very broad and common example, module x = views. Other modules provide custom views to be used by views module. Seems like "supports" would be a good choice here.
2. this module is enhanced by module x. Maybe just the word "enhanced"?

supports[] = views
enhanced[] = integration_module

Michelle’s picture

Putting that all on the module screen isn't very appealing to me. Advanced Forum is "enhanced by" at least 20 contribs, maybe a lot more. That would be an insanely long list there.

Michelle

Bojhan’s picture

Michelle talks about an important point, the ability for this idea to scale. Although it sounds like a good idea, if you put it in the context of having a lot of modules enabled(visual mess) or big modules with a lot of enhancing modules it is not that useful.

It doesn't seem like the place for this type of information. Although in a lot of ways it is good to trigger the behaviour of installing all kinds of modules that enhance the module you have, it also has it downsides. Where as triggering this behaviour on d.o or in the plugin manager might be better on informing the user about what the enhancement does.

I don't think this should be in core, but is a great contrib module if you work a bit on visual representation. The way they are now presented with all the colours and line-up is way to overwhelming.)

For the scenario that moshe portraits, it makes sense - however something like this could be dealt with a better design on d.o - where for OG it would make sense for a lot of other modules it might not.

moshe weitzman’s picture

If you are listing 20 modules in your 'supports' line, you are doing something wrong. We should restrict the keyword to 'this module implements the APIs of these other modules'. To me, that keyword is 'supports'. Lets banish the idea of 'enhanced by' as it leads to much clutter.

Please stop saying that this information belongs on drupal.org. We all agree on that point (as much as we agree on anything). If a person does not think this belongs on /admin/build/modules, then say that and not some "nicer way of saying that". Thanks.

dman’s picture

Edit:... ignore this post, I realized I wasn't really clear in my own ideas.

catch’s picture

To be honest, I'd like to see us remove required by and dependencies from admin/build/modules (or at least turn them into links) - CTRL-F is useless on that page, and this patch with a UI would make it worse. If we could use it to integrate with the help system somehow - like in each module's help index show it's dependencies, requirements and modules it's enhanced by, that might be a way of using it in core (or plugin manager etc.)

Dave Reid’s picture

I'd still like to differentiate between 'my module supports the api of another module' and 'my modules adds new cool features if module x is enabled'... As this develops, I can definately see this has no place on admin/build/modules, but could be very useful on the d.org update or an simpler way to display in the site itself.

Bojhan’s picture

this doesnt belongs on /admin/build/modules - sorry for explaining my motivations, but I thought it was important to note that the information value is deeply related to wheter it should be placed on /admin/build/modules.

yoroy’s picture

webchick:
Could I have someone from the UX team take a look at http://drupal.org/node/328932 ? there's a screenshot at http://drupal.org/node/328932#comment-1107935

Bojhan:
I am still undecided on that issue, I am kinda unsure what the value is in the field enhanced by.
I dont know enough of contribs to answer this issue, sutha or yoroy - you maybe?

yoroy:
colorful!

sutha:
lol

Bojhan:
yoroy: apart from the visual mess, would this really be usefull?

yoroy:
it's useful, but don't know if we need it at this level

beeradb_:
seems like information overload to me

sutha:
I would rather have maintainers write a good and short introduction on the project page. That is the place where I learn if a module enhances an other module.

yoroy:
If every module had it's own "About $modulename" page-thingie, I'd want it in there.

and what sutha says

sutha:
One a module is installed I expect people to know about the enhancements already
So to report an enhancement here is not required. i.m.o.

beeradb_: I tend to agree with Michelle and most here, that it creates a bit of a information overload - enhanced by is usefull information, but I don't think we want to push the behavior of installing all modules that enhance, right?

yoroy:
well, it's a fact that there's quite a few contrib modules that have their own subcultures of enhancement modules
and there are som big ones like OG that just create an entire new /admin section for themselves.
I mean, it would be nice if we could use the "plays-nice-with" info for some smarter groupings of modules?

Bojhan:
hmm, but this isnt grouping.
It will soley display, could be enhanced by , and then a list of modules, in the case of OG I would understand its value - but for most other modules I dont really see it. For big modules, the list would also be to long
I am not sure of its usefullness for core.

yoroy:
meh, feels rather after-the-fact info then. and of course there will be modules that Integrates with: this one en that one and modulenameboo one en theothertoo and viewsofcourse
mucho clutter
little value

webchick:
Yeah, my personal feeling is that on module project pages, this would be a great thing
But in core it makes absolutely no sense

Bojhan: webchick: Agreed
Bojhan: yoroy: yup

catch__:
The thing I don't like it is it makes ctrl-F even more useless on that page.

yoroy:
gooood point

myke’s picture

Or we could keep it as a module, giving people the option of choosing for themselves, and not having it forced by default.

-Myke

webchick’s picture

Project: Drupal core » Drupal.org site moderators
Version: 7.x-dev »
Component: system.module » Redesign

I think it's safe to say, at least for now, that this is won't fix for Drupal core. Moving to Drupal.org webmasters for consideration there.

However, based on the fact that 10 different people seem to have 10 different understandings of what exactly "enhanced by/supported by" means, I'm wondering if this is won't fix, period. .info files become a sea of soup due to every contributor using the "package" property slightly differently, and if we introduce more ambiguous properties it's probably just going to become a maintenance headache.

webchick’s picture

A thought regarding the redesign: maybe a "related projects" multi-value node reference on project pages that can reference up to 10 other modules? We sorta have this with the pivots system, but values that were entered explicitly by module maintainers might be really useful, actually.

We'd still miss the ability to assign "meta-data" to that relationship though; for example, TinyMCE is an *alternative* to FCKEditor, but FCKEditor might *require* jQuery Update, and might be *enhanced by* the Rules module (I'm making this particular example up, but..).

mikey_p’s picture

FileSize
184.05 KB
94.47 KB

Agreed with webchick, just as a note I think these type of things could be in your modules project page on drupal.org, and if you want site users to know, use hook_install and hook_requirements to make your message clear.

I don't want this soup on admin/build/modules to get worse. (See attached images)

miro_dietiker’s picture

moshe weitzman & webchick:
We had a discussion about module similarity and its presentation at drupal.org/project:
http://groups.drupal.org/node/16935#comment-57904

I believe adding a similarto[] on a module.info, drupal.org would be able to provide many useful information to users.
The presentation of this similarity should be added in both directions.
Based on this information a block is possible to tell "There are other modules that claim to be similar to this one".
If you would additionally interprete the current project usage stats a popularity comparision (rate) could be presented and used as primary ordering.

From my point of view this is a very important application of the module .info files to improve users' demands for drupal.org project presentation.

fgm’s picture

@Michelle: this is a duplicate of #92233: Modules in conflict - conflicts[], breaks[], brokenby[] field in modules .info file, which itself already had at least an other duplicate with the wording "negative dependencies", so it appears to be a recurring request.

miro_dietiker’s picture

Thinking more about the topic we should take a look at an adult package manager and its definitions:
http://www.debian.org/doc/debian-policy/ch-relationships.html

Indeed this one does a little more than what we need in some cases, but it has a clear definition and those aren't in doubt.
Please read the exact definition of the terms:
depends, recommends, suggests, enhances
breaks, conflicts
I think they make sense for drupal too!
The installer and modules page could always provide an overview what further is recommended, suggested, ... and this all would allow us to understand the whole module interaction much better.

Thinking again in concrete about "enhanced by", the key thing about is the direction of relation and state of knowledge.
Debian e.g. has a full package index, while our local drupal currently only has knowledge about installed packages. Therefore we can't rely on "enhances" to build "enhancedby" on a local environment. One should always avoid adding relations on two sides if possible.
For drupal.org presentation this is not the case and it might also be able to reverse relationships.

Instead of adding bidirectional / reverse relationship fields here's the key point:
Shouldn't a drupal installation be capable of repositories and index them as a start of fully fledged package management?

Additionally i'd still vote for a similarity field. Since its intention and usage is pretty different to the above debian definitions. Especially to provide possibly non-conflicting alternatives to a specific package and allow users to see there's more than just a single module he possibly found while browsing.

Well i'm already far from the original topic...

dman’s picture

Good link. I'd strongly recommend re-using existing terminology and definitions from such a well-established precedent.

nedjo’s picture

Agreed, a very pertinent reference.

A challenge in using any of this is that we provide information on modules in .info files but drupal.org really only knows about projects.

In #102102: Parse project .info files: present module list and dependency information I've started to sketch in a module to parse .info files as part of the packaging process so that we can e.g. provide a list of dependencies when browsing a project. It needs a lot more work--reviews would be appreciated. If completed, this module could provide the means to extract and display these extended project relationships when browsing projects and also to send information to Drupal installs on the projects corresponding e.g. to recommended modules.

babbage’s picture

Happy to accept that this is not ready for core (yet). Think that this highlights some very interesting ideas however. I have recently released Contrib Toggle module which among other things in v1.3 prompts users to confirm that they want to activate all required modules when a module is activated. (Note: as noted in the release notes, don't install v1.3 until this patch is committed: #365474: Add jQuery Alerts plugin.) It allows module dependencies in both directions to be handled on the fly, rather than by disabling checkboxes and then checking required modules on form submission.

This kind of functionality could also provide an interface asking a user if they want to activate modules that would enhance the functionality of the module currently being activated—but it would require the metadata that is being proposed here to be available in the form. Note this does not mean it would necessarily even need to be displayed on the form, if people are worried about visual clutter.

mickey_p's screenshots were the final straw. Might end up doing something about that too. :)

dww’s picture

Project: Drupal.org site moderators » Drupal core
Version: » 7.x-dev
Component: Redesign » base system

A) This data needs to be per-release, not per project, just like dependencies. "Enhanced by", "Enhances", "Conflicts with", "Similar to", etc, are all things that can/do change per-release. Furthermore, this information is specific to a single module, not all the modules included in a release (view bonus pack, I'm looking at you). So, really the only sane place to define this is in the .info files for each module, since those are already the repository of per-module metadata, unlike release nodes or project nodes on d.o.

B) I think it makes sense to see (some of) this data inside core itself on your site. Maybe you just started with a pre-packaged installation profile/distribution -- you didn't manually navigate to all the project nodes and download in the first place -- you just got a set of 20 contribs when you started. A few of them might say "Enhanced by: foo" as a clue that you might want to go check out foo.

C) Once support for this data is in core, we can encourage project maintainers to start backporting it into the D6 (and even D5) .info files. A contrib can make use of the data in D6 (e.g. http://drupal.org/project/module_supports).

D) Once the data is in the .info files, we can parse that data, populate a DB on d.o with it, and use it for all kinds of goodness for project pages and project browsing, via #102102: Parse project .info files: present module list and dependency information.

redndahead’s picture

This is a nice idea. If no one else said it, I read through the responses but rather quickly, I would like to see it handled something like.

enhances['foo'] = 'If you install module foo it will do this to my module. So check it out.'

The description could be used as a hover tip or inside a fieldset. Are .info file fields translatable?

YesCT’s picture

I agree with #62 B.
The UI needs thought, maybe a link to messy colorful "module interactions" page from the module enable/disable page.

And using this on d.o would rock.

matt2000’s picture

+1 for #62, subscribing

voxpelli’s picture

I totally agree with #62 - the info needs to be specified in the individual modules for many reasons.

I also would like to emphasize that this issue is about enabling modules that's making great use of other modules like Views to have a good way of indicating this.

Also - this issue should not be too much about how to declutter the module list - it can be that this issue clutters the module list but it can also be that the module list already have a flawed design today and if so then that's a separate issue that shouldn't stop this issue.

The Debian link provided in #58 is very interesting - I felt inspired to create some patched based on those thoughts so that we can have something to try out and discuss.

I've created two patches - one with just the new module relationships and another, that's applied on top of the first patch, which adds a javascript for summarizing, folding and unfolding the relationship info in the module list.

I'm also attaching a screenshot from each patch.

tstoeckler’s picture

The Required field should never be collapsed in that way. If I want to enable a module and I can't, I want to see why.
Also: "Recommends, Supports, Enhances" What's the difference?
I mean are there really three states needed?

webchick’s picture

I can only reiterate again that I really do NOT want to see these things on the admin-facing modules page. Especially if we expand out support to match what Debian does (which I totally think we should do). Aside from the awful clutter aspect, this data clearly belongs on Drupal.org project pages (and a drush extension that can read this data as well for the command line junkies), where the person who's building the Drupal site is going to be getting these modules in the first place.

Our goal in core should absolutely be to remove stuff from that page, not add more to it.

Additionally, we could start adopting this right now and not have to wait until D7 gains marketshare.

voxpelli’s picture

@tstoeckler: It's of course possible to customize it to take such a situation better into account

@webchick: I agree that the module list isn't the optimal place - the question is where else to place it? Sure - the information should appear on Drupal.org - but not all code originates from Drupal.org so it must be possible to check such relations from within a Drupal site as well.

As someone suggested it could perhaps be done in a style like the "Available updates" page. It could be reachable from the status page and be showing the relationships for both activated and non-activated modules. Optionally a warning could be issued as well on the status page if a "recommended" module isn't activated - since then something is probably wrong. Would that be a good way do you think?

What's important is that the information is discoverable enough to promote module creators to create progressively enhanced modules. Module creators shouldn't feel needed to add modules that enhances the functionality of their modules greatly as dependencies to get people to activate them. By promoting progressive enhancement modules will become more flexible in their interaction with other parts of Drupal - which is a desirable thing.

dww’s picture

@webchick: I agree the admin/build/modules page is already trying to do too many things. But, modules are a central aspect of what makes Drupal so great, so it's no surprise that we've got hard problems there. Instead of a blanket "we need to remove stuff from that page, not add more to it", I think we need a Mark + Leisa style "let's burn it all to the ground and start over from scratch with something (maybe a whole series of pages) that does everything we need."...

That said, thoughts on #62B? ;)

p.s. Does that mean we should probably won't fix #197486: GHOP #65: Add "available update" indicator to installed modules ? ;)

webchick’s picture

@dww: No, if you look at http://www.d7ux.org/modules/ you'll see that the update status is integrated into the page directly in the mocks. But the page is more action-oriented -- "Now that you have modules, what do you want/need to do with them?" -- rather than "Here's a big mess of everything possibly related to modules in the world on one gigantic ugly page" :P

Viewing enhanced/supporting/etc. information isn't an "action" that needs to be taken by the site administrator. At best it's supporting curiosity information and belongs under admin/reports somewhere, as voxpelli suggests. I'd be willing to entertain patches/mockups in that direction. But for the love of all that is holy, leave that poor modules page alone!

voxpelli’s picture

@webchick: I'm feeling that this issue contains two issues - one is what relationships between modules that Drupal should track and handle and another is how Drupal should present that information.

We could decide what relationships we want Drupal to handle prior to figuring out where to present that information - and it would also make it easier to figure out how to present it because we would know what to present.

Do we for example feel that Drupal could benefit from, as the Debian project does, supporting the relationships: dependency, recommendation, support and enhance? I certainly think that those could be very useful.

Regarding the presentation of information - should that be synchronized with the usability project? If so - know of any related issues?

matt2000’s picture

@webchick

Seems there's a question to be clarified in differentiating between the 'site builder' and the 'site administrator.'

Who is admin/build/modules intended for?

At my company, we're looking at it as for 'site builders' only, and considering patterns module, or something custom, to let end-user administrators enable/disable "feature sets".

I presume the ideal goal is to collapse these two roles into one, but I don't see that happening with Drupal 7, or at all with the natural-selection ecosystem of contrib; we'll need experts to separate the wheat from the chaff of modules for a long time to come, I expect.

So we could simply admin/build/modules; or we could enhance it and add a super simple admin/build/features that uses 'recommended' and 'enhances' and 'enhanced by' data to set smart defaults for 80% of users.

voxpelli is correct that the first step is to determine which relationships will be supported, and what exactly they mean. E.g., what is the difference between 'Recommended' and 'Enhanced by' ?

webchick’s picture

@voxpelli: I don't think we'll find too many people who will disagree with implementing a standard that already exists for cataloguing this same type of information. I mean, I guess if you're out there, go ahead and speak up, along with your alternate suggestion and why it makes more sense to go with yours than a project with a decade or so of package management experience. :)

So to me, this is very clearly a "what do we do with this data once we start adding it" issue. I tried to bounce that to Drupal.org infrastructure to determine, but it got bounced back here again. I'm still not sure why this is a core issue. IMO, we need this solved in the larger Drupal.org infrastructure first and then (and only then!) figure out how to display this info in core, if at all. It's something that could always be added by a contrib module if we don't make it in time for code freeze.

@matt2000: The way the modules page is headed according to the current mocks is a "dashboard" for managing your site's features. You're doing things from here like turning features on/off, jumping to configuration pages, enabling permissions, etc.

"Go and get more features for your site" is a separate context, regardless of who the "person" is behind the act and whether they're an admin, site builder, developer, or whatever word you want to use to describe them. It doesn't belong smooshed into this page.

webchick’s picture

I guess the fundamental disconnect I'm trying and failing to communicate here is that in no other application that I can think of is the "go and find more stuff" the same place you "configure the stuff you have."

For example, in Firefox, if I want more features, I go to Tools > Add-ons > Get Add-ons:

Get Add-ons

If I want to turn on/off or configure features I've already acquired, I go to Tools > Add-ons > Extensions/Themes/Plugins:

Configure Add-Ons

Now! If we want to add a page like "Get Add-ons" to Drupal core, that would be lovely. :) But we still need work done on the infrastructure side first in order to get the proper information. And in the meantime, we should not cram this extra data into the one "module-related" page we have.

Dave Reid’s picture

http://drupal.org/project/module_supports
I haven't touched it in a while, but I've been meaning to refresh the display and make it a little better. Patches are welcome.

matt2000’s picture

I like the Debian model; I think we can improve on the terminology, which is not the least bit intuitive. One can't guess the difference between 'Recommends' and 'Suggests'

Here's a first attempt...

Depends -> Requires Available
Pre-Depends -> Requires Enabled
Recommends -> Highly Recommended
Suggests -> Enhanced by
Enhances -> Enhances

"Pre-depends" whatever it's called will be awesome . That would have been nice for Ubercart+Imagecache and some CCK tricks.

@webchick, I didn't realize we were talking about going out and fetching modules. I realize that this info needs to be on Drupal.org, and probably we need to do that first, but it also needs to be in Drupal itself for the modules that I have downloaded, completely independent of how the modules get there. (as was mentioned, because d.o. is not the only place code comes from.)

In terms of DX, I'd say getting it in the UI is more important than on d.o, but reasonable people can disagree. Either way, we need it in .info files first, and contrib can handle my wish if core doesn't, so you are especially correct in your choice of priority.

Anyway, I'm not in anyway advocating that this all goes on one page; our current admin/build/modules, or the D7UX mockup, or anything. #66 shows the info that needs to be in the Drupal UI, in whatever form and on whatever page it ultimately appears.

Bojhan’s picture

I am sorry, but I am totally siding with webchick on this one - we can argue forever but this is absolutely not a critical issue to get into Drupal core - especially not considering the page you intend to add it to.

We should really take a good look at the user and his current problems with the module page (all the usability testing on it - found loads of structural issues). Even with a large redesign coming up, I don't see this as a good improvement - since it is about possibilities and those should not be addressed at the module page for a while.

YesCT’s picture

So it looks like most agree that the vocabulary for the info files needs to come first. I double checked the title of this issue, and that matches.

Any mock ups to help with discussing that should avoid the core modules page and either use d.o or a new get add-ons type page in core, or contrib.

Maybe a separate issue needs to be opened for the d.o display of this info.

And either use an already existing contrib or start a new module for adding a page on the site to display this stuff. (someone pcik one of these paths we should go down). Is it even a possibility of proposing a core module? Or should we move this discussion out of the core queue?

I see a value in having both d.o and my particular installation display this information.

Each site I build and admin has slightly (or radically) different modules, and I want to see a summary of enhancements or recommendations that know about what I already have, in the context of a particular site.

Dave Reid’s picture

Marked #188038: module info file: recommended modules as a duplicate of this issue.

Anonymous’s picture

Glad to see action on this duplicate of #101922: conflicts variable. ;D

adrian’s picture

This is going to be needed (along with versioned dependencies), if we want to get install profiles working properly :
#509404: Fix some conceptual problems with install profiles and make them actually usable

I dare say that this also has repercussions in the package manager project, because otherwise we will only be able to automate the downloading of required modules and not the optional modules that need to be downloaded alongside them.

and furthermore this also has an effect on the D.O packaging system, if we want to package install profiles properly.

dww’s picture

This is definitely still worth doing, but unless Adrian wants to clarify this with concrete evidence, the following statement is incorrect:

and furthermore this also has an effect on the D.O packaging system, if we want to package install profiles properly.

This feature has no bearing on how d.o-packaged install profiles should work. Maintainers of install profiles will just specify exactly what versions of which projects should be packaged with any given release of their install profile. The ability for .info files to brag about "enhanced by" or "recommends", etc, might be useful for the maintainers of install profiles to find other modules themselves, but it has no bearing on the packaging system.

catch’s picture

Version: 7.x-dev » 8.x-dev

Moving this to Drupal 8.

webchick’s picture

Project: Drupal core » Drupal.org customizations
Version: 8.x-dev »
Component: base system » Code

I don't think this needs to be pushed to D8; adding this information to project pages on Drupal.org is something that could happen literally at any time and would hugely benefit the vast majority of people downloading and installing modules. Once this is done, it becomes at worst a couple-line change to Plugin Manager in core to read this data in from Drupal.org.

Trying this queue instead to see if there's any better luck. But the bottom line is I see absolutely no reason to tie this to the core release cycle, because it is fundamentally not a Drupal core issue.

voxpelli’s picture

@matt2000 in #77: Nice list - adding the corresponding classic specification wordings from http://tools.ietf.org/html/rfc2119 to it:

Depends -> MUST be enabled
Pre-depends -> MUST already be enabled
Recommends -> SHOULD be enabled
Suggests -> MAY be enabled
Enhances -> MAY be enabled
Conflicts -> MUST NOT be enabled

Below are both lists combined and with a little more description:

Depends
Specified module MUST be enabled for this module to work properly
Pre-depends
Specified module MUST be enabled prior to this module for this module to work properly
Recommends
Specified module SHOULD be enabled for this module to work properly
Suggests
Specified module MAY be enabled to enhance this module
Enhances
Specified module MAY be enabled and is enhanced by this module
Conflicts
Specified module MUST NOT be enabled - one or both of the modules will break.

Also - I think the versions that has been added to Drupal 7 - http://drupal.org/node/542202#dependencies - should be usable with all of these relationships.

rszrama’s picture

fwiw, Depends / Pre-depends are confusing. Is this simply trying to get at the fact that an install func for one module might use an API defined by another module? I don't see why we wouldn't install all dependencies first anyways... Also, semantically there isn't really a difference between suggests and recommends. If something SHOULD be enabled for a module to work properly, then that's a dependency. I'm with matt2000 - these terms can be clarified or collapsed into fewer categories.

miro_dietiker’s picture

dww and rszrama, information such as "recommends" might have no direct technical usage for the package system (while packaging and while executing install procedures).
But for the gui and a user interacting with the module manager, it is very useful.
If we want to have more than a minimalistic package system we MUST support such terms and additional relations. It is the only way to provide improved usability. It is the job of maintainers to provide the information - and it is the users' need to learn more about what might be the next steps to do to improve the systems' functionality and fulfill his needs.

Recommendations in general differ much from suggestions and should remain as different internal relationships.

Recommendations should always be displayed to users, to understand a potential lack of functionality due to an (optional) missing module. It should be a strong recommendation and users should be notified of recommendations and even be able to add recommendations with a click.

Suggestions are less than recommendation, but still worth a pinpoint. They might bring some addon, but are typically no standard use case. If you're interested in some specific functionality, suggestions could help you. There's no need to display suggestions directly in case of installation -- or even allow to add them with a single click.

There are many modules with great third party integration - perfectly done - whereas the third party is optional, but still recommended.

Michelle’s picture

There are many modules with great third party integration - perfectly done - whereas the third party is optional, but still recommended.

My modules are an example of this. (Well, I won't claim, they're perfect... ;) Advanced Forum makes heavy use of Views, for example, and you'll have a much better forum experience with it, but there are fallbacks for people who don't have views installed. All three of my modules have other modules that are highly recommended but, since the modules will function without them, I don't make them hard dependencies.

Michelle

bleen’s picture

superscribe

q0rban’s picture

subscribe.

I don't see why we wouldn't install all dependencies first anyways..

I totally agree, pre-depends is just doing what depends should already do.

A related issue on the module_supports queue is #617068: Give clear semantic meaning for each directive. I totally agree with yhahn's comment on that issue: http://drupal.org/node/617068#comment-2278134. Basically, that dependencies, recommends, conflicts, & replaces are really the only items that are clear to the end user and of value.

miro_dietiker’s picture

Recommendation VS enhancement is a difference of direction.

I tried to explain in #617068: Give clear semantic meaning for each directive why there is a clear difference between recommendation/suggestion and enhancement.

quazardous’s picture

HI,

I don't know if it s the good place to ask...

I've two modules A and B. B does not need A, but A define some hook_menu_alter() that B redefines....

How to make sure that B's hooks are called after A's hooks ?

may be the Enhances directive could solve my problem ?

q0rban’s picture

@quazardous you need to increase the weight in the system table of module B.

aidanlis’s picture

I am going to limit myself to discussing only the specific issue, that is partial dependencies. Anything else should be moved to a new issue, or the title of this issue generalised.

The steps for getting this specific issue implemented:

Step 1. Decide on the terminology to be used
Step 2. Wireframe how this information can be displayed to the user in a meaningful way.
Step 3. Provide patches against http://drupal.org/project/module_supports in an attempt to get the contrib module fully implemented and at a point where everyone agrees.
Step 4a. Provide patches against D7/D8 so we can move this to core.
Step 4b. Provide patches against the project module, so this information can be displayed on d.o module pages.
It would be great if everyone could prefix their posts with the step they're addressing.

Now, in terms of Step 1. Let's examine some real life use cases (more real life cases are welcome if something disputes my conclusion):

views_bulk_operations and views:
- views is enhanced by views_bulk_operations because views_bulk_operations provides extra features for views. This relationship is not useful on a module status page, but may be useful on a d.o page.
- views_bulk_operations enhances views. However, it's less of an enhancement and more of a new feature that happens to depend on views. I consider this a weak relationship, it might still be useful on a d.o page.

views and advanced_help:
- views is enhanced by advanced_help. In this case, views having the enhanced_by relationship is important.
- advanced_help enhances views. This would be a useless relationship.

regcode and role_expire:
- regcode is enhanced by role_expire through a series of if(module_exists('role_expire')) checks. This relationship is important.
- role_expire enhances regcode. This relationship is not at all important.

path and pathauto:
- path is enhanced by pathauto. This relationship is good to know as it is very common functionality, but perhaps not critical information. Seeing this relationship on the module status page for example, is not useful.
- pathauto enhances path (and is enhanced by transliteration). This is reasonably obvious from the title of pathauto, and because of the dependency on path is probably not useful.

From these examples, we can see that the most important relationship is enhanced by and that this information needs to be available locally for each module. enhances is not hugely important as it's usually pretty obvious. There's only small value to displaying this information locally, but it would be useful on d.o.

So, granted we need two keywords, and that information can flow both ways for both of those keywords, we just have to pick names.

Let's get back to our debian package keywords: depends, recommends, suggests, enhances, breaks, conflicts. I propose dropping "suggests", as it's really just a strong recommendation and will confuse users. enhanced by is covered adequately by recommends. depends is covered, and breaks/conflicts are problems for another issue.

In summary, I propose adding two keywords.
* module_a recommends module_b: module_a's functionality is significantly improved with module_b is enabled. This tag is recommended only when module_a has "module_exists('module_b')" in its code.
* module_a enhances module_b: module_a was written specifically to extend the functionality of module_b.

If we have a look at the fielfield module, http://drupal.org/project/filefield, we can see a list of recommended packages. Under the current scheme, this would look something like:
* Transliteration: Converts characters in uploads to server-safe formats. filefield recommends transliteration
* ImageField: Upload widget for FileField that shows an image preview, with support for ALT and Title text. imagefield enhances filefield
* FileField Paths: Save files using node-based tokens. filefield_paths enhances filefield
* FileField Podcaster or iTunes: Create podcast feeds using Views and FileField. itunes enhances filefield
* SWF Tools: A set of media players for playback of audio and video files. swftools enhances filefield
* Search Files: Allows searching the actual contents of PDF, Word, Excel, text, and other files. no relation

Is everyone happy with this?

tstoeckler’s picture

Yup.
But we need another field for "Module A conflicts module B".
In D6 e.g. Image/Imagefield
In D7 maybe Blocks/Panels
I think that is pretty useful information.

myke’s picture

Drupal could also give a warning if you're trying to install a module that conflicts another module...

This would probably need version information, as it's possible an older version might conflict but a newer one might not..

naught101’s picture

Subscribe. Awesome ideas.

Webchick:

I guess the fundamental disconnect I'm trying and failing to communicate here is that in no other application that I can think of is the "go and find more stuff" the same place you "configure the stuff you have."

The module page isn't for configuring modules... it's just for installing them and removing them. I don't see how that's a good argument.

The firefox model is probably not very useful really. Firstly, the "get addons" thing in firefox is looking for addons that aren't installed - something that the modules page doesn't (and shouldn't, I think) ever deal with. Secondly, none of the firefox addons have dependencies!

Better would be to look at a GUI frontend for apt, or similar. These, of course, do exactly what we want. An added bonus doing it the way kpackagekit does it (see attachments) is that you can hide the descriptions as well as the dependencies and so on, making the page even less cluttered.

tim.plunkett’s picture

sub

NancyDru’s picture

rfay’s picture

Version: » 6.x-3.x-dev

Setting this to 6.x-3.x. Not sure how it got set to "nothing"

NancyDru’s picture

Project: Drupal.org customizations » Drupal core
Version: 6.x-3.x-dev » 8.x-dev
Component: Code » system.module

It got messed up in #53 and subsequent shuffling.

mikey_p’s picture

Nancy, the change you are undoing, was made in #85, and I'm not sure we want to move this back to core, but then again I'm not sure where it lives.

All the arguments about how this has to be integrated with the packaging system don't really make much sense. Drupal doesn't have a packaging system in the same way that Linux distros manage their software. All current info is processed inside Drupal with info from a file, not from a service. This issue seems to be about 1) there is no standard for this info, and 2) once there is, there is no way to find the dependencies, without downloading the modules in the first place. It seems that those are issues for Drupal core, and Drupal.org respectively. Perhaps this issue should be split into two components, one for Drupal core, and one for Drupal.org?

NancyDru’s picture

Well, for where this should live: Where does "dependencies[] = 'Xyz_module' " live? This should be in exactly the same spot. I really don't see this as having anything to do with packaging. This is merely a courtesy comment by the module owner. It tells the site owner (on the modules admin page) that if he/she installs "Xyz Module," it will enhance the functionality of the module specifying this. This is hardly worthy of 100 comments.

bleen’s picture

I agree with NancyDru ... Adding enhanced_by[] = 'Xyz_module' (or whatever) to .info and displaying that info on the module info page is pretty simple. What else we do with that information (like having D.O. read it in to display on a project page) should be dealt with later.

NancyDru’s picture

In #328932-12: Modules and partial dependencies - enhances[] and enhancedby[] field in modules' .info.yml files, Dave Reid points to a contrib he did 3 years ago that does far more than I think is needed here (thank, DR). This is a one-way "comment" intended by the module owner to inform the adopter that additional features are available if such-and-such a module is available, but is not required. I don't want module maintainers to have to compile a list of module that are enhanced by their module. Consider the nightmare Earl would have trying to keep track of which modules use Views or Ctools? However, it is not unreasonable for him to say that Views itself is enhanced by, for example, the Views RSS module. Then a potential adopter can see that and say to him/herself, "Gee, I've always wanted a better feed, why don't I go look at that."

About the only case I can see for "enhances" is submodules, and I'm having trouble thinking of a case where this is not effectively covered by "dependencies."

bleen’s picture

I have always been looking for this from a slightly different standpoint. Here is an example... the DART module (for ads) is *much* more usable if a user has vertical tabs installed, but it is certainly not required. Or the context module would be enhanced by the admin module, but again this is not required.

Personally I was never looking at it from the point of view of Merlin trying to keep track of the 2.3 gazillion modules that "enhance" views, but rather from the point of view of the module developer that explicitly puts in code that will make their module work better (or theme look nicer) in the event that another non-required module is installed.

NancyDru’s picture

@bleen18, that is exactly what I am saying. This should be a one-way deal. There should be no reason why the Vertical Tabs maintainer should be aware of any other module that makes use of his/her module. However, it would be very nice of the Dart module maintainer to let people know that his/her module is made better is some way by using VT. This may also prevent a few issues from being filed.

voxpelli’s picture

Status: Needs work » Active

To get anywhere with this issue I think we would need to:

  1. In a new issue, replacing this one, standardize what kind of relationships that should be definable between Drupal modules - the keyword and meaning of them. I'd say we start with my definition in #86 (which is also discussed in #617068: Give clear semantic meaning for each directive).
  2. In a follow up issue to 1. discuss where this standard can and should be implemented. Should it be in Drupal core? In Drupal contrib? On Drupal.org? In Drush?
  3. In one issue for each of the implementation that 2. concluded should be built do those implementations.

This issue is to scattered to be able to reach any further. We need to reach a conclusion here and move on as suggested above.

aidanlis’s picture

See #95 for how I think we should proceed.

aidanlis’s picture

Before we can move forward we need to decide on the keywords to be added. I think "conflicts" should be a separate issue, so we need to chose between:

My suggestion:

* module_a recommends module_b: module_a's functionality is significantly improved with module_b is enabled. This tag is recommended only when module_a has "module_exists('module_b')" in its code.
* module_a enhances module_b: module_a was written specifically to extend the functionality of module_b.

Or voxpelli's suggestion:

* Recommends - Specified module SHOULD be enabled for this module to work properly
* Suggests - Specified module MAY be enabled to enhance this module
* Enhances - Specified module MAY be enabled and is enhanced by this module

Please discuss and let's come to an agreement.

NancyDru’s picture

I certainly prefer "depends" to "dependencies." And "pre-depends" would have been occasionally helpful. I just hope no one takes "depends" to mean that the module is incontinent. ;-)

Looking at your definitions, I am wondering how we would describe the situation in Web Links. It does not require Taxonomy, nor do we suggest or recommend that any one install it. However, if Taxonomy is available, additional features become available. That is, Web Links is enhanced by the presence of Taxonomy.

Further, I will not even think of asking core to add "enhances" to Taxonomy for Web Links. Nor would I consider asking Earl to add "enhances" to any of my (or anyone else's) modules that may use Views, Ctools, Panels, etc.

So, now lets' look at Faq_Ask. It is an add-on to FAQ that adds the capability for users to ask the questions that get added to the FAQ after they are answered. I can't really say that Faq_Ask enhances; I wouldn't want Stella to suggest Faq_Ask, because many don't need it. But I could argue that FAQ is "enhanced by" Faq_Ask" but there is already a dependency, so do I need any of these others? Not IMO.
---------------------------------------------------------------------------------------------------
So let me ask those who want all the other conditionals that were not requested in the original post: Are you asking core to control all of those? If so, I am -1 on the whole issue. What the original poster and I want is a simple courtesy comment that gets included in the modules admin list that shows that module A is now enhanced by the installation of module B, which may mean that if I am about to remove A, I may also want to remove B, or that I may want to go to A's settings pages and set it up to use whatever enhancements that B provides.

"Recommends" and "Suggests" are confusing to me. So, does Views "recommend" or "suggest" Advanced Help? Based on Earl's text, I would say he "recommends" it, but in your definition in #86, it may be only "suggests." We should eliminate one unless we have a better definition of the difference (with "depends" as well).

Anonymous’s picture

We already have Requires which in the admin modules page gives a reverse "is required by" list. So for instance faq_ask would need to require faq since without faq faq_ask has no functionality. Therefore in my opinion faq_ask should not also have an "Enhances" argument for faq since we already need to "Require" faq. If both are supplied then "Require" takes precedence. If a "Enhances" is given but no "Require" is given then the complement "is enhanced by" should be given on the modules admin page.

As for "Depends", IMO it is synonymous with "Requires" and has no further validity to the issue.

As for "Suggests" this term to me hints toward another module enhancing the abilities of my module. I do not see that we should have a complementing comment of "suggested by" in the module admin page but I would not vote against it either. Finally the weight of these terms from lowest to highest is Suggests, Enhances and Requires such that the higher weight takes the precedence in the view on the module admin page.

aidanlis’s picture

@NancyDru #112: Did you actually read what I posted in #111?

With my scheme, it would be "web_links recommends taxonomy" -- your description fits what I wrote for "recommends" perfectly. For faq_ask you would not use any additional keywords, as it already has a dependency on faq.

With regard to the rest of your comments, that's exactly why I think the definitions in #86 are problematic.

@earnie #113: I'm having a hard time understanding what your feedback boils down to ... can you vote on the two proposed schemes in #111?

NancyDru’s picture

Yes, and I also see that you updated it after I posted.

But I do not recommend Taxonomy. It is unnecessary and a number of issues were written back when it was required. It is only that WL exposes additional functionality when Taxo. is available, otherwise it works just fine without it. There is no reason to install Taxonomy or to build vocabularies and terms just because of WL.

----------------------------------------------------------------------------

If a module needs another module to "function properly" then it depends on (requires) that module; it doesn't recommend it.

* module_a is enhanced by module_b: module_a's functionality is significantly improved when module_b is enabled. This tag is recommended only when module_a has "module_exists('module_b')" in its code. Included in module_a's .info file.

* module_b enhances module_a: module_b was written specifically to extend the functionality of module_a. This is pretty much implied by "dependencies[]."

Further: "enhanced_by" should not be included if both modules are included in a single distribution - the enhancing action is pretty much implied. It is entirely optional; it is a courtesy to the user to let them know that another module offers additional features.

aidanlis’s picture

@NancyDru, I see your point about not "recommending" taxonomy -- I don't think any tag is necessary in this situation.

module_a enhanced_by module_b is a viable alternative to module_a recommends module_b. What do others think about the wording?

However, "enhances" is not at all covered by dependencies ... please re-read the actual use cases in #95. For example, my filefield enhancement module might have a dependency in ctools, it doesn't mean it enhances ctools.

dman’s picture

It is only that {$A} exposes additional functionality when {B}. is available, otherwise it works just fine without it. There is no reason to install {B} or to build vocabularies and terms just because of {$A}.

That is also the situation with
$A = Views and $B = Advanced help
A "Suggests" B

That is basically the same as "is enhanced by". The only difference is a small one of tone.
"FYI, you could go and use this module too, you'd get a few more features specific to this job. Just a suggestion"

But I do not recommend Taxonomy. It is unnecessary

@NancyDru, you don't have to necessarily endorse or recommend a module to suggest it. I think we can/should treat it as an emotionless statement.

In keeping with the Debian, already-in-use terminology, that is what "Suggests" means. When you apt-get an upgrade, a bunch of odd libraries "suggest" other things that enhance them (like a font-kerning library for truetype or something), and you say, "Yeah, interesting, but I don't think I need that extended feature right now, so thanks but I don't care"

I'm with Earnie on #113

One thing however is that (with Debian) the 'suggestions' only happen once on upgrade time. It may be that we/users don't really want to see nagging 'suggestions' on the module admin screen all the time if the strength of suggestion is so weak. Though I don't know a better+simpler alternative.

Anonymous’s picture

@earnie #113: I'm having a hard time understanding what your feedback boils down to ... can you vote on the two proposed schemes in #111?

I was disagreeing with your term definitions and I am suggesting to use requires, enhances and suggests. We already have requires so all that needs to happen is adding enhances and suggests. My suggestion moves the onus of information to the module enhancing or suggesting rather than the onus of information being the one enhanced or suggested. The "Enhanced by" term as in the issue title would instead become Enhances.

The term depends is synonymous with requires and therefore not needed.

Requires - Cannot function without.
Enhances - Adds functionality to.
Suggests - Can be enhanced by.

The module admin page already gives "required by", it could also give "enhanced by" and "suggested by" nomenclature but as dman points out does this make the page too cluttered? Perhaps this information could be given as a tabbed page available on the module admin page.

As mentioned in #8 we should also include "Conflicts - Cannot function with." However, this would need to change the functioning of the module admin page such that you are not allowed to enable conflicting modules.

Hmm... An interesting idea that just came to mind would be a change to the project module to read the .info files in each project and give this information on the project pages in the side column. Nah, I'm dreaming out loud.

lpalgarvio’s picture

+1

fgm’s picture

@earnie: a problem for this is the fact that the project page is per-project, but the .info is per-module, and a single project can contain many modules: think CCK or DrupalCommerce, for instance.

Anonymous’s picture

@fgm: What are you trying to argue here? I'm not referencing the project page, I'm referencing .info files. In my project FOO.info I can state that it is enhanced by module BAR but I cannot insist that someone's BAR.info adds an enhances module FOO. The module administration page can in turn though add to the display for module BAR that it is enhanced by FOO and FOO enhances BAR.

This is also true in reverse, FOO can enance BAR and I can add to my FOO.info file that FOO enhances BAR but I cannot insist that someone's BAR.info state that it is enhanced by FOO. Now the question becomes how does one know about FOO from project BAR and vice versa; that can only be achieved from the project page, either through cooperation of maintainers or an enhancement to the project module to parse the .info files of projects.

fgm’s picture

@earnie: referencing "mm... An interesting idea that just came to mind would be a change to the project module to read the .info files in each project and give this information on the project pages in the side column. Nah, I'm dreaming out loud.".

Project pages do not reference modules, if you think of it, only projects. And these dependencies are at the module level, not the project level. UI-wise, it could easily be ugly for multi-module projects.

tstoeckler’s picture

lpalgarvio’s picture

strong point in #116

it's easier for maintainers to state which modules their own modules can enhance, than to have maintainers guess what other modules enhance their own modules

more thoughts
http://drupal.org/node/937778

bleen’s picture

it's easier for maintainers to state which modules their own modules can enhance, than to have maintainers guess what other modules enhance their own modules

That's not true at all. As a module maintainer I often add code like this:

if (module_exists('foo')) {  //Do some extra cool stuff that those slackers without "foo" installed wont see.  }

This is the common situation where a module maintainer will want to add "enhanced_by foo" to the .info file. Please take a look at #107 & #108

Sigh ... I feel like we are going round and round in circles on this issue

Anonymous’s picture

@#125: Yes, which is why I stated it both ways in #121. I can use a module that enhances my module and is therefore "enhanced by" the other module but I can also create a module that enhances your module and therefore "enhances" your module. We need to be able to specify both and have the module admin page display the appropriate wording. But in the "enhances" scenario the project page of your project may or may not indicate the enhancement module depending on maintainer cooperation. You may not trust the maintainer that enhanced your module with his and don't want to propagate its use.

Anonymous’s picture

@#123: No, the issue you point to isn't the same except that I mention the subject in #121 which fgm scoffed in #122.

lpalgarvio’s picture

not saying it shouldn't happen, just saying it's easier for a maintainer to know what his own module enhances, than which of the 10000+ modules enhance his own module.

consider merging the two values (enhanced by / enhances) with some relational SQL/PHP code upon display on the drupal modules page.

Views
- enhanced by Advanced Help
enhancedby = advanced_help
Advanced Help
- enhances Views
enhances = views
CCK
- enhanced by FileField, ImageField, audiofield, videofield, video, content_display_order
- recommends FileField, ImageField, content_display_order
enhancedby = filefield,imagefield,audiofield,videofield,video,content_display_order
recommends = filefield,imagefield,content_display_order
FileField
- enhances CCK
- enhanced by FileField UI Extras, FileField Sources, FileField Paths
- recommends FileField UI Extras, FileField Sources, FileField Paths
- deprecates Upload
enhances = cck
enhancedby = filefield_uiextras,filefield_sources,filefield_paths
recommends = filefield_uiextras,filefield_sources,filefield_paths
deprecates = upload
ImageField
- enhances FileField
- deprecates Image
enhances = filefield
deprecates = image

notes,
- recommends value could omit the modules already present and enabled in the system to avoid duplicating visual information (OR hide somehow to avoid cluttering the interface)
- deprecates value could omit modules that aren't present in the system (redundant)

fgm’s picture

A problem I see with your example is CCK: you suggest including "enhancedby" and "recommends" on it, but there is just no cck.info at all.

Now, these could be added to content.info, along with text, number, options, and probably all cck submodules, but then how would the module building the info for the project page know that the reference module on which to base its information is called "content" when the project itself is called "cck".

Same problem in the opposite direction when filefile enhances cck: does it enhance "content", or some other module from the cck project ?

lpalgarvio’s picture

oh true, i mistaken content for cck.
you know what i mean, Content Construction Kit (CCK), known as content project (content.info), but with cck project url, directory and tar.gz file.

my assumption is for project names (project tag in .info file)

NancyDru’s picture

Are you advocating for replacing "dependencies?" Since Filefield requires Content (CCK) and has no value without it, what is the value of also having "enhances?" However some modules do have value without "foo" but if "foo" is installed, then "bar" makes it better.

As an example, Email Verify enhances the User module if that feature is enabled, but it can do other things as well, and may be used to do things for a site specific use only, so it does not have to depend on User, nor must it alter User at all.

lpalgarvio’s picture

no, not replacing. i didn't included that or other things like name or project or description in my example because there's an assumption we need those.

for that particular case you talked about FileField vs CCK, yes it makes sense. i didn't though on that much.

therefore, Enhances/Enhanced By could come into play when a certain module relationship is NOT REQUIRED for the modules to work, but can be established to improve or add certain features. and thus exclude REQUIRED modules.

another example,
http://drupal.org/project/ubercart (7.x)

requires:
Rules (7.x-2.0-alpha5 or later)
Views
Ctools
Entity API
Entity tokens
is enhanced by:
Colorbox
Google Analytics

ubercart

dependencies[] = rules
dependencies[] = views
dependencies[] = (...)
enhancedby[] = colorbox
enhancedby[] = google_analytics
enhancedby[] = (...)

colorbox

dependencies[] = (...)
enhances[] = ubercart
enhances[] = commerce
enhances[] = (...)
lpalgarvio’s picture

btw, in my example i also stated Recommends/Deprecates. ignore that.
it would bloat the UI and confuse users.

as per my older idea,
Recommends/Deprecates could be more useful on the .XML files at the project server, to be used by Update and Ugrade Status.

also, enhances/enhancedby could also be named the same thing, like enhances, companions, integrates, etc
many times the module integrations are two-way.

ex,
Rules Views Integration
- allows views (and VBO) to execute rules.
- allows rules to execute and get results from views.

webchick’s picture

I don't think enhancedby[] really makes sense; just as we don't have dependenton[]. The inverse can easily be calculated, just as it is with dependencies, and also an API module like Views would have to change enhancedby[] every time a new module came out, practically. :P

Keep the list of properties in the hands of the person who actually developed the module.

voxpelli’s picture

@webchick:

"Enhancedby"/"Suggests" is used in cases where you have a module_exists() in your module (as stated by #125) that sniffs for another module and does something cool when that other module is active.

"Enhances" is used when your module enhances another module - like a Views plugin.

Only if Views were to include module_exists()-sniffing for every new module it would need to add an enhancedby for it. As far as I remember Views includes very few module_exists() - in Drupal 6 I think CCK was the only contrib module Views sniffed for and it didn't really sniff it in an "enhancedby" way either.

I agree we should keep the list in the hands of the person developing the module. That's why an API-module like Inputstream shouldn't have to add "enhance" for all modules supporting it but have rather those modules define it as an "enhancedby". Or why Views shouldn't have to add "enhance" for all modules exposing tables to Views but rather have them define Views as an "enhancedby" (or rather as the originally suggested "suggests" as it's a more appropriate semantic in these cases)

Anonymous’s picture

I agree we should keep the list in the hands of the person developing the module.

Exactly my point.

That's why an API-module like Inputstream shouldn't have to add "enhance" for all modules supporting it but have rather those modules define it as an "enhancedby". Or why Views shouldn't have to add "enhance" for all modules exposing tables to Views but rather have them define Views as an "enhancedby" (or rather as the originally suggested "suggests" as it's a more appropriate semantic in these cases)

But enhanced by is the complement of enhances and more appropriately identifies the idea of what is meant. Suggests could mean that the module maintainer is highly affectionate toward a module without regard to the maintainer's module and just wants to promote another module.

aidanlis’s picture

@LPCA I think it would help if you read the whole issue, you seem to be rehashing / stumbling over topics which have already been discussed in great detail.

@webchick The relationships are not as symmetrical as they appear, views and advanced_help for example:

- views is **enhanced by** advanced_help. In this case, views having the enhanced_by relationship is important.
- advanced_help **enhances** views. This would be a useless relationship.

@earnie If a developer starts abusing the "suggests" keyword, then an issue should be filed for the webmasters. I think the possibility of keyword abuse for the example given is pretty low and eventually self correcting.

My summary of the issue with real world examples from a variety of drupal.org modules is at #95 -- if you would like to propose an alternate syntax, provide examples and shortcomings against the existing proposals - then hopefully we can vote and move this issue forward.

NancyDru’s picture

@aidanlis: Indeed you have a good point. Advanced Help enhances any module that cares to use it and couldn't possibly list all 10,000 modules as "enhances."

lpalgarvio’s picture

Title: Modules and partial dependencies - enhances[] and enhancedby[] field in modules .info file » Modules and partial dependencies - "Enhanced by" field in modules .info file
Issue tags: -.info file, -.info

maybe API modules shouldn't list which modules use them or which modules they enhance, but instead, just the modules they directly affect. if any.

advanced help, wysiwyg, cck, libraries, and so on, are IMO such cases.

edit,
re-read all the issue, from the start, and posting new comments

Planning:

noting that...
* #95: subscribing plan
* #62: although i don't know how exactly the drupal.org infrastructure works, i agree with dww
* #141: new plan by bleen18
* Module supports and Project Dependency, as outlined above, are good testing grounds to finally port it to Drupal core and drupal.org

Metadata / terminology:

noting that...
* #58 and #86: makes sense. but does not include everything we need, as it's based on debian. we need more, like stated in...
* Module supports a nice module by Dave Reid. i've supported it right since i found it out. also posted some ideas before i found out about it: here, here and here (some dealing with project/release XML files).

we need:
* dependencies[] (aka depends) - module(s) required for this module to function
* enhances[] (aka enhanced) - module(s) that are enhanced by this module
* conflicts[] - module(s) that can NOT be enabled when enabling this module
* breaks[] - module(s) that will NOT work after enabling this module

we could use (for the sake of Similar Module Review group):
* recommends[] (aka recommended) - module(s) that are recommended (module will work a lot better with these enabled as well. NOT a place to list modules who use your module! only list the ones who are truly recommended as any others can be calculated by reverse relationship with enhances[]. example, FileField could recommend FileField Sources, because it really boosts the FileField module)
* alternatives[] (aka alternate/similar/similars) - module(s) with similar functionality (alternative modules that aren't replaced/deprecated by this module. example, Admin is an alternative to Administration Menu and vice-versa)
* replaces[] (aka deprecates/replaced/deprecated) - module(s) that are replaced or deprecated by this module (example, ImageField replaces Image in D6)

probably don't need:
* suggests[] (aka suggested/enhancedby) - module(s) that enhance this module (calculate reverse relationship, enhances[])

GUI - modules page on drupal 7/8:

noting that...
* i like alot this redesign concept
* D7 new module page and ModuleInfo proved good points
* #66: could resolve the UI issues - IF loaded in a fieldset, via AJAX, it could also reduce IO/CPU/memory usage when loading the modules page.
* #98: package managers in linux are always good things to take ideas from

my ideas:
* show dependencies[], enhances[], conflicts[], breaks[], inside a AJAX fieldset.
* also show enhanced by (a reverse enhances[] by way of a relationship), inside the AJAX fieldset.
* provide an option to define whether to show dependencies outside or inside the AJAX fieldset (to mimic old behavior/GUI).

GUI - project page on drupal.org:

my ideas:
* show dependencies[], enhances[], conflicts[], breaks[], using Views, as a list, bellow the project description, and before project releases.
* also show suggests[] (a reverse enhances[] by way of a relationship), in the same place, so visitors know which modules use this module.
* show recommends[], alternatives[], replaces[], using Views, on the right side, as blocks.
* use an AJAX "view more" to list if there are more than 5. IF empty, do not show.

speaking of relationships - in a more far future...

* get Views System merged in Views?
* get Views in core (D8/9)?
* use Views to render the modules page? as a form. you can customize the view, like with other views.
* use Views to render the content and users page, as well other pages? see Administration Views in Administration Menu module

Anonymous’s picture

As has been stated already and the view I support, only a module maintainer knows which modules they use and/or which modules they enhance. It isn't onus of the modules being used or enhanced to state what uses them or enhances them; it is the onus of the module using or enhancing that knows what she uses or enhances.

enhances - My module adds abilities to another module.
enhanced by - My module performs other cool stuff when this other module is enabled.

The word suggests has been thrown out as equal to enhanced by but lets look at definitions.

If you look at the word meanings enhanced by is more appropriate than suggests. The word suggests clearly carries the wrong meaning for the purpose used here. We need to be clear so that users of the product aren't more confused but less confused.

bleen’s picture

it is the onus of the module using or enhancing that knows what she uses or enhances.
enhances - My module adds abilities to another module.
enhanced by - My module performs other cool stuff when this other module is enabled.

YES YES YES...

This seems to be the sticking point that we keep coming back to, but earnie is exactly right. The onus must be on the module maintainer who has the ability to edit his/her .info file. No other alternatives that have been suggested/discussed above are practical.

If we can all finally agree on this point, I think we can start to move forward using the "Metadata" section from LPCA's post in #139...

As I see it we have the following roadmap ahead of us:

  1. Agree on the metadata and termonology to be included in .info
  2. Create a D8 patch to properly handle the new meta data (probably based on some of the patches above)
  3. Once that patch is RTBC and committed, backport to D7 & D6 (if possible)
  4. Create a new issue, referencing this, one to improve Drupal.org Project pages based on this new meta data
aidanlis’s picture

Issue summary: View changes

Provide an issue summary

aidanlis’s picture

Issue summary: View changes

Fix the HTML.

lpalgarvio’s picture

#328932-139: Modules and partial dependencies - enhances[] and enhancedby[] field in modules' .info.yml files

GUI - modules page on drupal 7/8:

noting that...
* i like alot this redesign concept
* D7 new module page and ModuleInfo proved good points
* #66: could resolve the UI issues - IF loaded in a fieldset, via AJAX, it could also reduce IO/CPU/memory usage when loading the modules page.
* #98: package managers in linux are always good things to take ideas from

my ideas:
* show dependencies[], enhances[], conflicts[], breaks[], inside a AJAX fieldset.
* also show enhanced by (a reverse enhances[] by way of a relationship), inside the AJAX fieldset.
* provide an option to define whether to show dependencies outside or inside the AJAX fieldset (to mimic old behavior/GUI).

a really nice thing would be turning dependencies that have sub-dependencies into links, and hiding those sub-dependencies those dependencies have (as in tree like structure).
upon clicking these links, their sub-dependencies would show, right after their parent dependency (the link).
clicking again the link, would hide these sub-dependencies.

they should load with AJAX if possible.

this would remove completely the dependency soup that would show when listing dependencies - you would only get the top-level dependencies.

nice module here (GUI):
http://drupal.org/project/module_table

lpalgarvio’s picture

aidanlis’s picture

I have provided an issue summary.

voxpelli’s picture

Regarding the issue summary:

""suggests" is just a strong "recommendation" and will confuse users." - what is meant by that?

"suggests" is a weak "recommendation" and nothing else and can by no means be replaced by "recommendation" - if anything it would be the opposite - see: http://drupal.org/node/328932#comment-2031276

"recommendation" is very similar to dependencies - it's something that in most cases should be installed but that in some special cases don't have to. In most cases probably: If you're not a coder - install it - if you're a coder or an advanced user which knows you wont need it - then you're free to skip the module.

"suggests" on the other hand is a module that's only a nice to have - it should only be installed if you want the extra functionality that it brings, but there's absolutely no need to install it - you're not losing anything vital but not installing it.

voxpelli’s picture

I'm +1 to #141 - lets settle with "enhances" and "enhanced by" for now - it seems like most people can agree on those and it will be an improvement over our current situation where we only have dependencies.

We've soon been discussing this for 3 years - lets start building something that can get into D8 now and lets revisit and enhance that when it's done.

aidanlis’s picture

I'm inclined to agree with voxpelli on his interpretation of "recommends" vs "suggests", it fits well with the Debian guidelines: http://www.debian.org/doc/debian-policy/ch-relationships.html

I don't like "enhanced by" so I'm going to vote we stick with the Debian keywords and use suggests/enhances. I've updated the issue summary to match.

aidanlis’s picture

Issue summary: View changes

Update notes

lpalgarvio’s picture

let's settle the issue. for the remaining ideas, perhaps i'll open new issues some time soon

Bojhan’s picture

It was already settled in http://drupal.org/node/328932#comment-1103439 , http://drupal.org/node/328932#comment-1103590 and http://drupal.org/node/328932#comment-1108301 . I understand that you all feel its a worthwhile addition, but there have been many concerns with the direction of this as a whole - which have not been addressed, instead the discussion turns to other parts.

fgm’s picture

Admitteedly this is only tangentially related, but @Bohjan's latest post made me think that having a reference "project page" for every module in an install could be much more useful than adding lots of info on the module list page.

To some extent, this could be a bit like the project page on d.o. (or the appropriate feature server for a non-d.o. module), serving as a general entry point for the module on the install, pointing the the various links standardized (or not) during the D7 cycle, like:

- existing: dependent, depends on
- standard: permissions link, configure link
- non standard: [advanced_]help link, coder review link when applicable
- proposed in this issue: dependencies, suggestions, enhancements, etc
- proposed on #92233: Modules in conflict - conflicts[], breaks[], brokenby[] field in modules .info file: conflicts
- links to project page, to online manual, to issue queue...
- author credits
- ...
And since (a) it is a full page (b) for one module (c) on a limited subset of the module on d.o., the visual clutter phenomenon vanishes.

Maybe it should go in a separate issue, though ?

Anonymous’s picture

Maybe we could handle this in a advanced_info contrib similar to advanced_help? An Advanced tab could be added to give the additional information. At least it would be a start toward incorporation into core. A lot of good core ideas came first from a module.

Bojhan’s picture

@earnie I would definitely favor such experimentation, especially since discussing the UI implications of this can prevent valuable research through contrib into the actual usefulness of a lot of this.

NancyDru’s picture

Given that the only two people who can commit are both leaning against this happening, I say go for it.

lpalgarvio’s picture

Title: Modules and partial dependencies - "Enhanced by" field in modules .info file » Modules and partial dependencies - enhances[] and enhancedby[] field in modules .info file
Issue tags: +.info file, +.info

on table:
* dependencies[] (aka depends) - module(s) required for this module to function
* enhances[] - module(s) that are enhanced by this module
* enhancedby[] - module(s) that enhance this module

for new issue #92233-17: Modules in conflict - conflicts[], breaks[], brokenby[] field in modules .info file:
* conflicts[] - module(s) that can NOT be enabled when enabling this module (ERROR)
* breaks[] - module(s) that will NOT work after enabling this module (WARNING)
* brokenby[] - module(s) that will make this module NOT work after being enabled (WARNING)

for yet another new issue #1234668: Similar Modules - alternatives[], replaces[] and replacedby[] field in modules .info file:
* alternatives[] - module(s) with similar functionality (alternative modules that aren't replaced/deprecated by this module. example, Admin is an alternative to Administration Menu and vice-versa)
* replaces[] - module(s) that are replaced or deprecated by this module
* replacedby[] - module(s) that replace or deprecate this module

#328932-149: Modules and partial dependencies - enhances[] and enhancedby[] field in modules' .info.yml files sounds good, and wouldn't mind it in core with an API and extended further by contrib modules (advanced_help, coder, simpletest.

but the standard module page needs to show basic info on what you need (dependencies - first level at least, remaining with AJAX would be cool) and what could break/get into problems (conflicts, breaks), and i do like that it shows also the links (D7).
maybe some options could be provided to let the user specificy what to show on the standard module page, while on the other one, it would show everything.

further more, if the modules standard and project page were to be built with Views (a contrib module to work with views_system), we could forget about options by instead customizing the view.

klonos’s picture

Title: Modules and partial dependencies - "Enhanced by" field in modules .info file » Modules and partial dependencies - enhances[] and enhancedby[] field in modules .info file
Version: 8.x-dev » 9.x-dev
Issue tags: +.info file, +.info

..too late, too bad :/

Xano’s picture

Title: Modules and partial dependencies - enhances[] and enhancedby[] field in modules .info file » Modules and partial dependencies - enhances[] and enhancedby[] field in modules' .info.yml files
tstoeckler’s picture

tstoeckler’s picture

Issue summary: View changes

Added the issue# for breaks/conflicts.

sun’s picture

Component: system.module » extension system
Issue tags: -.info file, -.info
matt2000’s picture

Rather than adding ehances/enhanced-by relationships explicitly to info files, we could approximate it pretty well, I think, by parsing module code for code blocks conditional on a `module_exists()` call. No?

bleen’s picture

not necessarily ... One use case that comes to mind is hook_form_moduleXsform_alter ... I'm sure there are others but this is the first one that popped in my head

catch’s picture

Version: 9.x-dev » 8.x-dev
Issue tags: +minor version target
darol100’s picture

Version: 8.0.x-dev » 8.1.x-dev
Issue tags: +Needs reroll
andypost’s picture

I think better to move that information out of modules page (for example to help#module)
Also when there's no "suggested" modules installed you can't display the module name

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.0-beta1 was released on March 2, 2016, which means new developments and disruptive changes should now be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.0-beta1 was released on August 3, 2016, which means new developments and disruptive changes should now be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.0-alpha1 will be released the week of July 31, 2017, which means new developments and disruptive changes should now be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.0-alpha1 will be released the week of January 17, 2018, which means new developments and disruptive changes should now be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.6.x-dev » 8.7.x-dev

Drupal 8.6.0-alpha1 will be released the week of July 16, 2018, which means new developments and disruptive changes should now be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

klonos’s picture

Trying to revive this issue after 7 years the last time it saw some activity...

Sorry for the lengthy post - the TL;DR/gist of it is this: the "suggests" keyword and functionality does make sense, and we should definitely start implementing that, but the "enhances" bit may actually be moot, so we should linger too much on that.

I'm well aware that the current proposal in the issue summary is the result of careful consideration and lengthy discussions, but it is proposing to use keywords being used by other systems (namely Debian package keywords). I don't think that we should be necessarily basing our decisions on conventions that are used by completely different software, especially if that software is not a dependency for Drupal - that's comparing apples to oranges in my view, so it provides no actual value in the context of a CMS. It also does not provide any solid argument at all in my view. Why the keywords/conventions used by Debian and not other operating systems? Why operating systems to begin with? ...and before anyone rushes to answer these "why"s, please make it be meaningful/useful for Drupal users and web developers/site builders - not an operating system preference that in your view may imply "popularity" of the keywords. We don't know if the average site builder is familiar with or used to these conventions. In fact I doubt that we care much - most of us simply pick a hosting provider (mostly based on $$$/value), and we leave them manage the underlaying operating system and webserver/database stack - we never touch any of that, not to mention keywords being used that are esoteric to these systems.

Anyway, the current proposal is to go with the verbs suggests and enhances, however, our existing .info and .info.yml files already use the nouns dependencies and test_dependencies. So for the sake of consistency I believe that we should change the proposal to also be using the equivalent noun suggestions instead of the verb. This should be an array, as a module may suggest multiple other modules.

When it comes to enhances though, I disagree with that proposal (at least from a UI perspective, please see further considerations later in this post). The reason being that it implies that it will need to be added to the .info.yml file of the "target" module (the one currently living in d.org - which is not currently downloaded/installed on the site). So if the person that has just span up a fresh Drupal site is not a seasoned Drupal person, then what's the point after all if they don't know that this module exists or where/how to find it to begin with? I believe that whatever we go with should live in the "source" module. In other words, I don't think that it's practical nor useful to have a module that the user potentially has no knowledge of be "enhancing" existing modules on the site - it should be the other way 'round, in order to improve discoverability of modules once their "parents" (the things that can potentially be enhanced) are installed on a site. The fact that the current proposal emphasises on the implementation requirement (or acceptance criterion) that the relationships should NOT be bi-directional makes this a necessity the way I see it, unless I'm missing something(?).

Specifically, to counter this logic currently in the issue summary:

path and pathauto:

  • INCORRECT (path won't know about pathauto): path is enhanced by pathauto.
  • CORRECT: pathauto enhances path.

It's quite the opposite in fact:

  • The Path module is already in core, so we can add the "enhanced by" (whatever the wording will be - don't fixate on this for the moment) in path.info.yml, and the result will be that in the admin UI we'll be able to let the user know that there is a module called "pathauto", which does not currently exist on the site, and which the user can now search by name (or once we have Project Browser in core, they can even view info about it without ever having to leave the admin UI, and they can also download and install it directly). Either way, UX++
  • The Pathauto contrib module may very well be enhancing the Path module in core, but what's the point of implementing a way to do that? Pathauto is not present on the site, so we are making the assumption that the user knows how to find it, or knows that there exists a module by that name to begin with. And even if people do find the Pathauto module in d.org contrib-land, that's the reverse of what we should be trying to achieve here. Right? ...or am I missing something?

Then, if you consider this bit in the issue summary:

User interface changes

The modules page will display suggests and enhances besides the existing dependencies.

Firstly, I agree with the suggests bit 👍 (although as I mentioned above, the keyword should be the noun suggestions, and in plural, to indicate that an array of modules is possible), but enhances is simply silly in my opinion - it only helps people when the module that enhances another is present on the site. So fine, views_bulk_operations enhances views, but if we add the "enhances" keyword in views_bulk_operations.info.yml while the module does not exist on the site, then what have we achieved? Wouldn't it be more appropriate to have the suggestions[] array in views.info.yml point to views_bulk_operations?

The only way I can envision "enhances" working in a meaningful way is to somehow take advantage of it NOT within the admin UI of the software itself, but rather on the listing of modules in d.org (which my understanding is that it is a paradigm that we are trying to move away from via the Project Browser initiative) ...or if we make use of it in the Project Browser itself. Even in that case, what's the point of pointing to more "popular" or well-known modules from "lesser" modules? 🤔

I'm curious to hear what people think after no comments here in so long.

PS: the Project Browser is a strategic initiative (and for very good reasons), so we should be trying to view the proposed solution here from that aspect.

Medha Kumari’s picture

Status: Active » Needs review
Issue tags: -Needs reroll
FileSize
11.08 KB

Rerolled in Drupal 10.1.x.

Spokje’s picture

Status: Needs review » Needs work

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.