To further reduce over head, maybe content_admin should be its own module, much like views_ui so we don't include any hooks or functions that aren't necessary. I think typically advanced users defining content types will only need to use the features occasionally and can disable/enable the module as needed. Opinions?

.darrel.

Comments

yched’s picture

yched commented

I'm not sure I figure all the implications this could have (won't this leave annoying "holes" when content.module enabled and content_admin disabled ?), but on the principle this seems a good idea.

I guess we could auto-enable content_admin on cck's first installation (views does something like that I think), and maybe issue a "help" message on core's content types overview page advising "enable content_admin.module in order to access content fields settings" when content_admin is disabled.

karens’s picture

karens commented

We would definitely need to be sure it gets enabled automatically on installation, which might be annoying. The big issue is making sure that the files are so cleanly separated that no errors could possibily occur and that might be hard, especially since we have a slew of contrib modules that might need those functions. I think we would have to proceed very cautiously here, and I'm not sure it's a high priority, so I'd postpone it until we get more basic things finished up. We could, however, be working towards getting functions that are always needed moved to the content.module as we work on other problems.

karens’s picture

karens commented

What about starting by selectively including it in the menu function if the args show you're in the admin area? That way it only gets included when you're in that part of the site and should reduce the overhead when you're elsewhere. Any other modules that needed (content_copy would be one) can then just be sure to include it, too.

yched’s picture

yched commented

include content_admin only if path in admin/* : isn't that already the case ?

karens’s picture

karens commented

I was thinking even deeper, like admin/content/types, but that is a good point. We're already only including it in the admin area, so how much of a problem is it really?

dopry’s picture

dopry commented

Its not a terribly large problem. Conditionally including things in hook_menu just feels like a hack. We have a perfectly usable module system to enable and disable modules and hooks that fire on those actions. I'm also concerned about future changes to the menu system making the current technique more difficult or hackish.

There shouldn't be an issue with contrib modules requiring it, currently its only included in 'admin' sections. Those menu items wouldn't be available unless the module was enabled anyway.

I agree its not a major priority. Just a clean up IMHO.

karens’s picture

karens commented
Status: Active » Closed (duplicate)

This would be accomplished by http://drupal.org/node/255829 as a part of the effort to split CCK into core and contrib parts.