Get rid of using 'views.settings':skip_cache in ViewsData

Not a bug I'd say, and not a useful setting, as described, there are other ways to temporarily disable this cache if you are working at ViewsData development, and there is really no other use for this that I see.

Reroll, let's see what I got wrong!

CS clean up

The last submitted patch, 34: 2541074-34.patch, failed testing. View results →

Added update to clear the setting from config, not adding a test for it since the fails in #34 show we have coverage for this.

The last submitted patch, 36: 2541074-36.patch, failed testing. View results →

Update tests to match the new flow.

--- a/core/modules/views/src/ViewsData.php
+++ b/core/modules/views/src/ViewsData.php
-  public function __construct(CacheBackendInterface $cache_backend, ConfigFactoryInterface $config, ModuleHandlerInterface $module_handler, LanguageManagerInterface $language_manager) {
+  public function __construct(CacheBackendInterface $cache_backend, ModuleHandlerInterface $module_handler, LanguageManagerInterface $language_manager) {

I think we need to do the deprecation-dance here (as specified in https://www.drupal.org/about/core/policies/core-change-policies/drupal-d... → )?

Too right, thanks @Spokje

Something like this I guess.

Well, since I'm already being annoying, we kinda need a CR and the deprecation notice needs to link to that.

(Also CRs are being watched by people working on Rector/PHPStan Drupal-related magic)

It has a CR and it is linking to that :)

The NIDs are just eerily similar https://www.drupal.org/node/2541974 →

Meh!

The NIDs are just eerily similar

Yes, and also in the 2k-range, so I never expected a CR so old...

I've looked at the code and all seems well enough for an RTBC.

Committed/pushed to 11.x, thanks!

The associated change record notes this is being introduced in 10.2.0, but the metadata and commit here seem to indicate 11.x. Is the change record incorrect?

Good question, since it has an update and removed something, I'm gonna assume it will probably not be backported to 10.2, so quick follow up to adjust the deprecation message to mention the correct versions

Just to clarify, 10.2.x will be branched off 11.x around when we get to alpha. https://www.drupal.org/about/core/blog/new-drupal-core-branching-scheme-... → has the details.

Automatically closed - issue fixed for 2 weeks with no activity.