Flesh out list of modules that were moved to core in 8.x

This will be tricky. Was date moved into core? Partially it was but there are (many) features in date that are not found in core. I kind of remember other field modules getting the trimming treatment before getting into core.

http://drupal.stackexchange.com/a/68139/49

1. +++ b/upgrade_status.module
   @@ -258,6 +258,189 @@ function theme_upgrade_status_last_check($variables) {
   +      $projects[$project]['help'] = t('Not including recurring dates support.');
   

   (and elsewhere)

   I'd generally replace the negated "not" with "without", which allows us to make the notes more concise and readable; e.g., here:

   "Without recurring dates support."

2. +++ b/upgrade_status.module
   @@ -258,6 +258,189 @@ function theme_upgrade_status_last_check($variables) {
   +    case 'email':
   +      $projects[$project]['in_core_since'] = '8.x';
   +      $projects[$project]['help'] = t('Simple text field with HTML5 validation only.'); ¶
   

   The additional "contact" feature of the E-mail module should never have been included in that module.

   In "minor" cases like this, I did not add a note/help text previously.

   For the vast majority of users, the core email module meets their expectations. So if we want to output any note, then we should output the reverse/opposite; e.g., "E-mail address contact forms are not supported by core."

3. +++ b/upgrade_status.module
   @@ -258,6 +258,189 @@ function theme_upgrade_status_last_check($variables) {
   +      $projects[$project]['help'] = t('Simple text field with HTML5 validation only.');
   

   That's not right. :)

   Status quo is:

   "Without support for internal links."

4. +++ b/upgrade_status.module
   @@ -258,6 +258,189 @@ function theme_upgrade_status_last_check($variables) {
   +    case 'phone':
   +    case 'telephone':
   +      $projects[$project]['in_core_since'] = '8.x';
   +      $projects[$project]['help'] = t('Simple text field with HTML5 validation only.'); ¶
   

   I think we can remove this note.

Hm. Grepping for "help" in upgrade_status.report.inc yields zero results, but "in_core_note" is actively used, so all of the "help" seem to be wrong ;)

IIRC, there might have been a "help" previously. But "in_core_note" is also meant to be consistent with the "in_core_since" property.

See also:
https://drupal.org/node/2116417
https://drupal.org/node/2164623

Seems weird to say that things like BEAN and navbar are in core... should the module have a different handling for "core functionality replaces/renders obsolete"? I'd be confused as heck when I opened core/modules and saw only a quarter these things.

+++ b/upgrade_status.module
@@ -258,6 +258,189 @@ function theme_upgrade_status_last_check($variables) {
+      $projects[$project]['help'] = t('Simple text field with HTML5 validation only.'); ¶
...
+      $projects[$project]['help'] = t('Simple text field with HTML5 validation only.'); ¶
...
+      $projects[$project]['help'] = t('Bulk operations on simple actions only. No support for batch operations or configurable actions.'); ¶
...
+      $projects[$project]['help'] = t('API support added to the core "Editor" module. No support for multiple text editors per text format.'); ¶

TRAILING WHITESPACE?!!1 ;)

> should the module have a different handling for "core functionality replaces/renders obsolete"

Please consider that any module that won't have a D8 version might need a migration in core. It's somewhat unfair to expect developers of a project to write a D8 version that only contains the migration...

I was surprised to discover today that upgrade_status still doesn't tell you about all the new shiny in D8 core and started making this patch again, totally forgetting there was already something here.

Escalating the priority since D8 is in RC and this is kind of urgent now. I'll update the patch and incorporate the things I've added locally.

Note that I couldn't figure out where the in_core_note was actually displayed, but at this point I think it's better to get it in and then annotate as needed.

I've also been referencing https://www.drupal.org/added-d8-modules, but it is less useful because it only tells you the new D8 module names, some of which were part of D7 core in a different way.

Attached:

1. Incorporates @sun's feedback from #8 and #10.
2. Removes trailing whitespace.
3. Improves some of the notes.
4. Provides information on what replaces modules that do not have a direct replacement as a core module.
5. Removes some D7 lines that got duplicated somehow (bad diff?).
6. Adds a note about Features, because the 80% usecase of Features is not Features.

Let's try that again. Previous attached patch was just the interdiff.

Filed #2603860: in_core_note and in_core_since do not display anywhere as well.

Please consider that any module that won't have a D8 version might need a migration in core. It's somewhat unfair to expect developers of a project to write a D8 version that only contains the migration...

That has nothing to do with this issue, which is just about reporting functionality that is included in D8 core.

+++ b/upgrade_status.module
@@ -258,16 +258,164 @@ function theme_upgrade_status_last_check($variables) {
+    case 'i18n_views':

The machine name does not actually contain an underscore.

Thought I uploaded this patch last night -- but correcting the module name, removing accidental changes to the D7 listing, and improving the wording for Services.

+++ b/upgrade_status.module
@@ -258,6 +258,154 @@ function theme_upgrade_status_last_check($variables) {
+    case 'admin_language':
+    case 'entity_translation':
+    case 'fallback_language_negotiation':
+    case 'translation':
+    case 'i18n':
+    case 'i18nviews':
+    case 'l10n_install':
+    case 'l10n_update':
+      $projects[$project]['in_core_since'] = '8.x';
+      $projects[$project]['in_core_note'] = t('Replaced by core localization functionality, the core Language module, and the core Configuration, Content, and Interface Translation modules.');
+      break;

@xjm asked me to look at this. I don't think anyone would use the 'translation' contrib module (there is a D7 core module with the same name). The others are good.

The variable module suite is also superseded by config and config schema. Not strictly multilingual but it was one of the main uses.

I published a module list in https://drupalwatchdog.com/volume-4/issue-1/drupal-babel. From that, title is missing here, but then listed later :)

Modules that were partially added to core are stringoverrides (in terms of overriding English text now in core) and transliteration (in terms of the API and use for machine names). There are other features of those modules that are not in core. Your list includes transliteration, but that was not entirely added to core. And the list lacks string overrides AFAIS.

Thanks @Gábor Hojtsy! I'll update those things.

Attached:

• Removes translation.
• Adds variable.
• Adds a note that core transliteration does not include support for transliterating filenames. Edit: this should be updated to say "path aliases or filenames".
• Standardizes on "No support" rather than "Without support".
• Adds stringoverrides. This would be better if it listed what core doesn't do that stringoverrides does, but I'm not sure what that is.

Rerolled using #2603876: "Recommended version" makes no sense for modules now in core.

Here's an example screenshot with a few common modules.

I'm planning to commit this as it is now and tag an alpha. We can correct any of the current patch or add additional modules in followup issues.

Cherry-picked with a small merge conflict to resolve.