Group related modules together on module install page

+1 for this idea in general

I think the module naming convention for CCK should (in order of priority for me) ...

1. list the field type modules together
2. list the field type modules with the main "content" module
3. possibly distinguish core field types (included with CCK) from contributed ones (defined by other projects)

Ignoring the last one for the moment, as I'm not sure it's necessary or even desireable, here's one idea ...

• cck_content
• cck_field_date
• cck_field_number
• cck_field_text

There are some problems with underscores in module names I won't get into here.

Please support this issue, and ideally propose patches:
http://drupal.org/node/19477

In the meantime I will add a note in the module description indicating the dependencies.

Also, a dependency system would help solve this:
http://drupal.org/node/18447

+1 for this effort.

jonbob -- re: underscores in module names, what's the problem? i notice a few (node_privacy_byrole, simple_access, etc) do it now. is there a specific issue # about this you could post so we could read some context/background on why this is bad?

re: Module Grouping by Folder in Admin/Modules or Simple dependency system, honestly, i don't see how either one is going to happen before 4.7.0. :( it'd be great if one/both of them did, but it seems like all eyes are on critical bugs, that new features aren't going to be committed anymore, etc... i hope i'm wrong, but i'm not counting on it. i'm about to send email to the development list asking about this, but i suspect the answer will be "this isn't critical, deal with it".

therefore, i believe we need to rename the cck field modules. that seems like the only safe way to group them together that we can directly control. plus, having something like "cck_date.module" might be good for module namespace purposes, anyway, so nothing breaks if someone installs their own "date.module" from somewhere else.

regardless of the new names we choose, the earlier we rename these files in cvs, the better, since cvs doesn't make renaming files easy. unless we do treacherous things in the repository (which probably isn't a good idea, and i'm not sure it'd even be possible), we'll just have to do, basically:

for i in date nodereference number text userreference weburl; do
  mv -f $i.module cck_$i.module
  mv -f $i.install cck_$i.install
  cvs rm $i.module $i.install
  cvs add $i.module $i.install
  cvs commit -m "renaming $i to cck_$i" $i.module cck_$i.module $i.install cck_$i.install
done

if we do it that way, trying to go back and find change history on the files will be a two step process if we need early history. any line of code that's revision 1.1 in cck_foo.module will have to be checked separately in foo.module (if we really need to know who/where/why a given line came from). the only alternative is to copy the ,v files directly in the repository, then "cvs rm" the old names. since there aren't any tags on any of these files yet, there's no pain about moving tags. it just means we need someone with direct filesystem access to the cvs repository to do the dirty deed, but i'm not sure that's available to any of us. so, assuming we're stuck with cvs rm; cvs add ... the sooner we do it, the better, so we don't continue to make changes and create history in the place that's going to be harder to use down the road.

of course, once we rename the files, we have to change all the source (hook names, etc)! i'd just write a little perl script to do most of the heavy lifting for that, if there's interest.

should i assign this issue to myself and work on a giant patch to the source for the rename? do people like "cck_field_foo" and "cck_content" as suggested by karens? that sounds good to me. i'm not sure how end-user-friendly "cck" is in this case, but i guess site admins clueful enough to find and install cck should be clueful enough to handle this. ;) i'm the cvs guru for the research project where i work for my day job, so i'd be happy to help with (or just do) the file renames.

let's nail this down soon (definitely before 4.7.0 rc goes live!) so that a) more users don't get confused by the current behavior, b) less people get confused when we make the switch, and c) we stop making commits to the old file names.

thanks,
-derek

See 4.7-ready patch at http://drupal.org/node/53096.

See 4.7-ready patch...

in comment #11 of that thread, dries explicitly said that he's not going to commit it in 4.7.0. since it's a new feature, that means it won't be committed in 4.7 at all. as the email thread on development showed, people are downright hostile to the idea of fixing this in 4.7. i think we're screwed on this one, and we either live with the (rather crappy) current state of affairs, or rename all the CCK modules ourselves... it's pretty clear no changes are going to happen to core to help this in 4.7.x.

-derek

I'm hesitant about renaming the modules for various reasons. This doesn't mean I won't do it, but I want to think this through carefully.

1) CCK has from the start been conceived as a core-bound project. It is being released as a contributions package out of necessity due to falling behind this summer, and missing the 4.7 window. For this reason, I don't think of the field type modules as being "CCK modules" but rather simply "modules." Modules such as story and page depend on node.module, but we don't name them node_story and node_page to group them together (maybe we *should*, but we don't).

2) The name "CCK" itself was only an internal designation while the project was being worked on, and wasn't supposed to be user-visible at all; it was to just be a feature in core (see #1). For that reason, increasing the prominence of this name by including it in filenames seems like a bad idea.

3) Not all modules are required, or even desired in many situations. Every module that's enabled gets loaded on each page request, so it's best to go slim if you can. What's more, another module might handle text fields better than text.module, and is free to replace it. I don't think the modules bundled with the CCK project should be special in this regard.

4) The problem with underscores in names is namespacing. For example, the core has taxonomy.module and contrib has taxonomy_menu.module (which I named before I realized this problem). For namespace reasons, a function inside taxonomy_menu.module would be named taxonomy_menu_foo(). But at any time, taxonomy_menu_foo() could be defined in taxonomy_module(), causing a fatal PHP error. This is a problem that we shouldn't have to deal with at all, and avoiding underscores gets around it completely.

I do acknowledge that the placement of the modules on the admin screen is annoying, but I'm not sure if it is enough of a problem to outweigh the disadvantages. I'll consider it further.

I'm hesitant about renaming the modules for various reasons. This doesn't mean I won't do it, but I want to think this through carefully.

a wise move. i agree, this is definitely worth thinking through. however, i do think it's important to decide on a plan before 6.7.0 is out, preferably before 6.7.0 RC is out.

1) CCK has from the start been conceived as a core-bound project. It is being released as a contributions package out of necessity due to falling behind this summer, and missing the 4.7 window. For this reason, I don't think of the field type modules as being "CCK modules" but rather simply "modules." Modules such as story and page depend on node.module, but we don't name them node_story and node_page to group them together (maybe we *should*, but we don't).

yeah, i think we probably should. there's an effort underway to classify all the modules in various ways. i think it makes sense to have modules that provide new node types logically and visually grouped together for the purposes of administration. similarly, all the modules that provide CCK field types should be grouped. whether or not we use a naming convention is a separate matter, but i think that's the easiest way to achieve grouping in a whole range of places:

• the admin/modules page
• the download pages at drupal.org/project/Modules (especially so folks can easily find all the contrib field types in 1 place)
• the "project" drop-down menu at drupal.org/node/add/project_issue/drupal
• the layout of their filesystem on their webserver
• general confusion about modules in user's heads, in the forums, on mailing lists, etc. (for example, imagine: "i want my website to have a calendar, should i enable date.module or event.module?" if our thing was called "field_date.module", there'd be less (i won't say "no") confusion about it. of course, event.module should mostly go away and turn into a kick-ass date field for CCK, but that's another story...)

these aren't just any random modules, these *are* special. they require the CCK core (content.module), and they neither provide a whole new node type nor do they provide other random functionality. they're a special case, a new kind of module for drupal admins. therefore, i think we should help people understand them by grouping them together based on a name that helps them keep it clear: these modules provide new possible fields for defining custom node types. the thing they *all* have in common is that they're fields. therefore, i think "field" should be in the name. something like:

field_number.module
field_text.module
...

2) The name "CCK" itself was only an internal designation while the project was being worked on, and wasn't supposed to be user-visible at all; it was to just be a feature in core (see #1). For that reason, increasing the prominence of this name by including it in filenames seems like a bad idea.

i fully agree. that's what i meant by "i'm not sure how end-user-friendly "cck" is in this case". i'm hereby convinced that putting "cck" in the name is a bad idea. ;)

3) Not all modules are required, or even desired in many situations. Every module that's enabled gets loaded on each page request, so it's best to go slim if you can. What's more, another module might handle text fields better than text.module, and is free to replace it. I don't think the modules bundled with the CCK project should be special in this regard.

true. a few other things to consider:

a) from a bug tracking point of view, it's confusing which field-modules are part of "core CCK" and which are "contrib". either *every* field module should have its own project (which the drupal.org folks would probably hate), they should all be tracked under the same project with different components, or folks are going to get confused. :( i guess re-classifying reports to the right place isn't the end of the world, but it creates more work for us the CCK maintainers.

b) this is another good reason not to use "cck", but i still think grouping *all* CCK-field modules, core or contrib, is a good idea. just because all of them, core or contrib, will be(?) called "field_xxx", doesn't mean admins should necessarily turn them all on. it just means they're all listed in the same place in the admin page (and download pages, when i'm looking for others) and immediately from looking at their name, you know what kind of module they are and what they do.

4) The problem with underscores in names is namespacing. For example, the core has taxonomy.module and contrib has taxonomy_menu.module (which I named before I realized this problem). For namespace reasons, a function inside taxonomy_menu.module would be named taxonomy_menu_foo(). But at any time, taxonomy_menu_foo() could be defined in taxonomy_module(), causing a fatal PHP error. This is a problem that we shouldn't have to deal with at all, and avoiding underscores gets around it completely.

if "field_" is constant at the front of every CCK field module name, i don't think this becomes a problem. it means we shouldn't name things like:
"field_text_box.module" since that might conflict with functions in "field_text.module". i don't know of any other character we can use to delimit the names, and i think smushing things together, as in "fieldtext.module" and "fielddate.module", make them hard to read and deal with.

and, i suppose someone could add their own "field.module", which would suck, but i'm not sure the fear of such a module is worth using a crappy name like "fielddate.module". perhaps we can reserve the word by applying for a project by that name (think domain squatting). ;)

I do acknowledge that the placement of the modules on the admin screen is annoying, but I'm not sure if it is enough of a problem to outweigh the disadvantages. I'll consider it further.

i don't think that's the only problem. see my list above.

i hope this helps you broaden your perspective on this problem. i think the pros of renaming (provided we come up with a really good naming convention) far outweigh the cons...

-derek

p.s. i'm tempted to rename this issue "Use naming convention for CCK field-type modules", since that's more at the root of the problem, and grouping them on the admin page is but 1 benefit of doing so. but, the other perspective is that grouping them on the admin page is the main issue, and using a naming convention is 1 possible way to solve it. ;) i'll let karens or jonbob rename as they see fit.

Some of your grouping issues can be solved in other ways:

- the admin/modules page

Right now the only way we can group things here is with a prefix.

- the download pages at drupal.org/project/Modules (especially so folks can easily find all the contrib field types in 1 place)

The 4.7 version of drupal.org is to have a categorization system for modules. I expect we can easily convince the necessary parties to add a category for field types.

- the "project" drop-down menu at drupal.org/node/add/project_issue/drupal

This seems to be handled by taxonomy, and what's more, sorted by human-friendly name rather than file name. Prefixing won't help by itself.

- the layout of their filesystem on their webserver

The general solution to grouping issues in a filesystem is the "directory. ;-) Users may group files however they want under their modules directory, and in fact the default install instructions for CCK are to drag the whole folder in as a unit.

- general confusion about modules in user's heads, in the forums, on mailing lists, etc. (for example, imagine: "i want my website to have a calendar, should i enable date.module or event.module?" if our thing was called "field_date.module", there'd be less (i won't say "no") confusion about it. of course, event.module should mostly go away and turn into a kick-ass date field for CCK, but that's another story...)

Agreed.

For the time being, perhaps prefixing module descriptions with a 'CCK' might suffice?

Thanks
-K

I'm kind of confused by the chatter on this topic. In CCK, I see all these modules:

content.module
date.module
number.module
text.module
....etc.....

Is there ever going to be a reason to enable any of the sub-modules (e.g. date.module, text.module) without also enabling content.module?

If not, then simply rename the sub-modules like:

content.module
contentdate.module
contentnumber.module
contenttext.module
....etc.....

This will make them much more manageable in the modules admin table.

J

fixed by http://drupal.org/node/81740