Add tests for menu links not expanded on front page and other pages

July 28, 2014, 5:46 pm

≫ Next: Annotations topic should document PluginID shorthand

≪ Previous: Remove uses of drupal_add_http_header and related functions

Problem/Motivation

Related to point 8 in #75 on #2301317-75: MenuLinkNG part4: Conversion
(and #53)

Was fixed.

Proposed resolution

Add test for expanded checkbox, and that links are expanded/or not.

Remaining tasks

look at current test coverage to understand what might be missing
add test(s)

Contributor tasks needed
Task	Novice task?	Contributor instructions	Complete?
Create a patch		Instructions
Add automated tests		Instructions
Review patch to ensure that it fixes the issue, stays within scope, is properly documented, and follows coding standards		Instructions

User interface changes

No.

API changes

No.

↧

Annotations topic should document PluginID shorthand

July 24, 2014, 4:09 pm

≫ Next: Add test for menu links and custom menu links are rendered translated in both nav menu and a menu block

≪ Previous: Add tests for menu links not expanded on front page and other pages

API page: https://api.drupal.org/api/drupal/core%21modules%21system%21system.api.p...

The Annotations topic should document that some annotation types, which extend the PluginID annotation class, have only a single 'id' key in their annotation. For these, it is possible to use a shorthand annotation:

* @SimplePluginType("id_value")

in place of

 * @SimplePluginType(
 *   'id' => "id_value"
 *  )

Task: Add this information to the topic, which is located in the file core/modules/system/system.api.php near the end (although the topic documentation may soon be moved to file core.api.php).

Note that you need to leave a space after the @ sign, as is done in the rest of this documentation.

↧

Add test for menu links and custom menu links are rendered translated in both nav menu and a menu block

July 28, 2014, 5:51 pm

≫ Next: Make the entity storage system handle changes in the entity and field schema definitions

≪ Previous: Annotations topic should document PluginID shorthand

Problem/Motivation

Related to point 15 in #75 on #2301317-75: MenuLinkNG part4: Conversion

Was fixed.

Proposed resolution

Add tests for menu links (the default/plugin ones) and custom menu links title translation in different kinds of rendered places (navigation menu and a menu block).

Remaining tasks

look at current test coverage to understand what might be missing
add test(s)

Contributor tasks needed
Task	Novice task?	Contributor instructions	Complete?
Create a patch		Instructions
Add automated tests		Instructions
Review patch to ensure that it fixes the issue, stays within scope, is properly documented, and follows coding standards		Instructions

User interface changes

No.

API changes

No.

↧

Make the entity storage system handle changes in the entity and field schema definitions

March 24, 2012, 2:17 pm

≫ Next: Poll title should have same length as regular content type (255)

≪ Previous: Add test for menu links and custom menu links are rendered translated in both nav menu and a menu block

Updated: Comment #113

This is being coded in the D8MI - Entity Translation sandbox.
Test issue: #2298525: Test issue for Make ContentEntityDatabaseStorage handle changes in the entity schema definition.

Problem/Motivation

In #2183231: Make ContentEntityDatabaseStorage generate static database schemas for content entities we introduced the capability for the entity storage to automatically generate the SQL schema for any entity type. This is currently limited to static generation at install time and concerns only the tables described in the official entity storage SQL table layout standard. That is the ones storing values for base fields. At the moment dynamically handling changes in the entity type and field definitions, and reflecting them in the SQL table layout, is not supported.

This is a critical missing piece towards achieving a whole set of improvements:

Modules are no longer required to inject random data into the $entity object during the load phase, since all the data retrieval is handled by the storage itself. This will motivate module authors to define their data through field definitions, instead of using random properties, with all the related benefits, such as automatic Rules integration, typed-data validation and so on.
Any entity type leveraging the core entity storage API, natively supports revision and translation without requiring module authors any additional effort.
Translation and revision support can be independently enabled/disabled by just altering the entity type definition. This makes it easy for site developers to adopt the table layout that is the most performant with respect to their business requirements.
Additional base fields can easily be added to the native entity table layout, making it straightforward to implement highly-efficient denormalization strategies.
The API is designed without having a particular storage backend in mind. This means module authors can leverage a storage-agnostic API without any additional effort required.

Proposed resolution

Part 1: unified API

Extend the content entity schema handler implemented in #2183231: Make ContentEntityDatabaseStorage generate static database schemas for content entities to be able to handle the addition/removal/update of field storage definitions, transparently handling differences between single-valued base fields, which are stored in the entity tables, and bundle fields or multiple-value base fields, which instead are stored in dedicated tables.
Make the content entity schema handler able to handle changes in the entity type definition for the revisionable and translatable properties.
Move the Field SQL Storage (private) API to the (default) table mapping implementation, which is the SQL specific part of the core entity storage API, responsible for representing how fields are mapped to tables.

Part 2: UI and data handling

Implement a new EntitySchemaManager service responsible for spotting differences between the installed schema and the one generated from the current versions of the entity type and field storage definitions. Probably leveraging state to track changes.
Based on the current Field Storage API limitations, implement a set of validation rules so that only changes that do not imply a data migration are applied to the schema when data exists, that is:
- adding a field table
- adding a custom field column to a base/data/revision table
- switching from revisionable to non-revisionable
- switching from translatable to non-translatable
Any change not (yet) reflected in the installed schema is reported as an error in the status report, which offers a link to the update.php script to fix the database schema. The update.php script calls the entity schema manager to trigger any allowed schema change.

See #48 for a detailed description of the implementation plan: it's a bit outdated but many details are still valid.

Remaining tasks

~~Implement part 1~~
Implement part 2
Reviews
Party!

Follow ups

User interface changes

Entries added to the status report page.
Minor tweaks to the update.php UI.

API changes

All the Entity Field CRUD API has moved to the entity schema handler.
All the Field SQL storage (private) API has been moved to the default table mapping.

↧

Poll title should have same length as regular content type (255)

July 17, 2014, 12:49 pm

≫ Next: Sometimes you want more than 128 chars of allowed file extensions

≪ Previous: Make the entity storage system handle changes in the entity and field schema definitions

Problem/Motivation

The poll module title is limited to 128 characters, even though the database schema allows for 255 characters. This is due to the fact that poll_form() redefines the edit form without specifying the maxlength of the title element. The default length of a textfield in the form API is 128.

from poll_form():

<?php
  $form['title'] = array(
    '#type'=> 'textfield',
    '#title'=> check_plain($type->title_label),
    '#required'=> TRUE,
    '#default_value'=> $node->title,
    '#weight'=> -5,
  );
?>

node_content_form() forces the length to 255:

<?php
    $form['title'] = array(
      '#type'=> 'textfield',
      '#title'=> check_plain($type->title_label),
      '#required'=> TRUE,
      '#default_value'=> $node->title,
      '#maxlength'=> 255,
      '#weight'=> -5,
    );
?>

poll.module was removed from D8, so filing this against D7 directly.

Proposed resolution

Force length of poll.module title form element to 255.

Remaining tasks

patch

User interface changes

none

API changes

none

↧

Sometimes you want more than 128 chars of allowed file extensions

May 30, 2014, 2:00 pm

≫ Next: user.api.php hook summary lines should be more consistent with other entity hooks

≪ Previous: Poll title should have same length as regular content type (255)

Problem/Motivation

In D8's core/modules/file/src/Plugin/Field/FieldType/FileItem.php and D7's modules/file/file.field.inc uses textfield's default '#maxlength' => 128. On Drupal.org, we want more than that, #1246118: Allow uploading of videos (screencasts) to d.o.

Before screenshot

Proposed resolution

Increase the file field widget allowed extensions setting input to 256.

After screenshot

Remaining tasks

Contributor tasks needed
Task	Novice task?	Contributor instructions
Add automated tests	Yes	Instructions
Manually test the patch	Novice	Instructions
Embed before and after screenshots in the issue summary	Novice	Instructions
Review patch to ensure that it fixes the issue, stays within scope, is properly documented, and follows coding standards		Instructions

User interface changes

API changes

Original report by @drumm

↧

user.api.php hook summary lines should be more consistent with other entity hooks

April 7, 2011, 10:21 pm

≫ Next: Lazy inititialize the theme system by injecting the theme negotiator into places with uses global $theme

≪ Previous: Sometimes you want more than 128 chars of allowed file extensions

Problem/Motivation

The hook_user_role_*() docs in user.api.php are not consistent with other documentation like hook_node_insert(). @Dave Reid pointed out in #1119158-6: user_role_save() doesn't implement a presave hook that these usually start with "Act on…".

Proposed resolution

Update the docblocks of these hooks.

Remaining tasks

Contributor tasks needed
Task	Novice task?	Contributor instructions	Complete?
Create a patch	Yes	Instructions	No

User interface changes

n/a

API changes

n/a

Original report by @skwashd

Some of the language in user.api.inc is a little clunky and not consistent with others parts of core. This was raised during the review of #1119158: user_role_save() doesn't implement a presave hook.

An example of this is the docs for the hook_user_role_*() functions.

/**
 * Inform other modules that a user role has been added.
 *
...

↧

Lazy inititialize the theme system by injecting the theme negotiator into places with uses global $theme

October 17, 2013, 8:22 am

≫ Next: Event With Multiple sessions

≪ Previous: user.api.php hook summary lines should be more consistent with other entity hooks

Updated: Comment 0

Problem/Motivation

@TODO

#1954892: Replace 'theme callback' and hook_custom_theme() with a clean theme negotiation system

Proposed resolution

Remaining tasks

User interface changes

API changes

↧

Event With Multiple sessions

July 28, 2014, 9:11 am

≫ Next: Remove use of function content_translation_overview(EntityInterface $entity) and the function

≪ Previous: Lazy inititialize the theme system by injecting the theme negotiator into places with uses global $theme

Hi,

I am not sure whether this is the correct place for this question but I was not able to find any other better place . My scenario is I have to create an event with multiple sessions . So, There are typically 20+ workshops with small registration caps (10-15 students). The students need to see what is available, register, and update their registration when necessary. Staff need to be able to see who is registered for what and to create an attendance sheet with that data. Is there any module that could accomplish this feature? OR any ideas how to implement this in a simple way ?

Please assist.

Thanks,
Kavitha.

↧

Remove use of function content_translation_overview(EntityInterface $entity) and the function

July 29, 2014, 9:55 am

≫ Next: Provide a way to keep test results and verbose messages as artifacts

≪ Previous: Event With Multiple sessions

Meta issue: #2205673: [meta] Remove all @deprecated functions marked "remove before 8.0"

↧

Provide a way to keep test results and verbose messages as artifacts

April 29, 2014, 8:17 am

≫ Next: theme_fieldset() should allow any non-empty-string #title

≪ Previous: Remove use of function content_translation_overview(EntityInterface $entity) and the function

Hi,

In my team we are using Simpletests extensively both on local workstations and on our continuous integration server.

Our workflow resembles something like this:

* before committing code to the git repo, developers run all tests pertaining the test group "my-website" and make sure they pass. This is often done in the GUI, as the GUI provides nicely themed green and red test report with links to verbose messages.
* when a change in git is detected by the continuous integration, tests are run on the command line either with drush test-run my-website or php scripts/run-tests.sh.

I modified Drush slightly as documented here so that, when the tests are run on the command line, the themed test reports and verbose messages (captured html code) can be stored in a given directory as a build artifact. This is very useful to quickly figure out what is going wrong with a particular build.

Moshe Weitzman suggested in this issue that it might be worth considering the possibility of adding this functionality to php scripts/run-tests.sh.

Would there be interest in including this functionality to Drupal, as an option for php scripts/run-tests.sh and as a checkbox on the test GUI page? When the option is selected, the themed test results and corresponding verbose messages would be saved to a given directory, for example, public://simpletest/artifacts/ or public://simpletest/artifacts/1234 (the ID of the test).

Other options would be adding this functionality to drush_extras or to a dedicated module.

↧

theme_fieldset() should allow any non-empty-string #title

June 18, 2012, 8:24 am

≫ Next: Regression: Entity definitions miss a language entity key

≪ Previous: Provide a way to keep test results and verbose messages as artifacts

Currently, theme_fieldset() uses empty() to determine whether or not to display a title for the fieldset. This means that #title's such as a zero will not be displayed. The attached patch converts #title to a string and displays the title unless the string is the empty string.

↧

Regression: Entity definitions miss a language entity key

November 25, 2013, 8:09 am

≫ Next: Check for common words in password strength indicators

≪ Previous: theme_fieldset() should allow any non-empty-string #title

While working on #1966436: Default *content* entity languages are not set for entities created with the API we figured that Drupal 8 misses the 'language' entity key, as it got introduced for Drupal 7 in #1495648: Introduce entity language support.

Right now Drupal 8 hard-codes "langcode" as language key, but it should respect the defined 'language' key as we do for the other keys.

↧

Check for common words in password strength indicators

March 23, 2012, 3:37 pm

≫ Next: Delete a field in a content type breaks the site

≪ Previous: Regression: Entity definitions miss a language entity key

Problem/Motivation

Password cracking tools contain lists of commonly used passwords, we should warn users that some passwords are too weak to be of use. Motivation is that currently the password "password" is ranked as fair by the checker tool.

Proposed resolution

This patch integrates Drupal with a third party (MIT licensed) library for password strength checking. The library is zxcvbn.

Remaining tasks

Needs security team review
Needs signoff from someone to assert the inclusion of the new JS library into core - 680k (320k gzipped)

User interface changes

Password strength meter will reflect a better approximation of how long it would take to brute force the password, e.g. the following things will be checked:

English words, with a frequency list skewed toward American usage and spelling
Names and surnames, coming from the US census
A few common keyboard layout based passwords (eg QWERTY)
If the user's email address is used
If the user's email address name part is used
If the user's email address domain part is used
If the user's username is used

API changes

n/a

#454014: Include length in password strength evaluation

Original report by webkenny

So while at the code sprint today I noticed when you type the word, "password", as your password it marks that as "Fair" - Luckily I happened to be sitting with Jakub and greggles was in earshot so we thought maybe based on this report to the security team (See http://drupal.org/node/454014#comment-5743806), it might be worth checking for a list of common words.

↧

Delete a field in a content type breaks the site

July 3, 2014, 3:54 am

≫ Next: Provide interfaces for the local task and action manager.

≪ Previous: Check for common words in password strength indicators

Problem/Motivation

On a fresh Drupal Alpha 13 version I was not able to delete a field without breaking the website. I have try with different fields and I always get the same result.

Steps:

Install a fresh copy of Drupal Alpha13
Delete the comment type for the Article Content type
I will get a "No data received in Google Chrome"
If I reload I got a "The website has encountered an error. Please try again later."

Proposed resolution

I manage to get the site up and running again by dropping all the cache_* table.

↧

Provide interfaces for the local task and action manager.

July 29, 2014, 2:27 pm

≫ Next: Apply formatters and widgets to Node base fields

≪ Previous: Delete a field in a content type breaks the site

Problem/Motivation

Provide interfaces for the local task and action manager.

Proposed resolution

Let's do it.

Remaining tasks

User interface changes

API changes

↧

Apply formatters and widgets to Node base fields

March 26, 2014, 7:59 am

≫ Next: $user->getUsername() should return the username, not the formatted user name

≪ Previous: Provide interfaces for the local task and action manager.

Updated: Comment #0

See Issue summary for #2010930: [META] Apply formatters and widgets to rendered entity base fields (all besides node.title)

This issue is about the following base fields of the Node entity type (basically everything except the title):

author (uid)
publication date (created)
language (langcode)
published (status)
stick at top of lists (sticky)
revision log message (log)

This includes the addition of new widgets / formatters:

author (uid): AuthorFormatter (generic, for EntityOwnerInterface entities) + RouteBasedAutocompleteWidget (generic, to not depend on entity_reference.module) + AuthorAutocompleteWidget (extends the previous one with author-specific UX)
publication date (created): TimestampFormatter (generic) + TimestampWidget (generic)
published (status) & stick at top of lists (sticky): BooleanWidget (generic)
revision log message (log)

Only the language (langcode) field (and its corresponding LanguageWidget) will not be done in this issue, for that we have #2230637: Create a Language widget.

And for datetime.module's "enhancing override" to switch the default text field widget to a fancy datetime widget now has a DateTimeTimestampWidget that can be used for any TimestampItem— this also cleans up datetime.module.

Also removes node_field_extra_fields()! :)

And last but not least, this finally makes the node author and date in-place editable! Or well… almost. In-place editing the author fails, for reasons that swentel and I don't yet understand. Hopefully yched, fago or amateescu can shed some light on that.

Remaining tasks

Fix test failures.

User interface changes

None.

API changes

None. The base fields above are rendered using widgets and formatters, and are no longer exposed as an "extra field".

↧

$user->getUsername() should return the username, not the formatted user name

October 15, 2013, 2:52 pm

≫ Next: Regression: "Translate" local task always visible, also for entities that do not have translation enabled

≪ Previous: Apply formatters and widgets to Node base fields

Problem/Motivation

The same way we have getPassword() and getEmail() which return the raw values, I would expect getUsername() to follow the same logic, and not return a formatted user name. Simpletest for example is under the assumption that getUsername() return the value used to log in a user (the username) when it in fact returns the formatter user name (aka real name). See #1929420-22: $account->getUsername() should be used when outputing username in RDF module for an example where this fails.

Proposed resolution

Align getUsername() with getPassword() and getEmail() and return the raw username value (used to login for example). Use label() get the formatted user name.

Remaining tasks

patch

User interface changes

none

API changes

getUsername() returns the raw/db username. label() returns the same as today: the formatted user name.

↧

Regression: "Translate" local task always visible, also for entities that do not have translation enabled

February 4, 2014, 8:18 am

≫ Next: [meta] Complete Entity Field API

≪ Previous: $user->getUsername() should return the username, not the formatted user name

Problem/Motivation

When the content translation module is enabled, the "Translate" local task is always visible, even if content translation has not been enabled for the bundle.

Steps to replicate

Install a new site with the minimal profile.
Enable the Language and Content Translation modules.
Verify at /admin/config/people/accounts that content translation has NOT been enabled for users.
Go to /user/1

Result: the "Translate" tab is shown and displays an empty translation overview when clicked. This appears to occur for all entities (confirmed for nodes and taxonomy terms).

Screenshot of user translation not enabled:

Screenshot of user admin with the "translate" tab showing even though translation is not enabled:

Screenshot of the empty translation overview page when "translate" is clicked:

Proposed resolution

The "Translate" tab should not be visible, and the path /user/1/translations should return an appropriate error. With this patch from #28 installed a page not found error is returned if the translation modules are not enabled and an access denied error results after enabling the modules if translation is not enabled for the entity.

Remaining tasks

(done) Create initial patch.
(done/pending) Evaluate the tests before and after the patch
(done) Review to confirm all cases in the matrix in #31 are still satisfied.
address the remaining questions listed in #48.
(novice) Review final patch to check it fixes the issue, the change is properly documented and for coding standards. Make sure patch stays within scope of just this issue. | Contributor task documentaiton for reviewing patch

User interface changes

Interface link "translate" will be shown only when translation is enabled for the entity.
translation-overview page will be available only when translation is enabled for the entity.

API changes

None.

↧

[meta] Complete Entity Field API

September 23, 2013, 1:23 am

≫ Next: Support RDFa output in link field formatter

≪ Previous: Regression: "Translate" local task always visible, also for entities that do not have translation enabled

Not Completed

Entity Manager and related topics
	#2144677: Add per entity type managers to improve DX
	#1867228: Make EntityManager provide an entity factory (API Addition)
	#1233394: [Policy, no patch] Agree on a property naming pattern
	#1976158: [meta] Rename entity storage/list/form/render "controllers" (Approved API Change)
	#2015535: Improve instantiation of entity classes and entity controllers
Documentation
	#1729812: Separate storage operations from reactions
Content Entities conversions
	#2256521: [META] New plan, Phase 2: Implement menu links as plugins, including static admin links and views, and custom links with menu_link_content entity, all managed via menu_ui module
Core / module
	#2031717: Remove entity.module - once again. (API Change)
	#2079427: [META] Core/Entity depends on classes / functions from field.module - Same issue (?)
Entity fields
	#2084829: The FieldDefinition should be injected in the Field / FieldItem objects
	#2023473: Merge FieldItem::insert() and FieldItem::update() on fields into preSave()
	#2143297: setters on FieldDefinitionInterface
	#2150511: [meta] Deduplicate the set of available field types
	#2224761: Add support for cross-field-type, extensible, extra configuration
	#2283977: Create a new ConfigEntity type for storing bundle-specific customizations of base fields
Widgets / formatters rendering
	#2023571: Support preprocessing in EntityViewBuilder
	#2010930: [META] Apply formatters and widgets to rendered entity base fields (all besides node.title)Assigned to: Wim Leers
Typed Data / Metadata
	#2002138: Use adapters for supporting typed data (Simplify/re-architect typed data?) (Approved API Change)
	#2028097: Map data types to interfaces
Access
	#777578: Expand the node access API to a general entity access API to improve security (issue about grant system)
	#2028027: [META] Missing access control for base fields
	#2204363: [sechole] Returning TRUE from hook_entity_access()/hook_ENTITYTYPE_access() must not bypass EntityAccessController::checkAccess()
Caching
	#1885830: Enable static caching for config entities
	#2099137: Ensure entity access and field access modules can affect entity render cache granularityAssigned to: effulgentsia
Language
	#1916790: Convert translation metadata into regular entity fields
	#2073217: Remove the $language parameter from the entity view/render system
	#2072945: Remove $langcode parameter from EntityAccessControllerInterface::access() and friends
	#1824964: Setting entity language to an invalid language should throw exception
	#2090983: EntityNG::addTranslation() is slow and unnecessarly called (?)
Storage
	#2068325: [META] Convert entity SQL queries to the Entity Query API
	#1498720: Make the entity storage system handle changes in the entity and field schema definitionsAssigned to: plach
	#2079019: Make Views use SqlEntityStorageInterface
	#2100343: Rename 'fieldable' key in entity definitions
	#2137801: Refactor entity storage to load field values before instantiating entity objects
	#1740492: Implement an entity views data controllerAssigned to: dawehner
	#2068655: Entity fields do not support case sensitive queries
Form Controllers
	#1728816: Ensure multiple entity forms can be embedded into one form (also #766146: Support multiple forms with same $form_id on the same page)
	#2006248: Add an EmbeddableFormInterface so that FormInterface can delegate to multiple objects (possible solution for above problem)
	#1728818: Clarify $operation and the relationship to form modes (as a counterpart of view modes)
	#2091871: Add an ConfigEntityFormController with an exists() method
	#2022875: Resolve difference between submitForm(), submit(), and save() in EntityFormController
Validation
	#2002180: Entity forms skip validation of fields without widgets
	#2023465: Allow validation constraints to add in message replacements
	#2012776: [META] Improve validation constraint test coverage
	#2012690: 'type' constraints generate crappy error messages.
REST
	#1979260: Automatically populate the author default value with the current user
	#2259445: [Meta] Entity Resource unification
Nice things
	#2004672: Add a default value for filter format item properties
Known bugs
	#2031183: Problems editing nodes if datetime.module is not enabled

Completed

Existing meta issues that this replaced
	#1346204: [meta] Drupal 8 Entity API improvements
	#1346214: [meta] Unified Entity Field API
Entity Manager and related topics
	#2095587: #HardProblems DX conclusion: Remove IdentifiableInterface
	#1879200: Remove uneeded $entity_type argument from entity type callbacks
	#2005716: Promote EntityType to a domain object
	#2168333: Ensure custom EntityType controllers can be provided by modules
	#2165155: Change $entity_type to $entity_type_id and $entity_info to $entity_type/$entity_types
	#2164827: Rename the entityInfo() and entityType() methods on EntityInterface and EntityStorageControllerInterface
	#2191655: Type hint $entity_type everywhere it is an instance of EntityTypeInterface.
	#2078387: Add an EntityOwnerInterface
	#1981858: Rename hook_entity_info/alter() to hook_entity_type_build/alter()
	#2191651: Rename Drupal\Core\Entity\Query\QueryInterface::getEntityType() to getEntityTypeId()
	#2119905: Provide @ConfigEntityType and @ContentEntityType to have better defaults
	#2154711: Move entity_get_(form/view)_mode_options() functions to EntityManager and add get(Form/View)ModeOptions() methods
	#2182239: Improve ContentEntityBase::id() for better DX
	#2190313: Add $EntityType::load() and loadMultiple() to simplify loading entities
	#2096899: Add $EntityType::create() to simplify creating new entities
	#2039435: Convert EntityManager to extend DefaultPluginManager
Documentation
	#2216553: Fill in @defgroup/topic docs for Typed Data
	#2216533: Fill in topic/@defgroup docs for Entity API overview
	#2216535: Replace Node overview topic and Node API topic with Entity Hooks topic
Config / Content Entities
	#2004244: Move entity revision, content translation, validation and field methods to ContentEntityInterface
Core / module
	#2050835: Move Widget, Formatter, and FieldType plugin types to the Core\Field system
	#2031725: Move all entity display interfaces to the core component
Entity fields
	#2051923: Rename \Drupal\Core\Entity\Field\Field, related subclasses and interfaces to *FieldItemList
	#2023563: Convert entity field types to the field_type plugin
	#2014671: [META] Convert all field types to plugins
	#1819472: Consider renaming the "_field" data type to "_item" and DX around the reference fields
	#1988612: Apply formatters and widgets to rendered entity base fields, starting with node.title
	#2052135: Determine how to deal with field types used in base fields in core entities
	#2047229: Make use of classes for entity field and data definitions
	#2143263: Remove "Field" prefix from FieldDefinitionInterface methods
	#1798140: Agree upon terminology for configurable fields
	#2042773: Change #items within a theme_field() render array from an array to the same $items object used throughout the rest of the formatter pipeline
	#2095303: Rename 'field_entity' to 'field_config' and 'field_instance' to 'field_instance_config'
	#2152825: rename FieldItemBase::getFieldSetting[s]() to getSetting[s]()
	#2156337: merge ConfigEntityReferenceItemBase up into EntityReferenceItem, and fix inconsistencies
	#2114707: Allow per-bundle overrides of field definitions
	#2027059: Pass validation violation property paths on to widgets
	#2192259: Remove ConfigField.. Item and List classes + interfaces
	#2095919: Kill ContentEntityBase::init()
	#2191709: Remove the "configurable" flag on field types
	#2116363: Unified repository of field definitions (cache + API)
	#2167167: Remove field_info_*()
	#2188075: Remove magic getter of EntityReferenceItem
	#2143291: Clarify handling of field translatability
	#2287727: Rename FieldConfig to FieldStorageConfig
Widgets / formatters rendering
	#2157153: Remove field_attach_preprocess()
	#2090509: Optimize entity_get_render_display() for the case of "multiple entity view"
	#2134887: move field_view_field() / field_view_value() to methods
	#2095195: Remove deprecated field_attach_form_*()
	#2005434: Let 3rd party modules store extra configuration in EntityDisplay
Typed Data / Metadata
	#2002134: Move TypedData metadata introspection from data objects to definition objects
	#1928938: Improve typed data definitions of lists
	#2132145: Rename 'typed_data' / Drupal::typedData() to 'typed_data_manager' / Drupal::typedDataManager
	#2110467: Add first(), get($index) and possibly other methods to ListInterface
	#2144631: Add a revisionable key to field definitions
Access
	#1947880: Replace node_access() by $entity->access()
	#1994140: Unify entity field access and Field API access
	#2078473: Use entity access API for checking access to private files
Caching
	#2027795: Optimize content entity serialization
	#2083785: Add support for determining which field properties are cacheable
	#597236: Add entity caching to core
Language
	#2019055: Switch from field-level language fallback to entity-level language fallback
	#2076445: Make sure language codes for original field values always match entity language regardless of field translatability
	#2018685: Remove field_is_translatable()
Storage
	#2095399: Merge DatabaseStorageController and DatabaseStorageControllerNG
	#2057401: Make the node entity database schema sensible
	#2142549: Support multi-column field types in base tables
	#2095283: Remove non-storage logic from the storage controllers
	#1823494: Field API assumes serial/integer entity IDs, but the entity system does not
	#2144327: Make all field types provide a schema()
	#2267753: ContentEntityDatabaseStorage::mapToStorageRecord hard-codes $entity->$name->value
	#2183231: Make ContentEntityDatabaseStorage generate static database schemas for content entities
	#2144263: Decouple entity field storage from configurable fields
Form
	#2151775: EntityFormController does things that only make sense for ContentEntities
Validation
	#1696648: [META] Untie content entity validation from form validation
	#2070429: Configurable fields aren't validated against the "required" constraint except in forms
Operations
	#1839516: Introduce entity operation providers
REST
Nice things
	#2085071: Auto validate fields on $entity->save(), but allow opt-out
	#1980822: Support any entity with path.module
	#2145103: Provide non-configurable field types for entity created, changed and timestamp fields
	#2201051: Convert path.module form alters to a field widget
Known bugs
	#2050201: Unsetting field item properties via FieldItemBase::set() does not always work
	#221081: Entity cache out of sync and inconsistent when saving/deleting entities

↧

Problem/Motivation

Proposed resolution

Remaining tasks

User interface changes

API changes

Problem/Motivation

Proposed resolution

Remaining tasks

User interface changes

API changes

Problem/Motivation

Proposed resolution

Remaining tasks

Follow ups

User interface changes

API changes

Problem/Motivation

Proposed resolution

Remaining tasks

User interface changes

API changes

Problem/Motivation

Before screenshot

Proposed resolution

After screenshot

Remaining tasks

User interface changes

API changes

Original report by @drumm

Problem/Motivation

Proposed resolution

Remaining tasks

User interface changes

API changes

Original report by @skwashd

Problem/Motivation

Proposed resolution

Remaining tasks

User interface changes

API changes

Related Issues

Problem/Motivation

Proposed resolution

Remaining tasks

User interface changes

API changes

Related Issues

Original report by webkenny

Problem/Motivation

Proposed resolution

Problem/Motivation

Proposed resolution

Remaining tasks

User interface changes

API changes

Remaining tasks

User interface changes

API changes

Problem/Motivation

Proposed resolution

Remaining tasks

User interface changes

API changes

Related Issues

Problem/Motivation

Steps to replicate

Proposed resolution

Remaining tasks

User interface changes

API changes

Not Completed

Completed