Drupal\Component\Plugin\Exception\PluginNotFoundException: The "" plugin does not exist

Thanks for the bug report. I'll take a look at this today.

Hi,

This caused by https://www.drupal.org/project/eu_cookie_compliance/issues/2955489

The ConsentStorageManager needs to implement the FallbackPluginManagerInterface & implement getFallbackPluginId() with the basic ConsentStorage plugin :)

See added patch with fallback addition.

Next SQL err is caused when $revision_id is FALSE:

Drupal\Core\Database\DatabaseExceptionWrapper: SQLSTATE[HY000]: General error: 1366 Incorrect integer value: '' for column 'revision_id' at row 1: INSERT INTO {eu_cookie_compliance_basic_consent} (uid, ip_address, timestamp, revision_id, consent_type) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2, :db_insert_placeholder_3, :db_insert_placeholder_4); Array ( [:db_insert_placeholder_0] => 0 [:db_insert_placeholder_1] => 192.168.88.1 [:db_insert_placeholder_2] => 1524931163 [:db_insert_placeholder_3] => [:db_insert_placeholder_4] => banner ) in Drupal\eu_cookie_compliance\Plugin\ConsentStorage\BasicConsentStorage->registerConsent() (line 43 of /var/www/html/xxxxxx/docroot/modules/contrib/eu_cookie_compliance/src/Plugin/ConsentStorage/BasicConsentStorage.php).

See re-rolled patch with additional check before db insert in the BasicConsentStorage plugin.

@baik - thanks for the patch! I have one question: what happens by default, will it use the basic consent storage when no storage plugin is selected?

Hi @svenryen,

Yes, it will default to the BasicConsentStorage plugin. Although I think we may have another issue, as we have 2 conditions that need to be leveraged being both the consent method (1) & consent storage (2) default behaviours. The issue applies to the StoreConsent controller & the check if the consent storage is to be used at all:

    // If we're not going to log consent, return NULL.
    if ($consent_storage_method == 'do_not_store') {
      return new JsonResponse(NULL);
    }

For this upon install, the $consent_storage_method is possibly NULL, which makes this check for storage usage implicit. What I think seems more right is to check explicitly for neither NULL nor do_not_store?

    // If we're not going to log consent, return NULL.
    if (!$consent_storage_method || $consent_storage_method == 'do_not_store') {
      return new JsonResponse(NULL);
    }

With this I believe, we additionally have the correct check in place in the controller. I've re-created the patch & updated the type hinting to ConsentStorageInterface as well.

The deafult behavior should be "Do not store", not "Basic". If this patch results in people getting logging enabled without being aware of it after the update, we can't do that. The table would grow far to quickly on a busy site.

I've tried various ways of reproducing today, and it seems the problem is more that I forgot to set a default setting for the consent_storage_method config variable. If that's set we won't have this problem.

@svenryen, I see that does seem to get rid of the error indeed.

I added the defaults to the patch provided and tested. Seems to work really well - nice work! Thanks for the contribution!