Deprecate core/modules/views_ui/admin.inc

1. +++ b/core/modules/views/src/Plugin/views/wizard/WizardPluginBase.php
   @@ -146,6 +168,12 @@ public function __construct(array $configuration, $plugin_id, $plugin_definition
   +      @trigger_error('The $element_info parameter will become mandatory before Drupal 9.0.0. See https://www.drupal.org/node/3040111.', E_USER_DEPRECATED);
   

   Although it's not finalized, it would be good to use the format in #3024461: Adopt consistent deprecation format for core and contrib deprecation messages

2. +++ b/core/modules/views_ui/admin.inc
   @@ -39,10 +39,19 @@
   +  static $seen_buttons = [];
   

   Not really sure about the changes in here?

3. +++ b/core/modules/views_ui/src/ViewAddForm.php
   @@ -22,14 +25,28 @@ class ViewAddForm extends ViewFormBase {
   +      @trigger_error('The $element_info parameter will become mandatory before Drupal 9.0.0. See https://www.drupal.org/node/3040111.', E_USER_DEPRECATED);
   

   Ditto above

I see this is not adding new Functional javascript tests, so this depends on the current coverage being sufficient to make this move safely.

Before doing this I would recommend doing an analysis of existing test coverage for the functionality that is being moved. I know there is SOME coverage for this, but a more in depth review of that is in order I think.

Re-roll of #11, because it has failed to apply on 8.8.x branch.

1. +++ b/core/modules/views/src/Plugin/views/wizard/WizardPluginBase.php
   @@ -124,14 +135,25 @@ public static function create(ContainerInterface $container, array $configuratio
   +  public function __construct(array $configuration, $plugin_id, $plugin_definition, EntityTypeBundleInfoInterface $bundle_info_service, ElementInfoManagerInterface $element_info = NULL) {
   
   @@ -144,6 +166,12 @@ public function __construct(array $configuration, $plugin_id, $plugin_definition
   +    if (!$element_info) {
   +      @trigger_error('The $element_info parameter will become mandatory before Drupal 9.0.0. See https://www.drupal.org/node/3040111.', E_USER_DEPRECATED);
   
   +++ b/core/modules/views_ui/src/ViewAddForm.php
   @@ -22,14 +25,28 @@ class ViewAddForm extends ViewFormBase {
   +    if (!$element_info) {
   +      @trigger_error('Calling WizardPluginBase::__construct() without the $element_info argument is deprecated in drupal:8.8.0 and the $element_info argument will be required in drupal:9.0.0. See https://www.drupal.org/node/3040111', E_USER_DEPRECATED);
   +      $element_info = \Drupal::service('plugin.manager.element_info');
   

   changing base class is weird, better to set new property in create()

2. +++ b/core/modules/views_ui/admin.inc
   @@ -39,15 +39,22 @@
   + * @deprecated in Drupal 8.8.0 and will be removed before Drupal 9.0.0. There's
   ...
   +  @trigger_error("views_ui_add_ajax_trigger() is deprecated in Drupal 8.8.0 and will be removed before Drupal 9.0.0. There's no public replacement for this function. Form classes can use the protected method \\Drupal\\views_ui\\ViewsUiFormHelperTrait::addAjaxTrigger(). See https://www.drupal.org/node/3040111.", E_USER_DEPRECATED);
   
   +++ b/core/modules/views_ui/src/ViewsUiFormHelperTrait.php
   @@ -0,0 +1,128 @@
   +    $triggering_element['#ajax']['callback'] = 'views_ui_ajax_update_form';
   

   Looks callable should be replaced for 9.x

Fix #22.1 and needs work for callable - it looks not best idea to put callable (views_ui_ajax_update_form()) into trait

re-roll for 9.5

added deprecation mamba

Unassigning myself, the fact that we have failing tests here seems like a good indication that we have test coverage for this method.

I think this is ready.

This was actually very tricky to review.

There are a couple of methods that need to remain static because forms in plugins can't call them otherwise. https://git.drupalcode.org/project/drupal/-/merge_requests/14615#note_67...

There is a really clever BC class in the file for the traits.

I confirmed all deprecation versions are 11.4 and removals line up with the policy 12 for callbacks and _ and 13 for api functions.
Deprecation messages describe the function and replacements correctly.
I pulled it down and there are no more loadIncludes for this file either.

Only question is the config call if we should add that as a dependency. I think it can be a follow up since this is already tricky.

> There are a couple of methods that need to remain static because forms in plugins can't call them otherwise.

That's correct, plugins can't define their own non-static callbacks because it's not possible to access their instance from somewhere, it's neither a service nor the known form object.

> There is a really clever BC class in the file for the traits.

I was wondering if it's just clever or maybe a bit too clever (as in something we should have test coverage for). I think it's fine, I'd also be fine with keeping the code, but per my added review, we likely need to move the functions to the .module file, so it's nice to not having to duplicate the code.

There was a fairly long discussion in slack around various strategies for dependency injection with traits. https://drupal.slack.com/archives/C079NQPQUEN/p1770230131118289

The short answer is that it is very complex and we don't have a standard yet.

I think the key takeaway is that these two items should be normal services even if they are a bit light and we can just handle things normally.

It's not ideal, but probably the cleanest we can do here.

I'm on board with that pivot back, I think it's cleaner than the services, thank you for exploring that.

There is one thing to resolve still on the MR which is the magic autoloading that berdir caught.

This is good now, glad we got the extra cleanup in too.

Discussed the removal version of the form/AJAX callbacks functions with @xjm, and these were our general thoughts:

For removing in D12:
These aren't specifically API functions
No found usages in contrib search

For removing in D13
There aren't underscore functions, and they're not documented as internal
Consistency of removal across all deprecated functions in this issue
Timeline to D12 release getting closer and todo list is long

Our conclusion was to make D13 the removal version, so updating the IS.

I think a reasonable general guideline about removal versions is if there's a question, go with 13.

Yes those are the guidelines we've been following for this initiative, it had been agreed that callbacks should be able to be removed in 12, but I don't think it's a huge burden to bump to 13.

I just reviewed your commit and it looks right for bumping the version.

Committed and pushed a2bcba1 to main. and 52711e6 to 11.x. Thanks!