NodeType's settings array was meant to be able to store information from mutliple modules

@effulgentsia pointed out that this is a schema addition, so no beta deadline. Makes sense as a beta target though.

Go!

Nice, will give this a try. This will overlap with #2226493: Apply formatters and widgets to Node base fields, which is cleaning up bogus node type options, would be awesome to get reviews/RTBC over there and get it out of the way.

/me like ThirdPartySettingsTrait.

Based on the discussion in the other issue, I also killed of node.type.settings and moved the few remaining things to separate top-level properties, with better names and methods.

One thing I'm not sure about is the forced default value that you have to provide. It has the advantage that it immediately solves the problem that it is currently impossible to provide default node types with non-default menu_ui menu settings, as it forcefully overrides it, but it is a bit tedious to repeat and very unlike other configuration behavior (where the defaults stick and don't change when the coded default changes).

Will probably need some test for menu_ui default configuration/sync to make sure the schema stuff and so on is right, but a manual export test worked fine.

Fixing those tests.

Well, that is a disturbing amount of tests that create nodes with non-existing types.

We might want to add an existence check back, I'm surprised that actually still "works" but figured it makes sense to clean up those tests anyway, it's going to hurt us sooner or later.

Two more tests fixed.

Looks sensible!

This is still tagged with Needs tests, but I think we should be pretty good here.

+++ b/core/modules/node/node.module
@@ -635,11 +635,10 @@ function template_preprocess_node(&$variables) {
   // Display post information only on certain node types.
   // Avoid loading the entire node type config entity here that may not exist.
-  $node_type_config = \Drupal::config('node.type.' . $node->bundle());
+  $node_type = $node->type->entity;
   // Used by RDF to add attributes around the author and date submitted.
   $variables['author_attributes'] = new Attribute();
-  // Display submitted by default.
-  $variables['display_submitted'] = $node_type_config->isNew() || $node_type_config->get('settings.node.submitted');
+  $variables['display_submitted'] = $node_type->displaySubmitted();

I'm not sure if there was any profiling done on this and it's less a problem now with the render cache, but at least the comment above loading the node type needs to be updated. Setting back to needs work for that.

It might also make sense to wait before committing this until @alexpott is back, so he can confirm that this is in line with what he had in mind.

Another thing is $node->type->entity, we use that in a few places, not sure if we want to add a method for it. There is an issue somewhere that getType() is incorrectly named as it returns the ID of the type and not the type object. But the interesting/weird thing is that the ID property of node types is type, and getTypeType() would *not* make sense ;) But if we keep that, then I don't know how to name a method that returns the node type entity...

getNodeTypeType() !

- Removed the comment
- Removed the use
- #2333985: Migrate menu_default_node_menu setting. Fun stuff.

For change record, I'm thinking about what exactly we want, possibly two?

- One that just says that the specific menu settings are now third party settings of nodes and how to access them, possibly with a reference to the second.
- And a generic one that describes how to convert the 7.x node_type variable tricky to third party settings, as done here (with #entity_builders and stuff).

Makes sense?

+++ b/core/modules/book/config/install/node.type.book.yml
@@ -2,11 +2,8 @@ type: book
+new_revision: false
+display_submitted: true
+preview_mode: 1

I quite like this but I can't see anywhere in the issue where it was discussed to rename these? Surely this is a beta blocker if we're going to rename these?

@benjy: I kind of agree. This is already tagged as beta target and a critical (which is a strange combination). Anyway, it should be ready except the change records.

Also, it's not just those renames. Moving the menu_ui configuration to third party settings is just as big a change.

Done:

Generic change record: https://www.drupal.org/node/2334447
Menu-specific changes: https://www.drupal.org/node/2334449

there are existing issues for $node->type->entity/$node->getType(), I think we don't need to change this here.

Who wants to RTBC? :)

Re-roll, being optimistic.

Clearly being too optimistic again.

Fixing the new test.

This is already tagged as beta target and a critical (which is a strange combination).

Just a note on this, it is a bit weird but I think it works:

Critical -> has to be done before release.

Beta target -> might have some impact on contrib modules and/or require data migration, however the change doesn't have enough impact to require actually blocking the beta.

So critical/beta target represents changes that we will do right up until RC, but are going to be more annoying (upgrade path needs writing, handful of contrib modules might get broken) the later they get done.

Committed/pushed to 8.0.x, thanks!