I noticed that the Pathauto module does not have a Package defined in the .info file. By default it falls into the "Other" section on the modules admin page. While pathauto was a module that stood on its own that was ok, but now we're starting to see modules that extend pathauto. I'm also working on one myself. It would be great if we could organize these modules together on the module listing page under the same package. Yes... I'm a neat freak. :-)
Here are some of the other modules..
- http://drupal.org/project/view_alias
- http://drupal.org/project/subpath_alias
- http://drupal.org/project/path_alias_xt
Whether the package is called 'Pathauto', 'Aliasing', or something else doesn't matter as much to me. But I would love to be able to organize my module listing page. :)
Comments
Comment #1
dave reidI'm pretty opposed to abusing the module taxonomy as 'package' information. On http://drupal.org/node/231036 it's very clear:
Comment #2
gregglesI agree with both of you ;)
I could see moving this to "Aliases" along with path redirect and globalredirect and perhaps a few others that all cover this general "alias" area.
Comment #3
caschbre commented@Dave... I agree. I don't want to have a bunch of classifications with very few modules in it. That doesn't solve anything. On the other hand having a bunch of modules classified as 'other' doesn't help usability. I think greggles has a great solution. 'Aliases' is a good classification that can encapsulate more modules.
Comment #4
dave reidIf it's going to be anything (and again, I'm very anti package-abuse), I would prefer it match the corresponding module term: Path management. Since path redirect really does not do much with aliases.
What we should really be doing instead of abusing package lines in .info files is push to add tags[] to .info files and be able to browse the modules page by tags. Developer modules would have tags[] = developer, etc.
Comment #5
espirates commentedSeems like paths, pathauto should be under a main heading like seo that's what its used for.
Comment #6
caschbre commentedI like the tags[] in the .info file idea. Is that supported and just not used or is tags[] not an option yet for .info files?
Comment #7
dave reidIt's not supported by core. I'm going to push for people to start using it in their own .info files in D7 because 1. core just ignores it and 2. other modules can still use this info (think of admin_menu and it's 'disable developer modules' feature).
Plus modules like http://drupal.org/project/instantfilter are way better at helping usability on the modules page rather than misusing the package information.
Comment #8
gregglesPathauto is not just for SEO so I don't like that as the title.
Path management works for me.
Comment #9
dave reidThis is still a mis-use of package information. We need to work on improving our modules page.
Comment #10
lpalgarvio commentedhow about,
"Pathing", "Pathfinding" or "Paths and URLs"?
Comment #11
lpalgarvio commentedi'm suggesting all related modules to do a change to "Path and URL" package
Comment #12
lpalgarvio commentedComment #13
gregglesWe do have
Pathauto
Path redirect
Global redirect
That's 3 which should be used on all sites. While it's not the limit of 4...it is something.
Then there is subpath alias and perhaps one or two other lesser used modules...I think we should consider this.
Comment #14
dave reidI'm still very against abusing and re-purposing something for taxonomy purposes. There are solutions available (http://drupal.org/project/module_taxonomy) to allow admins to customize this information themselves. As well as good solutions to improve the modules page (http://drupal.org/project/module_filter).
Comment #15
lpalgarvio commentedwill all due respect DR, and i'm a big fan of your work (and sun and others, who think the same), module_filter does not solve the problem.
mitigates, but does not solve.
in my sites, i have more than 30 categories for the modules... cause every module insists on having their own sub modules with their own categories, instead of using categories that tailor to their functionality.
and i have more than 50 modules solely in the Others package group.
the problem is the taxonomy itself, which needs a little visit from developers and logistics workers.
http://groups.drupal.org/node/97054
let me also say that standards are not just what fits on white papers.
a standard is also what a group of people consistently use for their work.
Comment #16
gregglesRe-titling. This is what d.o uses and therefore we should too: http://drupal.org/project/modules?filters=tid%3A8818
Comment #17
lpalgarvio commentedgood point.
subscribing to that.
Comment #18
mably commented