Hello,
After updating the core from 8.5.6 to 8.6.0, the custom block library appears empty. Custom block types still exist, but the custom block list is empty. Yet, they still exist in the database.

On the Block Layout page, custom blocks are listed in their place in the regions, but they do not appear with the message :

This block is defective or missing. The content is missing or you may need to activate the original module

.The TypedConfigManager.php file is identical to https://cgit.drupalcode.org/drupal/tree/core/lib/Drupal/Core/Config/Type... and I restarted the server without success.

The update operations for the blocks ran successfully :
block_content 8600 hook_update_n Add 'reusable' field to 'block_content' entities.
block_content add_views post-update Adds a 'reusable' filter to _reusable Custom Block views. _filter

The drush command php with

$ service=\Drupal :: service ('config.typed');
get_class ($ service);

return :

=> Drupal\Core\Config\TypedConfigManager {# 917
     + "_ serviceId": "config.typed",
   }

And after a press on entry :

=> "Drupal\Core\Config\TypedConfigManager"

Commenting out the line $context->setTypedDataManager($old_context->getTypedDataManager());in the core/lib/Drupal/Core/Plugin/Context/Context::createFromContext() file does not solve the problem.

Thank you for considering this case

Problem/Motivation

In Drupal Commerce, we created a field that storage a plugin's ID and configuration. The latter is saved as a serialized blob (https://github.com/drupalcommerce/commerce/blob/8.x-2.x/src/Plugin/Field...).

When the field is attached to an entity type and has a dedicated table the target_plugin_configuration property is unserialized just fine. However, if the field is attached as a base field item and part of the shared table, it does not.

You can see that \Drupal\Core\Entity\Sql\SqlContentEntityStorage::loadFromDedicatedTables takes into consideration column schema being marked as serialized. And then \Drupal\Core\Entity\Sql\SqlContentEntityStorage::loadFromSharedTables does not, at all.

Proposed resolution

Improve \Drupal\Core\Entity\Sql\SqlContentEntityStorage::loadFromSharedTables to handle serialized column data.

Remaining tasks

User interface changes

None.

API changes

None.

Data model changes

None.

Updated: Comment [#516]
Jump to page 2

Problem/Motivation

Install profiles are not inheritable, so if you want to, say, take Drupal Commons, and base your site off of it, but add one or two extra modules in your own customized install profile, you have to clone the entire install profile and change it to your needs. Allowing install profiles to declare base profiles (just like themes can declare base themes) would drastically simplify customizations to existing distributions by:

• Inheriting configuration from a parent install profile (base-profile)
• Overriding specific configuration from the base-profile
• Inheriting customizations in the installer from the base-profile
• Having additional installer tasks and form items to customize their own "start-state"

Additional motivations are detailed on Dries's blog post.

Proposed resolution

• Modify the module load system to take into account base install profiles.
• Modify the install profile system to run parent installer(s) in the correct order.
• One proposed solution was to simply use modules instead of profile inheritance. This was discussedatlength and the prevailing attitude was that the functionality for profile inheritance has valuable use cases that cannot be solved by modules alone.
• An early resolution was to include a tag to exclude dependencies and themes. In an effort to clearly define focus for this patch, this functionality was removed from this patch. The use case for excluded_dependencies and excluded_themes is still very much valid, so this feature request has been given its own issue.

Complications

Implementing this would expose or compound existing problems with the way distributions handle config. Specifically how distributions provide low level config bug fixes and new features to existing sites. #3004662: [META] Standardize the way distributions handle config updates was opened to see if we can get consensus around a solution.

Remaining tasks

• Create plan
• Write useful issue summary
• Fix issue from #405
• Fix issue from #412
• Fix issue from #476
• Update Change Record.
• Make tests pass.
• Extensively test this patch against a real-world base-profile
• Add to existing documentation page (To be published only after patch is applied.)
• Review Documentation to make sure they are up-to-date.

User interface changes

None.

API changes

Install profiles can define base profiles using the syntax base profile: BASE_PROFILE inside their .info.yml files.

Related Issues

• For D7 patch tracking: #2067229: Allow install profiles to declare base profiles for Drupal 7
• For D8 info inheritance patch tracking: #2692403: Make info and configuration inheritable in profiles
• For D8 excluded_dependencies and excluded_themes: #2914389: Allow profiles to exclude dependencies of their parent

Problem/Motivation

Drupal\Core\Composer\Composer::vendorTestCodeCleanup() needs to be able to run on the whole install and not just one package at a time. Refactoring that to allow for post-create-project hooks would be useful.

This is to support #2990257: Determine how to handle composer scripts in drupal/drupal and be able to perform the vendor test cleanup once the library which supports it is available, which in turn supports creating the drupal/drupal-project-legacy project template in #2982680: Add composer-ready project templates to Drupal core.

Regardless of how #2990257: Determine how to handle composer scripts in drupal/drupal is implemented, we will likely need to be able to clean up the vendor directory in one step at the end of the installation process, since the library will have become available and autoloadable by that point.

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Problem/Motivation

Follow-up from #2222719: Use parameter matching via reflection for access checks instead of pulling variables from request attributes.

Drupal\Core\Routing\Access\AccessInterface is empty. Access check methods can have different method parameters for different access checkers, so it is not possible to express that with an interface. Therefore the interface is pointless and should be deprecated.

Proposed resolution

• Deprecate AccessIntreface for removal before Drupal 9.0.0 release.
• Leave AccessInterface in core until shortly before Drupal 9, for BC.

Remaining tasks

• Update https://www.drupal.org/node/2122195
• Ensure change record leads developers to useful documentation: https://www.drupal.org/node/2731311
• Ensure that access logic in core does not check instanceof AccessInterface
• Remove usages of AccessInterface in core.

User interface changes

None.

API changes

We'd be marking part of an API as deprecated, but it's not tagged @api, and the plan is to leave the interface itself in core.

So while we're discouraging the use of an API, we're also not breaking or changing it.

Data model changes

None.

Problem/Motivation

This is a followup for changes introduced by #2957425: Allow the inline creation of non-reusable Custom Blocks in the layout builder.

The layout builder cron job removes unused inline blocks. It however errors when there are no inline blocks to be removed as it tries to run a query with an 'IN' condition passing it an empty array.

Drupal\Core\Database\InvalidQueryException: Query condition 'block_content_id IN ()' cannot be empty. in Drupal\Core\Database\Query\Condition->condition() (line 103 of /home/contacts/domains/devb.contacts.freelygive.org.uk/app/web/core/lib/Drupal/Core/Database/Query/Condition.php).

Proposed resolution

Check if the list of blocks to be removed is empty before running the query.

Remaining tasks

• Add empty check.

Hello,

I've been studied the media core module, and I have found that it is not possible to support multiple websites with the same provider at the same time. I think it is really annoying that it supports only the centralized approach because the internet is supposed to be decentralized.

The name of the provider is fixed by the service that you use. I will take the example of my usecase to be easier to understand. So my usecase is the PeerTube, a decentralized video platform.

So oEmbed imposes us the provider name as we can see in those examples:

For Youtube:
https://www.youtube.com/oembed?url=https://www.youtube.com/watch?v=xHLes...
provider_name = Youtube

For PeerTube:
https://framatube.org/services/oembed?url=https%3A%2F%2Fframatube.org%2F...
provider_name = PeerTube
https://peertube.cpy.re/services/oembed?url=https%3A%2F%2Fpeertube.cpy.r...
provider_name = PeerTube

Consequently we have something like that in the ressource fetcher yml file pointed by the oembed_providers_url variable from media.settings

[
  0	=> {
    provider_name:	"PeerTube",
    provider_url:	"https://framatube.org",
    endpoint: [
      0 => {	
        url	"https://framatube.org/services/oembed",
        discovery	true
      }
    ]
  },
  1	=> {
    provider_name:	"PeerTube",
    provider_url:	"https://peertube.cpy.re",
    endpoint: [
      0 => {	
        url	"https://peertube.cpy.re/services/oembed",
        discovery	true
      }
    ]
  }
]

After that we arrive to the part that the media core module fails totally.

In Drupal\media\OEmbed\ProviderRepository

$keyed_providers = [];
    foreach ($providers as $provider) {
      try {
        $name = (string) $provider['provider_name'];
        $keyed_providers[$name] = new Provider($provider['provider_name'], $provider['provider_url'], $provider['endpoints']);
      }
      catch (ProviderException $e) {
        // Just skip all the invalid providers.
        // @todo Log the exception message to help with debugging.
      }
    }

If we read that code, it will iterate on every provider and fill the $keyed_providers variable. But of course, it will erase the data from the other websites with the same provider. After that, the core media module will be ok but only for the last website you have declared with the common provider.

I will try to work on that but this will probably be a big change on how the media module uses oEmbed.

For those who want to work on that, the core doesn't allow to override the oembed_providers_url setting yet. So set it manually or there is already an issue on drupal.org: #2999018 Expose oEmbed provider URL setting in the Media configuration form

I have a working module that supports only one website of Peertube because of this issue. If you want to debug this issue, it will give you a usecase to debug: PeerTube

Thank you to those who will help me to resolve this issue.

Problem

RSS view with fields instead of content rendering in RSS view mode results in wrong URLs from path field (with pathauto enabled).

Instead of correct URL with http://mysite.domain/content/my-node-title we got http://mysite.domain/my-node-title.

Reproduced on multiple sites with current d.o D8 pathauto module.

1. Edit 'Frontpage' view
2. Select 'Feed' display
3. Switch display mode from content to fields
4. Add title, path, author, created field
5. Configure fields in display mode settings. Link & GUID with permaLink = Path field
6. Check URLs in preview output

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Problem/Motivation

Images uploaded to an image field are lost when the node language is changed (because file usage incorrectly drops down to zero, causing the permanent file to be marked temporary, and then eventually being deleted — after 6 hours by default).

Same for files uploaded to a file field.

Steps to reproduce

1. create a content type with an image field
2. enable >=2 languages in site
3. set the content translatable (tested setting the file translatable or not)
4. create a node with an image and save it
5. verify that the uploaded file has its status column in the file_managed table set to 1,
   and it has 1 usage in the file_usage table
6. edit the node and change the language
7. • expected result: the uploaded file still has its status column in the file_managed table set to 1, and it has 1 usage in the file_usage table
   • actual result: the uploaded file now has its status column in the file_managed table set to 0, and it has 0 usage in the file_usage table
8. run cron 6 hours later (this is the default value of the temporary_maximum_age setting in system.file)
9. • expected result: the uploaded file is still present (because usage > 0)
   • actual result: the uploaded file is absent (because usage = 0)

Note: see #40, where it is explained how this same problem is even reproducible on sites without content_translation are affected by this, merely having the language (Interface translation) module installed and having >1 interface language enabled is sufficient to reproduce this problem for image/file fields on User entities!

Proposed resolution

Root cause analysis:

• \Drupal\file\Plugin\Field\FieldType\FileFieldItemList::delete() removing file usages:
  

    public function delete() {
      parent::delete();
      $entity = $this->getEntity();
  
      // If a translation is deleted only decrement the file usage by one. If the
      // default translation is deleted remove all file usages within this entity.
      $count = $entity->isDefaultTranslation() ? 0 : 1;
      foreach ($this->referencedEntities() as $file) {
        \Drupal::service('file.usage')->delete($file, 'file', $entity->getEntityTypeId(), $entity->id(), $count);
      }
    }
  

• to delete file usages, it relies on $entity->isDefaultTranslation() (i.e. \Drupal\Core\TypedData\TranslatableInterface::isDefaultTranslation()) to determine whether a translation is being deleted or not
• $entity->isDefaultTranslation() behaves incorrectly when the default translation is being changed

Therefore the solution is: fix \Drupal\Core\Entity\ContentEntityBase::isDefaultTranslation().

Remaining tasks

TBD

User interface changes

None.

API changes

None.

Data model changes

None.

DrupalSqlBase::getSystemData() has a design quirk that it eats exceptions and just treats the failures as an empty system data array. This works fine in practice but its also the core of the logic in DrupalSqlBase::checkRequirements() where this is a usability issues.

For example, a connection string error shows the following for the d6_filter_format migration:

[ok] Running d6_filter_format
[error]  Migration d6_filter_format did not meet the requirements. The module filter is not enabled in the source site. source_module: filter. 
 

It would be a lot more useful for the requirements check to check the database first and see something like:

[error]  SQLSTATE[HY000] [1045] Access denied for user 'migration_user'@'localhost' (using password: YES) 

When fields allow multiple values (other than e.g. checkboxes), the widget is output in a table with tabledrag. This is functional but difficult to style to look consistent with other form elements. When a form needs to match a design, we often find ourselves fighting to hide the fact that fields, which often do not need to be orderable at all, are being presented in a tabledrag table we don't want.

This patch adds an option to the field widget settings which shows up for multiple fields to allow you to choose if the field should be orderable. If you do not choose orderable it will not use a table with tabledrag to output the fields.

Before:

After:

Setting:

Problem/Motivation

SqlContentEntityStorage::mapToStorageRecord sends update statements that includes IDENTITY fields that need to be updated, such as: UPDATE xxx SET nid = 1, property0 = :value0 WHERE nid = 1;. This is not supported in SQL Server because although there is no actual update happening it is explicitly telling the database engine that you wish to perform an update.

Question: Is it correct to allow UPDATE statements that change (even if new value is same as previous) IDENTITY values?

IDENTITY column values are immutable.

Proposed resolution

Remaining tasks

User interface changes

API changes

Original report by david_garcia

Problem/Motivation

HTML5 proposes/solidifies asynchronous loading of JavaScript files based on two attributes: defer and async. Drupal has supported defer since at least D6, and support for async is currently in the works (#1140356: Add async, onload property to script tags).

Current behavior (as of 8.6) is that scripts with the defer attribute do not ever get aggregated (even in the case where there are multiple scripts added through one library).

Proposed resolution

Presumably, something will be added to drupal_group_js that groups "async" values with one another and "defer" values with one another, respecting their weights.

Remaining tasks

• Related issue: #1140356: Add async, onload property to script tags
• Related issue: #865536: drupal_add_js() is missing the 'browsers' option
• Patch, test, etc.

User interface changes

None

API changes

Though this affects JavaScript aggregation, this should have little-to-no API impact.

My custom form date field is set up as follows:

$form['right']['validfrom'] = array(
      '#type' => 'date',
      '#title' => $this->t('Start date'),
      '#description' => $this->t('The beginning date.'),
      '#attributes' => array('class' => array('lala')),
    );

And the error thrown is the following:

Notice: Undefined index: type in Drupal\Core\Render\Element\Date::processDate() (line 63 of /var/www/website/public_html/core/lib/Drupal/Core/Render/Element/Date.php)
#0 /var/www/website/public_html/core/includes/bootstrap.inc(548): _drupal_error_handler_real(8, 'Undefined index...', '/var/www/website...', 63, Array)
#1 /var/www/website/public_html/core/lib/Drupal/Core/Render/Element/Date.php(63): _drupal_error_handler(8, 'Undefined index...', '/var/www/website...', 63, Array)
#2 [internal function]: Drupal\Core\Render\Element\Date::processDate(Array, Object(Drupal\Core\Form\FormState), Array)
#3 /var/www/website/public_html/core/lib/Drupal/Core/Form/FormBuilder.php(981): call_user_func_array(Array, Array)
#4 /var/www/website/public_html/core/lib/Drupal/Core/Form/FormBuilder.php(1044): Drupal\Core\Form\FormBuilder->doBuildForm('vehicle_main_fo...', Array, Object(Drupal\Core\Form\FormState))
#5 /var/www/website/public_html/core/lib/Drupal/Core/Form/FormBuilder.php(1044): Drupal\Core\Form\FormBuilder->doBuildForm('vehicle_main_fo...', Array, Object(Drupal\Core\Form\FormState))
#6 /var/www/website/public_html/core/lib/Drupal/Core/Form/FormBuilder.php(557): Drupal\Core\Form\FormBuilder->doBuildForm('vehicle_main_fo...', Array, Object(Drupal\Core\Form\FormState))
#7 /var/www/website/public_html/core/lib/Drupal/Core/Form/FormBuilder.php(314): Drupal\Core\Form\FormBuilder->processForm('vehicle_main_fo...', Array, Object(Drupal\Core\Form\FormState))
#8 /var/www/website/public_html/core/lib/Drupal/Core/Controller/FormController.php(74): Drupal\Core\Form\FormBuilder->buildForm('vehicle_main_fo...', Object(Drupal\Core\Form\FormState))
#9 [internal function]: Drupal\Core\Controller\FormController->getContentResult(Object(Symfony\Component\HttpFoundation\Request), Object(Drupal\Core\Routing\RouteMatch))
#10 /var/www/website/public_html/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(123): call_user_func_array(Array, Array)
#11 /var/www/website/public_html/core/lib/Drupal/Core/Render/Renderer.php(574): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}()
#12 /var/www/website/public_html/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(124): Drupal\Core\Render\Renderer->executeInRenderContext(Object(Drupal\Core\Render\RenderContext), Object(Closure))
#13 /var/www/website/public_html/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(97): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext(Array, Array)
#14 [internal function]: Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}()
#15 /var/www/website/public_html/vendor/symfony/http-kernel/HttpKernel.php(144): call_user_func_array(Object(Closure), Array)
#16 /var/www/website/public_html/vendor/symfony/http-kernel/HttpKernel.php(64): Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object(Symfony\Component\HttpFoundation\Request), 1)
#17 /var/www/website/public_html/core/lib/Drupal/Core/StackMiddleware/Session.php(57): Symfony\Component\HttpKernel\HttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#18 /var/www/website/public_html/core/lib/Drupal/Core/StackMiddleware/KernelPreHandle.php(47): Drupal\Core\StackMiddleware\Session->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#19 /var/www/website/public_html/core/modules/page_cache/src/StackMiddleware/PageCache.php(99): Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#20 /var/www/website/public_html/core/modules/page_cache/src/StackMiddleware/PageCache.php(78): Drupal\page_cache\StackMiddleware\PageCache->pass(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#21 /var/www/website/public_html/core/lib/Drupal/Core/StackMiddleware/ReverseProxyMiddleware.php(47): Drupal\page_cache\StackMiddleware\PageCache->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#22 /var/www/website/public_html/modules/devel/webprofiler/src/StackMiddleware/WebprofilerMiddleware.php(38): Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#23 /var/www/website/public_html/core/lib/Drupal/Core/StackMiddleware/NegotiationMiddleware.php(50): Drupal\webprofiler\StackMiddleware\WebprofilerMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#24 /var/www/website/public_html/vendor/stack/builder/src/Stack/StackedHttpKernel.php(23): Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#25 /var/www/website/public_html/core/lib/Drupal/Core/DrupalKernel.php(652): Stack\StackedHttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#26 /var/www/website/public_html/index.php(19): Drupal\Core\DrupalKernel->handle(Object(Symfony\Component\HttpFoundation\Request))
#27 {main}.

I've tested that this happens with whatever attribute you try to set and works perfectly when no attribute set.

EDIT adding more debugging info:

The code in /core/lib/Drupal/Core/Render/Element/Date for the relevant parts is:

class Date extends FormElement {

  /**
   * {@inheritdoc}
   */
  public function getInfo() {
    $class = get_class($this);
    return [
      '#input' => TRUE,
      '#theme' => 'input__date',
      '#process' => [[$class, 'processDate']],
      '#pre_render' => [[$class, 'preRenderDate']],
      '#theme_wrappers' => ['form_element'],
      '#attributes' => ['type' => 'date'],
      '#date_date_format' => 'Y-m-d',
    ];
  }

  /**
   * Processes a date form element.
   *
   * @param array $element
   *   The form element to process. Properties used:
   *   - #attributes: An associative array containing:
   *     - type: The type of date field rendered.
   *   - #date_date_format: The date format used in PHP formats.
   * @param \Drupal\Core\Form\FormStateInterface $form_state
   *   The current state of the form.
   * @param array $complete_form
   *   The complete form structure.
   *
   * @return array
   *   The processed element.
   */
  public static function processDate(&$element, FormStateInterface $form_state, &$complete_form) {
    // Attach JS support for the date field, if we can determine which date
    // format should be used.
    if ($element['#attributes']['type'] == 'date'&& !empty($element['#date_date_format'])) {
      $element['#attached']['library'][] = 'core/drupal.date';
      $element['#attributes']['data-drupal-date-format'] = [$element['#date_date_format']];
    }
    return $element;
  }

The sequence the code is processed is:

1. Creation of field in custom form code
2. Date::getInfo()
3. Date::processDate()
4. Date::preRenderDate - not relevant here

So now if I dpm($element) in Date::processDate()

when there's no attributes set in my field the element seems to have the attributes returned from Date::getInfo() :

But when I set attributes from my own field declaration they seem to override the attributes all together:

All my other fields work fine with attributes just the date seems to be going crazy.

In core/misc/dialog/off-canvas.js and beforeCreate, the displace offsets (top and botton) are not deducted as in resetSize.

For some themes overriding the dialog system, as Bootstrap for example, it resulting in a 100% window height with the impossibility to scroll down to the bottom of the off-canvas modal when the content is larger than the window height.
As an addition, I guess that the correct height should be setted from the start to cover any case. Plus it doesn't seems to break anything for the basic expected behaviour.

Block visibility settings allow to show a block "per page path" OR "per content type" only.

Example: "Recent blog posts" - a pure blog related block.
If "Pages" is set to "All pages" AND "Content types" to "Blog entry" it will show up ONLY on blog posts but not on Blogs page.
If "Only the listed pages" is set to "blog" it will show up ONLY on Blogs page but not on any of blog posts.
If "Only the listed pages" is set to "blog" AND "Content types" is set to "Blog entry" it will not be shown at all. Nowhere.
Isn't it logical to allow it to be visible at Blogs page AND Blog posts?

The same goes for any other block, not only "recent blog posts".

(There are snippets like this one http://drupal.org/node/134425 but they require the PHP module.)

My recent log have a lot of this error (every page not found creat 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.

In ac63952 from #2624770: Use more specific entity.manager services in core.services.yml , EntityDefinitionUpdateManager swapped out the old entity.manager for entity_type.manager. When you use the content translation manager to set an entity/bundle to translatable, It's now run through EntityTypeManager::clearCachedDefinitions instead of EntityManager::clearCachedDefinitions, and EntityTypeManager::clearCachedDefinitions does not clear out the bundle info cache, so subsequent calls to the bundles ->isTranslateable() function do not return the new value.

Hi!

Today we upgrade our site to 7.60.
PHP version: 5.6
OS: Amazon Linux AMI
The upgrade is done without problems, but after this all the file fields stop to work.

There is no problem with the file system config because this are working without problem in the previous version.
I think that the problem is related to the AJAX process.

Some examples:

If you try to remove an image in a file field, then and Ajax is thrown:
An AJAX HTTP request terminated abnormally.
Path: /node/add/app
StatusText: n/a
ResponseText:
ReadyState:,
If you trace the AJAX response in the console, this returns the whole page inside the AJAX response!

The same happens if you try to upload an image.
Some times the same AJAX error is thrown, but other times the "uploadprogress" bar is shown, but never ends.
If you try to trace the network requests in browser console, you will see an infinite loop trying to upload the file.
And if i connect to the "tmp" folder where Apache store the upload file, before Drupal process it, the file is present.

We are not using the "Domain Auto" module.

Any idea?

When attempting to access the an autocomplete field suggestions using the arrow keys and JAWS is enabled, the user is unable to navigate beyond the first element. While navigating using the down arrow key the user is navigated to next available field rather than the next autocomplete suggestion.

• Testing was performed using JAWS v18.0.2945.
• This defect exists in Google Chrome v69.0.3497.100 and in IE11.

Step to reproduce:

1. Add a entity reference field to content type and use an autocomplete widget.
2. Add some content to the entity that is being referenced.
3. Open JAWS v18.0.2945.
4. Create or edit a node that has the new field.
5. Use the Tab key to navigate to the field.
6. Start typing in the filed so that suggestions appear.
7. Use the down arrow to try and select autocomplete suggestion below the first suggestion.

Expected result: All interactive user interface elements are expected to be accessible via the keyboard while JAWS is enabled.