Problem/Motivation

As a follow up of #2831274: Bring Media entity module to core as Media module we will need to provide migrate integration for the media entity.

Migration destinations do not block the media entity API or its file and image formats from being added to core, but will be needed before the full module (and any dependencies) are marked non-hidden and non-experimental.

Proposed resolution

• Add a media entity destination plugin to be able to migrate stuff into media entities.
• Provide example migration to migrate files into media entities. This would use the existing file entities, but then wrap them into media entities.
• Provide migrations/update paths for file/image field configurations. They should become entity reference fields that reference the migrated media entities. #2885002: Provide an optional migration path for sites using files/images to media entities
• Provide a migration example for an actual file field
• Provide a migration example for an actual image field
• Provide a migration example for the file/image field display configuration.
• ... more?

Remaining tasks

User interface changes

API changes

Data model changes

Problem/Motivation

Like commerce's order,It use 'any' type data to store object:Adjustment, But the TypedDataNormalizer just return the Adjustment object, It cause it can't be encode, So it can't be serializad

First(laravel): Let's look at laravel's serialization
laravel's serialization has two steps:

1. toArray() ====> corresponds to druapl's normalize
2. toJson() ====> corresponds to drupal's encode

laravel's toArray() is recursive，it will recurs to check whether the child value is Arrayable
https://github.com/illuminate/database/blob/5.5/Eloquent/Model.php#L918
https://github.com/illuminate/database/blob/5.5/Eloquent/Concerns/HasAtt...

Second(symfony):
https://github.com/symfony/serializer/blob/3.2/Serializer.php#L138

    public function normalize($data, $format = null, array $context = array())
    {
        // If a normalizer supports the given data, use it
        if ($normalizer = $this->getNormalizer($data, $format)) {
            return $normalizer->normalize($data, $format, $context);
        }
        if (null === $data || is_scalar($data)) {
            return $data;
        }
        if (is_array($data) || $data instanceof \Traversable) {
            $normalized = array();
            foreach ($data as $key => $val) {
                $normalized[$key] = $this->normalize($val, $format, $context);
            }
            return $normalized;
        }
        if (is_object($data)) {
            if (!$this->normalizers) {
                throw new LogicException('You must register at least one normalizer to be able to normalize objects.');
            }
            throw new UnexpectedValueException(sprintf('Could not normalize object of type %s, no supporting normalizer found.', get_class($data)));
        }
        throw new UnexpectedValueException(sprintf('An unexpected value could not be normalized: %s', var_export($data, true)));
    }

symfony's Serializer->normalize() has the ability to recursive normalize object and array too

Both laravel and symfony has the ability to recursive normalize object or array

Then(Drupal):
Let's see TypedDataNormalizer used by normalizing 'any' type data
core/modules/serialization/src/Normalizer/TypedDataNormalizer.php#n21

  public function normalize($object, $format = NULL, array $context = []) {
    return $object->getValue();
  }

We can see TypedDataNormalizer Just return the value
Drupal use symfony's serializer, But it dosn't follow or take full advantage of the symfony's serializer's design

Proposed resolution

1. make TypedDataNormalizer flow and use symfony's serialize->normalize()'s design. (solve here)
2. Map type data has similar trouble too: But Map have other more base problem, It can't be normalized when it has no propertydefinition , But if TypedDataNormalizer's problem is solved, Two kind of https://www.drupal.org/node/2895532's the patch(two kind of controversial solution) will work good with no change needed

Remaining tasks

User interface changes

API changes

Data model changes

Follow-up to #2876085: Before upgrading, audit for potential ID conflicts

Problem/Motivation

In #2876085-152: Before upgrading, audit for potential ID conflicts, it was suggested we break up the form into smaller parts. Let's do that. Also, make child issues for any other cleanup or improvements as this is a substantial change itself.

Proposed resolution

Make a base form, MigrateUpgradeFormBase
Make new forms for:

• Overview - /upgrade
• Incremental - /upgrade/incremental
• Credential - /upgrade/credentails
• IdConflict - /upgrade/idconflict
• Review - /upgrade/review

Use a private store to share data between forms
Use an event subscriber to handle redirection logic

Remaining tasks

Manual testing
Review

User interface changes

None.

API changes

None.

Data model changes

None.

Receiving this error when clicking a button that submits a form in an ajax modal.

Proposed solution:

Adding this.url = ''; to line 402 in core/misc/ajax.js

Not sure if this will cause an issue further down the line but it stops the error from appearing in my console.

Attached are errors and code locations.

Problem/Motivation

Many software programs (including CMS software such as WordPress) support automatic updates, in which the site applies an update on its own with no intervention from the site administrator.

We need to continue exploring this for Drupal. Here are some pros and cons identified in this and related feature requests:

Pros

• Userswantit. Some have found that it is worth leaving the platform for easier/cheaper to maintain alternatives.
• It would be particularly useful for situations like SA-CORE-2014-005/PSA-2014-003 (very low-risk patch for a very critical security issue where speed is of the essence).
• It would go a long way to improving the overall security of Drupal installations across the internet: the reality is many sites just go un-updated under the current manual processes. As a platform powering better than a million websites, it is the "good netizen" thing to do -- every site that doesn't get compromised translates to many outdated browsers not getting exploited, and personal computers not getting hacked.
• Given the larger codebase and use of external libraries in Drupal 8, manually applying fixes is likely to become more frequent and on a less predictable schedule, making automatic updates even more valuable.
• Even if a less conservative strategy is selected regarding the scope of code changes pushed automatically (ie, force sites to take feature releases when not at security release - 1), broken sites are much easier and cheaper to fix with confidence than compromised sites. Accepting some risk of breakage is therefore the preferred model of a segment of the userbase (additional attribution). Organizations running sites that secure billing and other confidential information may similarly find this risk model preferable.
• It would not be forced on anybody. It would only empower site owners to choose whether it is the right solution for them. It could be built as a highly isolated module that can be disabled completely, which would make an exploit of the automatic update system itself very implausible on sites that don't think it is right for them.
• Without some form of automated security update solution in place, I fear I may never be allowed to take a holiday again...(attr.)

Cons

• Implementing automatic updates means substantial new code of nontrivial complexity. There is no way to guarantee that the new code will not itself have security vulnerabilities. From the original issue summary, "The risks of introducing automatic updates to Drupal are that we don't want to open up new security holes in the process."
  • Counter-argument: But can anyone argue that the net effect of the advent of automatic updates in other software has been decreased security? Automatic updates have been done, and done successfully, in many ways by many vendors with positive results.
• A case is repeatedlymade that it would require the site to be able to write to its own executable areas, and that this is by definition less secure.
  • Counter-argument 1: A number of implementation strategies have been suggested that would not require the site to directly write to its own executable areas. In one, favorable hosting environments would install purpose-built software running in a separate process from the site itself to verify and perform the update. For generic hosting environments that offer authenticated (s)ftp/ssh as the means to change code, site owners could choose to provide the update infrastructure with valid credentials ahead of time; these could be retained in an encrypted database whose private key is offline 99% of the time (attribution). Credentials would then be supplied back to the site (an encrypted channel may be achievable for this purpose through native php code) and kept in memory during an update event.
  • For sites that have been configured such that they can write to their own executable areas, "automatic security upgrades on systems with an already weakened security is a good idea. One might argue that every bit helps." (attribution)
• It is a feature primarily targeting users with a low technical level, and they are not going to turn it on anyway (attribution).
  • Counter-argument: If you're smart enough to build the rest of the site, then you can make the decision that is right for you whether or not you wish to turn it on. If your site was built for you, the firm who did so is smart enough to turn it on when continuing support is not part of the agreement -- an option they don't currently even have. These assertions won't hold true all the time for all people, but that's not a reason for Drupal not to offer this feature.
• "Assuming that the low technical level users do enable the feature, the very first time that using it "breaks" their site, either by forcing it into maintenance mode or by performing an update which causes issues with some functionality in the site, they will either start to resent the Drupal project or turn the auto-update functionality off." (attribution)
  • Counter-argument 1: The testing and review in place is sufficient that even if a less-conservative strategy is selected regarding the scope of code changes pushed automatically (ie, force sites to take feature releases when not at security release - 1), it will at worst break some sites and cause resentment for some people, and even that's not likely to be a regular occurrence. In the current state of affairs, all sites have a right to resent Drupal equally for its regular need to be manually updated, sometimes at inhumane hours of the day.
  • Counter-argument 2: Fixes to security vulnerabilities rarely require large-scale refactorings or other changes that pose a high risk of site breakage. The infamous example need not be named yet again. Drupal has an opportunity to decide to do better than WordPress and use the automatic update facility to backport and distribute critical fixes. Combined with the testing and review mechanisms in place, site breakage could become a very minor concern.
• There are concerns that the infrastructure that is used for distributing updates to sites would become "the biggest, fattest target ever for hacking. Just hack your way to there and suddenly you can hack a million sites in one go!" (Attribution)
  • Counter-argument: This risk can be designed away by a good implementation. An implementation that merely serves up signed packages, probably Phar archives, that were signed using a private key on an airgap system nullifies this concern.
• "My main concern would be with Version control systems and how would the updates be applies and tracked there." (Attribution)
  • Counter-argument: If you use version control, you're not the target audience, at least for an initial version of this feature. However, if the design keeps the the distribution and deployment components decoupled, advanced users would be free to contribute additional modules to handle deployment to all these scenarios.
• it's been mentioned twice in this thread that popular contrib modules with an equally severe issue could also benefit from a system like the one being proposed. The question becomes, where do we draw the line? (Attribution)
  • Counter-argument 1: This is a policy issue, and shouldn't derail the development of the automatic update technology. If a system was in place, there are some clear and appropriate uses for it that everyone can agree to.
  • Counter-argument 2: Site owners already choose which modules they trust on their sites, and if the system were used to push contrib updates as well, site owners could take that into consideration in the modules they select (or, potentially, allow to be auto-updated). When the software is free, the user accepts the risk of possible defects. Making updates available automatically wouldn't need to fundamentally change the relationship between the security team and module maintainers.
• But the patch might not apply...
  • Counter-argument: What to do in the event of an attempted update that fails should be made configurable by the site owner, with the option to kill the site completely. This solution is discussed repeatedly, one attribution.

Proposed resolution

Implement a system to allow automatic background updates in Drupal.

It could be related to the current Update Manager functionality, but would likely need to be different because:

• At least at first, we wouldn't want to use it on every security update, just a select few, and
• We might want it to support patches (that apply against older releases as well, as was the case with SA-CORE-2014-005) rather than or in addition to actual version updates.

Security considerations

The risks of introducing automatic updates to Drupal are that we don't want to open up new security holes in the process.

Remaining tasks

Investigate how other systems implement this, including WordPress (see http://codex.wordpress.org/Configuring_Automatic_Background_Updates) see #82.

Decide if it's a good idea for Drupal and flesh out the plan.

Implement it.

User interface changes

There would likely have to be some kind of user interface to inform an administrator when automatic updates have run, or attempted to run but failed. There would have to be some method to turn this off for sites that absolutely don't want the functionality.

API changes

This would not be likely to involve any API changes, although certainly API additions. If approved and implemented, I see no reason it couldn't go in both Drupal 8 and Drupal 7.

Problem/Motivation

API page: https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Core%21Field%21P...

While working on #2552799: FieldType with no available widget causes Fatal error, I noticed that \Drupal\Core\Field\Plugin\Field\FieldType\MapItem has very little documentation. And I couldn't find where it was used. And git blame has little to explain about its creation.

We need documentation and tests for this class.

Proposed resolution

It's a field type with no formatter or widget so let's add proper documentation and tests for this.

Remaining tasks

Create a patch

User interface changes

None.

API changes

None

Data model changes

None.

Beta phase evaluation

Problem

MenuLinkTree::buildItems ignores cacheable metadata of disabled links. This is bad for dynamically enabled links.

Example

I have created a simple menu link plugin which shows a link to the front page on any page except the front page itself. Code:

<?php

namespace Drupal\blablabla\Plugin\Menu;

use Drupal\Core\Menu\MenuLinkDefault;
use Drupal\Core\Menu\StaticMenuLinkOverridesInterface;
use Drupal\Core\Path\PathMatcherInterface;
use Symfony\Component\DependencyInjection\ContainerInterface;

/**
 * A menu link for front page.
 */
class FrontpageMenuLink extends MenuLinkDefault {

  /**
   * The path matcher.
   *
   * @var \Drupal\Core\Path\PathMatcherInterface
   */
  protected $pathMatcher;

  /**
   * Constructs a new FrontpageMenuLink.
   *
   * @param array $configuration
   *   A configuration array containing information about the plugin instance.
   * @param string $plugin_id
   *   The plugin_id for the plugin instance.
   * @param mixed $plugin_definition
   *   The plugin implementation definition.
   * @param \Drupal\Core\Menu\StaticMenuLinkOverridesInterface $static_override
   *   The static override storage.
   * @param \Drupal\Core\Path\PathMatcherInterface $path_matcher
   *   The path matcher.
   */
  public function __construct(array $configuration, $plugin_id, $plugin_definition, StaticMenuLinkOverridesInterface $static_override, PathMatcherInterface $path_matcher) {
    parent::__construct($configuration, $plugin_id, $plugin_definition, $static_override);
    $this->pathMatcher = $path_matcher;
  }

  /**
   * {@inheritdoc}
   */
  public static function create(ContainerInterface $container, array $configuration, $plugin_id, $plugin_definition) {
    return new static(
      $configuration,
      $plugin_id,
      $plugin_definition,
      $container->get('menu_link.static.overrides'),
      $container->get('path.matcher')
    );
  }

  /**
   * {@inheritdoc}
   */
  public function getTitle() {
    return $this->t('Frontpage');
  }

  /**
   * {@inheritdoc}
   */
  public function getRouteName() {
    return '<front>';
  }

  /**
   * {@inheritdoc}
   */
  public function getCacheContexts() {
    return ['url.path.is_front'];
  }

  /**
   * {@inheritdoc}
   */
  public function isEnabled()
  {
    return (parent::isEnabled() && !$this->pathMatcher->isFrontPage());
  }

}

?>

Steps to reproduce cache ignorance:

1. Use this plugin, place a link of it into the main menu
2. Clear cache
3. Request the front page: No link to front page is set (OK)
4. Request a page other than front: No link to front page is set (not OK, because wrong cache record is being fetched).
5. Clear cache
6. Request a page other than front: You see the link to front page (OK, because Drupal now knows about the cache context)
7. Request the front page: No link to front page is set (OK)

Proposed solution

Collect cache metadata from links regardless whether they're disabled or not. I'm attaching a patch for this.

Problem/Motivation

any data in core or contrib that uses MapDataDefinition is serialized into empty array/null. This is unexpected, because MapDataDefinition implements core ComplexDataInterface, and ComplexDataInterface is the requirement for ComplexDataNormalizer.

This is because Map data doesn't require the definition of its properties by default. But, the definition of the properties are needed for normalizes.

Below is an incomplete list that uses MapDataDefinition, and they are unable to be serialized currently:

1. core/LinkItem
2. commerce
3. BlockField

Remaining tasks

1. Write a failing test
2. Auto cast Map data values into its properties
3. Decide if a REST test is necessary, and how to test it with Core only, see #60
Use Core's link options(Map dataType) serialization test instead
4. The newest patch has been tested on 8.4.x,So it can be directly used on 8.4.
Back port the patch to 8.4.x (Given the timing, this backport won't get committed, but it's still valuable when people search for a solution on 8.4.x for the next 6 months or so.)

User interface changes

None

API changes

None

Data model changes

None

Update versions of Stylelint dependencies.

I don't really know if this is a core issue or block cache alter issue... even I don't know if it there is any solution...
I have a website with both "User login" block and "Search" block, cached with "Globally cached" option. But when using cache on that blocks, I get duplicated ID's (i.e., #edit-submit and #edit-actions). I think it's because admins don't see "User login" block, so "Search" block HTML gets cached with #edit-submit ID. Then, when first anonymous visitor comes to the site, "Search" block HTML gets loaded from cache, and "User login" block it's dinamically generated with #edit-submit ID (because it wasn't generated dinamically before). So, the HTML generated can't be validated by automatic tools.
This also can generate bugs in javascript, and stylesheet problems (luckily for me, it's not my case).
Is there any way to avoid this? Storing somewhere IDs cached used when caching or something...
As I said, I don't know if this is a core issue or not.

When a new module is installed (kernel rebuild) the reference between the messenger service and the flashbag is reset. Any messenger service instantiated or any messages set before the this will be lost.

See #474684-141: Allow themes to declare dependencies on modules

See #2848161: [meta] Replace calls to deprecated db_*() wrappers.

Replace all usages of db_insert in core, except in code that is testing db_insert.

See #2848161: [meta] Replace calls to deprecated db_*() wrappers.

Replace all usages of db_update in core, except in code that is testing db_update.

My custom form date field is set up as follows:

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

And the error thrown is the following:

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

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

EDIT adding more debugging info:

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

class Date extends FormElement {

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

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

The sequence the code is processed is:

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

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

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

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

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

Hi I would like some advice on events vs hooks for drupal 8 and moving forward. Lot of online material for drupal 8 is expressed with hooks. is there a standard way of expressing a hook through the symfony events hook i.e. if i have a hook can i determine its event?

Is it best practice for all programmers new to drupal to write to hooks, or events?

any advice appreciated

thanks

Entity Reference Plugins have weird behaviour around their ID and other properties which make them a timesink when trying to create one.

This should be fixed -- see #2649712: Entity reference selection plugins break when not following an undocumented ID pattern (which also has several developers commenting on how they've wasted time figuring it out).

A fix will not be straightforward, so until that lands, the documentation should be improved so we stop wasting developers' time.

Things to decide here before a patch is worked on:

- where should the docs go: the plugin manager / the plugin base class / the plugin interface?
- what do the docs need to say?

To start with:

- An ERSP must declare its ID and group in one of the following forms:
-- group: GROUP, id: GROUP:ID (the id has the group as a prefix)
-- group: ID, id: ID (the id and the group are identical)
- the weight property is not used to order them in the UI, but rather to select the 'best' plugin within a group

Using the AJAX option for views pages breaks the destination url in operation links when filtering repeatedly. Steps to reproduce:

1. Perform a standard installation of Drupal 8.3.x
2. Edit the default "People" view under admin/structure/views, enable the "Use AJAX" option in the advanced settings and save
3. Go to admin/people
4. Hover the edit link for the only user, the destination parameter starts with "admin/people"
5. Click the filter button
6. Hover the edit link again, the destination parameter still starts with "admin/people"
7. Click the filter button again
8. Hover the edit link again, the destination parameter now starts with "views/ajax"

Problem/Motivation

Main reason to adopt media entity to core was the need to be able to work with remote media (specially videos). In order to prove that we need an example implementation.

Proposed resolution

Decide which video provider to support by default (YouTube?). Plugin can be implemented with a specific provider in mind or through oEmbed, which would naturally support many video providers at once.

With a plugin also create default media bundle that will allow us to actually store videos in the system.

Security considerations

From https://oembed.com/#section3

When a consumer displays HTML (as with video embeds), there's a vector for XSS attacks from the provider. To avoid this, it is recommended that consumers display the HTML in an iframe, hosted from another domain. This ensures that the HTML cannot access cookies from the consumer domain.

Drupal does not require multiple domains so it is not possible for oembed video fields to be secure out-of-the-box. Since #2522002: Do not strip www. from cookie domain by default because that leaks session cookies to subdomains has been committed to Drupal 8 it is possible to use a subdomain, for example: video.example.com, as long as example.com is redirected to www.example.com. We need make it simple to configure a different domain to serve the oembed content from and we need to have sufficient security warnings to inform users that their configuration is not secure.

Additionally we need to ensure that content creators can not enter arbitrary URLs. A content creator should only be able to link to sources from a list configured by someone with a trusted permission. The defaults for this configuration need to be sensible and restrictive. Plus the configuration field needs documentation about the security implications of adding sources.

(related comments: #139#137#132)

Remaining tasks

- decide between specific provider or oEmbed based solution
- implement plugin
- create media bundle
- figure out content creation and rendering part of the story (potentially in a separate issue)

It happens when using external libraries that at some point, run the error handler manually (in my case it happens with Symfony, but it could happen with any library playing a bit with error handlers).

A very simple solution is make the 5th argument optional providing a default value.