After installing showing below error in drupal 9.x-dev.

Deprecated function: The each() function is deprecated. This message will be suppressed on further calls in _drupal_shutdown_function() (line 3363 of core/includes/bootstrap.inc).

Because of this above error all admin menu links are not working.

Problem/Motivation

#2739075: [plan] Make Place Blocks module functionality part of the Block module (etc.) wanted to move the module into block module originally, but now Layout Builder superseded it. So we should figure out a way to deprecate the module and remove it so it in Drupal 9 is not in Drupal 9.0 anymore.

Proposed resolution

1. Figure out a way to deprecate a module. We don't yet have a process.
2. Deprecate this module.
3. Remove it in Drupal 9.

Remaining tasks

Do it.

User interface changes

Module will be removed.

API changes

None.

Data model changes

None.

Release notes snippet

TBD.

Problem/Motivation

Symfony 4 does not contain hard breaking changes compared to Symfony 3 - at least for the components that Drupal core uses and in the way that we use them. Therefore, once the issues that do affect us are fixed (mainly the removal of Symfony's classloader), it should be possible to allow sites to run Symfony 4.

We'll still want to package core with Symfony 3, Symfony 4 would only be available installing with composer.

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

On sites served by https, the session cookie starts with "SSESS" because of Drupal\Core\Session\SessionConfiguration::getName().

drupalUserIsLoggedIn only checks for cookies starting with "SESS".

Proposed resolution

Allow cookies starting with SESS and SSESS.

Note we can't test this on drupal.org because DrupalCI does not offer https testing.

Remaining tasks

Fix it.

At now Drupal autocomplete form fields (eg entity reference autocomplete) needs to type at least one symbol for show field autocomplete results.

But in many situations users don't know what to type in form field, and good to show top of available options to user via simple mouse click on field, without any typing. Replacing autocomplete to select is bad idea, when select contain 1000+ options.

Solution for this problem is enabling searching autocomplete results with empty string, but this is hardcoded in Drupal core web/core/modules/system/src/Controller/EntityAutocompleteController.php:

  public function handleAutocomplete(Request $request, $target_type, $selection_handler, $selection_settings_key) {
    $matches = [];
    // Get the typed string from the URL, if it exists.
    if ($input = $request->query->get('q')) {

Quick easy hack is enable calling "getMatches" for empty q get argument via changing to this:

  public function handleAutocomplete(Request $request, $target_type, $selection_handler, $selection_settings_key) {
    $matches = [];
    // Get the typed string from the URL, if it exists.
    if ($input = $request->query->get('q', '_EMPTY_')) {
      if($input == '_EMPTY_') $input = '';

Other solutions maybe use some keyword (eg q=_ALL_) for show all results, use additional argument (?q=&show-empty=1).

On field widget settings side will be good to add separate checkbox "Allow autocomplete for empty string", or maybe combine with "Minimum string length for autocomplete = 0", and separate setting for form fields with entity_autocomplete type.

What do you think about this idea?

Problem/Motivation

While implementing the new design system, the team raised some interest in using some of the new CSS features (mainly CSS custom properties or CSS variables). Being able to leverage these new features would lead to less overhead in the maintenance.

For example, CSS custom properties are currently supported by latest browser versions, while some older browsers are lacking support (browser support matrix). However, with the usage of CSS preprocessor, we could already reliably use CSS custom properties.

Proposed resolution

Use PostCSS to compile a version of our CSS that is supported by the browsers Drupal currently support. PostCSS is used by industry leaders including Wikipedia, Twitter, Alibaba, and JetBrains. PostCSS has over 20 000 stars in Github and is being used by almost 2 million projects according to Github.

Plugins we are currently using:

• Autoprefixer is a plugin to parse CSS and add vendor prefixes to CSS rules using values from Can I Use. It is recommended by Google and used in Twitter and Alibaba.
• PostCSS Calc reduces calc() references whenever it's possible. This can be particularly useful with the PostCSS Custom Properties plugin.
• PostCSS Custom Properties lets us use Custom Properties in CSS, following the CSS Custom Properties specification.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

Migrate the revisions for d7 entity translation to d8. This is moved out of #2746541: Migrate D6 and D7 node revision translations to D8, which is now only about node translation, to reduce complexity.

Proposed resolution

TBD

Remaining tasks

Add revisions to the existing entity translation content type, test_content_type.

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

The render system has \Drupal\Core\Render\RenderCache(Interface). This is capable of doing cache redirects, based on bubbled cache contexts. I.e. compare the originally known cache contexts with those that the final-to-be-cached data depends upon, and if that set is different, cache it as a cache redirect. (See RenderCache's docs for details.)

This is useful outside of the render system too.

Proposed resolution

Abstract RenderCache into a service (name TBD, initial quick thought: RedirectingCache) that RenderCache can use, so that RenderCache is just one of many things able to use this generic concept.

Remaining tasks

TBD

User interface changes

None.

API changes

None, pure API addition.

Data model changes

None.

After update jsonapi:1.x to jsonapi2.x
We got error when execute drush cr:

PHP Fatal error:  Uncaught TypeError: Argument 2 passed to Drupal\jsonapi\Routing\Routes::Drupal\jsonapi\Routing\{closure}() must be an instance of Drupal\jsonapi\ResourceType\ResourceType, null given in /app/www/de/modules/contrib/jsonapi/src/Routing/Routes.php:330
Stack trace:
#0 [internal function]: Drupal\jsonapi\Routing\Routes::Drupal\jsonapi\Routing\{closure}(false, NULL)
#1 /app/www/de/modules/contrib/jsonapi/src/Routing/Routes.php(332): array_reduce(Array, Object(Closure), false)
#2 /app/www/de/modules/contrib/jsonapi/src/Routing/Routes.php(251): Drupal\jsonapi\Routing\Routes::hasNonInternalTargetResourceTypes(Array)
#3 /app/www/de/modules/contrib/jsonapi/src/Routing/Routes.php(165): Drupal\jsonapi\Routing\Routes::getIndividualRoutesForResourceType(Object(Drupal\jsonapi\ResourceType\ResourceType))
#4 /app/www/de/modules/contrib/jsonapi/src/Routing/Routes.php(104): Drupal\jsonapi\Routing\Routes::getRoutesForResourceType(Object(Drupal\jsonapi\ResourceType\ResourceType), '/jsonapi')
#5 [internal function]: Drupal\jsonapi\ in /app/www/de/modules/contrib/jsonapi/src/Routing/Routes.php on line 330

Fatal error: Uncaught TypeError: Argument 2 passed to Drupal\jsonapi\Routing\Routes::Drupal\jsonapi\Routing\{closure}() must be an instance of Drupal\jsonapi\ResourceType\ResourceType, null given in /app/www/de/modules/contrib/jsonapi/src/Routing/Routes.php:330
Stack trace:
#0 [internal function]: Drupal\jsonapi\Routing\Routes::Drupal\jsonapi\Routing\{closure}(false, NULL)
#1 /app/www/de/modules/contrib/jsonapi/src/Routing/Routes.php(332): array_reduce(Array, Object(Closure), false)
#2 /app/www/de/modules/contrib/jsonapi/src/Routing/Routes.php(251): Drupal\jsonapi\Routing\Routes::hasNonInternalTargetResourceTypes(Array)
#3 /app/www/de/modules/contrib/jsonapi/src/Routing/Routes.php(165): Drupal\jsonapi\Routing\Routes::getIndividualRoutesForResourceType(Object(Drupal\jsonapi\ResourceType\ResourceType))
#4 /app/www/de/modules/contrib/jsonapi/src/Routing/Routes.php(104): Drupal\jsonapi\Routing\Routes::getRoutesForResourceType(Object(Drupal\jsonapi\ResourceType\ResourceType), '/jsonapi')
#5 [internal function]: Drupal\jsonapi\ in /app/www/de/modules/contrib/jsonapi/src/Routing/Routes.php on line 330
 [error]  Drush command terminated abnormally due to an unrecoverable error.
Error: Uncaught TypeError: Argument 2 passed to Drupal\jsonapi\Routing\Routes::Drupal\jsonapi\Routing\{closure}() must be an instance of Drupal\jsonapi\ResourceType\ResourceType, null given in /app/www/de/modules/contrib/jsonapi/src/Routing/Routes.php:330
Stack trace:
#0 [internal function]: Drupal\jsonapi\Routing\Routes::Drupal\jsonapi\Routing\{closure}(false, NULL)
#1 /app/www/de/modules/contrib/jsonapi/src/Routing/Routes.php(332): array_reduce(Array, Object(Closure), false)
#2 /app/www/de/modules/contrib/jsonapi/src/Routing/Routes.php(251): Drupal\jsonapi\Routing\Routes::hasNonInternalTargetResourceTypes(Array)
#3 /app/www/de/modules/contrib/jsonapi/src/Routing/Routes.php(165): Drupal\jsonapi\Routing\Routes::getIndividualRoutesForResourceType(Object(Drupal\jsonapi\ResourceType\ResourceType))
#4 /app/www/de/modules/contrib/jsonapi/src/Routing/Routes.php(104): Drupal\jsonapi\Routing\Routes::getRoutesForResourceType(Object(Drupal\jsonapi\ResourceType\ResourceType), '/jsonapi')
#5 [internal function]: Drupal\jsonapi\ in /app/www/de/modules/contrib/jsonapi/src/Routing/Routes.php, line 330

I haven't reproduced it in a fresh install drupal. Trying...

Problem/Motivation

#3041924: [META] Convert hook_help() module overview text to topics for the search module.

Proposed resolution

Take the information that is currently in the hook_help module overview section for the module(s), and make sure the information is in one or more Twig help topic files. Steps:

1. Find the hook_help() implementation function in the core/modules/MODULENAME/MODULENAME.module file(s). For example, for the core Contact module, the module files is core/modules/contact/contact.module, and the function is called contact_help().
2. Locate the module overview portion of this function. This is located just after some lines that look something like this:
   

     switch ($route_name) {
       case 'help.page.contact':
   

   And ends either at the end of the function, or where you find another case 'something': line.

3. We want to end up with one or more topics about the tasks that you can do with this module, and possibly a section header topic. So, read the help and figure out a good way to logically divide it up into tasks and sections. See Standards for Help Topics for information on how to do this.
4. See if some of these tasks are already documented in existing topics. Existing topics could be in one of the following directories:
   

   core/modules/help_topics/help_topics
   core/modules/MODULENAME/help_topics
   core/help_topics
   

   Note that to see existing topics, you will need to enable the experimental Help Topics module (available in the latest dev versions of Drupal 8.x).

5. For each task or section topic that needs to be written, make a new Twig topic file (see Standards for Help Topics) in one of the modules' help_topics directory (you will probably need to create that directory). Alternatively, if the information spans several modules or if the information should be visible before the module is installed, you can put it in core/help_topics. For instance, it might be useful to know that to get a certain functionality, you need to turn on a certain module (so that would be in Core), but then the details of how to use it should only be visible once that module is turned on (so that would be in the module).
6. File names must be MODULENAME.TOPICNAME.html.twig -- for example, in the Action module, you could create a topic about managing actions with filename action.managing.html.twig .
7. Make a patch file that adds/updates the Twig templates in Core. The patch should not remove the text from the hook_help() implementation (that will be done separately).

Remaining tasks

a) Make a patch (see Proposed Resolution section).

b) Review the patch:

1. Apply the patch.
2. Turn on the experimental Help Topics module in your site, as well as the module(s) listed in this issue.
3. Visit the page for each topic that is created or modified in this patch. The topics are files in the patch ending in .html.twig. If you find a file, such as core/modules/action/help_topics/action.configuring.html.twig, you can view the topic at the URL admin/help/topic/action.configuring within your site.
4. Review the topic text that you can see on the page, making sure of the following aspects:
   • The text is written in clear, simple, straightforward language
   • No grammar/punctuation errors
   • Valid HTML -- you can use http://validator.w3.org/ to check
   • Links within the text work
   • Instructions for tasks work
   • Adheres to Standards for Help Topics [for some aspects, you will need to look at the Twig file rather than the topic page].
5. Read the old "module overview" topic(s) for the module(s), at admin/help/MODULENAME. Verify that all the tasks described in these overview pages are covered in the topics you reviewed.

User interface changes

Help topics will be added to cover tasks currently covered in modules' hook_help() implementations.

API changes

None.

Data model changes

None.

Release notes snippet

None.

Follow-up to #2225775: Migrate Drupal 6 core node translation to Drupal 8

Problem/Motivation

In D8, a node revision has data for all languages. In D6 and D7, each node revision has data for just one language. This means currently D6 -> D8 and D7 -> D8 migrations yield a revision history where each node revision has only one language present, even if previous revisions had translations. This is strange and likely to confuse users.

Priority is given to the D7 migration because the D6 one might be effected by the term node migrations.

This is for migrating core translation revisions, migrating revisions for entity translation is now being done in #3076447: Migrate D7 entity translation revision translations to D8. It is intended that this issue is completed first and then the approach used here is also used for entity translations.

Proposed resolution

The current focus is to get the D7 version working and then move those changes to D6.

Using the existing method where the final revision is migrated first doesn't work instead the revisions need to be migrated in order. The first proof of concept patch to show this is in #121, thanks to mikelutz. The current working name of the migration is dN_node_master.

However, this new approach doesn't integrate with the current migrations, that is the one either runs the existing node migrations or the new master one, not both. This will also be a problem for the drush migrate-upgrade --all command which runs all migrations. Also, we need to make sure that non-translatable and non-revisionable nodes are migrated correctly.

From the original IS
D6 and D7 node revisions do not directly indicate which other translated node revisions they are associated with. But we can attempt to guess this, based on the order of revisions.

Remaining tasks

From #55

1. Make this work with a multilingual source and a non multilingual source
2. Discuss and document implications for drush, especially drush migrate-upgrade --all
3. Make sure the d6 and d7 tests includes testing a fields on each revision
4. Handle the case where the vid of the first revision is higher the vid of a later revision. This is true for both d6 and d7.
5. Make sure that the use of migration_tag 'translation' is documented. It is used in
   • d6_node_translation.yml
   • d7_node_entity_translation.yml
   • d7_node_translation.yml
   • d7_node_revision_translation.yml
   • d7_user_entity_translation.yml
   • d7_taxonomy_term_entity_translation.yml/li>
   • d7_comment_entity_translation.yml
   • d6_node_revision_translation.yml
6. Make sure that the source plugin 'translation' property is documented
7. Make sure that the destination plugin 'translations' property is documented

Problem/Motivation

Recently @catch, @webchick, @xjm, @cottser, @cilefen and I discussed #2801777: Give users the option to prevent drupal from automatically marking unused files as temporary , #2810355: $entity->isDefaultTranslation() behaves incorrectly when changing default translation, causing file/image field usage to be set to zero, causing files to be deleted and #2708411: [PP-1] editor.module's editor_file_reference filter not tracking file usage correctly for translations. We all agreed that the current file usage behaviour that is resulting in files being deleted when they are being used by a site is unacceptable and a critical issue.

This was also discussed at Drupal Dev Days Seville — see the meeting notes.

This issue is exist to propose a series of steps to mitigate and fix these related issues.

The current behaviour

As files are "used" in different situations we add to the counter in the file_usage table. As the usages are removed we subtract from the counter. Once the counter gets to 0 the file is made temporary in \Drupal\file\FileUsage\FileUsageBase::delete(). Then a cron process (file_cron()) comes along and deletes temporary files after system.file:temporary_maximum_age seconds.

There are several cases where that counter is not incremented or decremented correctly.

Regardless of all the sub-issues we have the known issue that this does not track usages added by content editors if they are able to add links to file but editing the source HTML. Also the system of maintaining a counter seems very fragile and evidence supports that :).

Which cases/issues are there?

These fall into clear buckets, along three axes:

1. Field (image/file/entity reference) versus editor.module's editor_file_reference filter
2. Entity revisions versus entity translations
3. Data loss: yes or no

Proposed resolution

TBD

Remaining tasks

TBD

User interface changes

TBD

API changes

TBD

Data model changes

TBD

Problem/Motivation

#3041924: [META] Convert hook_help() module overview text to topics for the contact module(s).

Proposed resolution

Take the information that is currently in the hook_help module overview section for the module(s), and make sure the information is in one or more Twig help topic files. Steps:

1. Find the hook_help() implementation function in the core/modules/MODULENAME/MODULENAME.module file(s). For example, for the core Contact module, the module files is core/modules/contact/contact.module, and the function is called contact_help().
2. Locate the module overview portion of this function. This is located just after some lines that look something like this:
   

     switch ($route_name) {
       case 'help.page.contact':
   

   And ends either at the end of the function, or where you find another case 'something': line.

3. We want to end up with one or more topics about the tasks that you can do with this module, and possibly a section header topic. So, read the help and figure out a good way to logically divide it up into tasks and sections. See Standards for Help Topics for information on how to do this.
4. See if some of these tasks are already documented in existing topics. Existing topics could be in one of the following directories:
   

   core/modules/help_topics/help_topics
   core/modules/MODULENAME/help_topics
   core/help_topics
   

   Note that to see existing topics, you will need to enable the experimental Help Topics module (available in the latest dev versions of Drupal 8.x).

5. For each task or section topic that needs to be written, make a new Twig topic file (see Standards for Help Topics) in one of the modules' help_topics directory (you will probably need to create that directory). Alternatively, if the information spans several modules or if the information should be visible before the module is installed, you can put it in core/help_topics. For instance, it might be useful to know that to get a certain functionality, you need to turn on a certain module (so that would be in Core), but then the details of how to use it should only be visible once that module is turned on (so that would be in the module).
6. File names must be MODULENAME.TOPICNAME.html.twig -- for example, in the Action module, you could create a topic about managing actions with filename action.managing.html.twig .
7. Make a patch file that adds/updates the Twig templates in Core. The patch should not remove the text from the hook_help() implementation (that will be done separately).

Remaining tasks

a) Make a patch (see Proposed Resolution section).

b) Review the patch:

1. Apply the patch.
2. Turn on the experimental Help Topics module in your site, as well as the module(s) listed in this issue.
3. Visit the page for each topic that is created or modified in this patch. The topics are files in the patch ending in .html.twig. If you find a file, such as core/modules/action/help_topics/action.configuring.html.twig, you can view the topic at the URL admin/help/topic/action.configuring within your site.
4. Review the topic text that you can see on the page, making sure of the following aspects:
   • The text is written in clear, simple, straightforward language
   • No grammar/punctuation errors
   • Valid HTML -- you can use http://validator.w3.org/ to check
   • Links within the text work
   • Instructions for tasks work
   • Adheres to Standards for Help Topics [for some aspects, you will need to look at the Twig file rather than the topic page].
5. Read the old "module overview" topic(s) for the module(s), at admin/help/MODULENAME. Verify that all the tasks described in these overview pages are covered in the topics you reviewed.

User interface changes

Help topics will be added to cover tasks currently covered in modules' hook_help() implementations.

API changes

None.

Data model changes

None.

Release notes snippet

None.

Problem/Motivation

#2381277: Make Views use render caching and remove Views' own "output caching" replaces output caching with render caching.
Render caching though is disabled on POST requests, so that ajax requests aren't cacheable.

We need to get #956186: Allow AJAX to use GET requests in, to be able to get render caching done.

Proposed resolution

- Add setting for query type to views pagers
- Make views pager respect that setting so that it uses the correct protocol
- Get render caching to work on views AJAX paging responses

Remaining tasks

- Fix broken tests on 8.3 re-roll.
- Get #956186: Allow AJAX to use GET requests committed
- Verify that we have enough test coverage on this issue
- QA testing to get to RBTC

User interface changes

I added a "pager query type" selector to sql-base pagers which becomes active if you set the view to use AJAX.

API changes

- Added a "getParam" method to ViewAjaxController to make it easier to get parameters off of a request.

How to test

- Install a new site
- Apply most recent patch from this issue (currently: https://www.drupal.org/files/issues/2500313--views-get-paging-support-83...)
- Apply https://www.drupal.org/files/issues/ajax-956186-65_2x_1.patch from #956186: Allow AJAX to use GET requests
- Create at least five articles
- Create two views as follows

View 1
- Add a block display
- Call it "GET pager view"
- List all nodes
- Turn on AJAX for the view
- Use a pager (try them all if you can); 2 per page, set query type to GET

View 2
Same as View 1, except:
- Call it "POST pager view"
- Set query type on the pager settings to POST

Now:
- Place both blocks somewhere on the page
- Start using the pager, and use the network tab (helpful to filter by XHR) to ensure that the views are using the correct protocol for their requests.

Some other things to try:
- Using a table display, ensure that column sorting is respected after paging back and forth.
- Add an exposed filter and make sure paging works after the setting the filter value.
- Test the render caching somehow. Make sure page cache is turned on, and put a breakpoint or something inside a function that runs when rendering a row. The breakpoint should hit a) when the cache is first populated and b) if something invalidates the cache (i.e. that node is updated).

Problem/Motivation

This is a bug fix for [##2994702]

Using EditorMediaDialog to change alignment can leads to double alignment classes on the wrapper. This is due to the fact that the alignment classes are not cleared when the dialog is saved.

Proposed resolution

Since there are three classes, we need to maintain, we can just clear the classes before adding a new class.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

I am trying to add a relationship "file usage" to a view. I click the submit button, but the relationship never gets added and UI never closed. I can add other relationships as expected.

To replicate (with "standard" profile):

1. Create a new view listing node content (no displays need to be added).
2. Don't touch the base view config in any way (the default "title" field will be the only field, etc.)
3. Add a File Usage "File" relationship via the UI

After these steps the relationship config dialog reports "The handler for this item is broken or missing" and no config form is displayed. The relationship can then be saved on the view (without configuration) but cannot be used.

Immediately upon adding the relationship an error similar to the following is printed in the views UI:

SQLSTATE[42S22]: Column not found: 1054 Unknown column 'fid' in 'field list': SELECT node_field_data.created AS node_field_data_created, node_field_data.nid AS nid, fid AS fid FROM {node_field_data} node_field_data WHERE (( (node_field_data.status = :db_condition_placeholder_0) )) ORDER BY node_field_data_created DESC LIMIT 10 OFFSET 0; Array ( [:db_condition_placeholder_0] => 1 )

And a barrage of notices are logged, containing and/or repeating:

Notice: Undefined index: id in Drupal\views\Plugin\ViewsHandlerManager->getHandler() (line 109 of /var/www/drupal-8/core/modules/views/src/Plugin/ViewsHandlerManager.php).
Notice: Undefined variable: items in Drupal\views\Plugin\views\relationship\Broken->buildOptionsForm() (line 79 of /var/www/drupal-8/core/modules/views/src/Plugin/views/BrokenHandlerTrait.php).
Notice: Undefined index: original_configuration in Drupal\views\Plugin\views\relationship\Broken->buildOptionsForm() (line 61 of /var/www/drupal-8/core/modules/views/src/Plugin/views/BrokenHandlerTrait.php).

Problem/Motivation

The Authoring information tab let's people edit the author, date and time a node was originally created.

The date field has placeholder input expecting DD-MM-YYYY

But!

The tooltip says "Date (e.g. 2017-02-11)"
The description says Format: "2017-02-11 01:31:30"

This is inconsistent and confusing. We can't change the datetime format for authored on field because the values going into and coming out of are RFC 3339 / ISO 8601 ( See: https://www.w3.org/TR/html-markup/input.date.html )

Current browsers also seem to be implementing HTML5 date fields in their own special ways. According to Ian Devlin on HTML5Doctor

"The implementation of this datepicker is up to the browser vendor, as the HTML5 specification does not tell vendors how to implement the input’s UI."

"As a user, I expect the help text to guide me to provide the correct date format, so that I can get it right the first time, without guessing."

Can we find a way to make this consistent? We already seem to be automatically inserting today's date here.

Proposed resolution

The descriptive help text and tool tip for this field needs to accommodate different date conventions. It needs to match the input range expected here.

#5 Suggestion: Hide the help text when on a supported browser (we have Modernizr in core, but don't add the body classes for a CSS-only solution) or when using the polyfills.

Remaining tasks

• Unify patches
• UX review
• a11y review
• code review

User interface changes

Removes misleading help text for browsers that support the HTML5 date/time widget

Original summary

'Authored on' field on add/edit form has 'mm/dd/yyyy' date format and 'am/pm' time format.
Field description says 'Format: 2016-08-29 14:18:25. Leave blank to use the time of form submission.'

Datetime Timestamp widget does not have any settings,
changing datetime format in Regional settings does not help either.

Problem/Motivation

Some browsers don't support HTML5 time entry. A polyfill should be provided to improve UX.

Proposed resolution

Use http://jonthornton.github.io/jquery-timepicker/ as a polyfill.

Remaining tasks

None.

User interface changes

Users with browsers that don't support HTML5 time entry get a shiny time picker.

API changes

None.

Data model changes

None.

Problem/Motivation

When drupal-media is embedded with data-caption="", opening the dialog and changing the alignment causes the edit button to disappear.

<drupal-media data-align="right" data-caption="" data-entity-type="media" data-entity-uuid="5cc07365-5fde-47a5-83b7-3302da0f0f2b" data-view-mode="wee"></drupal-media>

Video:
https://www.drupal.org/files/issues/2019-09-18/disappearing-edit-button.mov

The problem is that the code for the edit button blows up if the caption isn't properly initialized, due to this code:

          // Find the actual embedded media in the DOM.
          const embeddedMediaContainer = this.data.hasCaption
            ? this.element.findOne('figure')
            : this.element;

Proposed resolution

Assure that if this.data.hasCaption is true, that a figure actually exists.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

Per #1314214: MySQL driver does not support full UTF-8 (emojis, asian symbols, mathematical symbols) there is currently no uniqueness constraint on the uri field in the file_managed table enforced in the db schema in D8, because of limitations on lengths of keys under utf8mb4 with lowest-common-denominator MySQL configs. Instead we rely on a Drupal/application-level constraint in \Drupal\file\Plugin\Validation\Constraint\FileUriUnique.

However, this constraint is not currently enforced in file_save_upload(), as the validate() method is never explicitly called on the $file object.

Coupled with the way new filenames are chosen in file_destination() and file_create_filename() (based on checking file_exists() on a candidate name) this can lead to a race condition whereby more than one entry can be created in the file_managed table with the same value for the uri field.

When this happens, there is a risk of data loss. For example, if garbage collection deletes temporary files which have the same uri as other (permanent) files.

Slow implementations of hook_file_validate() (e.g. in the ClamAV module) can exacerbate the race condition, by increasing the likelihood that multiple parallel(ish) processes select the same filename before anything is written to disk.

Proposed resolution

Enforce the unique constraint on files'uri to avoid multiple rows with the same value in the file_managed table.

Remaining tasks

• Review the patch.
• Commit the patch.

User interface changes

There may be a new error message presented to users if they try to upload a file and the race condition occurs. However, it actually seems that changes since the initial report of this bug make it less likely that this will happen in the UI (see #52 for example).

API changes

None.

Data model changes

None.

Release notes snippet

Use "Problem/Motivation" section above?

Original report by manarth

First discovered in the ClamAV module: #2864506: Long ajax process causing files to disappear.

A slow implementation of hook_file_validate() can cause inappropriate entries in the file_managed table, causing an in-use file to be treated as orphaned, and therefore deleted on a cron-run. This causes permanent loss of data.

More significantly, the upload appears to succeed and the data is available for a period of time, whilst the data-loss happens on cron, between 6 hours and 3 months after the data was uploaded. This can make the cause of the issue harder to recognise, and reduce the likelihood that the original file is still available for recovery.

Steps to reproduce:

Not possible to manually reproduce since 8.6.x (see #52) - see the new test instead: SaveUploadTest.php::testDuplicate()

1. Prepare a Drupal install with a content-type that contains a file field.
2. Enable a module which has a slow implementation of hook_file_validate(); either use example code provided below, or install this sandbox (machine name: slow_file_upload)
3. Go to the node-add page for the relevant content-type
4. Click the "browse" button, and choose a file to upload
5. Click the form's "Save and publish" button quickly, before the AJAX upload + validate process has completed

The outcome is that two entries are added to the file_managed table, and one entry added to the file_usage table. Here is an example:

mysql> select * from file_managed;
+-----+--------------------------------------+----------+------+----------+----------------------------+------------+----------+--------+------------+------------+
| fid | uuid                                 | langcode | uid  | filename | uri                        | filemime   | filesize | status | created    | changed    |
+-----+--------------------------------------+----------+------+----------+----------------------------+------------+----------+--------+------------+------------+
|   1 | 3bcdd711-988e-4906-b8c6-0b22df271b93 | en       |    1 | foo.txt  | public://2017-04/foo_0.txt | text/plain |        9 |      0 | 1492187343 | 1492187343 |
|   2 | 0a7a9874-7e73-43da-8eeb-a7caa03ae63d | en       |    1 | foo.txt  | public://2017-04/foo_0.txt | text/plain |        9 |      1 | 1492187346 | 1492187346 |
+-----+--------------------------------------+----------+------+----------+----------------------------+------------+----------+--------+------------+------------+
2 rows in set (0.00 sec)


mysql> select * from file_usage;
+-----+--------+------+----+-------+
| fid | module | type | id | count |
+-----+--------+------+----+-------+
|   2 | file   | node | 1  |     1 |
+-----+--------+------+----+-------+
1 row in set (0.00 sec)

One entry is correctly recorded in the file_managed table, with a corresponding file_usage entry; the second is an orphaned file. However, both entries share the same uri. When the cron cleanup process deletes orphaned files, the valid, in-use file is deleted, causing permanent data loss.

The issue was originally reported in the context of the ClamAV module, however, I've been able to reproduce using nothing more than a sleep(10) command in a new debug module:

/**
 * Implements hook_file_validate().
 */
function mymodule_file_validate(Drupal\file\FileInterface $file) {
  $errors = [];

  if (!isset($_POST['op']) || ($_POST['op'] != 'Save')) {
    // Add a delay if we're not actually saving the node.
    sleep(30);
  }

  return $errors;
}

This particularly affects the ClamAV module, where certain virus-scan configurations can add 10 seconds to the file-validate process, but this issue could affect any scenario where validation invokes a slow external process.