if a node has a populated image field (which does not have a default image specified) with a file that fails to load then the default image formatter will try to display a broken image.

on display
* image_field_load() calls file_field_load()
* file_field_load() tries to load all the referenced files, and replaces the entries which it did not find in the $items array with a NULL
* image_field_formatter_view() walks over all the $items and sends them to theme regardless if the content is NULL. with this, image derivative generation will try to show an image with an uri that doesnt exist.

Problem/Motivation

in #3085717: [PP-1] Do not rely on version_* tags it was determined that release information version_patch and version_extra are not fully tested.

In that issue we want to remove reliance on this metadata from the update xml and instead get the information directly from version number instead.

We should first make sure we have test coverage for the current functionality. Currently these are taken into account for contrib test and may be under tested for core

Proposed resolution

Determine what test coverage we are missing and create it

Remaining tasks

Duplicate \Drupal\Tests\update\Functional\UpdateCoreTest::testNormalUpdateAvailable() which test version_patch and version_extra for core in \Drupal\Tests\update\Functional\UpdateContribTest for contrib

User interface changes

none

API changes

none

Data model changes

none

Problem/Motivation

Cleanup the content management user experience.
The management of the visibility of the author and date information is living in the content type configuration page instead of the Manage display tab.

Proposed resolution

Show the author and creation date on the manage display tabs.
Remove the display author information on the content type settings page.
Remove the theme settings "show author picture on the nodes".

Remaining tasks

Show the author and creation date on the manage display tabs.
Remove the display author information on the content type settings page.
Remove the theme settings "User pictures in posts".
Handle the upgrade path.

User interface changes

Disappearance of the vertical tab "Display settings" on the content type edit page.
Disappearance of the theme setting "User pictures in posts"

API changes

None.

Data model changes

Probably none.

Problem/Motivation

The function referencedEntities() in class EntityReferenceFieldItemList return all the referenced entities without access check. As a result it's mandatory to put a access check for every render and provide multiple occasion to forget it and then display a content link to a users that won't have access.

It's a data security access issue if the content is displayed to users who don't have permission.
It's a bad user experience for user to have a clickable link that open on a "access denied" page.

Proposed resolution

As the minimum access permission grant for every content should be the visibility for it. I suggest to have this ->access('view') permission check before returning the referenced entities and that globally.

Problem/Motivation

The Big Picture of what we've already done

In order for Drupal 8 sites to have great performance, we've done a huge amount of work. A big part of that is making Drupal 8 the first release to no longer break render caching all over the place.
E.g. by no longer doing highly personalized things (such as quick edit links, "new" and "updated" comment markers …) or highly dynamic things (adding a class to the "active" links) without thinking about consequences. Those things have been replaced either with #post_render_cache placeholders/callbacks or client-side rendering.

We've already done this work for all of the obvious violators. So, we're mostly there. But we're not yet 100% there. We're ~95% there in terms of cache tags. But we're nowhere near 100% when it comes to cache contexts.

Cache Contexts: current status & potential

So far only applied cache contexts to 2 things: blocks (see BlockBase) and access results (see AccessResult).

If we'd bring the usage of cache contexts to 100%, then we could truly leverage all that performance work… and bring a massive leap in performance. Because we would have complete knowledge about the contexts by which every rendered thing is varied by, which combined with bubbling of cache contexts, would allow us to reliably cache ever larger pieces of the page, hence needing to invoke ever fewer objects to build ever fewer render arrays, to do ever fewer rendering… to also initialize ever fewer services.

Why?

It is precisely that metadata that was missing in prior versions of Drupal… which required us to generate pretty much everything on the entire page for every single request. But in Drupal 8, we have a Holy Cache Metadata Trinity:

1. Cache keys identify a thing. E.g. ['node', 5]
2. Cache contexts identify the different variations (representations) of that thing. (The contexts it depends upon.) E.g. ['cache_context.user'].
3. Cache tags identify the reasons for (a variation of) a thing to be invalidated. (The other things it depends upon.) E.g. ['node:5', 'taxonomy_term:3']

Together, they give us exactly what we need to cache the majority of a page, instead of the minority (like in the past).

Finally: this allows us to add mindblowing alternative render pipelines, which e.g. automatically convert pieces of content that are varied by a "high frequency cache context" (like the "per user" cache context — there usually are many users on a site) into placeholders. That would mean we can still cache the entire page's HTML, but just have some placeholders in there for the highly personalized (high frequency cache contexts) things, which would be the only things that'd still need to be calculated. Those placeholders could even be rendered BigPipe-style.

For more info about the big performance improvements that this allows, see:

• 3-step plan, with algorithms etc.: https://docs.google.com/document/d/1Gw7ohBOUKu38t4kMbN9zj6cX-4-_2ZNXGotv...
• Step 1 in that plan: #2429617: Make D8 2x as fast: Dynamic Page Cache: context-dependent page caching (for *all* users!).

Proposed resolution

We need it to be applied to everything that can have different representations:

1. field formatters (output may vary depending on the permissions of the user)
2. text format filters (output may vary depending on e.g. language)
3. …

Remaining tasks

Must-haves (in order of importance, most important first)

All done!

Should-haves that we should be able to do after 8.0, because all blockers are critical

• Actionable: #2473873: Views entity operations lack cacheability support, resulting in incorrect dropbuttons
• Actionable (in its own child issues): #2469431: BigPipe for auth users: first send+render the cheap parts of the page, then the expensive parts
• #2526470: Audit core for things missing cacheable metadata (for authenticated users)

Nice-to-haves that we may not be able to do after 8.0 (in order of importance, most important first)

• #2495001: [meta] Add a replacement for renderRoot() that returns a cacheable render array instead of a string
• #2465377: Long-standing architecture flaw: Directly printing a nested element skips important processing (including #access) of parent elements

Can happen after 8.0, because no API changes:

• #2541344: BlockBase subclasses should merge their cache tags/contexts with the parent's (BlockBase's)
• Actionable: #2453945: Use multiple get for #pre_render / #cache where possible
• Actionable: #2480077: Using the URL alias UI to change aliases doesn't do necessary invalidations: path aliases don't have cache tags
• Not started yet: #2453835: Allow non-intrinsic (implementation-dependent) cache context services to specify their parents via DynamicParentContextInterface::getParents()
• #2443077: Add cache_context.main_request to force execution of the main route
• Not started yet: #2495779: Make #theme => links take cacheability metadata as an argument
• #2443077: Add cache_context.main_request to force execution of the main route
• #2352009: [pp-3] Bubbling of elements' max-age to the page's headers and the page cache

Done (in chronological commit order, first listed was committed first):

1. #2318437: Replace the hardcoded langcode key on blocks with the 'language' cache context
2. #2329101: CacheableInterface only has a getCacheKeys() method, no getCacheContexts(), leads to awkward implementations
3. #2429261: Replace the hardcoded cache key on the book navigation block with a 'book navigation' cache context
4. #2428563: Introduce parameter-dependent cache contexts
5. #2430341: Comment pager-dependent cache key should be a cache context
6. #2429257: Bubble cache contexts
7. #2396333: BlockContentBlock ignores cache contexts required by the block_content entity
8. #2445761: Add a X-Drupal-Cache-Contexts header to aid in debugging and testing
9. #2433599: Ensure every (non-views) pager automatically associates a matching cache context
10. #2445743: Allow views base tables and entity types to define additional cache contexts
11. #2443073: Add #cache[max-age] to disable caching and bubble the max-age
12. #2453891: Renderer::getCacheableRenderArray() does not include max-age
13. #2444211: Document cacheability of render arrays, and the considerations to use when generating render arrays
14. #2432837: Make cache contexts hierarchical (e.g. 'user' is more specific than 'user.roles')
15. #2448823: Add languages:<type> cache contexts
16. #2458413: BlockViewBuilder should specify cache contexts even for uncacheable blocks
17. #2458993: #cache[expire] is undocumented, unused, untested: remove it, use #cache[max-age] instead
18. #2428805: Remove the ability to configure a block's cache contexts
19. #2459003: #cache[cid] breaks bubbling
20. #2428703: Add a 'user.permissions' cache context (was: "Should cache contexts be able to associate a cache tag?")
21. #2451679: Validate cache contexts (+ cache contexts in some views plugins wrong)
22. #2453059: Set default render cache contexts: 'theme' + 'languages:' . LanguageInterface::TYPE_INTERFACE
23. #2444231: Fix CacheableInterface so it makes sense (was: "Make Config objects & Entities implement CacheableInterface + add BubbleableMetadata::createFromCacheableObject()")
24. #2458349: Route's access result's cacheability not applied to the response's cacheability
25. #2460013: Uninstalling modules containing cache contexts or #post_render_cache callbacks may break Drupal if they are cached somewhere
26. #2462851: Improve Views entity row renderer plugins' cache contexts
27. #2452317: Let views result cache use cache contexts
28. #2459819: Remove CacheableInterface (and no longer let block plugins implement it)
29. #2464877: Update RendererInterface::addDependency() to accept *any* object, not only CachableDependencyInterface objects
30. #2099137: Entity/field access and node grants not taken into account with core cache contexts
31. #2469277: Changing #cache keys during #pre_render or anywhere else leads to cache redirect corruption
32. #2468151: Rename the CacheContexts service to CacheContextsManager
33. #2463009: Introduce CacheableResponseInterface: consolidate ways of setting X-Drupal-Cache-Tags/Contexts headers
34. #2466585: Decouple cache implementation from the renderer and expose as renderCache service
35. #2335661: Outbound path & route processors must specify cacheability metadata
36. #2489966: The Views table style plugin does not specify cache contexts for click sorting
37. #2433591: Views using pagers should specify a cache context
38. #2487099: Set cache contexts for exposed sorts / items_per_page / offset.
39. #2493091: Installing block module should invalidate the 'rendered' cache tag
40. #2493047: Cache redirects should be stored in the same cache bin
41. #2470715: cacheGet-case: #post_render_callback's that result from other #post_render_calback are not processed
42. #2483781: Move cache contexts classes from \Drupal\Core\Cache to \Drupal\Core\Cache\Context
43. #2407195: Move attachment processing to services and per-type response subclasses
44. #2500443: Cache API topic says nothing about cache context, add something
45. #2511472: Refactor all usages of drupal_render()/Renderer::render() that break #2450993
46. #2449459: [PP-1] Make URLs cache context aware
47. #2487600: #access should support AccessResultInterface objects or better has to always use it
48. #2463581: #cache_redirect cache items should have an 'expire' timestamp that matches the merged max-age
49. #2495171: Block access results' cacheability metadata is not applied to the render arrays
50. #2375695: Condition plugins should provide cache contexts AND cacheability metadata needs to be exposed
51. #2443323: New convention: CacheContextInterface implementations should mention their ID in their class-level docblock
52. #2450993: Rendered Cache Metadata created during the main controller request gets lost
53. #2512718: EntityManager::getTranslationFromContext() should add the content language cache context to the entity
54. #2512866: CacheContextsManager::optimizeTokens() optimizes ['user', 'user.permissions'] to ['user'] without adding cache tags to invalidate that when the user's roles are modified
55. #2349679: Support registration of global context
56. #2217985: Replace the custom menu caching strategy in Toolbar with Core's standard caching.
57. #2351015: URL generation does not bubble cache contexts
58. #2525910: Ensure token replacements have cacheability + attachments metadata and that it is bubbled in any case
59. #2524082: Config overrides should provide cacheability metadata
60. #2430397: When mapping cache contexts to cache keys, include the cache context ID for easier debugging
61. #2526472: Ensure forms are marked max-age=0, but have a way to opt-in to being cacheable
62. #2559011: Ensure form tokens are marked max-age=0
63. #2504139: Blocks containing a form include the form action in the cache, so they always submit to the first URL the form was viewed at
64. #2429617: Make D8 2x as fast: Dynamic Page Cache: context-dependent page caching (for *all* users!)
65. #2458763: Remove the ability to configure a block's cache max-age
66. #2464427: Replace CacheablePluginInterface with CacheableDependencyInterface
67. #2483887: Mark RenderCache as internal

Problem/Motivation

The d7_url_alias migration runs at an arbitrary time. This has been fine. Until recently

Recently, two things happened that make this problematic:

1. It's now possible to enable validation for content entity type destinations #2745797: Add option to content entity destinations for validation
2. Path aliases have been converted to entities: #3009014: Convert path alias migrations to use entity:path_alias destination and … added validation logic

Combined, this means that if you enable validation for content entity destinations (and you should — see #3095456: [Plan] Discuss strategy for long term use of entity validation in the migration system), the d7_url_alias migration runs at a time when usually no content entities have been migrated yet. Result: an enormous amount of validation errors for PathAlias entities.

Proposed resolution

Automatically enhance migrations with Path Alias entities as their destination (destination plugin entity:path_alias) to have optional dependencies on every migration that has a locatable content entity type as their destination (if it's not locatable, it can't have an URL, and there's no point in pushing Path Alias entity creation until later).

In Drupal core, this would affect the d6_url_alias and d7_url_alias migrations. But it would also automatically enhance contributed/custom migrations.

Remaining tasks

Review.

User interface changes

None. Other than: far fewer validation errors when validations are enabled.

API changes

None.

Data model changes

None.

Release notes snippet

N/A

Problem/Motivation

On the single item config export form (/admin/config/development/configuration/single/export), one can change the configuration type in order to see configuration names that match the type, before then choosing a configuration name to be shown the item's export code. However, once a configuration name has been chosen, changing the configuration type leaves the export code in place, which can be confusing UX.

Proposed resolution

The proposed solution is to clear the export field value when the configuration type is changed. This will prevent confusion and allow the user to then choose a configuration name for the newly-select type.

Remaining tasks

A patch for this change is attached, and review/testing/comment would be appreciated. The change does not alter the UI or other behaviour on the form.

Child elements in grouping elements like (meta) details and vertical tabs are invisible to the user when the grouping element is closed or not-focused respectively.
To improve the user experience and accessibility we should indicate when there are errors 'inside'.
Currently it is hard for the user to find the actual problematic field when the (child) field itself is invisible.

Note that only the Seven theme knows the additional concept of using Details elements as meta data elements at the right side of the node edit page.

Before

Meta details open (Seven only, LTR)

After (proposal)

Meta details open (Seven only, LTR)

Meta details closed (Seven only, LTR)

Meta details open (Seven only, RTL)

Meta Details closed (Seven only, RTL)

Normal Details closed (Seven only, LTR)

Normal Details closed (Bartik, LTR)

Normal Details closed (Bartik, RTL)

Vertical Tabs not focused (Seven, LTR)

Vertical Tabs not focused (Seven, RTL)

Vertical Tabs focused (Seven, LTR)

Vertical Tabs focused (Seven, RTL)

Vertical Tabs non focused (Bartik, LTR)

Vertical Tabs non focused (Bartik, RTL)

One of the most difficult things about manipulating Drupal forms is the process of manipulating the arrays themselves. And one of the things that I commonly want to do is "stick this stuff in after that". But I have yet to find a PHP function to manipulate arrays in this way.

So I wrote this function called array_insert(). Perhaps there's a cleaner way to handle this, but it seems like a function that should be available in Drupal core. It would certainly help with a lot of common hook_form_alter() tasks.

For instance, this function (finally) offers a way to stick something into the node-type settings page (admin/settings/content-types/[node-type]) immediately before the "submit" buttons, you'd just create an array with your form items and then call

$form = array_insert($form, 'buttons', $my_stuff, TRUE);

/**
 * Inserts values from $arr2 after (or before) $key in $arr1
 * if $key is not found, $arr2 is appended to $arr1 using array_merge()
 *
 * @param $arr1
 *   array to insert into
 * @param $key
 *   key of $arr1 to insert after
 * @param $arr2
 *   array whose values should be inserted
 * @param $before
 *   insert before the given key. defaults to inserting after
 * @return
 *   merged array
 */
function array_insert($arr1, $key, $arr2, $before = FALSE){
  $done = FALSE;
  foreach($arr1 as $arr1_key => $arr1_val){
    if(!$before){
      $new_array[$arr1_key] = $arr1_val;
    }
    if($arr1_key == $key && !$done){
      foreach($arr2 as $arr2_key => $arr2_val){
        $new_array[$arr2_key] = $arr2_val;
      }
      $done = TRUE;
    }
    if($before){
      $new_array[$arr1_key] = $arr1_val;
    }
  }
  if(!$done){
    $new_array = array_merge($arr1, $arr2);
  }
  return $new_array;
}

Problem/Motivation

I would like the field errors to have the same structure as the description of the field - unique id and his id added to his corrsponding input `aria-describedby` attribut (look screenshot).

Proposed resolution

Add this attribute as it is added to the Webform description label.

Problem/Motivation

When tampering with the page parameter for a view and setting it to a huge size, a mysql error occurs:

Syntax error or access violation: 1064 You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near '-6446744073709551616' at line 3: SELECT ...

e.g. http://example.com/myview?page=1e18

Proposed resolution

Add an integer limit on the LIMIT parameter.

Problem/Motivation

As stated in the parent issue #3050389: Remove dependency to Classy from core themes, Classy will be moved to contrib before Drupal 9 and we have to remove dependencies on Classy from all core themes.

This process included documenting template usage in this spreadsheet:Core Theme's use of Classy. This documenting made it apparent that there are 24 templates in Classy that are identical to the same-named templates in Stable. This makes it possible to simply remove these files so they are no longer a Classy dependency for any core theme. (as opposed to copying individual versions of every Classy-inherted template to every core theme, a step that will be necessary for most templates.

Running diff -srq classy/ stable/ | grep identical shows that these templates are identical:

Files classy/templates/content-edit/file-upload-help.html.twig and stable/templates/content-edit/file-upload-help.html.twig are identical
Files classy/templates/content-edit/file-widget-multiple.html.twig and stable/templates/content-edit/file-widget-multiple.html.twig are identical
Files classy/templates/field/image-style.html.twig and stable/templates/field/image-style.html.twig are identical
Files classy/templates/form/checkboxes.html.twig and stable/templates/form/checkboxes.html.twig are identical
Files classy/templates/form/confirm-form.html.twig and stable/templates/form/confirm-form.html.twig are identical
Files classy/templates/form/container.html.twig and stable/templates/form/container.html.twig are identical
Files classy/templates/form/dropbutton-wrapper.html.twig and stable/templates/form/dropbutton-wrapper.html.twig are identical
Files classy/templates/form/form-element-label.html.twig and stable/templates/form/form-element-label.html.twig are identical
Files classy/templates/form/form.html.twig and stable/templates/form/form.html.twig are identical
Files classy/templates/form/input.html.twig and stable/templates/form/input.html.twig are identical
Files classy/templates/navigation/links.html.twig and stable/templates/navigation/links.html.twig are identical
Files classy/templates/navigation/menu-local-action.html.twig and stable/templates/navigation/menu-local-action.html.twig are identical
Files classy/templates/navigation/pager.html.twig and stable/templates/navigation/pager.html.twig are identical
Files classy/templates/navigation/vertical-tabs.html.twig and stable/templates/navigation/vertical-tabs.html.twig are identical
Files classy/templates/views/views-view-grid.html.twig and stable/templates/views/views-view-grid.html.twig are identical
Files classy/templates/views/views-view-list.html.twig and stable/templates/views/views-view-list.html.twig are identical
Files classy/templates/views/views-view-mapping-test.html.twig and stable/templates/views/views-view-mapping-test.html.twig are identical
Files classy/templates/views/views-view-opml.html.twig and stable/templates/views/views-view-opml.html.twig are identical
Files classy/templates/views/views-view-row-opml.html.twig and stable/templates/views/views-view-row-opml.html.twig are identical
Files classy/templates/views/views-view-rss.html.twig and stable/templates/views/views-view-rss.html.twig are identical
Files classy/templates/views/views-view-unformatted.html.twig and stable/templates/views/views-view-unformatted.html.twig are identical

There are 3 additional templates that should be added to this list as they should be identical.
classy/templates/field/image-formatter.html.twig: the only difference a line in Classy's DocBlock that should have been removed in #2350837: Convert most usages of EntityInterface::getSystemPath() to use routes.
classy/templates/form/select.html.twig: the only difference are annotation changes that should have been applied to Stable in #2546248: Use consistent style to mention HTML tags in code comments, but were only applied to Classy.
classy/templates/form/field-multiple-value-form.html.twig: the version in stable had a line of whitespace following the DocBlock that was not present in Classy's

Proposed resolution

Address the differences in the 3 almost-identical templates listed in Problem/Motivation
Remove the templates from Classy
Add a test that confirms these templates were truly identical.

Remaining tasks

Implement, review.

User interface changes

n/a

API changes

n/a

Data model changes

n/a

Release notes snippet

n/a

Follow-up to #2584243: Make Drupal handle path aliases in a consistent and case-insensitive fashion on all database drivers

Problem/Motivation

It is currently not possible to do a case-insensitive LIKE comparison on values with non-ASCII characters, SQLite needs to be compiled with the ICU extension for this:

(18) Case-insensitive matching of Unicode characters does not work.

The default configuration of SQLite only supports case-insensitive comparisons of ASCII characters. The reason for this is that doing full Unicode case-insensitive comparisons and case conversions requires tables and logic that would nearly double the size of the SQLite library. The SQLite developers reason that any application that needs full Unicode case support probably already has the necessary tables and functions and so SQLite should not take up space to duplicate this ability.

Instead of providing full Unicode case support by default, SQLite provides the ability to link against external Unicode comparison and conversion routines. The application can overload the built-in NOCASE collating sequence (using sqlite3_create_collation()) and the built-in like(), upper(), and lower() functions (using sqlite3_create_function()). The SQLite source code includes an "ICU" extension that does these overloads. Or, developers can write their own overloads based on their own Unicode-aware comparison routines already contained within their project.

Ref https://www.sqlite.org/faq.html#q18

Proposed resolution

TBD

One workaround may be to do UPPER(x) = UPPER(y) COLLATE NOCASE_UTF8, where NOCASE_UTF8 is the custom collation defined in the PDO driver.

Remaining tasks

User interface changes

API changes

Data model changes

Problem/Motivation

Discovered in #3003586-21: [PP-4] Use setStorageRequired() instead of overriding the storage schema to mark fields as NOT NULL in the database where the update test fails. The problem is that the only returned revision metadata key in

/**
 * Move revision metadata fields to the revision table.
 */
function system_update_8400(&$sandbox) {

for the block content entity type is workspace when retrieving the keys with $revision_metadata_fields = $entity_type->getRevisionMetadataKeys();. The problem is that the BC layer runs only when the property is not initalized or matches the required revision metadata keys property. However a Workspaces update 8801 updates only the one property inbworkspaces_update_8801().

Potentially there might be a similar problem in workspaces_module_preinstall().

Proposed resolution

In the update modify both properties on the installed entity type similar to the system update 8501 - revision_metadata_keys and requiredRevisionMetadataKeys.

Updating both properties will allow the BC layer to run property.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

How to best inform contrib/other developers how not to use db_like() in their queries

Proposed resolution

open

Remaining tasks

open

User interface changes

no

API changes

no

Data model changes

no

Release notes snippet

maybe

Original report by [username]

@alexpott

What are the steps required to reproduce the bug?

You want to change the language of a word or phrase in CKeditor with the option "Language" in the area "Format".

What behavior were you expecting?

Changing the language in CKeditor this way should produce valid code as:

this <span dir="ltr" lang="fr" xml:lang="fr">Francaise</span> word

or without xml
this <span dir="ltr" lang="fr">Francaise</span> word

What happened instead?

Changing the language in CKeditor with language module, creates invalid output in generated HTML:

this <span dir="ltr" lang="fr" xml:lang="fr" xml:lang="fr">Francaise</span> word

The attributes "xml-lang" is created twice and you get invalide code. For accessibility testing we need valid code.
It doesn't matter if you use simple HTML or full HTML in the editor.

Drupal version: 8.6.17
PHP Version: 7.1.11
Webserver: Apache

There is currently only one assignable user permission for i8ns Translation module: "Translate nodes". Giving a user this permission makes the "Translation" tab appear for all translatable nodes. I would like to request the addition of a "Translate own nodes" permission which causes the "Translation" tab to show up only for those nodes owned by the user.

The BC layer for revision metadata keys has been a source of dozens of lost hours and frustration for Entity API maintainers...

On the Content admin page, I tried the "Delete content" bulk operation with 46 nodes selected. After clicking "Apply", it simply reloads the page (no confirmation form), with the following message:

Delete content was applied to 46 items.

However, the 46 items were still there.

I assume that view is released as part of core, and I have not modified it at all.