Problem/Motivation

Migrating from a drupal 6 site and get this error:

[error] The internal path component 'https://example.com/publications.html' is external. You are not allowed to specify an external URL together with internal:/.''

Which is coming from MenuLinkParent because of the assumption that the parent link path is routeable through $url = Url::fromUserInput("/$parent_link_path");

Proposed resolution

Check for external and search for the link uri properties.

Remaining tasks

User interface changes

API changes

Data model changes

I have tested that code:

process:
    uri:
      plugin: file_copy
      reuse: true
      source:
        - source_file_path_remote
        - destination_file_path

In the transform method of file_copy process plugin the download process plugin is called when a source file is remote. So the file is downloaded ignoring the reuse option.

Since a user is an entity, it should be possible to have multiple user bundles. At first this idea looks very useless, because to differ between users we are using roles. But a role should just be there to give a certain user permissions. A user bundle would give us the oppertunity to create diffrent types of users, a possible usecase would be a premium user, with diffrent fields and view modes. It would be very easy to create multiple userforms for multiple users on-the-fly, wich would serve several usecases.

Problem/Motivation

First, a quick tip of the hat to a certain legendary core developer, who shall here remain nameless, for discovering this problem.

Migrate includes an EntityRevision destination, which can migrate data into specific revisions of entities. Because EntityRevision inherits from the EntityContentBase destination, it also supports migrating data into specific translations of specific revisions of entities.

However, there is a critical hole in that functionality: the migrated translation data is keyed only by revision ID, and not by langcode. This can potentially result in data loss -- one language's data being overwritten with data intended for another language. Uh-oh!

It also means that it is impossible to look up the source identifier by destination revision ID and language, since the langcode was not part of the destination identifier.

Proposed resolution

EntityRevision needs to allow migrated data to be keyed by langcode in addition to revision ID.

Remaining tasks

• Write a patch
• Review it
• Improve it
• Commit it
• Breathe a big fat sigh of relief

User interface changes

None.

API changes

Nothing user- or developer-facing.

Data model changes

Nothing user- or developer-facing.

Problem/Motivation

#2768651: Let TimestampItem (de)normalize to/from RFC3339 timestamps, not UNIX timestamps, for better DX fixed the normalization of "Time fields" aka the TimestampItem. But it did so by adding a normalizer for the @FieldType level. It could have been implemented just as well at the @DataType level, but this simply didn't cross anybody's mind AFAICT. At least it wasn't discussed on the issue. (And I was very active on it too, so my bad!)

IOW: not a normalizer with

use Drupal\Core\Field\Plugin\Field\FieldType\TimestampItem;
…
protected $supportedInterfaceOrClass = TimestampItem::class;

but with

\Drupal\Core\TypedData\Plugin\DataType\Timestamp
…
protected $supportedInterfaceOrClass = Timestamp::class;

The benefit is that the normalizers are then no longer format-specific: we'll need only one and it'll work for both the default normalization (serialization module: json + xml formats) and the HAL normalization (hal module: hal_json format). But also for contrib's jsonapi normalization/format!

Note: this will also fix #2870609: [PP-1] Core Date field is serialized as String instead of timestamp/long.

Proposed resolution

1. Add serializer.normalizer.timestamp
2. Add \Drupal\serialization\Normalizer\TimestampNormalizer
3. Deprecate \Drupal\serialization\Normalizer\TimestampItemNormalizer
4. Deprecate \Drupal\serialization\Normalizer\TimeStampItemNormalizerTrait
5. Deprecate \Drupal\hal\Normalizer\TimestampItemNormalizer
6. Deprecate serializer.normalizer.timestamp_item
7. Deprecate serializer.normalizer.timestamp_item.hal

See #72 for a clear overview of the patch.

Remaining tasks

None.

User interface changes

None.

API changes

1. @FieldType=timestamp: no changes!
2. @FieldType=datetime fields configured to store date + time:
   

   Before

   '2017-03-01T20:02:00'

   Note: timezone information is absent!

   After

   '2017-03-01T20:02:00+11:00'

   Note: the site's timezone is present! This is now a valid RFC3339

3. @FieldType=datetime fields configured to store date only:
   

   Before

   '2017-03-01T20:02:00'

   Note: time information is present despite this being a date-only field!

   After

   '2017-03-01'

   RFC3339 only covers combined date and time representations. For date-only representations, we need to use ISO 8601. There isn't a particular name for this date-only format, so we have to hardcode the format. See https://en.wikipedia.org/wiki/ISO_8601#Calendar_dates.
   

Data model changes

None.

Problem/Motivation

This is the implementation issue for #2732081: WI: Phase G2: Full-site preview with Workspace UI.

There is one dependency:
#2916781: Allow off-canvas dialog to be rendered at the top of the page

Should-have:
#2940677: Support prefers-reduced-motion in off-canvas dialog

Proposed resolution

Following the designs from https://marvelapp.com/2db8i71/screen/26360612, implement the Workspace list builder in a top dialog.

Remaining tasks

User interface changes

There are many changes to the Workspace UI which is experimental.
The concerning changes are those to off canvas CSS which is stable.

API changes

None

Data model changes

None

Problem/Motivation

We need to support migration of several different types of legacy reference fields to D8:

• Node and user reference, for both D6 and D7
• D7 taxonomy term reference fields
• D7 entity reference fields

Proposed resolution

Create a base class for cckfield plugins that handle all reference-type fields, since they tend to be more similar than they are different.

Remaining tasks

Write the patch, tests, docs. Let's pull ReferenceBase out of the patchzilla in #191, clean it up, and turn it into its own patch.

User interface changes

None.

API changes

None.

Problem/Motivation

The user interface standards for empty text in a table state:

Use Text pattern "No [things] available. Add [a thing]".
The "Add [a thing]" link is the same action as the Local action link on the same page.

As far as I can see, core not only uses this text pattern inconsistently, it also doesn't follow these guidelines.

Proposed resolution

As a first attempt at making this text consistent, I think we should attempt to update the first part of the text pattern: "No [things] available". The second part ("Add [a thing]") should be avoided for now because a) we're probably already going to break enough tests with this initial change, and b) there is already an attempt to solve this.

Remaining tasks

1. Identify and update all areas that don't follow the standards. Common patterns include "There are no [things] yet." and "No [things] are present yet." -- It's probably not vital that every case is covered, but I've grepped for these common patterns, as well as looking for occurrences of '#empty' in code (where a table is being themed), so I think that should be most of them.
2. Update the numerous tests this will probably break.
3. Resolve any edge-cases that may not fit within the guidelines. (listed in comment below for review/discussion)

User interface changes

Text changes to suit guidelines.

Is there an upgrade path planed or will users stand in the rain / stuck like in some past i18n upgrades? I'd like to know if there will be an automatic process or if everyone need to develop upgrades on his own.

It doesn't appear that there is a good way to handle the following scenario in a module:

1. Install a module.
2. In an update hook, add a brand-new entity type, in-lining the content entity type definition.
3. In a later update hook, add an additional field that depends on a new module. In the update hook, be sure to enable the new module before attempting to update the field definitions.
4. Try to deploy both update hooks at the same time.

It turns out that various methods throughout the entity system will reload the ContentEntityType and base field definitions from the class on disk, ignoring the definition passed in to installEntityType(). Since the on-disk definition includes the new field, and that field's module isn't enabled yet, the field definition throws an exception as the associated field type plugin can't be loaded.

The only workaround I've seen without core changes is to remove your old update hooks, and to do them all together in a new update hook. But, it's pretty confusing, especially for new developers who are just trying to add a field. From an API standpoint, it would be much better if any of the code used by \Drupal\Core\Entity\EntityDefinitionUpdateManagerInterface (particularly SqlContentEntityStorage) never reloaded entity definitions from disk and only relied on the passed-in objects.

When the javascript files are compiled from the *.es6.js files a comment is added to the top of the page. This is not a docblock and if phpcs checks the file it will always fail.

I have changed the comment block generation to create a standard docblock and also added @codingStandardsIgnoreFile to the top so it will not be checked by phpcs since this is a generated file.

Help texts are needed for user 1 edit page:

- "user/1/edit"

[removed old path and reference]

Suggested text (adapted from #4)

Be careful, you are editing the admin user. Changes made here could lock you out of your site completely.

I'm dealing with a strange issue on my site where somehow $_GET is being rewritten and the image derivative token itok is no longer present for my image derivative requests. I don't know exactly where it's being rewritten, but it's a huge bugbear to deal with. Unwilling to deal with the risk of having to keep image derivative token support disabled, I wrote this patch.

The patch retains the existing behaviour of checking $_GET[IMAGE_DERIVATIVE_TOKEN] first, and returning it if found. Failing that, it then parses request_uri(), extracts and parses the query string, and attempts to find a value for IMAGE_DERIVATIVE_TOKEN in that. As long as nobody's rewriting $_SERVER, we should be good.

Packaging this functionality into a nice API-friendly function means that the same logic can be reused by other modules that do their own custom image style delivery, such as Remote Stream Wrapper.

What are the steps required to reproduce the bug?

I have an entity/content type that has 3 file upload fields.

These are for 3 video formats (ogv, webm, mp4) I am hoping to render out to a element in my twig files.

By default it renders a label and title + link to the file.

I went to `/admin/structure/types/manage/video_object/display` to change the display options for the fields.

Changed each of them to display the URL to file.

Hit save, and receive this error.

The website encountered an unexpected error. Please try again later.</br></br><em class="placeholder">Drupal\Component\Plugin\Exception\ContextException</em>: Required contexts without a value: entity. in <em class="placeholder">Drupal\Core\Plugin\Context\ContextHandler-&gt;applyContextMapping()</em> (line <em class="placeholder">96</em> of <em class="placeholder">core/lib/Drupal/Core/Plugin/Context/ContextHandler.php</em>). <pre class="backtrace">Drupal\layout_builder\SectionComponent-&gt;getPlugin(Array) (Line: 74)
Drupal\layout_builder\Event\SectionComponentBuildRenderArrayEvent-&gt;__construct(Object, Array, 1) (Line: 99)
Drupal\layout_builder\SectionComponent-&gt;toRenderArray(Array, 1) (Line: 80)
Drupal\layout_builder\Section-&gt;toRenderArray(Array, 1) (Line: 195)
Drupal\layout_builder\Controller\LayoutBuilderController-&gt;buildAdministrativeSection(Object, 0) (Line: 96)
Drupal\layout_builder\Controller\LayoutBuilderController-&gt;layout(Object, )
call_user_func_array(Array, Array) (Line: 123)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber-&gt;Drupal\Core\EventSubscriber\{closure}() (Line: 582)
Drupal\Core\Render\Renderer-&gt;executeInRenderContext(Object, Object) (Line: 124)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber-&gt;wrapControllerExecutionInRenderContext(Array, Array) (Line: 97)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber-&gt;Drupal\Core\EventSubscriber\{closure}() (Line: 151)
Symfony\Component\HttpKernel\HttpKernel-&gt;handleRaw(Object, 1) (Line: 68)
Symfony\Component\HttpKernel\HttpKernel-&gt;handle(Object, 1, 1) (Line: 57)
Drupal\Core\StackMiddleware\Session-&gt;handle(Object, 1, 1) (Line: 47)
Drupal\Core\StackMiddleware\KernelPreHandle-&gt;handle(Object, 1, 1) (Line: 99)
Drupal\page_cache\StackMiddleware\PageCache-&gt;pass(Object, 1, 1) (Line: 78)
Drupal\page_cache\StackMiddleware\PageCache-&gt;handle(Object, 1, 1) (Line: 47)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware-&gt;handle(Object, 1, 1) (Line: 50)
Drupal\Core\StackMiddleware\NegotiationMiddleware-&gt;handle(Object, 1, 1) (Line: 23)
Stack\StackedHttpKernel-&gt;handle(Object, 1, 1) (Line: 664)
Drupal\Core\DrupalKernel-&gt;handle(Object) (Line: 19)
</pre>

What behavior were you expecting?

I was expecting to see a comfirmation message, and when viewing the node in the browser to see no label and to see just the URL to the file I need (so I can use that in my theming).

What happened instead?

As above, it gives me that error dump.

The LOG shows me this when I try to change the display layout modes again (I'm unable to change it back).

Type	php
Date	Tuesday, April 17, 2018 - 16:27
User	admin
Location	http://localhost/admin/structure/types/manage/video_object/display-layout/full
Referrer	http://localhost/admin/structure/types/manage/video_object/display/full
Message	Drupal\Component\Plugin\Exception\ContextException: Required contexts without a value: entity. in Drupal\Core\Plugin\Context\ContextHandler->applyContextMapping() (line 96 of /app/core/lib/Drupal/Core/Plugin/Context/ContextHandler.php).

The LOG shows me this when I try to view the node

Type	php
Date	Tuesday, April 17, 2018 - 16:44
User	admin
Location	http://localhost/node/4
Referrer	http://localhost/node/4/edit
Message	Drupal\Component\Plugin\Exception\ContextException: Required contexts without a value: entity. in Drupal\Core\Plugin\Context\ContextHandler->applyContextMapping() (line 96 of /app/core/lib/Drupal/Core/Plugin/Context/ContextHandler.php).

Problem/Motivation

The two choices at the bottom of the confirmation screen when canceling a user account are a button with the text "Cancel account" and a link with the text "Cancel." While the intention may be obvious to many people, it is also likely confusing to many.

This is true for both, cancelling a user account or mass cancelling several accounts.

Proposed resolution

Replace the "Cancel" label button with "Abort".

Remaining tasks

None.

User interface changes

On user cancel account confirmation form, the label "Cancel" of the cancelling operation button is replaced with "Abort".

API changes

None.

Data model changes

None.

This is a follow up from #2938194: Focus styles should meet accessibility guidelines in Umami theme
===
The main menu links are poor. The underline is a bit pale looking. What contrast is that? Also the focus style is only distinguished from the current page by colour alone. That's a level A failure so make it a major follow-up.
===

Problem/Motivation

This was raised as a review point in #2784921-135: Add Workspaces experimental module:

+++ b/core/modules/workspace/src/Entity/Workspace.php
@@ -0,0 +1,223 @@
+      ->setDefaultValueCallback('Drupal\workspace\Entity\Workspace::getCurrentUserId')
...
+  /**
+   * Default value callback for 'uid' base field definition.
+   *
+   * @see ::baseFieldDefinitions()
+   *
+   * @return int[]
+   *   An array containing the ID of the current user.
+   */
+  public static function getCurrentUserId() {
+    return [\Drupal::currentUser()->id()];
+  }

Node and Media also have this, this is the 3th occurance of this exact code + docblock in core, should we open a followup to figure out if it makes sens to move this to a common class, or a trait?

Proposed resolution

Add a EntityOwnerTrait, similar to EntityPublishedTrait.

Remaining tasks

Do it.

User interface changes

Nope.

API changes

Nope.

Data model changes

Nope.

Problem/Motivation

Follow up to #2949964: Add an EntityOwnerTrait to standardize the base field needed by EntityOwnerInterface.

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Problem/Motivation

Follow up to #2949964: Add an EntityOwnerTrait to standardize the base field needed by EntityOwnerInterface.

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Note: This is issue is part of #2721129: Workflow Initiative and is only meant for planning and governance sign-offs. Work will happen in child issues of this plan.

Target version for beta stability: Drupal 8.6

This phase will introduce the concept of workspaces through a new experimental module.

Content entities always belong to a workspace (there is one main exception, which is the user entity type). A workspace is a silo/container of content on a site. However, this phase mostly introduces the underlying concept with one single workspace available, without many supporting APIs around it (see later phases).

Implementation

• #2784921: Add Workspaces experimental module
• For more conceptual description of workspaces, along with full UI prototypes, see: #2732081: WI: Phase G2: Full-site preview with Workspace UI
• Further functionality (such as conflict management) will be done in: #2867707: WI: Phase H: Replication and conflict management

Required before beta release

Must-have

• #2958752: Discuss workspace content replication use cases
• #2949991: [PP-1] Add workspace UI in top dialog
• #2968850: Figure out use-cases for per-workspace permissions and provide them if needed

Should-have

• #2940677: Support prefers-reduced-motion in off-canvas dialog
• ?

Could-have

• ?

Sign-offs needed

Product manager

A product manager needs to sign-off on this plan because the concept of workspaces constitutes a significant addition to Drupal core.

Framework manager

A framework manager needs to sign-off on this plan as the above phases introduces very significant API additions.

Release manager

A release manager needs to sign off because the scope and impact of the work are significant for core.

Sub-system maintainers

The sub-system maintainers for the Entity API needs to sign-off on this plan as it significantly impacts the Entity API.

Sign-offs given

• Product manager - pending
• Framework manager - pending
• Release manager - pending
• Sub-system maintainers - pending