🇪🇪Estonia @hannes.himma

I had the same problem. The warnings came after every time I flushed all caches.

I think the problem is the same in this module. More precisely:

• in file: flippy\src\Plugin\Block\FlippyBlock.php
• in function: public function build() {
• in the building of the variable $build

The $build variable currently doesn't have this: '#configuration' => ['label' => $block->label(), 'provider' => $provider, ...

.. And a lot of Drupal core modules have code that want this $provider value (like core/modules/block/block.module):

/**
 * Implements hook_theme_suggestions_HOOK().
 */
function block_theme_suggestions_block(array $variables) {
  $suggestions = [];

  $suggestions[] = 'block__' . $variables['elements']['#configuration']['provider'];

I had the same problem when trying to update Panopoly.

This worked and should work for You:

mkdir newsite
cd newsite
composer require drush/drush:^8.0
vendor/bin/drush dl panopoly // I chose "1"
vendor/bin/drush make ./profiles/panopoly/drupal-org-core.make
vendor/bin/drush make --no-core ./profiles/panopoly/drupal-org.make
mv ./sites/all/modules/contrib ./profiles/panopoly/modules/  // The missing modules are here
// If you want to install, then now install the site either by /install.php or using the command
// If you want to update, then just replace the /sites/default/settings.php
vendor/bin/drush cc
vendor/bin/drush updb
vendor/bin/drush updb // Twice!

This is how I managed to get Panopoly's files so I could update the db, this should also work for installation:

mkdir newsite
cd newsite
composer require drush/drush:^8.0
vendor/bin/drush dl panopoly // I chose "1"
vendor/bin/drush make ./profiles/panopoly/drupal-org-core.make
vendor/bin/drush make --no-core ./profiles/panopoly/drupal-org.make
mv ./sites/all/modules/contrib ./profiles/panopoly/modules/ 
// If you want to install, then now install the site either by /install.php or using the command
// If you want to update, then just replace the /sites/default/settings.php
vendor/bin/drush cc
vendor/bin/drush updb
vendor/bin/drush updb // Twice!

hanneshh → created an issue.

Larowlan, why did you change the category to feature request instead of a bug?

The infromation user outputted (youtube embed url) gets removed by accident that shouldn't be removed. This is a bug, plain and simple. I do not want to use video_embed_field - I am talking about using Media.

video_embed_field even has a disclaimer:

If you are installing this module for integration with a media library, core already contains all the tools required for embedding remotely hosted videos. This module should no longer be required for most use cases and should be avoided if possible.

Does YouTube support those parameters with oembed?

Yes, of course YouTube supports those parameters with oembed :)

I've made a temporary js fix that solves the problem, but isn't the "right" way of doing things:

function fixAutoplay() {
  jQuery('iframe[src^="/et/media/oembed?"]').each(function () {
    if (jQuery(this).attr('src').indexOf('autoplay%3D1') == -1)
      return;

    var nestedIframes = jQuery(this).contents().find('iframe');
    if (nestedIframes.length > 0) {
      nestedIframes.each(function () {
        var src = jQuery(this).attr('src');
        if (src) {
          src += (src.indexOf('?') === -1 ? '?' : '&') + 'autoplay=1&mute=1';
          jQuery(this).attr('src', src);
        }
      });
    }
  });
}

The right way of doing things would be to just modify the code that strips the url of all other variables besides the video ID, would it not? :)

What do you mean by that cilefen? ("This may be more of a feature request than a bug.")

I am not asking for new features - I am asking not to break the remote video's url when handling it.

There is a lot of functionality that gets broken because of how Drupal's media module handles video urls.

For example youtube has GET variables you can add to the end of the video url when embedding a video, that control various aspects from autoplay and mute to the related videos that get shown. The current way of handling media remote video urls (1. take youtube video ID 2. remove everything else) breaks all of that functionality.

Again, I am not asking for new functionality, I am just asking not to completely annihilate the url when handling it.

hannes.himma → created an issue.