Term Processor Missing $this->feedType->id() check

I think the bug is that $this->feedType is not set. \Drupal\feeds\Feeds\Processor\EntityProcessorBase derives from \Drupal\feeds\Plugin\Type\PluginBase, which contains a property called "feedType". In the constructor method of that class, that property is set:

  /**
   * Constructs a PluginBase object.
   *
   * @param array $configuration
   *   A configuration array containing information about the plugin instance.
   * @param string $plugin_id
   *   The plugin_id for the plugin instance.
   * @param array $plugin_definition
   *   The plugin implementation definition.
   */
  public function __construct(array $configuration, $plugin_id, array $plugin_definition) {
    $this->feedType = $configuration['feed_type'];
    unset($configuration['feed_type']);
    $this->setConfiguration($configuration);
    $this->pluginId = $plugin_id;
    $this->pluginDefinition = $plugin_definition;
  }

It would be probably be useful to throw an exception if $configuration['feed_type'] is not an instance of \Drupal\feeds\Entity\FeedType.

This patch adds throwing an exception when a Feeds plugin is constructed without $configuration['feed_type'] being set.

Let's see what breaks.

Alright, in some cases an object is passed that seem to derive from \Drupal\feeds\FeedTypeInterface. So let's check for that instead. Also, if an object is passed, but it is not of the right type, tell what its class is.

This should probably be an assert().

That said, still need to find the bug.

I'm not sure if assert() should be used here. I think the code behaves unpredictable when $configuration['feed_type'] is not an instance of Drupal\feeds\FeedTypeInterface.

From php.net/assert:

Assertions should not be used for normal runtime operations like input parameter checks. As a rule of thumb your code should always be able to work correctly if assertion checking is not activated.

In this case it's about an input parameter check?

Assertions should not be used for normal runtime operations like input parameter checks. As a rule of thumb your code should always be able to work correctly if assertion checking is not activated.

This doesn't make any sense. Asserts are almost exclusively used as input parameter checks. The difference, as I understand it, is that they should not be used for runtime checks. This isn't a runtime check, but a development/code issue.

Anyway, I'm not concerned, for two reasons.

1. Plugins should only be created by the factory, and the factory knows how to do it.
2. I'm going to rip that out eventually. It's ugly.

Either way, none of this is addressing the bug.

This was because of a change in the plugin bag crap.

We should rip that out, but that's a separate issue.