My recent log have a lot of this error (every page not found create one error):

RuntimeException: Failed to start the session because headers have already been sent by "mysite.com/public_html/vendor/symfony/http-foundation/Response.php" at line 1276. in Symfony\Component\HttpFoundation\Session\Storage\NativeSessionStorage->start() (line 141 of mysite.com/public_html/vendor/symfony/http-foundation/Session/Storage/NativeSessionStorage.php) #0 mysite.com/public_html/core/lib/Drupal/Core/Session/SessionManager.php(164): Symfony\Component\HttpFoundation\Session\Storage\NativeSessionStorage->start() #1 mysite.com/public_html/core/lib/Drupal/Core/Session/SessionManager.php(195): Drupal\Core\Session\SessionManager->startNow() #2 mysite.com/public_html/vendor/symfony/http-foundation/Session/Session.php(193): Drupal\Core\Session\SessionManager->save() #3 mysite.com/public_html/core/lib/Drupal/Core/StackMiddleware/Session.php(60): Symfony\Component\HttpFoundation\Session\Session->save() #4 mysite.com/public_html/core/lib/Drupal/Core/StackMiddleware/KernelPreHandle.php(47): Drupal\Core\StackMiddleware\Session->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) #5 mysite.com/public_html/core/modules/page_cache/src/StackMiddleware/PageCache.php(184): Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) #6 mysite.com/public_html/core/modules/page_cache/src/StackMiddleware/PageCache.php(121): Drupal\page_cache\StackMiddleware\PageCache->fetch(Object(Symfony\Component\HttpFoundation\Request), 1, true) #7 mysite.com/public_html/core/modules/page_cache/src/StackMiddleware/PageCache.php(75): Drupal\page_cache\StackMiddleware\PageCache->lookup(Object(Symfony\Component\HttpFoundation\Request), 1, true) #8 mysite.com/public_html/core/modules/ban/src/BanMiddleware.php(50): Drupal\page_cache\StackMiddleware\PageCache->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) #9 mysite.com/public_html/core/lib/Drupal/Core/StackMiddleware/ReverseProxyMiddleware.php(47): Drupal\ban\BanMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) #10 mysite.com/public_html/core/lib/Drupal/Core/StackMiddleware/NegotiationMiddleware.php(50): Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) #11 mysite.com/public_html/vendor/stack/builder/src/Stack/StackedHttpKernel.php(23): Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) #12 mysite.com/public_html/core/lib/Drupal/Core/DrupalKernel.php(664): Stack\StackedHttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) #13 mysite.com/public_html/index.php(19): Drupal\Core\DrupalKernel->handle(Object(Symfony\Component\HttpFoundation\Request)) #14 {main}.

Site still running good but this error keep flood my log.

Steps to reproduce error

First create a View with an Entity Reference display.
Create a new Content type with an entity reference field and use the previously created View as the source for that field.
In the Form display set the reference field's widget to "Autocomplete (Tags style)" widget.
Save it.

Go to the Views page and click on the Add View button and after the page loads, you should see the error message.

Expected behavior

Work without an error message.

Possible solution

I've found out that the Drupal\node\Plugin\views\wizard\Node.php file collects the tag fields according to their field widget type.
So currently only the fields that use the "Autocomplete (Tags style)" are collected. The main problem is that it does not checks if there is any kind of target_bundles value for that field or not. For view reference fields it will be empty, but if you use the above stated widget, then it throws an error even if it shouldn't.

The solution would be to check if the target_bundles key exists or not. I've created a patch for it.

Problem/Motivation

Drupal may be configured to allow untrusted users to upload files with arbitrary filenames, including filenames with path components. For instance, if Drupal is installed at /var/www/ and the uploaded file repository is at /var/www/sites/example.com/files/, then an uploaded filename of '../../../index.php' would point to the /var/www/index.php file.

To prevent untrusted users from overwriting such critical files, the current logic for the DrupalLocalStreamWrapper::getLocalPath() function works like this:

1. Set $directory to the realpath() of the files repository.

2. Set $path to the target file location.

3. Set $realpath to realpath($path).

4. Return FALSE if $realpath does not begin with $directory.

This causes a problem when the site builder wants to store some uploaded files outside of the Drupal web root. Many site owners have resorted to hard-linked directories, recursive bind mounts, or simply hacking Drupal core to remove the restriction.

Proposed resolution

The logic within the DrupalLocalStreamWrapper::getLocalPath() function should be revised as follows:

1. Set $directory to the realpath() of the files repository.

2. Set $path to the target file location.

3. Set $realpath to realpath($path).

4. Return FALSE if both of the following are true:

   • $path contains '/..' or '\..'.
   • $realpath does not begin with $directory

.

Remaining tasks

The patch proposed in #65 needs to be reviewed by the security team.

User interface changes

None.

API changes

The DrupalLocalStreamWrapper::getLocalPath() function would follow symlinks, even if they point outside the files repository.

Original report by tekante

Related issue: #155781: "realpath" check breaks symbolic links in file directory

The method by which directory ascension attacks are prevented in stream_wrappers.inc prevents file system layouts which rely on symlinks within the files directory. Specifically, the use of realpath within the getLocalPath results in the check of whether the destination directory exists within the files directory to fail.

I will attach a patch which allows for the destination directory to exist outside of the configured files directory when it appears this is due to the presence of a symlink and not due to directory ascension characters.

Problem/Motivation

\Drupal\jsonapi\ResourceType\ResourceTypeRepository::getRelatableResourceTypesFromFieldDefinition() directly reads the setting target_type from the field definition, however not all reference fields have this setting. A concrete example is the dynamic_entity_reference module, which allows for referencing multiple entity types and it lacks the setting target_type. See https://git.drupalcode.org/project/dynamic_entity_reference/blob/8.x-2.x...

Proposed resolution

Option 1:
Add a new method getReferenceableEntityTypes() on the interface \Drupal\Core\Field\EntityReferenceFieldItemListInterface(), which could be overwritten by \Drupal\dynamic_entity_reference\Plugin\Field\FieldType\DynamicEntityReferenceFieldItemList().

jsonapi could then call the new method instead of assuming the setting target_type always exists when there is a property of the type \Drupal\Core\TypedData\DataReferenceTargetDefinition.

Option 2:
A more scalable and independent option might be an approach of adding the referenceable entity types configuration to the DataReferenceTargetDefinition property. DynamicEntityReferenceItem defines two such properties and would have to do it for both, but this should not be a problem or maybe only one of them could list the referenceable entity types configuration.

jsonapi could then retrieve the referenceable entity types configuration directly from the DataReferenceTargetDefinition properties instead of assuming there is a field definition setting target_type.

------

Option 1 does not work because the item list might be used by multiple item implementations.
Option 2 does not work because the properties are retrieved based on the field storage definition and not on the field definition for bundle fields.

This led to Option 3:
The item class defines a method named getReferenceableEntityTypes(FieldDefinitionInterface $definition), which is then used to retrieve the entity types and bundles being referenced by that particular item class in a single API.

Ideally we would define an interface for this method, however EntityReferenceItem does not implement any specific/suitable interfaces. I think that adding a new interface to this class should not be a problem, because we will be providing a direct implementation of the method in the class and no problems could arise in classes extending from it.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

According to this issue with the new Admin UI Design Claro, we're willing to fix the views names sizing on the views listing. Out of the linked issue:

I came across /admin/structure/views and saw that the view names in that list are visually way too big in my opinion (they are even bigger than the list headline 'view name' row headline). It's a h3 causing that issue. See screenshot attached.

I would suggest that it should look like the block region name here /admin/structure/block

A part of moving legacy code out of file.inc, we should move file_scan_directory() to the file_system service.

Hi, When I try to update Drupal 8.7.0 db br drush updb I get the following error.

>  [notice] Update started: taxonomy_post_update_make_taxonomy_term_revisionable
>  [error]  Drupal\Core\Database\IntegrityConstraintViolationException: SQLSTATE[23000]: Integrity constraint violation: 1048 Column 'name' cannot be null: INSERT INTO {tmp_d305d9taxonomy_term_field_data} (tid, revision_id, vid, langcode, name, description__value, description__format, weight, changed, default_langcode, status, revision_translation_affected) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2, :db_insert_placeholder_3, :db_insert_placeholder_4, :db_insert_placeholder_5, :db_insert_placeholder_6, :db_insert_placeholder_7, :db_insert_placeholder_8, :db_insert_placeholder_9, :db_insert_placeholder_10, :db_insert_placeholder_11); Array
> (
>     [:db_insert_placeholder_0] => 1
>     [:db_insert_placeholder_1] => 1
>     [:db_insert_placeholder_2] => tags
>     [:db_insert_placeholder_3] => tr
>     [:db_insert_placeholder_4] =>
>     [:db_insert_placeholder_5] =>
>     [:db_insert_placeholder_6] =>
>     [:db_insert_placeholder_7] =>
>     [:db_insert_placeholder_8] =>
>     [:db_insert_placeholder_9] =>
>     [:db_insert_placeholder_10] =>
>     [:db_insert_placeholder_11] => 1
> )
>  in Drupal\Core\Database\Connection->handleQueryException() (line 689 of /var/www/drupal8/web/core/lib/Drupal/Core/Database/Connection.php).
>  [error]  The entity update process failed while processing the entity type taxonomy_term, ID: 1.
>  [error]  Update failed: taxonomy_post_update_make_taxonomy_term_revisionable
 [error]  Update aborted by: taxonomy_post_update_make_taxonomy_term_revisionable
 [error]  Finished performing updates.

Problem/Motivation

Constructor has @deprecated tag and shouldn't.

it should trigger an error if the parameter is missing.

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

The following error persists on various pages on my site despite the fact i have completely uninstalled and removed the offending module from the system. How/why is drupal still looking for a module that just isn't even installed? The error (and errors like this) aren't helpful on the admin interface. I'm sure there are no other modules using it.

User warning: The following module is missing from the file system: bricks_default_eck in drupal_get_filename() (line 256 of core/includes/bootstrap.inc).
drupal_get_filename('module', 'bricks_default_eck') (Line: 275)
drupal_get_path('module', 'bricks_default_eck') (Line: 132)
module_load_include('install', 'bricks_default_eck') (Line: 91)
module_load_install('bricks_default_eck') (Line: 85)
drupal_load_updates() (Line: 109)
Drupal\system\SystemManager->listRequirements() (Line: 49)
Drupal\system\Controller\SystemInfoController->status()
call_user_func_array(Array, Array) (Line: 123)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 582)
Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object) (Line: 124)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext(Array, Array) (Line: 97)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 151)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 68)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1) (Line: 57)
Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1) (Line: 47)
Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object, 1, 1) (Line: 106)
Drupal\page_cache\StackMiddleware\PageCache->pass(Object, 1, 1) (Line: 85)
Drupal\page_cache\StackMiddleware\PageCache->handle(Object, 1, 1) (Line: 47)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1) (Line: 52)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1) (Line: 23)
Stack\StackedHttpKernel->handle(Object, 1, 1) (Line: 693)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)

This message (like many others in drupal) is not friendly to site builders. drupal needs another layer of reporting in instances like this.

thanks

Problem/Motivation

Quick edit gets stuck at saving the changes, as shown in the screenshot.

• The "saving" popup doesn't go away and can't be removed by clicking on "x" either.
• The place where the original content used to be is blanked.
• When page is reloaded all is OK and the content has been updated.

The issue appears to be somewhat random. I experienced it every time when I tried editing the media (picture), while text editing sometimes works and sometimes doesn't.

Problem/Motivation

file_directory_temp() is a procedural function in file.inc and contains some interesting logic. If there is no value set in config, it will call getOsTemporaryDirectory(), and if that isn't set, it will fall back to public://tmp/

It then sets this value in config.

Proposed resolution

Remove the need for the config system, and instead use Settings, just like the private file system path.

Provide BC for config set values, and use the fall backs as we currently do if not set in Settings. However, do not set config.

Remaining tasks

1. Implement it.
2. Find a way to trigger deprecations
3. Add a requirements check if it is not set in settings.
4. Make the file system temp dir settings form field read only, so users cannot update it (or just display it like private filesystem dir)

User interface changes

Users will no longer be able to set the temp directory from the file system settings form.

API changes

file_directory_temp() is deprecated.

Users are required to set a value for 'file_temp_path' in settings.php. E.g.:

$settings['file_temp_path'] = '/tmp';

Data model changes

Release notes snippet

The temporary file path is no longer stored in configuration, and is a setting in settings.php.

Follow up to #3034072: Move file uri/scheme functions from file.inc and FileSystem to StreamWrapperManager

Problem/Motivation

The merge plugin was added for 8.1.x, to allow us to have special treatment for the core/ folder when running tests / composer install ("core/ is here, don't download it, just download its dependencies").

There are a number of disadvantages to using this plugin, though:

• It has a performance penalty (the composer process is slower and downloads more metadata) and a complexity penalty.
• People who install Drupal from a tarball can't update core via Composer until they edit the composer.json, move drupal/core from "replace" to "require" and remove the merge configuration (#3020337: Composer returns "Your requirements could not be resolved to an installable set of packages" when core/composer.json is included in the merge plugin configuration).
• The merge plugin is seldom used and not well maintained

Proposed resolution

Remove the wikimedia merge plugin and replace it with a Composer 'path' repository, a native Composer feature which serves the same needs as the merge plugin with fewer disadvantages.

This issue does not aim go make tarball downloads of Drupal "Composer ready", but it unblocks the way for that to happen in follow-up work.

Remaining tasks

None.

Follow-on Tasks

This issue is a blocker for a number of follow on tasks in the Composer in Core Initiative:

• #3067645: Utilize scaffold plugin for drupal core
• #3057094: Add Composer vendor/ cleanup plugin to core
• #2982680: Add composer-ready project templates to Drupal core.

User interface changes

None.

API changes

None.

Data model changes

None.

Filesystem layout changes

The file system layout is exactly the same with and without this patch, with the only exception being that there is a new symbolic link created from /vendor/drupal/core to /core.

Release notes snippet

The wikimedia/composer-merge-plugin has been removed and replaced with a Composer path repository.

Problem/Motivation

It looks like someone removed the ability to attach inline JS. No idea why, but I need this and I cannot move this to a library file.

Issues:

• JS cannot attached with 'html_head' as the order is random.
• The order of code is broken as inline JS need to be added after JS files and not before.
• CDATA is not added automatically and could be theme specific
• Inline JS code cannot moved to files in many cases as these are dynamic and may not automatically drupalSettings.

LogicException: You are not allowed to use js in #attached in drupal_process_attached() (line 1759 of drupal8\core\includes\common.inc).

Example code. See http://cgit.drupalcode.org/google_analytics/tree/google_analytics.module... for more:

    if ($config->get('track.adsense')) {
      // Custom tracking. Prepend before all other JavaScript.
      // @TODO: https://support.google.com/adsense/answer/98142
      // sounds like it could be appended to $script.
      $page['#attached']['js'][] = array(
        'data' => $googleanalytics_adsense_script,
        'group' => JS_LIBRARY-1,
        'type' => 'inline',
      );
    }

    $page['#attached']['js'][] = array(
      'data' => $script,
      'scope' => 'header',
      'type' => 'inline',
    );

Additionally Wim pointed indirectly to #2368797: Optimize ajaxPageState to keep Drupal 8 sites fast on high-latency networks, prevent CSS/JS aggregation from taking down sites and use HTTP GET for AJAX requests. The presentation Optimizing the critical rendering path in this case shows that the objections about inline JS are fairly invalid and the document proves that inline CSS/JS assets are highly critical feature and placing all stuff in external files is simply incorrect for page load speed and mobile first, too.

Proposed resolution

Respect dependency and load order for inline JS and utilize the libraries api for inline js.

Remaining tasks

• Write tests
• Refactor patch from #173 to be used for JS and not CSS
• Document any api changes

API changes

Unknown

Problem/Motivation

In \Drupal\jsonapi\Context\FieldResolver::resolveInternalEntityQueryPath() there is the following code:

$is_data_reference_definition = $property_definition instanceof DataReferenceTargetDefinition;
if (!$property_definition->isInternal()) {
// Entity reference fields are special: their reference property
// (usually `target_id`) is never exposed in the JSON:API
// representation. Hence it must also not be exposed in 400
// responses' error messages.
$property_names[] = $is_data_reference_definition ? 'id' : $property_name;
}

which does not take into consideration more complex cases like dynamic_entity_reference and entity_reference_revisions, which define more than one property of the type DataReferenceTargetDefinition.

Currently it is impossible to use these other properties in a filter.

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

When I look at the php section at phpunit.xml.dist I see the following:

<!-- Set error reporting to E_ALL. -->
    <ini name="error_reporting" value="32767"/>
    <!-- Do not limit the amount of memory tests take to run. -->
    <ini name="memory_limit" value="-1"/>
    <!-- Example SIMPLETEST_BASE_URL value: http://localhost -->
    <env name="SIMPLETEST_BASE_URL" value=""/>
    <!-- Example SIMPLETEST_DB value: mysql://username:password@localhost/databasename#table_prefix -->
    <env name="SIMPLETEST_DB" value=""/>
    <!-- Example BROWSERTEST_OUTPUT_DIRECTORY value: /path/to/webroot/sites/simpletest/browser_output -->
    <env name="BROWSERTEST_OUTPUT_DIRECTORY" value=""/>
    <!-- To disable deprecation testing uncomment the next line. -->
    <env name="SYMFONY_DEPRECATIONS_HELPER" value="weak_vendors"/>
    <!-- Example for changing the driver class for mink tests MINK_DRIVER_CLASS value: 'Drupal\FunctionalJavascriptTests\DrupalSelenium2Driver' -->
    <!-- Example for changing the driver args to mink tests MINK_DRIVER_ARGS value: '["http://127.0.0.1:8510"]' -->
    <!-- Example for changing the driver args to phantomjs tests MINK_DRIVER_ARGS_PHANTOMJS value: '["http://127.0.0.1:8510"]' -->
    <!-- Example for changing the driver args to webdriver tests MINK_DRIVER_ARGS_WEBDRIVER value: '["firefox", null, "http://localhost:4444/wd/hub"]' -->
  </php>

The Mink variables aren't set to empty values like the other ones, which led me to think that they could not be set here. It was by debugging a JavaScript test that I saw that these are environment variables that I could adjust. After doing so I started seeing Chrome being opened when I ran tests.

The Drupal\Core\Template\Attribute class and its helper classes have no Drupal dependencies apart from Drupal Components. There already exists at least one project where Attribute classes are used independently of Drupal, and it would be good if they could be used as a proper Composer package.

An attempt to use reference method "Views: Filter by an entity reference view" fail to open Entity reference views pulldown list, and an attempt to save fail with fatal error:

Fatal error: Drupal\views\Plugin\EntityReferenceSelection\ViewsSelection has colliding constructor definitions coming from traits in /home/mysite/www/core/modules/views/src/Plugin/EntityReferenceSelection/ViewsSelection.php on line 225

I have tried both with Content reference field and with Taxonomy term reference field (I have created entity reference views in advance) and it seems that it is globally broken.

It seems that this functionality is broken somewhere between 8.4.0-alpha1 and 8.4.0-beta1 versions. 8.4.0-alpha1 works fine and all latter versions including current 8.4.x and 8.5.x branches are broken. Tested at simplytest.me, so if server configuration matters it depends on current simplytest.me server configuration.

All contributed modules which use this functionality are broken too. Changing priority to "critical" since it seems to be so.

I am probably not in the right area, and this is a really really minor complaint. Apologies.

I'm running 8.7.3 with the experimental Media Library module enabled.

It creates a "Media Library thumbnail (220x220)" image style. The typo is that in "(220x220)" it uses an x (lower-case letter X), it should use × (a multiplication sign aka × or ×) as per the default image styles (large, medium, thumbnail).

Thanks!

Problem/Motivation

The PrivateTempStore works nice and well for creating a store, adding items to that store and then deleting individual items from the store. However, it does not provide an API to retrieve all the items from the store or deleting them. Although they are temporary, there is still a valid use case in my opinion for the possibility to delete all the items stored in a given collection for the given user. For example, a multistep form which has fields prepopulated with values in the store. Submitting the last part of the form should clear the store and save the data somewhere else.

Proposed resolution

Add 2 new public methods to delete and retrieve all the items in the store.

Remaining tasks

Write patch and test.

User interface changes

None.

API changes

Ability to delete all items in the store or retrieving all of them.

Problem/Motivation

I am migrating a d6 or d7 to d8, I have a date field with granularity "Year, Month, Day" but these are migrated by default to datetime_type datetime type and not to date type. The complete date of the installation was transferred in the format YYYY-mm-mmTHH:ii:ss into the database. This leads to a non existence of the date! The date is not shown in the rendered representation and in the edit form you get an empty date field

See this code.

Proposed resolution

Add something similar how d7 to d8 is doing it.

Remaining tasks

Shortening the date field in the database to YYYY-mm-dd fixes this issue.

User interface changes

API changes

Data model changes