Problem/Motivation

• Symfony\Component\HttpKernel\HttpKernel::handleRaw() pushes $request onto the stack and Symfony\Component\HttpKernel\HttpKernel::finishRequest() pops it.
• DrupalKernel::preHandle() also pushes $request onto the stack, but there's no matching pop.
• As a result, at the conclusion of a subrequest, the stack still contains the subrequest. One consequence of this is that on a comment permalink page (e.g., /comment/1), drupalSettings.path.currentPath is 'node/1' instead of 'comment/1'. I don't know if there are other, more important, consequences.

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Problem/Motivation

In #2836224: Missing schema exception on latest 8.3.x when adding view via the UI, I tracked the issue down to this code in DisplayPluginBase::getPlugin():

    // Query plugins allow specifying a specific query class per base table.
    if ($type == 'query') {
      $views_data = Views::viewsData()->get($this->view->storage->get('base_table'));
      $name = isset($views_data['table']['base']['query_id']) ? $views_data['table']['base']['query_id'] : 'views_query';
    }
    else {
      $name = $options['type'];
    }

The problem here is that the query plugin is updated (in the linked issue, to search_api_query), but the actual view definition still contains the default query plugin ID of views_query.

Proposed resolution

Update the $options['type'] value to have the correct plugin ID.

Remaining tasks

User interface changes

API changes

Data model changes

Problem/Motivation

EditEntityFieldAccessCheck has a somewhat confusing name, especially now that the module has been renamed.

Proposed resolution

• Rename EditEntityFieldAccessCheck to QuickEditEntityFieldAccessCheck.

Remaining tasks

• Needs patch.
• Will conflict with #2222719: Use parameter matching via reflection for access checks instead of pulling variables from request attributes so it should wait on that.

API changes

• EditEntityFieldAccessCheck renamed to QuickEditEntityFieldAccessCheck.

Postponed until

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

Problem/Motivation

To provide a unified and 'app-like' experience we should override default browser styles for select boxes in the offcanvas tray as we have done in seven theme.

Proposed resolution

Style the selects to match the styling of similar elements in the tray like dropbuttons.

Remaining tasks

• style the selects
• test cross browser

User interface changes

Selects will be grey with white arrow and 2p corner radius in all browsers.

Before

After

API changes

None

Data model changes

None

Problem/Motivation

For Drupal 8.3, we want to ship with a library that allows displaying and selecting from a listing of previously-uploaded media.

Proposed resolution

Implement an MVP media library, based on the user stories and design from #2796001: [prototype] Create design for a Media Library.

Implementation happening so far at https://github.com/mortenson/media_library, will post patches later.

Remaining tasks

These are fairly high level, but in general I think we should:

1. Discuss what should be covered by the MVP (this is being done in #2796001: [prototype] Create design for a Media Library).
2. Develop a pattern for selecting entities in views (this doesn't have to be a form element/widget, just the logic that powers the MVP)
3. Develop a pattern for adding (uploading) new media, with a focus on the "image" bundle
4. Write CSS and JS required for the MVP to function
5. Ensure that the library works in a standalone page at /admin/content/media
6. Ensure that the library works in Field widgets
7. Ensure that the library works in WYSIWYG

User interface changes

This is a UI addition, so existing user interfaces should not be affected by this change.

API changes

We may be implementing new APIs for implementing Views-based entity selection, but we haven't decided how abstract we're going to get (see task #2 above).

Data model changes

None, the data model changes are being added in #2831274: Bring Media entity module to core as Media module.

Problem/Motivation

Follow-up to #2725533: Add experimental content_moderation module.

For content moderation, there are the following concepts:

- state - configuration entity for a moderation state
- transition - configuration entity for the (one way) from and to relationship between two states
- valid states - the states that are allowed on a particular entity bundle, stored as a third party setting

This means you need to have two different config entity types, several individual entities of those types, as well as bundle third party settings to figure out what the workflow is for a particular bundle entity.

It also results in some trickiness with things like ordering states/transitions - since each needs to store its own weight relative to the others. This is usually a sign that data shouldn't be in configuration entities but rather a single object.

Also I can see people wanting to use this system for workflow on users (account pending, e-mail validated, approved, blocked etc.), even though they wouldn't use forward revisions for that, or even necessarily revisions. However those states are extremely user-specific, and something like translation editorial review is never going to apply to account entities too. So not sure how useful the global states and transitions are conceptually.

Proposed resolution

Consider consolidating this information into one or two objects per-entity or per-bundle (or per entity with per bundle overrides).

So something like (excuse the invalid YAML). This isn't a proposal as such, just something for comparison.

states:
 - draft:
       label: draft
 - published:
        label: published
 - archived:
       label: archived
transitions:
  - draft_published:
       from: draft
       to: published

In chat @alexpott pointed out that http://symfony.com/blog/new-in-symfony-3-2-workflow-component exists, this has a concept of a single 'workflow' that contains all the information. Again not a proposal but something to compare against.

Current resolution

Adds a new experimental Workflows module that provides

• A workflow configuration entity type. This is where states and transitions are configured.
• The concept of workflow type plugins. This is how modules can leverage workflows and extend the information stored against a state or a transition. If there are no workflow type plugins the user can not create workflows because there is nothing to apply them to.
• Fluid API for workflow entities:
  

      $workflow = new Workflow(['id' => 'test', 'type' => 'test_type'], 'workflow');
      // By default states are ordered in the order added.
      $workflow
        ->addState('draft', 'Draft')
        ->addState('published', 'Published')
        ->addState('archived', 'Archived')
        ->addTransition('create_new_draft', 'Create new draft', ['draft', 'published], 'draft')
        ->addTransition('publish', 'Publish', ['draft', 'published'], 'published');

• A workflow creation UI. A user interface that can create, edit and delete workflows and their states and transitions.

Changes content moderation module by:

• Removing the state and transition configuration entities
• Changing the content moderation state content entity to record the workflow and state used.
• Adds a new workflow type to moderate content entities.
• Changes the permission names to include the workflow label
• Changes how workflows are added to bundles. Instead of arranging states and transitions on the bundle you just select a workflow.

Advantages

• Just makes sense. Arranging a workflow on each bundle is a repetitive task and states and transitions not belonging to a workflow entity means that in order to create a workflow in HEAD you have to load all sorts of things. This also means we can totally get around issues with duplicate state names.
• States are ordered on the workflow using table drag.
• Allows additional configuration on both the state and transition level
• Allows workflows to be applied to things other than content by contrib

Experimental module / release strategy

All the changes are in experimental code.

Remaining tasks

Review patch, make decisions, and create / find followups

Decisions:

• What should the workflow provided by the content moderation be called. At the moment it has the ID 'typical' and the label 'Typical workflow' changed to 'Editorial workflow' / editorial see #117
• Decide how much of the UI work to include here - created follow up #2830584: Review the workflow UI
• Should we continue to use the word "State" or use the more generic and common in workflow theory "Place"? Chose state since the arguments in #95 are compelling
• Should the new module by called "Workflow"? This clashes with a 8.x contrib module. Ee could use "Workflows" just to avoid the issue. We called the experimental module "Workflows"
• Should transitions have multiple from states? And should transitions have multiple from states? We implemented multiple from states and a single to state - see #107

Followups:

• #2830584: Review the workflow UI
• #2830735: Add possible but not existent transitions to the state edit form
• #2830736: Add indication of where workflow is being used to workflow edit form
• #2830737: Add link to workflow on bundle edit screen
• #2830739: Discuss whether content moderations actions should be on the state or transition level
• #2830740: Allow workflow types to lock certain changes to workflows once things are in use
• #2830741: Decide if the workflow type should be able to rename the labels "State/Place" and "Transition" so it can call them what they like
• #2830581: Fix ContentModeration workflow type to calculate correct dependencies
• #2835545: Provide Workflow FieldType, allow multiple workflows per bundle

User interface changes

New UI for creating workflows - see #22 for a flavour.
Changed UI for attaching workflows to content entities.

API changes

New workflow configuration entity
New workflow type plugin type
Removed ModerationState config entity
Removed ModerationTransition config entity

Data model changes

The content moderation state content entity no longer references a ModerationState config entity by references a Workflow config entity and records a state ID.

Problem/Motivation

The current status report is informative but not highlighting the crucial information really well. A lot of key information gets lost in the rows of green, blue and other color indicators. From a design point of view this page could also be a lot more appealing.

Proposed resolution

We are looking for designers to pick up this page and propose a view alternatives. Yoroy and Bojhan will be available to guide any designers.

Remaining tasks

• Add default styles for counters and general information #400 to system. Would be nice to get a designers perspective on this.
• CSS clean-up (BEM conversion / remove class nesting)

User interface changes

The information will be separated in 3 regions:

Error counter at top

3 items with error/warning/checked if there are errors. Link to each item list.
Re-count of items checked if no errors. Link to item list.

General system information table

The aim for this region is to show the basic
info about the development environment.

• Drupal version
• Last cron run
• Button to run cron
• Web server info
• PHP info
• Database info

List of reports

• Separated lists by Errors, Warnings and Checked.
• The title for each list should be an anchor for each
  counter in the top regiom.
• On mobile, thedescription is collapsed by default.

Designs

Status page (no errors)

Status page (with errors)

Status page (mobile)

Status page in Bartik

Proposal.

API changes

None

Data model changes

None

Problem/Motivation

Discovered in #2718253: Upload progress w/PHP 7 (& recommendation on status report)

We should never recommend people enable APC in Drupal 8 because we only support PHP 5.5 and up which come with opcache by default and we recommend that that is enabled. Additionally, file_progress_implementation() can return APC on PHP7 and this is just not possible.

Proposed resolution

Remove recommendations from file_requirements().

Remaining tasks

User interface changes

Changes to what we recommend.

API changes

file_progress_implementation() can not return 'apc' on PHP7

Data model changes

Problem/Motivation

When adding a datetime exposed filter I cannot simply select a date - I have to manually enter a date which is very bad UX.

Proposed resolution

Use a form element with '#type' => 'datetime' so it's easy for users to select the date.

Remaining tasks

None.

User interface changes

Exposed date filters will have input[type=date], and will leverage HTML5 handling if supported by the browser, or fall back to the polyfill if it doesn't.

API changes

None.

Data model changes

None.

Problem/Motivation

See: https://www.drupal.org/pift-ci-job/523337

Note the time of the test run. It's displayed to me as:
Created November 5, 2016 - 04:02. jibran added test. Updated November 5, 2016 - 05:00.

My timezone is CST, which would make this 2:00a to 3:00a PST. When we add one day, as the test does, that's the official time when DST ended in the US.

From @jhedstrom:

the timezone for that test is set to `America/Vancouver`, so if they have daylight savings time, and the test was running at exactly the crossover, that could explain a failure...

This might be a bug that could occur only under rare circumstances, but whatever bug introduces test failures in HEAD at the least, and who knows what else could happen if there is an actual DST bug. So splitting the difference for issue priority at major, at least until we determine an underlying cause and whether it's related to DST or not.

Proposed resolution

Investigate the failure and determine whether there is a reproducible bug related to DST, or if there is a different low-frequency random fail.

Remaining tasks

TBD

User interface changes

N/A

API changes

TBD

Data model changes

Problem/Motivation

PHP 5.5 will be quite soon out of security support, see https://secure.php.net/supported-versions.php

Proposed resolution

Warn users of php 5.5, so we can remove support for it in a later release.

Remaining tasks

User interface changes

API changes

Data model changes

The documentation for the Date render element is not valid. #default_value should be provided as a Y-m-d string instead of a keyed array as the documentation says.

Currently is says:

/**
 * Provides a form element for date selection.
 *
 * Properties:
 * - #default_value: An array with the keys: 'year', 'month', and 'day'.
 *   Defaults to the current date if no value is supplied.
 *
 * @code
 * $form['expiration'] = array(
 *   '#type' => 'date',
 *   '#title' => $this->t('Content expiration'),
 *   '#default_value' => array('year' => 2020, 'month' => 2, 'day' => 15,)
 * );
 * @endcode
 *
 * @FormElement("date")
 */

which should be

/**
 * Provides a form element for date selection.
 *
 * Properties:
 * - #default_value: A string representing the date formatted as Y-m-d.
 *   Defaults to the current date if no value is supplied.
 *
 * @code
 * $form['expiration'] = array(
 *   '#type' => 'date',
 *   '#title' => $this->t('Content expiration'),
 *   '#default_value' => '2020-02-15',
 * );
 * @endcode
 *
 * @FormElement("date")
 */

The default_value documentation could be improved. In the attached patch I've used "A string formatted as Y-m-d". But for someone not familiar with php date this might not be sufficient?

Hello,

I am looking for a way to reset the uuid of the configuration of a site in order to be able to duplicate/ clone a site and have different uuid.

The goal is to be able to export the DB from site-A and create site-B be importing the DB (and of course setup all the other parts like the files, etc.), and to have different UUIDs for site-A and site-B. I prefer duplicating the DB allows to also take the content (node, taxonomy, etc.), and do very quick site setups and testing.

I currently do this without too much trouble to have site-A "Dev", site-A "staging" and site-A "production", with all entities and configurations having the same uuid, excellent.

The goal is to use site-A at some point of its development (like a profile), and create site-B, but site-B should have different UUIDs.

The way of doing this I can think of are:
1) install a new out of the box site (site-B), it will have different UUIDs, export site-A configuration into yml files without UUIDs, import these configuration files to site-B. I have not tested this but I guess it could work. But I am a bit worried about the content of site-A getting messed-up in site-B. Has anyone tried this?

2) copy site-A, re-generate all UUIDs by for example replacing them in the exported DB (mysqldump) before re-importing the DB to site-B. HAs anyone tried this?

3) any other idea on how to fully clone a site and have different UUIDs?

I am also a bit concerned about the default_config_hash key in system.site.yml and wonder what it is used for and if it can be changed without impacting the configuration or content, and if there is a relationship between that key and the UUIDs?

Best,
Pascal

Problem/Motivation

When you want to write an entity which provides revision support you need, for example, take care about the revision form functionality on entity forms yourself.

See https://github.com/fago/entity/pull/27

Proposed resolution

Resolve that, so there is one less thing to do.

Remaining tasks

User interface changes

API changes

Data model changes

I want to create a block listing authors and a counter of their published content, but I can't get this block to work as long as I don't create a page and a url for the view.

Steps to reproduce:

• Create a view listing content, defining a block only and no page
• Add a relationship: author
• Add a contextual filter: (author) user: name
• Save the view.
• The preview below disappears
• The logs show this message:

Location	https://dme0h.ply.st/admin/structure/views/view/artauth/preview/block_1?_wrapper_format=drupal_ajax
Referral 	https://dme0h.ply.st/admin/structure/views/view/artauth
Message 	InvalidArgumentException: You cannot create a URL to a display without routes. in Drupal\views\ViewExecutable->getUrl() (line 1806 of /home/dme0h/www/core/modules/views/src/ViewExecutable.php).
Severity 	Error

• Adding the block to the primary menu results in a blank page with this message "The website encountered an unexpected error. Please try again later. "

Adding a page to the view and defining a path for it solves the problem and allows to display the block.

Problem/Motivation

Out of the box set a node to 'Full HTML' as the text format and include an <hr /> tag. Edit the node using edit in place (quick edit). When you save in edit in place mode the <hr /> tag is stripped.

This happens because the edit in place mode always uses the 'Basic HTML' text format regardless of the text format of the node. Out of the box edit in place contains the 'Limit HTML tags' filter - so this issue strips every html tag that is not allowed in the 'Basic HTML' text format.

Proposed resolution

There is a simple workaround, which makes this problem minor - which is to remove the 'Limit Allowed HTML tags' filter from the Basic HTML setting - that is not ideal, though, for obvious reasons.

Solution: get the edit in place module to pick up the text format of the node it is editing.

(I imagine this must already be an issue - but I searched the queue and couldn't find it - so if this is a duplicate, my apologies...)

Problem/Motivation

https://www.drupal.org/pift-ci-job/537928
https://www.drupal.org/pift-ci-job/535605
https://www.drupal.org/pift-ci-job/538079

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

In Drupal 7, the Fulah (Fulfulde) African language is available for adding as a Regionalization option (admin/config/regional/language/add).

Drupal 8 does not list Fulah on the same path admin/config/regional/language/add.

Please reinstate. Fulah (Fulfulde or Fulani) is spoken in more than 20 African countries by millions of peoples. UNESCO lists it as one of the continent most widespread contact languages.

Suggested links:

- webPulaaku (http:www.webpulaaku.net)
- Fulbe and Africa (http://www.webguinee.net/blogguinee/2015/01/fulbe-africa/)

The people (Fulbe) and the language (Pular/Fulfulde -indigenous name) aka Fulah (foreign name) will feature prominently in the Semantic Africa project (http://www.afrixml.net), which is based on Drupal. The efforts will build on the Core Taxonomy module and on contributed modules (Metatag, Schemaorg, Linked Data, OSF), etc. Indeed, the Open Semantic Framework middleware is expected to complement Drupal efficiently in the development of the project.

Thanks

Tierno Bah

Problem/Motivation

file_unmanaged_copy() has an @todo saying
@todo Replace drupal_set_message() calls with exceptions instead.
added a long time ago by #517814: File API Stream Wrapper Conversion

Proposed resolution

Replace all instances of drupal_set_message() in file_unmanaged_copy() with throwing Exceptions.
Ensure that Exceptions are thrown after corresponding watchdog() calls, so that logging still happens.

Remaining tasks

Refactor all file_unmanaged_* functions into the file_handler.unmanaged handler service.

User interface changes

None.

API changes

Introduces a new service, file_handler.unmanaged, and an accompanying interface. This service has (thus far) only one method, copy(), which does exactly what file_unmanaged_copy() does, except it throws exceptions. file_unmanaged_copy() becomes a deprecated wrapper around this method, and if it throws any exceptions, they will be caught and logged, and the function will return FALSE.

In other words, as far as calling code is concerned, file_unmanaged_copy() will behave exactly the same way as it did before. Perfect backwards compatibility. Bam!

Related Issues

• @todo was introduced by #517814: File API Stream Wrapper Conversion

It turns out that when you render Seven's entity-add-list.html.twig template, you cannot set additional attributes on the bundle names, because Seven does this in the template:

    {% for bundle in bundles %}<li class="clearfix"><a href="{{ bundle.add_link.url }}"><span class="label">{{ bundle.label }}</span><div class="description">{{ bundle.description }}</div></a></li>
    {% endfor %}

The problem is Seven unpacking the bundle.add_link variable, which *should* be unnecessary because it implements RenderableInterface. But anyhoo, because it unpacks the variable, any attributes set on the link's URL object are thrown right out the window. We need something like this:

    {% for bundle in bundles %}<li class="clearfix"><a{{ create_attribute(bundle.add_link.url.options.attributes) }} href="{{ bundle.add_link.url }}"><span class="label">{{ bundle.label }}</span><div class="description">{{ bundle.description }}</div></a></li>
    {% endfor %}

Special thanks to Wim Leers for heroically tracing this and suggesting the fix.