Split Article content type into a module

@Rob, that sounds like install profiles ;)

You'd technically be able to enable the module, then disable it - but all the configuration will stay active on the site. I'm not sure we'd even want to add a hook_uninstall() here but that's up for discussion.

This leads to a wider issue of whether we want to allow configuration bundles (especially after CMI lands) that aren't explicitly tied to install profiles or modules but which can be imported into a site. This could definitely be one of them.

The memory footprint of just enabling a module is not as small as it should be due to #1061924: system_list() memory usage.

But yeah even with that we're talking about a couple kb of memory at most, once that patch is in, much less.

Since we don't have any feature-type things in core, I think it'd be worth doing this as a module (and possibly allowing our test suite to be significantly sped up in the process), then it'll be a good candidate to convert later on.

@Rob Loach.

I have to say I'm a big -1 on this. This seems like more of a product feature rather than a technical feature.

It's one that we already have.

Do we really need a module with about five lines of code in it? This could be accomplished during the installation process with a single call to node_type_save().

As David points out, there is more to this feature than a single call to node_type_save().

@webchick:

I'm -1 on this, too. The article content type within the standard profile is training wheels; it's intended to get you something in that "Create content" screen you can actually do, as well as get new users started on content types and how they work. It's not a base from which to build an actual website (though you can).

I have personally seen tens if not hundreds of sites based on Drupal 6 that used the old 'story' and 'page' content types as a base, quite a high proportion probably. Drupal.org continues to do so.

Being able to play around with it and add/remove fields from Article (or rename it to "Blog") and see what happens is critical to new users figuring out how Drupal works.

Nothing changes if it's provided by article.install instead of standard.install .

This approach would also force the minimal profile to ship with a module that can't be removed without "hacking core."

If you really care about modules being hidden from the modules page, you can use hook_system_info_alter(), no need to hack core. At least this would be a module based on modern Drupal concepts instead of 2002 spaghetti.

If for whatever reason this content type is desired by other profiles, the code to make it can be copy/pasted into a new profile in 30 seconds

Well we could make it a module that is placed inside profiles/standard then force people to copy the whole module if they want to use it in install profiles. That way, no-one else has to see it, ever.

I actually thought one of the advantages of this proposal would be that it is available in the UI to turn on later (even if the install profile you happened to use didn't provide articles, you can still decide a week later that you want to turn this feature on). This would basically make the standard install profile less of a magic black box.

Exactly.

However, there's no doubt that it's awkward as a module, for some of the reasons mentioned above (likely an empty .module file, nothing disappears when you disable the module, etc).

Yes it makes me wonder why we ever made install profiles modules in the first place, since they also fit that description perfectly. The idea here is to get us to a point where we can partly reverse that decision (i.e. that install profiles should be dependencies + configuration, not include runtime code).

So if there's strong opposition to doing this as a module, it could make sense to wait and see what happens with the configuration management stuff before revisiting it.

I'd like some of the points raised in this issue and #1242448-12: [meta] More flexibility for core installation profiles to be dealt with before we punt this for CMI. While it might be awkward to have a .module with no code in it, that's also a strength of core that you can build useful end-user features without runtime code baked into them. Less is more etc.

Also it wouldn't actually be an empty .module file, we'd need to add a hook_help() in there. Currently the standard profile has zero documentation or help text associated with it at all.