I created a content type for uploading CV and was working fine. But now the file field is not working for the below scenario:

Attach a file of valid format (Txt or doc or docx or pdf) -> After attaching remove this attachment -> Now try to attach a file of invalid format (Eg: jpeg, xls or png etc)

Expected result: There should display a proper error message

Actual result: No error displaying, only the loader icon is displaying as the file is loading. And sometimes it is showing AJAX error too.

Thanks

I have set up a site in such a way that all content is automatically translated by DeepL. Unfortunately, the continous translation job fails when translation of a short text field is longer than original text.

As it turns out, german and french translations are often up to 30% longer than english original, so this is a serious issue. It manifests in several ways:

1) If the error happens when new entity is added, the "The website encountered an unexpected error. Please try again later." is shown and the user has to start again.
2) if this happens on an existing entity, the same error is shown and the changes aren't saved (not even in English).

the Error messages in the log look like this:

Drupal\Core\Entity\EntityStorageException: SQLSTATE[22001]: String data, right truncated: 1406 Data too long for column 'field_short_summary_value' at row 2: INSERT INTO {group__field_short_summary} (entity_id, revision_id, bundle, delta, langcode, field_short_summary_value) 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] => 20 [:db_insert_placeholder_1] => 20 [:db_insert_placeholder_2] => solution [:db_insert_placeholder_3] => 0 [:db_insert_placeholder_4] => en [:db_insert_placeholder_5] => CrowdTasker enables crisis managers to efficiently provide large numbers of non-institutional volunteers with customizable tasks, contextual warnings and alerts, as well as to crowdsource information from them.CrowdTasker enables crisis managers to effici [:db_insert_placeholder_6] => 20 [:db_insert_placeholder_7] => 20 [:db_insert_placeholder_8] => solution [:db_insert_placeholder_9] => 0 [:db_insert_placeholder_10] => de [:db_insert_placeholder_11] => CrowdTasker ermöglicht es Krisenmanagern, einer großen Anzahl von nicht institutionellen Freiwilligen effizient anpassbare Aufgaben, kontextbezogene Warnungen und Warnungen zur Verfügung zu stellen und Informationen von ihnen zu sammeln. CrowdTasker ermöglicht es Krisenmanagern, Maßnahmen zu ergreifen. ) in Drupal\Core\Entity\Sql\SqlContentEntityStorage->save() (line 847 of /var/www/drupal8composer/web/core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorage.php).

Now the problem isn't that German translation is longer than english text. This can't be helped. As I see it:

1. The first problem is that the english original is of allowed size and should be stored before the translation error occurs.
2. The second problem is that the "the translation could not be made because..." error message should be shown to the user.
3. The third problem is that there is no way to limit the allowed string length for the short text field to a different length per language.

Having a separate "entry length limit" and "database length limit" would do the trick for me.

Problem/Motivation

This is issue is spun off from UX team feedback on #2831944-203: Implement media source plugin for remote video via oEmbed.

For security reasons, the oEmbed system uses an iframe to serve content from a third-party oEmbed provider. By default. the iframe is served from the same domain as the main Drupal site, but this is not secure. Therefore, Media introduced a setting, exposed in a configuration form, which allows site builders/admins to set up an alternate domain from which to serve the iframe.

In order to serve oEmbed content more securely, the iFrame domain needs to point to the Drupal site. This is explained on the form, but not validated in any way.

Proposed resolution

It would be nice to add some sort of validation to ensure that the iFrame domain is actually pointing to the Drupal site, because if it isn't, then almost all oEmbed content on the site will break (404 errors or worse), which scare the pants off of our users.

Remaining tasks

1. Discuss if we should even do this, and if so, how to do it in a way that will please the security team.
2. Write a patch
3. Review it until we're all sick of looking at it
4. Commit it

User interface changes

TBD, but probably none.

API changes

TBD, but probably minimal or none.

Data model changes

None anticipated.

Problem/Motivation

• UpdatePathWithBrokenRoutingFilledTest
• EntityUpdateToPublishableTest
• EntityUpdateInitialTest

need to use the 8.8.x filled update so they continue to work after #3087644: Remove Drupal 8 updates up to and including 88**.

Proposed resolution

Change the tarball these updates are using - try and remove the legacy tag.

Remaining tasks

User interface changes

None

API changes

None

Data model changes

None

Release notes snippet

N/a

Problem/Motivation

\Drupal\FunctionalTests\Update\UpdatePathTestBase allows us to install Drupal from a database dump and then run updates. However it's difficult to test the update system without using a database dump. However there are tests for bugs like #2863986: Allow updating modules with new service dependencies and #3063734: Support uninstalling the module providing the update hook in hook_update_N where it would be handy to be able test the update system against a fresh install and not use a database. This would mean that only the update the test is interested in would run and we wouldn't need to make the tests legacy tests - both of which are good things.

Proposed resolution

Move most of \Drupal\FunctionalTests\Update\UpdatePathTestBase::runUpdates() into a trait so it can be used by other BrowserTestBase tests.

Remaining tasks

User interface changes

None

API changes

Only new test API.

Data model changes

None

Release notes snippet

N/a

I have configured the site to automatically translate content using DeepL. The deepl provider is set to "auto accept finished translations". This works (mostly) fine, but I have noticed a strange behaviour related to "needs translation".

1. When no translation exists, translation is generated on edit.
2. When translation already exists, new translation is only generated if the "Flag other translations as outdated" is set.
3. When a new translation is added by DeepL, the "this translation is outdated" flag is not removed.

Ideally, I woudl like to have following configuration options:

1. "Flag other translations as outdated" publishing option. analogous to "Create new revision"
2. "Auto update translation status" in addition to "Auto accept finished translations" in the Deepl provider configuration. Or globally.

When both these options are set, the default would be to ask the Deepl to translate on every edit and the "outdated" flag would be automatically removed afterwards.

Problem/Motivation

Whever I try the upgrade, it hangs at 38%. Checking the error log, I see multiple entries with the message "Missing filter plugin: filter_null."

I know that the PHP plugin was enabled on the old site, so not sure if it's related to that. I did try enabling the contrib version of the D8 PHP filter, but php still showed up as a missing dependency, and there was no change in the import.

Proposed resolution

When replacing a filter with filter_null, be sure we are stripping out any settings that may fail a validation check.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Steps to reproduce

1. Install Drupal 8.8.1
2. drush en -y media_library
3. Create media type "Remote video"with these settings
4. Create some CT with a field making use of Media Library and allowing media type "Remote video"
5. In node form, click on field to open Media Library modal
6. If you have multiple media types, make sure you click on "Remote video" tab in modal

Current result

• DBlog logs :

• User error: "0" is an invalid render array key in Drupal\Core\Render\Element::children() (line 97 of /var/www/html/web/core/lib/Drupal/Core/Render/Element.php) #0 /var/www/html/web/core/includes/bootstrap.inc(596): _drupal_error_handler_real(256, '"0" is an inval...', '/var/www/html/w...', 97, Array) #1 [internal function]: _drupal_error_handler(256, '"0" is an inval...', '/var/www/html/w...', 97, Array) #2 /var/www/html/web/core/lib/Drupal/Core/Render/Element.php(97): trigger_error('"0" is an inval...', 256) #3 /var/www/html/web/core/lib/Drupal/Core/Render/Renderer.php(402): Drupal\Core\Render\Element::children(Array, false) #4 /var/www/html/web/core/lib/Drupal/Core/Render/Renderer.php(444): Drupal\Core\Render\Renderer->doRender(Array) #5 /var/www/html/web/core/lib/Drupal/Core/Render/Renderer.php(444): Drupal\Core\Render\Renderer->doRender(Array) #6 /var/www/html/web/core/lib/Drupal/Core/Render/Renderer.php(444): Drupal\Core\Render\Renderer->doRender(Array) #7 /var/www/html/web/core/lib/Drupal/Core/Render/Renderer.php(200): Drupal\Core\Render\Renderer->doRender(Array, false) #8 /var/www/html/web/core/lib/Drupal/Core/Template/TwigExtension.php(501): Drupal\Core\Render\Renderer->render(Array) #9 /var/www/html/web/sites/default/files/php/twig/5dfb4cb1a9345_media-library-wrapper.htm_f_JYNvTTrDG9miX3e2bneaS03/H_KnDp_1rc6iXO_SkhJbWRntrV_j5n1nyTPPE_UaW3g.php(64): Drupal\Core\Template\TwigExtension->escapeFilter(Object(Drupal\Core\Template\TwigEnvironment), Array, 'html', NULL, true) #10 /var/www/html/vendor/twig/twig/src/Template.php(455): __TwigTemplate_b883481b98094281f15633095b8d30955b6dbe2479a50f1c3d2fd27f11228de9->doDisplay(Array, Array) #11 /var/www/html/vendor/twig/twig/src/Template.php(422): Twig\Template->displayWithErrorHandling(Array, Array) #12 /var/www/html/vendor/twig/twig/src/Template.php(434): Twig\Template->display(Array) #13 /var/www/html/web/core/themes/engines/twig/twig.engine(64): Twig\Template->render(Array) #14 /var/www/html/web/core/lib/Drupal/Core/Theme/ThemeManager.php(384): twig_render_template('core/themes/cla...', Array) #15 /var/www/html/web/core/lib/Drupal/Core/Render/Renderer.php(431): Drupal\Core\Theme\ThemeManager->render('media_library_w...', Array) #16 /var/www/html/web/core/lib/Drupal/Core/Render/Renderer.php(200): Drupal\Core\Render\Renderer->doRender(Array, true) #17 /var/www/html/web/core/lib/Drupal/Core/Render/Renderer.php(144): Drupal\Core\Render\Renderer->render(Array, true) #18 /var/www/html/web/core/lib/Drupal/Core/Render/Renderer.php(573): Drupal\Core\Render\Renderer->Drupal\Core\Render\{closure}() #19 /var/www/html/web/core/lib/Drupal/Core/Render/Renderer.php(145): Drupal\Core\Render\Renderer->executeInRenderContext(Object(Drupal\Core\Render\RenderContext), Object(Closure)) #20 /var/www/html/web/core/lib/Drupal/Core/Ajax/CommandWithAttachedAssetsTrait.php(36): Drupal\Core\Render\Renderer->renderRoot(Array) #21 /var/www/html/web/core/lib/Drupal/Core/Ajax/OpenDialogCommand.php(135): Drupal\Core\Ajax\OpenDialogCommand->getRenderedContent() #22 /var/www/html/web/core/lib/Drupal/Core/Ajax/AjaxResponse.php(43): Drupal\Core\Ajax\OpenDialogCommand->render() #23 /var/www/html/web/core/modules/media_library/src/Plugin/Field/FieldWidget/MediaLibraryWidget.php(776): Drupal\Core\Ajax\AjaxResponse->addCommand(Object(Drupal\Core\Ajax\OpenModalDialogCommand)) #24 [internal function]: Drupal\media_library\Plugin\Field\FieldWidget\MediaLibraryWidget::openMediaLibrary(Array, Object(Drupal\Core\Form\FormState), Object(Symfony\Component\HttpFoundation\Request)) #25 /var/www/html/web/core/lib/Drupal/Core/Form/FormAjaxResponseBuilder.php(69): call_user_func_array(Array, Array) #26 /var/www/html/web/core/lib/Drupal/Core/Form/EventSubscriber/FormAjaxSubscriber.php(109): Drupal\Core\Form\FormAjaxResponseBuilder->buildResponse(Object(Symfony\Component\HttpFoundation\Request), Array, Object(Drupal\Core\Form\FormState), Array) #27 [internal function]: Drupal\Core\Form\EventSubscriber\FormAjaxSubscriber->onException(Object(Symfony\Component\HttpKernel\Event\GetResponseForExceptionEvent), 'kernel.exceptio...', Object(Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher)) #28 /var/www/html/web/core/lib/Drupal/Component/EventDispatcher/ContainerAwareEventDispatcher.php(111): call_user_func(Array, Object(Symfony\Component\HttpKernel\Event\GetResponseForExceptionEvent), 'kernel.exceptio...', Object(Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher)) #29 /var/www/html/vendor/symfony/http-kernel/HttpKernel.php(227): Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher->dispatch('kernel.exceptio...', Object(Symfony\Component\HttpKernel\Event\GetResponseForExceptionEvent)) #30 /var/www/html/vendor/symfony/http-kernel/HttpKernel.php(79): Symfony\Component\HttpKernel\HttpKernel->handleException(Object(Drupal\Core\Form\FormAjaxException), Object(Symfony\Component\HttpFoundation\Request), 1) #31 /var/www/html/web/core/lib/Drupal/Core/StackMiddleware/Session.php(57): Symfony\Component\HttpKernel\HttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) #32 /var/www/html/web/core/lib/Drupal/Core/StackMiddleware/KernelPreHandle.php(47): Drupal\Core\StackMiddleware\Session->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) #33 /var/www/html/web/core/modules/page_cache/src/StackMiddleware/PageCache.php(106): Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) #34 /var/www/html/web/core/modules/page_cache/src/StackMiddleware/PageCache.php(85): Drupal\page_cache\StackMiddleware\PageCache->pass(Object(Symfony\Component\HttpFoundation\Request), 1, true) #35 /var/www/html/web/core/lib/Drupal/Core/StackMiddleware/ReverseProxyMiddleware.php(47): Drupal\page_cache\StackMiddleware\PageCache->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) #36 /var/www/html/web/core/lib/Drupal/Core/StackMiddleware/NegotiationMiddleware.php(52): Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) #37 /var/www/html/vendor/stack/builder/src/Stack/StackedHttpKernel.php(23): Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) #38 /var/www/html/web/core/lib/Drupal/Core/DrupalKernel.php(694): Stack\StackedHttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) #39 /var/www/html/web/index.php(19): Drupal\Core\DrupalKernel->handle(Object(Symfony\Component\HttpFoundation\Request)) #40 {main}.
  

Expected result

• Displaying Media Library modal should not throw any error

Todo

• Debug and fix

Problem/Motivation

Drupal 9 will once again allow hook_update_N() to be used between major versions.

However, database updates still regularly introduce bugs, since they often run up against issues on real sites, such as corrupted data, or incompatibilities with contributed and custom schema changes/additions. Also sites that run into upgrade path issues and report them to the issue queue are not always run by people who can debug upgrade path issues themselves.

Proposed resolution

• Remove all updates added prior to Drupal 8.8.0-rc1 from Drupal 9.
• Remove all real legacy update tests

This will mean that sites still on Drupal 8.7 or lower, will need to update to Drupal 8.8.0 or later, prior to updating to Drupal 9.

There are various advantages to this:

1. Old upgrade path bugs from Drupal 8.5/8.6 can no longer be fixed in Drupal 8.7 but they can still be backported to Drupal 8.8. Therefore for sites running out of date core versions, getting them onto 8.8 first means they have the best chance of a smooth minor upgrade path before the major one.

2. Old updates may rely on deprecated APIs that are being removed in Drupal 9, and re-writing upgrade paths risk introducing new regressions.

3. Ensuring that every Drupal 8 site is on Drupal 8.8 or 8.9 before they update to Drupal 9 will drastically reduce the variables when upgrade paths are reported (compared to letting people update from Drupal 8.4 to Drupal 9 directly).

4. Contributed modules will also need to be updated to their latest versions prior to moving to Drupal 9, so ensuring core installs do this is encouragement to update contrib too.

Remaining tasks

Create a patch

User interface changes

None

API changes

None

Data model changes

None

Release notes snippet

Drupal 8 upgrade path has been removed.

I have set up a site with automated translating of content by DeepL. It works (mostly) OK, but I have noticed inconsistend behaviour between menu links that are made in different ways:

1. menu links published by views
2. menu links directly entered by teh suer
3. menu links explicitly defined in nodes.

Example 1: Custom "about" menu entry, pointing to a node. the node has a custom /about path defined and the custom path is not transportable.

In this example, /en/about will exist but /de/about will not. Translating the custom menu links and the node doesn't help.

Example 2: "About" menu entry is defined in the node. The node has a custom /about path defined and the custom path is not transportable.

In this example, the menu entry will point to the node also in German, but the link will be to /de/node/number and not to /de/about

Example 3: "About" menu entry is defined in the node. The node has a custom /about path defined and the custom path is transportable.

In this example, the menu entry will point to the node also in German, and DeepL will translate the /en/about to /de/über path. This is not so bad, but the blocks that are configured to show on /about page will not show on de/über so I woudl prefer to just leave the path untranslated.

For views, the behaviour is different. First, they can't be auto-translated like content and second, the view page at /about would be generated at both /en/about and /de/about if the view isn't translated.

Am I missing something? I woudl like this to work consistently between menues that are generated in three ways and also with the blocks. This is what I would like to have:

• de/ exists automatically when is defined for a node and aliases aren't translateable.
• Block "pages" can be configured to look for english (default language) aliases in patterns instead of the translated ones.

Problem/Motivation

Right now each content entity type needs to define its set of permissions from scratch, then declare a matching access handler. This is pure boilerplate, an entity type's permissions can very precisely be guessed based on the interfaces it implements and the permission granularity it specifies. Furthermore, requiring each developer to create a new access handler each time leaves room for frequent bugs, such as wrong cacheability metadata.

Proposed resolution

The permissions currently vary based on two factors:

• EntityOwnerInterface
• Permission granularity (bundle / entity_type)

Future iterations of the patch / issue followups would also take into account EntityPublishedInterface.

Generated permissions:

• "administer $entity_type_id" (god mode permission)
• "access $entity_type_id overview" (the basic permission for listings)
• "view $entity_type_id" OR "view own $entity_type_id" / "view any $entity_type_id" depending on EntityOwnerInterface
• create/update/delete permissions per bundle or per entity type, also taking into account EntityOwnerInterface

Note that view permissions are never per-bundle cause we have no way to enforce it, we'd need query access for that (ala node access).

Just like we did for route providers, we introduce the concept of permission providers. That makes this generation opt-in.
Each participating entity type would define the core's permission provider, and the matching access handler. Core calls the permission provider of each entity type when building permissions.

The proposed solution was implemented in the Entity API contrib module (#2801031: Provide a generic entity access handler and permissions) and is used by Commerce and other contrib modules.

Remaining tasks

Roll the patch

Problem/Motivation

As part of #3094468: [plan] Update core JavaScript (and CSS) dependencies prior to 9.0.0-beta1 we need to update Underscore to 1.9.1 from 1.8.3

Proposed resolution

Update it

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

Firefox 49 is out and has support for <details> which means our polyfill doesn't kick in. Normalize.css sets <details> and <summary> element as display:block which means Firefox won't display the marker, they fixed this in 5.0.0 (https://github.com/necolas/normalize.css/issues/604).

Checkout comparison aligned by @droplet: (removed comments & unchanged rules, re-reordering to match v3)
https://www.drupal.org/files/issues/diff-manual-aligned-by-%40droplet.patch

Here are the change logs for Normalize.css, starting at 4.0.0 (scroll up): https://github.com/necolas/normalize.css/blob/f06565fe8e0e1ad1b88f273271.... There are a lot of changes due to reorganization/sectioning of the code as well as comment changes.

There is one notable change that causes a regression in, at least, Seven: https://github.com/necolas/normalize.css/commit/02c5c7adbbec1707900fde86..., see the attached screenshot.

There may be regressions upgrading from 3.0.3 to the most recent normalize.css.

Proposed resolution

Upgrade core's Normalize to most recent version.
Normalize 3.0.3 should be copied to Stable. Stable needs to continue using 3.0.3 for BC.

Remaining tasks

1. Replace normalize with 5.0.0
2. Determine which removed or changed selectors will cause regression.
3. Add them back to Stable theme.

User interface changes

Hopefully none!

Problem/Motivation

As part of #3094468: [plan] Update core JavaScript (and CSS) dependencies prior to 9.0.0-beta1 we need to update popper.js to 1.16.0
https://github.com/popperjs/popper.js/releases

Proposed resolution

Update it

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

When browsing an Ajax view, many Drupal.Ajax are created for the refresh feature. Those objects are not cleaned up.

Need to either add some code to clean them up or prevent several objects from being created.

Problem/Motivation

As part of #3094468: [plan] Update core JavaScript (and CSS) dependencies prior to 9.0.0-beta1 we need to update jquery-once 2.2.3

It looks there haven't been big changes https://github.com/RobLoach/jquery-once/releases

Proposed resolution

Update it

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

As part of #3094468: [plan] Update core JavaScript (and CSS) dependencies prior to 9.0.0-beta1 we need to update picturefill.

Proposed resolution

Update it

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Here's the scenario. I keep all our sites on our server updated via Composer. Standard procedure is to run

composer update drupal/* --with-dependenices

Then I run

drush updb

Next

composer update drupal/core webflo/drupal-core-require-dev --with-dependenices

and drush updb once more.

When doing this to move from Drupal 8.7.10 to 8.8.0, I first learned that I needed to update Pathauto module. Good. I do that. But when I go to admin/reports/updates; I get the message "The website has encountered an error. Please try again later."
Log messages show
InvalidArgumentException: Host must be a string in GuzzleHttp\Psr7\Uri->filterHost() (line 611 of /home/jonestownag/vendor/guzzlehttp/psr7/src/Uri.php).

If I refresh the site several times I can get the page to load but no updates show.
Log messages show
Warning: Invalid argument supplied for foreach() in template_preprocess_update_report() (line 43 of /home/jonestownag/public_html/core/modules/update/update.report.inc) #0 /home/jonestownag/public_html/core/includes/bootstrap.inc(596): _drupal_error_handler_real(2, 'Invalid argumen...', '/home/jonestown...', 43, Array) #1 /home/jonestownag/public_html/core/modules/update/update.report.inc(43): _drupal_error_handler(2, 'Invalid argumen...', '/home/jonestown...', 43, Array) #2 /home/jonestownag/public_html/core/lib/Drupal/Core/Theme/ThemeManager.php(287): template_preprocess_update_report(Array, 'update_report', Array) #3 /home/jonestownag/public_html/core/lib/Drupal/Core/Render/Renderer.php(431): Drupal\Core\Theme\ThemeManager->render('update_report', Array) #4 /home/jonestownag/public_html/core/lib/Drupal/Core/Render/Renderer.php(444): Drupal\Core\Render\Renderer->doRender(Array) #5 /home/jonestownag/public_html/core/lib/Drupal/Core/Render/Renderer.php(200): Drupal\Core\Render\Renderer->doRender(Array, false) #6 /home/jonestownag/public_html/core/lib/Drupal/Core/Render/MainContent/HtmlRenderer.php(226): Drupal\Core\Render\Renderer->render(Array, false) #7 /home/jonestownag/public_html/core/lib/Drupal/Core/Render/Renderer.php(573): Drupal\Core\Render\MainContent\HtmlRenderer->Drupal\Core\Render\MainContent\{closure}() #8 /home/jonestownag/public_html/core/lib/Drupal/Core/Render/MainContent/HtmlRenderer.php(227): Drupal\Core\Render\Renderer->executeInRenderContext(Object(Drupal\Core\Render\RenderContext), Object(Closure)) #9 /home/jonestownag/public_html/core/lib/Drupal/Core/Render/MainContent/HtmlRenderer.php(117): Drupal\Core\Render\MainContent\HtmlRenderer->prepare(Array, Object(Symfony\Component\HttpFoundation\Request), Object(Drupal\Core\Routing\CurrentRouteMatch)) #10 /home/jonestownag/public_html/core/lib/Drupal/Core/EventSubscriber/MainContentViewSubscriber.php(90): Drupal\Core\Render\MainContent\HtmlRenderer->renderResponse(Array, Object(Symfony\Component\HttpFoundation\Request), Object(Drupal\Core\Routing\CurrentRouteMatch)) #11 [internal function]: Drupal\Core\EventSubscriber\MainContentViewSubscriber->onViewRenderArray(Object(Symfony\Component\HttpKernel\Event\GetResponseForControllerResultEvent), 'kernel.view', Object(Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher)) #12 /home/jonestownag/public_html/core/lib/Drupal/Component/EventDispatcher/ContainerAwareEventDispatcher.php(111): call_user_func(Array, Object(Symfony\Component\HttpKernel\Event\GetResponseForControllerResultEvent), 'kernel.view', Object(Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher)) #13 /home/jonestownag/vendor/symfony/http-kernel/HttpKernel.php(156): Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher->dispatch('kernel.view', Object(Symfony\Component\HttpKernel\Event\GetResponseForControllerResultEvent)) #14 /home/jonestownag/vendor/symfony/http-kernel/HttpKernel.php(68): Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object(Symfony\Component\HttpFoundation\Request), 1) #15 /home/jonestownag/public_html/core/lib/Drupal/Core/StackMiddleware/Session.php(57): Symfony\Component\HttpKernel\HttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) #16 /home/jonestownag/public_html/core/lib/Drupal/Core/StackMiddleware/KernelPreHandle.php(47): Drupal\Core\StackMiddleware\Session->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) #17 /home/jonestownag/public_html/core/modules/page_cache/src/StackMiddleware/PageCache.php(106): Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) #18 /home/jonestownag/public_html/core/modules/page_cache/src/StackMiddleware/PageCache.php(85): Drupal\page_cache\StackMiddleware\PageCache->pass(Object(Symfony\Component\HttpFoundation\Request), 1, true) #19 /home/jonestownag/public_html/core/lib/Drupal/Core/StackMiddleware/ReverseProxyMiddleware.php(47): Drupal\page_cache\StackMiddleware\PageCache->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) #20 /home/jonestownag/public_html/core/lib/Drupal/Core/StackMiddleware/NegotiationMiddleware.php(52): Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) #21 /home/jonestownag/vendor/stack/builder/src/Stack/StackedHttpKernel.php(23): Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) #22 /home/jonestownag/public_html/core/lib/Drupal/Core/DrupalKernel.php(694): Stack\StackedHttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) #23 /home/jonestownag/public_html/index.php(19): Drupal\Core\DrupalKernel->handle(Object(Symfony\Component\HttpFoundation\Request)) #24 {main}.

Google has not been much help. And I really want my sites stable. What can I do?

Problem/Motivation

As shown in #2699895: Allow configurable date attributes to collect, the Drupal 7 date module allowed the site builder to configure which granularity to collect:

For example, on my personal site, I have a projectNodeType which has a "time range"date field that only cares about year + month granularity. Example: https://wimleers.com/work/project/cdn-far-future-expiration-drupal-7 and https://wimleers.com/work/project/ledgrid.

There are some values like 2008-00-00T00:00 and 2006-10-00T00:00 in the D7 datatabase, which cause a hard failure during migration:

Proposed resolution

Make \Drupal\migrate\Plugin\migrate\process\FormatDate::transform() detect -00-00T and -00T ISO8601 timestamps and transform to valid values.

This then results in the following DB tables in D8:

Remaining tasks

TBD

User interface changes

N/A

API changes

N/A

Data model changes

N/A

Release notes snippet

TBD

Problem/Motivation

Field UI allows you to select multiple target bundles for a field.
When you get to the views UI though you can select just a single vocabulary. For some usecases this is a problem

Proposed resolution

Allow to set multiple vocabularies

Remaining tasks

• Write a proper update path
• Write a test for the new capability
• Write a test for the update path

Before:

After: