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

dave reid’s picture

I'm pretty opposed to abusing the module taxonomy as 'package' information. On http://drupal.org/node/231036 it's very clear:

If your module comes with other modules or is meant to be used exclusively with other modules, enter the name of the package here. If left blank, the module will be listed as 'Other'. In general, this field should only be used by large multi-module packages, or by modules meant to extend these packages, such as CCK, Views, E-Commerce, Organic Groups and the like. All other modules should leave this blank. As a guideline, four or more modules that depend on each other (or all on a single module) make a good candidate for a package. Fewer probably do not.

greggles’s picture

Title: Set Pathauto module package to 'Pathauto' » Set Pathauto module package to 'Aliases'

I 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.

caschbre’s picture

@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.

dave reid’s picture

Version: 6.x-1.3 » 7.x-1.x-dev

If 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.

espirates’s picture

Seems like paths, pathauto should be under a main heading like seo that's what its used for.

caschbre’s picture

I 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?

dave reid’s picture

It'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.

greggles’s picture

Pathauto is not just for SEO so I don't like that as the title.

Path management works for me.

dave reid’s picture

Status: Active » Closed (won't fix)

This is still a mis-use of package information. We need to work on improving our modules page.

lpalgarvio’s picture

how about,

"Pathing", "Pathfinding" or "Paths and URLs"?

lpalgarvio’s picture

Version: 7.x-1.x-dev » 6.x-2.x-dev
Component: Miscellaneous » User interface
Status: Closed (won't fix) » Active

i'm suggesting all related modules to do a change to "Path and URL" package

lpalgarvio’s picture

Title: Set Pathauto module package to 'Aliases' » Pathauto » package name
Issue tags: +package name
greggles’s picture

We 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.

dave reid’s picture

I'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).

lpalgarvio’s picture

will 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.

greggles’s picture

Title: Pathauto » package name » Change Pathauto's package name to "Path management"

Re-titling. This is what d.o uses and therefore we should too: http://drupal.org/project/modules?filters=tid%3A8818

lpalgarvio’s picture

good point.

subscribing to that.

mably’s picture

Issue summary: View changes
Status: Active » Closed (outdated)

Now that this issue is closed, review the contribution record.

As a contributor, attribute any organization that helped you, or if you volunteered your own time.

Maintainers, credit people who helped resolve this issue.