The SandwichPluginManager.php file contains a code comment with the following sentence.
For our Sandwich plugin type, we've specified the @cache.default service be used in the plugin_type_example.services.yml file.
However, the plugin_type_example.services.yml file does not contain any line setting the cache.default service as argument, contrary to what that code comment makes think.
That sentence should be removed. The full comment should be the following one.
// This sets the caching method for our plugin definitions. Plugin
// definitions are discovered by examining the $subdir defined above, for
// any classes with an $plugin_definition_annotation_name. The annotations
// are read, and then the resulting data is cached using the provided cache
// backend. The second argument is a cache key prefix. Out of the box Drupal
// with the default cache backend setup will store our plugin definition in
// the cache_default table using the sandwich_info key. All that is
// implementation details, however; all we care about it is that caching for
// our plugin definition is taken care of by this call.
Punctuation needs to be changed to avoid a comma-splice sentence. Furthermore, all we care about it that caching for our plugin definition is taken care of by this call must be changed to all we care about it is that caching for our plugin definition is taken care of by this call.
I would fix that in this issue, instead of opening a new issue.
Issue fork examples-3109867
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #2
valthebald@alberto56 this looks like an oversight, thank you for noticing!
Comment #3
avpadernoI guess that sentence can be removed. Plugin managers get the cache backend from the parent service (usually, default_plugin_manager).
Comment #4
avpadernoComment #5
avpadernoComment #8
avpadernoComment #10
avpadernoComment #11
andypostLooks lie we need to fix tests first
Comment #12
avpadernoThis issue just change a comment in code; it cannot cause those tests to fails.
Either there is something that needs to be fixed in the other modules, or their tests need to be updated. It is not something that should be fixed in this issue, though.
Comment #13
avpadernoComment #14
avpadernoActually, 13 seems the number of failing tests when a MR's changes do not cause more tests to fail. (I agree: It would be better if none of the tests fails, but the single issues cannot fix all the failing tests, and I would not postpone them to when all the tests are fixed.)
Comment #17
avpaderno