Problem/Motivation

If you try to provide a config entity type from within Drupal\Core, the resulting config name is Core.$type.$id.yml, and it should be lowercase.

Proposed resolution

Change the places core uses Core, and switch to core.

Remaining tasks

Pull fixes for this out of #2283977: Create a new ConfigEntity type for storing bundle-specific customizations of base fields

User interface changes

API changes

CommentFileSizeAuthor
#1 2294177.1.patch6.29 KBalexpott
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

alexpott’s picture

Status: Active » Needs review
FileSize
6.29 KB

This ain't really possible to test unless we convert an existing config entity. In many ways action, date format and menu should be in core and not system but that is one heck of a change in terms of config object name change (all existing site would break).

So if we do want to split this off from #2283977: Create a new ConfigEntity type for storing bundle-specific customizations of base fields then this will have to be another beta blocker too. Since this blocks that. Here's the patch if we want to go ahead.

yched’s picture

Other candidates would be entity view/form displays ?

xjm’s picture

Issue tags: +beta deadline
xjm’s picture

An advantage of moving something provided by the entity module is that it also unblocks the issue to de-module-ify entity again.

tim.plunkett’s picture

The other thing we have not resolved it how to deal with things like admin_permission = "administer display modes",

If the UI code is to be moved into field_ui.module and entity.module will be deleted, does that mean that system_permission would have to provide this?

effulgentsia’s picture

xjm’s picture

Based on the discussions in #2295469: Add support for static permission definitions with *.permissions.yml and #2088371: YAML discovery incompatible with translations I'd recommend looking into system_permission() for now, though Gábor also indicated one-off translation for YAYAML (Yet Another YAML) wouldn't be much worse than anything else. But hook_permission() does just work. It's ugly and non-ideal, but it could be fixed in a followup or not.

alexpott queued 1: 2294177.1.patch for re-testing.

Gábor Hojtsy’s picture

I think system_permission() is totally fine. I guess in this case we are not adding tests because we'll do in #2283977: Create a new ConfigEntity type for storing bundle-specific customizations of base fields soon and otherwise not possible here?

alexpott’s picture

Yeah we can't add a specific test for this unfortunately. But the moment it is use it is tested :)

Gábor Hojtsy’s picture

Status: Needs review » Reviewed & tested by the community

All righto, looks good to me. The entity module demodulifying will have to deal with the permission then (in #2031717: Make entity module not required) as far as I understand so this one is good.

Dries’s picture

Status: Reviewed & tested by the community » Fixed

Committed to 8.x. Thanks. It's a bit of a hack but I think we can make an exception to allow for the beta blockers to make progress.

  • Dries committed 135ca1c on 8.x
    Issue #2294177 by alexpott: Allow Drupal\Core to provide [config] entity...

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.

cilefen’s picture