Allow themes to alter inline entity forms

tnx

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

Bulk reopen.

Review:
- Regression risk? Very low, so can be committed without tests.
- Why do some hooks also dispatch to themes, why others not?
- hook_views_ui_display_tab_alterhas a good explanation:

    // In AJAX context, ViewUI::rebuildCurrentTab() returns this outside of form
    // context, so hook_form_view_edit_form_alter() is insufficient.
    // @todo remove this after
    //   https://www.drupal.org/project/drupal/issues/3087455 has been resolved.
    $this->moduleHandler->alter('views_ui_display_tab', $build, $view, $display_id);
    // Because themes can implement hook_form_FORM_ID_alter() and because this
    // is a workaround for hook_form_view_edit_form_alter() being insufficient,
    // also invoke this on themes.
    // @todo remove this after
    //   https://www.drupal.org/project/drupal/issues/3087455 has been resolved.
    $this->themeManager->alter('views_ui_display_tab', $build, $view, $display_id);

- Does this need an update in ief.api-php?
- Yes, will do that on commit.

Also added a Change record for the new constructor argument, just to be sure:
https://www.drupal.org/node/3413055 →

Done.

So you're still adding new features to the 3.x branch, and therefore the 3.0.x series? I thought part of the problem with the 2.0.x branch is that it was ignoring semver. 3.0.x should really be only bug fixes and tasks at this point. We probably need a 3.0.x branch now, so we can backport stable-only changes there, and leave 3.x as "main", for new features towards the 3.1.x series.

@dww: The problem with 2.x was missing QA making thousands to test rabbits. Not semver.

Having said that, i'm split what the best semver policy is for the future. For now imho it's RC still.
But as i said in the stable release issue, RC18 may be the last.

Opened 🌱 Maintenance policy Active .

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