Roll back "Hide required core modules"

Yes please. Saves a lot of space on admin/build/modules and it's really pointless to display them on there. Tested the patch and it works fine. We could also remove "- optional" from the optional core modules, and just leave it as 'core'.

I support this change, however, I think there might also be some special code that can be removed. For example, what causes the required modules' checkboxes to be disabled? Let's double check if we can throw out some code.

Patch works as intented.

Very off topic:
there's also a typo on line 642 in system.admin.inc :
// If the module is requried, set it to be so.
should be
// If the module is required, set it to be so.

(don't have the balls to go for MTPOTM, might include this in a following patch here then)
[Did major edit since I was posting things mentioned on http://drupal.org/node/229129 - saw this issue to late]

I think this is about hiding required core modules only.
+1 on this
-1 on hiding required optional/contrib modules. (but I do think/hope that Dries has misunderstood this issue)

Ok, small +1 for that too.

Dries meant that we can probably drop some code that support preventing core modules to be disabled in the module administration page. That page doesn't even work at this time, so I suggest postponing this until #229129: System module page *seriously* broken is resolved.

@swentel: this is a distinct issue, treated in #229129.

+1

Interesting, this would get a cautious -1 from me as currently proposed:

As a not-so-hardcore Drupal admin/wannabe devel, being able to see what the core-required modules are and what they do is actually useful (much more convenient than having to find and open all their .info files, or trying to find equivalent information on d.o. - which is probably not available in as convenient a form if at all).

Another option might be to have required/hidden modules displayed on a separate page, but at least have the info available from within the site. One of the great strengths of Drupal is the way it tries to be self-documenting, but once certain bits of vital info start getting hidden from view it makes it much harder to transition from novice user/novice admin to competent admin/novice developer. Having a listing of all modules active on the site and available to it is really, really useful (I can't emphasise that enough), and I can imagine new admins getting very confused ... there seems to be a block module in the modules directory ... but it doesn't seem to be listed on the modules page ... why is that ... (some hours later) ... oh, there are "hidden" modules ... I wonder what other modules are hidden ... how do I find out about them and what to do they do ... etc. etc.

OK, I've made my point, and I do appreciate that for novice users the modules page is completely daunting. The snag is that there are many different sorts of users, lots of different people to please, but I'm not sure that selectively hiding certain information (including the links to the help pages for these modules) actually helps.

There's hardly any useful information available at the modules page in the current situation. Perhaps a short instruction at the top of the modules page telling users there are five required Core modules is a solution?

I ended up committing a patch that did this as part of a larger effort to make the modules page work again. So marking this fixed.

@gpk: The fix *only* removes the Core - required group from the modules page with an #access property. They'll still show up everywhere else (Help, etc.). Although I agree that we'll get the odd curious person who furiously cmd+Fs for "Filter" on the modules page, I think this is sufficiently edge-casey enough that this fix is acceptable. It also has Dries's approval in #2.

Thanks for your comments webchick, I think another part of the issue is that the modules page is serving more than one function - the main function is to let you turn on and off the various modules (in which case having the core required modules makes no sense), but it also gives you an overview of the functionality on your site, and gives you a navigation route directly to the help information for specific modules. I think the latter is important because it connects technology to functionality - the "how" with the "what", even though this is a very elementary approach.

Perhaps more important would be to make the help page/system more helpful. I'm not trying to knock it, but I'd note for starters:
- the current alphabetical listing is I think not necessarily the most useful way of organising the information;
- the text "Help topics ... Help is available on the following items:" is interesting, in that what I think we would like is help organised by topics, but what we get is a listing of module names that implement the help hook.

I guess this requires rather more thought than the space in this particular issue permits!

@comment #10 see #299050: Help System - Master Patch

Thanks for updating me alpritt, that patch is looking really good :-D

@gpk: Also check out some of the work the Usability group is doing. Their current initiative is addressing the "missing help" problem. Feel free to take part in the discussion!

@13: thanks for your as ever helpful suggestions and comments!

Given that the module page now displays links to configure and help for all enabled modules, I think we need to revisit this decision.

See some discussion at http://drupal.org/node/645776#comment-2330318 and following comments.

I guess there is no "usabiliyt" component any more...

The modules have been hidden for a reason ("You can't disable them, so why bother showing them?" was the idea behind the change). Making them visible again is IMO a very bad idea and a solution to something that isn't even a problem. It's not that required modules need those help links, it's that those modules shouldn't even be required.

1) As far as I know those modules don't need help links (because there is no help), except maybe for System.module. However, System cannot get help links, because it has no centralised permissions or settings pages. I'm not sure if it has any help pages.
2) Before we are going to find a fix for this, we should first check if we cannot simply unrequire most of the modules (my guess is most field types can be optional).
3) Only if that doesn't work we might show required modules again.

Removing large-scale dependencies is not going to happen before D8. There are several required modules that define settings pages, permissions, and help pages, including Node, System, and the various Field-related modules.

Curious for yoroy/Bojhan to chime in and explain how hiding required modules jives with their vision for this page, now that the modules page actually does more than just let you turn things on and off. I'm not saying we should definitely show them again, but the situation is a bit different than when this patch was originally committed, so it's worth looking at again.

- As far as I can see the Field modules don't provide permissions and help pages, except for Field, Field UI and Field SQL Storage. Together with Filter, User, Node and System there are seven required modules that define help pages, of which four also define permissions.
- System module has no major settings page we can link to.
- I never suggested removed dependencies. All I said was we should look if we can simply unrequire them before displaying required modules again.

Anything else we should take into account?

All of the core modules, required or not, have or will soon have help pages. See #537828: Help text for core modules - update to conform to new standard and the issue queue associated with standardizing the help files http://drupal.org/project/issues/search/drupal?issue_tags=d7help

Here's a patch that:
a) Shows required modules (as long as they are not marked "hidden")
b) Marks them as required by "Drupal core".
c) Adds a line to the help text at the top of the page, making this clear.

Attached screen shots show the help at top of page, and the part of the module list showing the Node module, which would otherwise have been hidden. Note the 3 hopefully helpful links that are now exposed.

I think we should do this. Possibly also these core modules should be moved into group 'core - required', as they were in previous versions of Drupal, but this patch does not address that. I personally don't think that's all that necessary.

The main reason for having settings and permissions links on the modules page, is so that you can easily find settings and permissions for newly installed modules.

Core required modules are never, ever in that situation - while on your first ever install you might end up there, and we've seen people do this in usability testing, I don't think having those links would have done anything for the problems they were trying to solve.

Otherwise, for every other visit to this page, this will just add clutter to what is already a horrible, horrible page to visit. It also makes efforts like splitting system.module into more sane, self-contained modules (some of which are likely to be required) a much more difficult task in D8, since those new modules would then crowd the admin UI.

We still have primary routes to help texts from inline help links, and from the help menu item itself. The fact that core required modules have help texts is good, but that's no reason to reverse what was a really, really good change in the first place.

Short note: if we are going to reverse this change, we shouldn't use the word Drupal in the interface.

ERRR. Terminology techology #fail lead to quite some confusion here. It is the hidden property we'd have to remove, not the "required" ;)

And +1 for removing this magic for the required property. Both required and hidden can and should be defined in .info files - where appropriate.

/me headdesks like a ninja.

We unhide the hidden modules...

I must admit I tend to agree with catch more than with the others, partially because I'm not sure how helpful the help pages for most required (and hidden) modules are. I'm going to check those issues and report back here.

If you're going to check on the helpfullness of the help text for these modules, please apply all the RTBC patches from http://drupal.org/project/issues/search/drupal?issue_tags=d7help before commenting that the help text is useless. All of them have been completely rewritten.

RE #27/sun: Yes. I left it so that hidden modules are still hidden. I just removed the bit that hid required modules. If you want a module hidden, you should set the hidden property. It doesn't make sense to me that just because a module is "required" it shoudl be hidden. If you're going to leave it that way, it needs to be well-documented, and what then would be the point of having a "hidden" flag anyway, since presumably it would be pointless to hide a non-required module (there would be no way to enable it)?

We could change the text so it just says they are required by "core", but I think that would be even more confusing. Any other ideas of something other than "Drupal core" (the choice I put into the patch) to indicate a module that is required by Drupal core? And by the way, this is FAR from being the only mention of "Drupal" in the UI. For instance, the default installation profile's displayed name is "Drupal". Which in my opinion is a VERY confusing name choice...

Side effect of patch in #22: It greyed out the ability to disable modules that were turned on by the install profile. I'm not sure why. It made the install profile show up on the modules page, and it showed up as required, and all of the modules it required showed up as non-disableable.

So anyway, if we decide to unhide the required modules (leaving the hidden ones hidden), the patch will need a bit of work. Besides the fact that the tests failed.

I was just made aware of this issue, and I strongly agree with Jennifer that this needs to be reevaluated. Along the lines of what @gpk was saying, my reasoning is not so much practical (obviously there is no use to be able to click on anything since they are all enabled by default and required). It is more about allowing people who are not developers to be able to see what is running their site.

I think I crossed the line out of being a novice a while back, but it's still close enough in my memory that I know it was very useful to me to be able to look at the list of modules, core-required, core-optional, and contrib, to see what it was that was comprising the various parts of the site's functionality. And I think this is even more so in the case that the admin interface has changed significantly, grouping config options by categories and making it more difficult to figure out (for a new user/admin) what is running what and get an overall view of the core site functionality.

Indeed the help page update that we just completed #537828: Help text for core modules - update to conform to new standard will provide a more useful reference to explain to admins what the various modules do. But I really do feel that removing this list from being viewable is doing a real disservice to people who are not super familiar with Drupal, and taking away a great and easily accessible opportunity to familiarize themselves with the inner workings of their site.

Hmm, arianek makes a good point. In that case though, I'd still like them in a separate collapsed fieldset from 'core - optional', and maybe weighted very high or very low so they don't interfere in the middle of everything else.

Putting them back into a separate fieldset, as they were in 6.x, is a fine idea.

The current core module fieldset is not labeled "optional", by the way. The fieldset names come from the module .info files, and currently all the core modules are just labeled as group "Core".

catch indeed - like jennifer said, in 6.x there is a separate fieldset on the modules page, one for "core - optional" and one for "core - required" which is collapsed by default (screenshot when expanded http://skitch.com/arianek/nkkbb/modules-spend-locally-vancouver-bc). to me that was perfection, it's not cluttering up the screen with stuff you can't modify, but it is there if you want to see what is there.

I ran into #490400: modules with dependencies whose .info file sets required=TRUE cannot be enabled. today and it reminded me that I'd really love to revert this change and display required modules again.

Here's a patch that shows all modules that are not marked as "Hidden". It's basically a reroll of the patch in #22 with a few updates:
- Doesn't use the word "Drupal". Just uses the word "Core", which was already used elsewhere on that page. (see screen shot)
- Creates a new group for the required modules, called "Core - required", and puts the node, user, system, etc. modules in there. (see screen shot)
- Collapses this fieldset by default on the modules page (screen shot is what it looks like after un-collapsing).
- Marks the install profiles as "hidden". Otherwise they are shown on the modules page, even though they aren't really modules, so I thought it was too confusing to show them. Maybe something else should be done to never show install profiles? Not sure...
- Modified help text at top of Modules page (see screen shot).

hurrah jennifer!

i was gonna re-request the test, but looks like something to do with translatable strings is failing (i couldn't see what myself).

the text i think could use a little tweaking, to align with the usual voice/style the docs use, and add a little bit of missing info - i'm thinking (and this can probably be improved a little more, but for a general idea) something like:

===

To enable and disable modules, check or uncheck the boxes below accordingly. Some core modules are required, and therefore cannot be disabled. It may not be possible to disable other modules if there are modules enabled that require them to run. To disable them, look in the list of dependencies next to the module, and disable any that are listed.

You can download additional contributed modules to extend your site functionality.

Be sure to regularly review and install available updates to maintain a secure and up to date site. Always back up your site, before installing or updating modules, and make sure you run the update script after any modules are installed or updated.

Yarg, I'm not in favor of a 'Core - required' section. :/

I've seen that translate/locale test failure pop up in error before, so I requested a retest. If it still fails, I'll investigate.

Regarding the suggested help text, I definitely like some of it...

We've officially gone away (I think) from giving instructions about checking boxes and selecting options and then clicking submit, in on-screen contextual help. ...

Let's see. How about this:
-----
Some core modules are required and therefore cannot be disabled; these modules are marked "Required by Core". Some modules may have functionality that is used by other modules that you have enabled; these modules are marked "Required by [module name(s)]" and cannot be disabled until all requiring modules have been disabled first.

You can download additional (link)contributed modules(link) to extend your site functionality.

To maintain a secure and up-to-date site, regularly review and install (link)available updates(endlink). Always back up your site's files and database before installing or updating modules, and make sure to run the (link)update script(endlink) after modules are installed or updated.

Isn't Required by $module enough to tell the user that particular module cannot be disabled because another module depends on it? That's the whole idea of a requirement.

#44: Probably. :)

#42: Dave Reid - Do you think we should just leave the required modules in the "Core" section then, along with the non-required modules? It might actually make more sense, since some of the Field modules are also required (and they are in their own section). On the other hand, others (see above) have argued that they should be hidden away unless someone really wants to see them.

Can we get this patch in sometime? More opinions on #45?

I think it is also probably responsible for
#710974: Module dependencies not working for required/hidden modules but I haven't tested this patch to see if it fixes that problem.

btw, I posted a patch on http://drupal.org/node/710974#comment-2816658 which might solve this.

Really? It looks like that patch still hides "required" modules as well as "hidden".

Related: #490400-12: modules with dependencies whose .info file sets required=TRUE cannot be enabled. was committed.

We really really need to do this now. I'm retitling this to clarify what we are trying to do here :)

Another reason in favor of it is that #699848: admin/by-task is confusing since it lacks links to config pages and looks similar to admin/config and friends is close to going in, and one of the effects of that patch is to remove the "Help" and "Configure permissions" links from the index page at admin/by-module (soon to be renamed admin/index). The theory is that those links are best accessed from the modules page, but that won't work for required modules unless we get this one in too.

Comments on the approach:

1. For hiding install profiles, we really should do that by default - I think in _system_rebuild_module_data(), the same place where we force them to be 'required'. Probably what should happen is that they get automatically set to hidden unless they specifically put hidden = FALSE in their .info file?
2. "Required by: Core" in the dependencies list is somewhat confusing, and also not necessarily accurate (install profiles can make additional modules required if they want to, and they might do that with a contrib module). It sounds like the only reason "Required by: Drupal" was rejected is that we don't want to put the word "Drupal" in the UI; however, as far as I know it is not so much we want to avoid that word altogether, but rather make sure it is straightforward to replace by people who want to "white label" a distribution. In other words, it would be OK as long as other distributions can automatically replace it with "Required by: Open Atrium" or "Required by: Acquia Drupal" or whatever. We already have a method for install profiles to do this in their .info files, so we should just use that - see http://api.drupal.org/api/function/drupal_install_profile_distribution_n... (which we'd need to modify a bit so it works outside of the installer, but that should be easy).
3. I agree with #44 that we should not add to the help text as part of this patch. If it's not understandable by itself, then we are doing something wrong :)
4. I agree with #45 and others that we should not reintroduce the "Core - required" category. Keeping them in the same alphabetical list as the others is helpful, and creating more categories beyond the bare minimum sets a bad example for contrib modules. (Honestly, I think we should get rid of the "Core - Fields" section too, but how/if to do that depends on the outcome of the rest of this patch.)

Unless someone disagrees, I'll reroll the patch with those changes later today.

Yes please.

As far as that other issue is concerned, the theory sounds wrong to me, since the current help and permission links are located on a page that can be accessed by "site configurators". The modules page requires additional permissions, and actually allows a user to change all available configuration options.

If one needs to RTFM, then that one should rather not deal with module installation/enabling/disabling/etc.

Rather belongs into the other issue though. I agree we should display all modules, including required. Also agreeing with #50, as far as I'm able to follow currently.

For hiding install profiles, we really should do that by default - I think in _system_rebuild_module_data(), the same place where we force them to be 'required'. Probably what should happen is that they get automatically set to hidden unless they specifically put hidden = FALSE in their .info file?

I'd rather in system_system_info_alter(), we can check for explicit settings there too, and it lets people hack something else if they want to after it runs.

I think I'm fine with just a 'core' category, but let's see how it looks too.

Subscribe.

Here's what I've been thinking: a 'required' module should be a dependency of an install profile, not of the distribution. Profiles don't have real dependencies yet, but a fairly trivial patch could add that (see #820054: Add support for recommends[] and fix install profile dependency special casing). I would propose these profile dependencies would be listed as "Required by {distribution name} - {profile name}" (as in "Drupal - Standard"). Then node.module could be required for standard.profile and not for minimal, and the 'hard' required flag on modules would be unnecessary. Plus we could simplify the code to run through the normal module dependency API instead of special flags and checks.

Clarifying, D7 could still retain the required flag of course. But by also using profile dependencies, such as here on the modules page, we can lay the groundwork for D8 to allow core to stand alone as a framework, with the only "core" stuff being in .inc files.

OK, here is a patch with the changes from #50. It's pretty straightforward.

In response to #53, I still decided to put it in _system_rebuild_module_data() for now, because that function is already full of special-case code for install profiles anyway (might not theoretically be the best place, but a good idea to keep all that code together). I did make sure to add it before hook_system_info_alter() is called rather than after, so anyone using that hook to modify it will see the right value when they look at it.

In response to #55, at an API level I agree that the required modules should be able to differ by profile - and to the extent that profiles can use hook_system_info_alter() to set the 'required' flag on modules, they already can do so - but I'm not sure we want to put "Standard" in the UI here. I think the difference between "Standard" and "Minimal" is something people choose once in the installer and then forget exists, no? Whereas the distribution name is intended to be more permanent. Contrib profiles can choose their profile name and distribution name depending on how they want it to display - so e.g., if Open Atrium ships with multiple profiles and cares about this distinction enough to put it in the UI everywhere, it could set the distribution name to 'Open Atrium - Standard' for one and 'Open Atrium - Minimal' for the other. But for the core profiles I think we just want to show "Drupal" regardless of which one you selected.

Screenshot coming up in a bit.

Here is the full-page screenshot. I'm very happy with the way the top part looks (having Filter, User, etc appear right in the list with everything else).

The bottom part - i.e., the Fields section - maybe not so much :)

I think we ought to consider:

1. Getting rid of the "Core - fields" fieldset.
2. Moving "Field" to the regular Core section and continuing to show it, but hiding the other five (by explicitly setting hidden = TRUE in their .info files).

For the most part, those last five modules are already "invisible" in the rest of Drupal - they don't have permissions, don't have menu items, etc. The only reason they appear anywhere at all is that they each implement hook_help(). Although slightly out of scope for this issue, I wonder if it's worth thinking about how to merge their help into the main Field module? In that case, they really would be totally hidden in the UI, and I think we could safely mark them hidden and get them off this page too.

Screenshot looks good.

I think it might be confusing to refer to distributions using 'core', i.e. "Pressflow core" or "Open Atrium core", which might depend on contrib modules, which is odd to call 'core'.. :) Could we leave that off and just have "Required by: Open Atrium", etc.?

Re: #57, I agree with that. Even if the profile dependencies would be controlling what is shown as required, the distribution name could substitute fine for the profile name.

Oops, cross posted the status.

re #58:

1. In a subreality, at least Node and Filter module are technically not required. We just marked them as such, lacking time to explain why. D8, just mentioning.
2. Instead of considering to hide field modules, it would be wonderful for contributed modules to have a dedicated "Field" package to add field related modules into. We have field storage modules, fields, field widgets, field formatters, etc. It would be wise to expect a lot of noise in this entire area, just like we had for CCK for D6 already, and truth to be told, Field API shapes a sufficiently atomized topic that deserves its own package. We don't want all field related modules to show up in "Other".

This version:

1. Fixes the broken tests.
2. @sun's point in #62.2 is interesting. In the attached patch, I tried it with that. I still moved the main Field module to "Core" because Field UI is already there (and it makes sense to display them together; although I guess we could equally move them in the other direction), but I left the others visible and renamed the category to "Fields" so that contrib modules can use it as a repository for field-related modules. A new screenshot is attached - what do people think? I think I was thrown off last time by Field SQL Storage, which is a ridiculously ugly name; looking past that, it actually might look somewhat nice to show the others.

Re #60, yeah, I thought "core" by itself was confusing, but "Drupal core"/"Open Atrium core"/"Whatever core" was less so (a distribution can have its own core I think) and went with that because that's what the earlier patches such as #22 were using. I'd definitely be happy with just "Required by: Drupal" too. Left it as is for now, but happy to change it.

Wow, I like that. I think that is a really good solution.
"Field" and "Field UI" is a tough one, I couldn't say.
Just a thought (not really convinced): Moving Image module and File module in there as well?!

I think Image and File should be part of Fields, also. They are fields, aren't they?

Image is fields, but also image styles, but I think image styles are related closely enough to fields too that it's probably fine.

In Drupal 8 I want an entities section, just sayin'.

Scope creep warning! :) Suggest to keep this focused on un-hiding and positioning the required core ones first.

Taxonomy is a field module, too. Moving all of those makes sense - also shapes a clear sign on Drupal's future direction.

@yoroy: To unhide/show them, we have to know where and how they make sense.

@catch: This remix will leave entity modules (Node, User, Comment[, Taxonomy]) and core "features" (Blog, Forum, Tracker, etc.), and functionality add-ons (OpenID, Contextual, etc.) in "Core". If we expect noise in the "Fields" area, should we also expect noise in the "Entity" area? I.e., should we also split "Entities" off from "Other Core Stuff" for D7 already?

'You can't disable these but here they are anyway' seems like a stronger relation to group by. I'm really not too keen on showing more stuff 'for information purposes only' scattered across the modules tables. Consider how many people are helped with this info vs. how many really don't need/want to know about this.

Taxonomy isn't just a field module, I think for an initial patch, the Core - fields category should just go, and leave everything in core, then a followup if categorising core modules is desired.

@catch's plan sounds good to me. Recategorizing core modules could definitely be very beneficial, but it sounds like it's turning out to be more complicated than "Core" vs "Fields" and generally opens up a big can of worms, so let's do that in a followup issue.

I will plan to reroll the patch tonight with the following changes:

1. Move everything into the "Core" package and show them all.
2. Use "Required by: Drupal" rather than "Required by: Drupal core" as the text, following @carlos8f's suggestion.

If after looking at that screenshot we think there are some that are particularly offensive to display that way (e.g., Field SQL Storage), then for the purposes of this patch we can hide those individually by putting hidden = TRUE in their info files -- which would be very easy to change back later, if/when we find an acceptable way to display them.

Yeah, let's please bear in mind that we entered UX freeze on Dec. 1, so the less janking around we do with the interface, the better. I'd like to just fix the bug, plz.

+1000 for this change, though. Thanks for the great summary @ #50, David!

OK, here is what it's like with the changes described in #71.

I think the candidates to consider hiding are: Field SQL Storage, List, Number, Options, and Text.

And I'm still not sure what's better, "Required by: Drupal" or "Required by: Drupal core". But either way I think we are getting close :)

To be honest I'm not even sure why list, number, options and text are required, seems completely arbitrary, but separate issue.

Screenshot looks good, have not reviewed patch.

a) Like catch, I'm equally surprised by the list of required modules. Separate issue.

b) We should not hide any module. Only by displaying all modules, Drupal users and developers will be able to understand that a particular functionality is driven by a particular module, and not by arbitrary core code. It allows for the logical synaptic transmission that there may be similar or related modules.

Just as a note, as you can kind of grasp from the screen shot, we actually now have a Help page for every single core module, hidden or not, that at least explains what its purpose is. For that reason and what sun said in #75-b, I agree that no module should be hidden.

I like this patch, and would be in favor of RTBC if the test bot agrees.

As far as WTFs for follow-up: I agree with #74/#75 that the list of which modules are required is capricious/arbitrary. We should make as few as possible of them required (in an intrinsic sense by Drupal, in the .info) and as few as possible required by the minimal/standard install profiles. By all means, enable a bunch of them by default in the install profiles, but don't make it impossible for me to pare down a site by turning them back off.

This is looking fantastic, I am so thrilled to see this going in, thanks so much David and everyone who's been working at it. Agreed on all the changes in 70/71, and a huge +1 to sun's comment 75b, that's one of the biggest reasons I think it should all be out in the open, as I know it helped me understand what Drupal was capable of when I was first configuring sites. The rest about where to put what is indeed the icing on the cake.

-------

Slight aside, I'm trying to recall our (jhodgdon and myself) rationale regarding documenting the help for each field sub-module separately... I can't find any evidence of how we came to decision that in the old help issues, but I think it boiled down to:

1) Wanting to document help for every core module, which was partly because the help page for each core module has the link into the module's Handbook page on d.o.

2) The idea that if people added in other field related modules (date, link, email, etc.) those modules would have their own help hooks, so it would be odd for the core field modules not to.

Looks ready to fly for me. Let's make sure to open two separate issues for 1) Actually required modules, 2) New "Fields" package for core and contrib.

Great. Committed to HEAD! Thanks!