Problem/Motivation

The current stable release series, 3.0.x, miraculously works from D8 through D11. However, that carries a lot of technical debt. 3.0.x can be the "bridge release" for all legacy installations to get them up to D11.

Proposed resolution

The IEF 3.1.x series can require D11.3+ (and soon add D12 support), along with PHP 8.3+. This will allow us to remove a bunch of work-arounds and deprecations, cleanup the code, use property promotion, convert to OOP hooks, etc.

If it ends up involving API change, we can decide to release it as 4.0.x instead of 3.1.x.

Must have

Really-want-haves

Must decide

Important, but can be done later

Done

Architectural notes

  • Move all field widget/IEF handler related code to classes and basically leave only hook implementations in .module. => We can do this, but as we are already out of alpha, we must leave stubs anyway, so can do this after 1.0
  • Clean the code (readability) as much as possible when in classes
  • Move common code to base widget class
  • Convert IEF table theme function to twig template
  • InlineEntityFormMultiple::formElement() is huge and quite hard to understand. See if we can make it easier to understand.

Remaining tasks

  1. Use the 3.x branch to work in, and use versioned branches for release series (3.0.x, etc). Cherry-pick future commits to as many/few branches as appropriate.
  2. Co-maintainers agree on the requirements for the next release series (11.3.x or 11.4.x, etc)
  3. Agree on scope of changes
  4. Open sub issues for various aspects of the cleanup
  5. Decide if it should become 3.1.x or 4.0.x
  6. ...

User interface changes

API changes

TBD

Data model changes

Comments

dww created an issue. See original summary.

geek-merlin’s picture

+1 for this plan. This is exactly what evolved in my mind over the months.

dww’s picture

I created the 3.0.x branch and -dev release node. That can be for stable 3.0.x series bug fixes and non-disruptive tasks.

For now, let's just use 3.x as "main". We can always create a 4.x branch off of that if/when we're ready, and branch 3.1.x off the end of the 3.0.x branch, or whatever we need...

Everything should be merged to 3.x first, then cherry-pick/backport to 3.0.x if appropriate.

I moved over unfinished work from #2576445: Inline Entity Form stable release plan.

solideogloria’s picture

The IEF 3.1.x series can require D11.3+ (and soon add D12 support), along with PHP 8.5.

PHP 8.4 still has 2 years until its EOL, so I think supporting 8.4+ would be a good idea.

dww’s picture

Issue summary: View changes

Yeah, I actually realized D11.3 still supports 8.3, so for now, that's the new minimum at #3413233: Core requirements for 3.1.x: require D11.3+, PHP 8.3+.

joachim’s picture

Ok, so 3.1.x is where we'll start doing things like OOP hooks and other updates for Drupal core APIs?

We should file issues for those. There are rector rules that make a lot of these conversions fairly easy.

dww’s picture

Issue summary: View changes

Yes, the 3.x branch is now effectively "main" for this project. That currently only supports D11.3+ and PHP 8.3+. That's going to be for future work, D12 compatibility, "modern Drupal" porting, everything I wrote in the summary's proposed resolution.

Yes, we can open child issues for specific parts of that conversion (per "Remaining tasks" #4). Some already exist. Some are already marked as children of this plan. But feel free to open others if you're inspired for OOP'ing hooks or whatever.

Thanks!
-Derek

p.s. Moving some stuff that's already done to a new 'Done' section.