Problem/Motivation

We have some confirm forms that are more destructive than others. For example, the module uninstall confirm form can result in deleting large numbers of configuration entities, dropping database tables etc..

This came up whilst reviewing a new feature to delete content entities prior to uninstallation of a module where it was suggested that we swap the buttons and mark the delete all button as a danger button. See #2688945-90: Allow removing a module's content entities prior to module uninstallation. Eventually we decided not to do that because of UX concerns.

Proposed resolution

Some proposed designs so far have included one or more of these elements:

1. A modal confirm form, like the node preview links provide.
2. An extra field that forces the user to type in "Delete".
3. An extra checkbox that is something like "Yes, I really want to delete all these things."
4. Making the destructive operation link-styled instead of button-styled.
5. Using more red.
6. Swapping the position of the "Do it" and "Cancel" buttons.

Remaining tasks

Review the design.

User interface changes

API changes

Data model changes

None

Screenshots

Modules

http://127.0.0.1:8888/admin/modules/uninstall/confirm

Themes

http://127.0.0.1:8888/admin/appearance

Uninstalling a theme displays no warning even though all of the theme's blocks are deleted.

Nodes

http://127.0.0.1:8888/node/16/delete

Block: Custom

http://127.0.0.1:8888/block/1/delete

Block Block layout (Remove)

http://127.0.0.1:8888/admin/structure/block/manage/umami_search/delete

Book: Main

http://127.0.0.1:8888/node/BID/delete

Book: Page

http://127.0.0.1:8888/node/NID/delete

Comment

http://127.0.0.1:8888/comment/COMMENT_ID/delete

Contact form

http://127.0.0.1:8888/admin/structure/contact/manage/feedback/delete

Content type

http://127.0.0.1:8888/admin/structure/types/manage/article/delete

Field

http://127.0.0.1:8888/admin/structure/types/manage/article/fields/node.a...

Image style

http://127.0.0.1:8888/admin/config/media/image-styles/manage/large/delete

Media type

http://127.0.0.1:8888/admin/structure/media/manage/audio/delete

Media entity

http://127.0.0.1:8888/media/1/deletee

Menu

http://127.0.0.1:8888/admin/structure/menu/manage/example/delete

Menu: Link

http://127.0.0.1:8888/admin/structure/menu/item/1/delete

Language

http://127.0.0.1:8888/admin/config/regional/language/delete/es

Taxonomy: Vocabulary

http://127.0.0.1:8888/admin/structure/taxonomy/manage/recipe_category/de...

Taxonomy: Term

http://127.0.0.1:8888/taxonomy/term/27/delete

Text format (Disable)

http://127.0.0.1:8888/admin/config/content/formats/manage/basic_html/dis...

User (Cancel)

http://127.0.0.1:8888/user/2/cancel

User: Role

http://127.0.0.1:8888/admin/people/roles/manage/administrator/delete

Views

http://127.0.0.1:8888/admin/structure/views/view/articles_aside/delete

Problem/Motivation

Note: This is both a bug ("Computed bundlie fields are broken") and a feature request ("Introduce the notion of computed field storage definitions") so landing on "task" as a compromise.

Because every field definition - including bundle fields - require an accompanying field storage definition, you also need to provide a field storage definition for computed bundle fields even though a computed (bundle) field does not require any storage. Because field storage definitions do not have the notion of "computed", this means that schema tables or columns will be created for those computed fields.

This can be worked around by marking the field storage definitions as having "custom storage", but that is a different semantic and is really just a workaround.

Proposed resolution

This is postponed on #2935932: Add a FieldDefinition class for defining bundle fields in code..

Introduce the notion of "computed" to field storage definitions.

Bug description

We've met a buggy behaviour of a view having two reference-field filters in an OR subgroup.

That's how filters looked like:

And this is the resulting query:

There are two issues:
1. AND operator is used instead of OR one.
2. Even if OR operator would be used, INNER join breaks the OR logic.

STR

1. Create new Drupal 8 installation with a Standard profile.
2. Export configuration.
3. Copy/replace files from attached configuration-parts.tgz.
4. Import/synchronize the configuration.
5. At admin/structure/views/settings enable the "Show the SQL query" option.
6. Visit admin/structure/views/view/many_to_one_test and see the resulting query.

Remaining tasks

- decide if we want to somehow determine when the INNER join can be used

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

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

I think the design of draggable.png (found in the 'misc' folder) could be improved a bit:

The normal state should look more like grippie.png; grooves you can grasp on to. This is more consistent with the expandable formfields in Drupal and these 'grooves' are often seen in other software as well. It also looks less 'noisy' than a whole column of grey crosses.

Seperating the arrows from the horizontal bar makes that bar a little icon for the table-row you are actually dragging.

Together this also results in better contrast between the _up and _over states.

When I try to update Drupal from 8.4.0 to 8.6.1 I got the following error

Module Views
Updating table_display_cache_max_age

Fail: InvalidArgumentException: Placeholders must have a trailing [] if they are to be expanded with an array of values. in Drupal\Core\Database\Connection->expandArguments() (line 729 of /http/xxx/site/core/lib/Drupal/Core/Database/Connection.php).

Update from 8.6.1 to 8.6.2 gives a "unexpected error..."
There was one update in update.php: contextual module.

Disable contextuale module en quick edit module don't solve the problem.

Problem/Motivation

According to the original mockups from #2796001-101: [prototype] Create design for a Media Library, the media library as it shipped in Drupal 8.6 is very close to feature-complete. However, one notable thing is missing: the ability to add media using an external embed code. Now that Media has support for oEmbed, it's time to make Media Library support that.

Proposed resolution

Modify the Media Library field widget so that it's possible to add a media item using an embed code.

Remaining tasks

1. Discuss if it should be possible to only enter one embed code in the widget, or several. The widget does support multiple file uploads, but it's unclear if that same paradigm should be implemented for embed codes.
2. Write a patch and tests.
3. Get UX and product manager sign-off.
4. Pass security review (oEmbed always deserves a second look from a security standpoint).
5. RTBC and commit.

User interface changes

The Media Library field widget will receive new functionality, a new button, and a couple of new associated modal dialogs/forms.

API changes

TBD, but probably none since Media Library exposes no APIs.

Data model changes

TBD, but probably none.

Problem/Motivation

As part of #2999721: [META] Deprecate the legacy include files , deprecate drupal_set_time_limit()

Proposed resolution

Create a new Drupal\Core\Php class that will be used to interact with the PHP environment. To be used also in #2566619: Deprecate drupal_http_header_attributes() in order to store the PHP version constants.

Remaining tasks

None.

User interface changes

None.

API changes

New class Drupal\Core\Php.

Data model changes

Node.

Problem:

Image links have default browser focus style. On firefox this is expecially weak, a 1px black dotted outline up against an image which often has a dark background.

Solution:

normalize the browser inconsistency, re-use the green focus outline style used by form elements

When adding an external link to a menu, dots in query parameter names are converted to underscores, even though dots are allowed in query parameter names. This seems to be because Symfony uses parse_str() to convert parameters to PHP safe variable names. See https://github.com/symfony/symfony/issues/25541

To reproduce:
Spin up a new site
Add an external link to the main menu (https://www.drupal.org?first.name=Aaron&last.name=Wolfe)
The url in the menu linkshould be https://www.drupal.org?first.name=Aaron&last.name=Wolfe
Instead, the menu item links to https://www.drupal.org?first_name=Aaron&last_name=Wolfe

This also happens with redirects, and I imagine any other place that prepares URLs with query strings.

Umami theme does not have a favicon. Let's create one for it.

Previuosly discussed at https://github.com/lauriii/umami/issues/109

Problem/Motivation

I have set up the Umami demo on my local machine and on simplytest.me.

The order of articles/recipes on the home page is inconsistent.

Local:

Simplytest.me

This is because all the recipes/articles all have the same creation time, so the sort is undefined.

This in no ways impacts Umami when used as a demo, but does make it more difficult to A/B test changes, especially if we start using BackStop or similar to check for regressions.

Proposed resolution

Add creation dates to the content – either fixed or relative to the install date.

This warning appears when I try to update Drupal from version 8.5.6 to 8.6.0

Warning: Invalid argument supplied for foreach() in Drupal\Core\Template\Attribute->__construct() (line 81 of core/lib/Drupal/Core/Template/Attribute.php).

http://prntscr.com/ks3nzn

the update goes on and it seems like no errors have been noticed.
but what it is and why it happens - is alarming.

We are trying to determinate the causes of this issue.

In case you need an urgent fix. See #29

Hi,
I upgraded four different sites to Drupal 8.6. They all are Thunder installs. Then I updated them to Thunder 2.24 and on all sites I'm getting the following error:

  Warning: Illegal string offset 'value' in Drupal\views\Plugin\views\area\Text->preQuery() (Zeile 50 in .../core/modules/views/src/Plugin/views/area/Text.php)
  #0 .../core/includes/bootstrap.inc(584): _drupal_error_handler_real(2, 'Illegal string ...', '/home/www/doc/3...', 50, Array)
  #1 .../core/modules/views/src/Plugin/views/area/Text.php(50): _drupal_error_handler(2, 'Illegal string ...', '/home/www/doc/3...', 50, Array)
  #2 .../core/modules/views/src/ViewExecutable.php(1011): Drupal\views\Plugin\views\area\Text->preQuery()
  #3 .../core/modules/views/src/ViewExecutable.php(1233): Drupal\views\ViewExecutable->_preQuery()
  #4 .../core/modules/views/src/Plugin/views/display/PathPluginBase.php(390): Drupal\views\ViewExecutable->build()
  #5 .../core/modules/views/src/Plugin/views/display/Page.php(180): Drupal\views\Plugin\views\display\PathPluginBase->execute()
  #6 .../core/modules/views/src/ViewExecutable.php(1630): Drupal\views\Plugin\views\display\Page->execute()
  #7 .../core/modules/views/src/Element/View.php(77): Drupal\views\ViewExecutable->executeDisplay('page', Array)
  #8 [internal function]: Drupal\views\Element\View::preRenderViewElement(Array)
  #9 .../core/lib/Drupal/Core/Render/Renderer.php(378): call_user_func(Array, Array)
  #10 .../core/lib/Drupal/Core/Render/Renderer.php(195): Drupal\Core\Render\Renderer->doRender(Array, false)
  #11 .../core/lib/Drupal/Core/Render/MainContent/HtmlRenderer.php(226): Drupal\Core\Render\Renderer->render(Array, false)
  #12 .../core/lib/Drupal/Core/Render/Renderer.php(582): Drupal\Core\Render\MainContent\HtmlRenderer->Drupal\Core\Render\MainContent\{closure}()
  #13 .../core/lib/Drupal/Core/Render/MainContent/HtmlRenderer.php(227): Drupal\Core\Render\Renderer->executeInRenderContext(Object(Drupal\Core\Render\RenderContext), Object(Closure))
  #14 .../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))
  #15 .../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))
  #16 [internal function]: Drupal\Core\EventSubscriber\MainContentViewSubscriber->onViewRenderArray(Object(Symfony\Component\HttpKernel\Event\GetResponseForControllerResultEvent), 'kernel.view', Object(Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher))
  #17 .../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))
  #18 .../vendor/symfony/http-kernel/HttpKernel.php(156): Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher->dispatch('kernel.view', Object(Symfony\Component\HttpKernel\Event\GetResponseForControllerResultEvent))
  #19 .../vendor/symfony/http-kernel/HttpKernel.php(68): Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object(Symfony\Component\HttpFoundation\Request), 1)
  #20 .../core/lib/Drupal/Core/StackMiddleware/Session.php(57): Symfony\Component\HttpKernel\HttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
  #21 .../core/lib/Drupal/Core/StackMiddleware/KernelPreHandle.php(47): Drupal\Core\StackMiddleware\Session->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
  #22 .../core/modules/page_cache/src/StackMiddleware/PageCache.php(99): Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
  #23 .../core/modules/page_cache/src/StackMiddleware/PageCache.php(78): Drupal\page_cache\StackMiddleware\PageCache->pass(Object(Symfony\Component\HttpFoundation\Request), 1, true)
  #24 .../core/lib/Drupal/Core/StackMiddleware/ReverseProxyMiddleware.php(47): Drupal\page_cache\StackMiddleware\PageCache->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
  #25 .../core/lib/Drupal/Core/StackMiddleware/NegotiationMiddleware.php(52): Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
  #26 .../vendor/stack/builder/src/Stack/StackedHttpKernel.php(23): Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
  #27 .../core/lib/Drupal/Core/DrupalKernel.php(665): Stack\StackedHttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
  #28 .../index.php(19): Drupal\Core\DrupalKernel->handle(Object(Symfony\Component\HttpFoundation\Request))
  #29 {main}.

Problem/Motivation

Followup to #2779647: Add a workflow component, ui module, and implement it in content moderation.

In #2779647-48: Add a workflow component, ui module, and implement it in content moderation bojanz:

Why store the workflow ID inside the bundle info, and bless it as the "one true workflow"? Why not simply have a state_item field type that holds the state, and references the workflow? It would be convenient, and more natural when allowing multiple workflows.
This also makes sense when formatting the state, we currently store only the state ID, but will need to show the state label in various places. There's also a use case for a formatter that renders transition buttons (Jira-style), which would benefit from a field type.

This issue is proposing adding a new FieldType plugin which could be added to any entity which would reference a workflow and store the current state the content is at. The plugin would have formatters and widgets to allow users that can edit the content to transition the state. With pluggable workflow types, this could be used for things beyond moderation.

Right now content_moderation doesn't use a field type. In #2725533-67: Add experimental content_moderation module, concerns were raised that storing the state of content in a field would have ramifications for installing and uninstalling content_moderation as an experimental module. Thus a computed field is used instead, with a seperate entity type for storage. Other issues were raised about the usability of creating a field on an entity vs checking a box on a workflow edit screen.

• If a field type is introduce, would content_moderation have to use it?
• Could it be useful by itself or is there something else which could make use of it in core?
• Does it belong in contrib instead?

Proposed resolution

Unknown.

Remaining tasks

Define and narrow the scope of this issue until it's clear what needs to be done.

User interface changes

Unknown.

API changes

Unknown.

Data model changes

Unknown.

We've run into an issue where we are getting an error on a link field:

Error: Unsupported operand types in /core/modules/link/src/Plugin/Field/FieldFormatter/LinkFormatter.php on line 245

I don't know if it's possible to reproduce this error with just core. The error seems to be coming from a translation issue in Paragraphs where the "options" property isn't getting set right. This patch is a work-around to that but it's just checking that $options is an array and making it one if it's not so it won't hurt anything to have it in there as a failsafe.

On one of our current projects we have a view with some exposed filters and ajax enabled that is called inside a drupal modal window.
The exposed filters work while opening the modal for the first time - on the second call the it breaks and nothing happens due to javascript problems.

The issue was already described in #1809958 - i also get the Cannot read property 'top' of null ajax_view.js error, caused by a no longer existing class name (views DOM ID) of the view.

Attached you find a patch solving the issue.

WSOD after upgrading from 8.5.7 to 8.6.0.

Here's php and nginx log:

php | [07-Sep-2018 12:08:59] WARNING: [pool www] child 68 said into stderr: "NOTICE: PHP message: Uncaught PHP Exception Drupal\Core\Database\DatabaseExceptionWrapper: "SQLSTATE[42S22]: Column not found: 1054 Unknown column 'block_content_field_data.reusable' in 'where clause': SELECT base_table.revision_id AS revision_id, base_table.id AS id"
php | [07-Sep-2018 12:08:59] WARNING: [pool www] child 68 said into stderr: "FROM"
php | [07-Sep-2018 12:08:59] WARNING: [pool www] child 68 said into stderr: "{block_content} base_table"
nginx | 2018/09/07 12:08:59 [error] 24#24: *507 FastCGI sent in stderr: "PHP message: Uncaught PHP Exception Drupal\Core\Database\DatabaseExceptionWrapper: "SQLSTATE[42S22]: Column not found: 1054 Unknown column 'block_content_field_data.reusable' in 'where clause': SELECT base_table.revision_id AS revision_id, base_table.id AS id
nginx | FROM
nginx | {block_content} base_table
nginx | INNER JOIN {block_content_field_data} block_content_field_data ON block_content_field_data.id = base_table.id
nginx | WHERE (block_content_field_data.reusable IN (:db_condition_placeholder_0)) AND (block_content_field_data.default_langcode IN (:db_condition_placeholder_1)); Array
nginx | (
nginx |     [:db_condition_placeholder_0] => 1
nginx |     [:db_condition_placeholder_1] => 1
nginx | )
nginx | " at /var/www/html/web/core/lib/Drupal/Core/Database/Connection.php line 686" while reading response header from upstream, client: 172.18.0.6, server: drupal, request: "GET / HTTP/1.1", upstream: "fastcgi://172.18.0.4:9000", host: "EXAMPLE.COM"
nginx | 172.18.0.6 - - [07/Sep/2018:12:08:59 +0000] "GET / HTTP/1.1" 500 79 "-""Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/68.0.3440.106 Safari/537.36"
php | [07-Sep-2018 12:08:59] WARNING: [pool www] child 68 said into stderr: "INNER JOIN {block_content_field_data} block_content_field_data ON block_content_field_data.id = base_table.id"
php | [07-Sep-2018 12:08:59] WARNING: [pool www] child 68 said into stderr: "WHERE (block_content_field_data.reusable IN (:db_condition_placeholder_0)) AND (block_content_field_data.default_langcode IN (:db_condition_placeholder_1)); Array"
php | [07-Sep-2018 12:08:59] WARNING: [pool www] child 68 said into stderr: "("
php | [07-Sep-2018 12:08:59] WARNING: [pool www] child 68 said into stderr: "    [:db_condition_placeholder_0] => 1"
php | [07-Sep-2018 12:08:59] WARNING: [pool www] child 68 said into stderr: "    [:db_condition_placeholder_1] => 1"
php | [07-Sep-2018 12:08:59] WARNING: [pool www] child 68 said into stderr: ")"
php | [07-Sep-2018 12:08:59] WARNING: [pool www] child 68 said into stderr: "" at /var/www/html/web/core/lib/Drupal/Core/Database/Connection.php line 686"
php | 172.18.0.7 -  07/Sep/2018:12:08:59 +0000 "GET /index.php" 500

Problem/Motivation

Images/files uploaded to a file/image fields on entities with multiple revisions are never deleted, even when the entity is deleted. Because the file usage counts for the revisions is never released.

Steps to reproduce:

1. create an article node with an image A uploaded to its image field
2. verify that the uploaded file A has its status column in the file_managed table set to 1,
   and it has 1 usage in the file_usage table
3. edit the node, check the "Create new revision" checkbox, remove the original image A and upload a new image B, save
4. verify that the uploaded file B has its status column in the file_managed table set to 1,
   and it has 1 usage in the file_usage table. Verify that the rows for file A are unchanged in both tables.
5. delete the article
6. verify that the uploaded file B has its status column in the file_managed table set to 0, and it has no row anymore in the file_usage table
7. • Expected result: file A has its status column in the file_managed table set to 0, and it has no row anymore in the file_usage table
   • Actual result: file A has its status column in the file_managed table still set to 1, and it still has n1 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. verify that uploaded file B is now removed (because usage = 0)
10. • expected result: the uploaded file A is still present (because usage > 0)
    • actual result: the uploaded file A is absent (because usage = 0)

Proposed resolution

TBD, see #126 for an summary of comments #1–#125.

Remaining tasks

TBD

User interface changes

None.

API changes

TBD

Data model changes

TBD