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
- #3585018: Drupal 12 support
- #3592525: Remove deprecation for template_preprocess_inline_entity_form_entity_table
Really-want-haves
Must decide
- Dragons in nested IEFs: #3197038: [Plan] Make nested IEFs "work"
- #2908530: Referenced node changes language if different from node with IEF complex form
- #2753553: Referencing new entity fails when reference method is view or entity is unpublished
- #3099844: Required fields inside referenced entity make an optional IEF (erroneously) required
- Any other issue concerning data integrity or access
- Update documentation (README.md) to reflect changes that happened in D8
- and...
- #2472769: [META] Port 7.x commits to 8.x
- #2913571: Add a setting to enable/disable inline editing for existing entities
- #2979075: Use dropdown for entity operations (edit/dup/remove)
- #2787969: Compatibility with Paragraphs module
- #3173058: Uploaded file lost when modifying existing media entity
- #3115249: Simplify and reword the Complex form.
Important, but can be done later
- #3189811: Allow to select a form mode for edition AND for creation
- #3176429: [PP-1] Empty entity reference is being created [Simple Widget]
- #3136514: IEF complex widget: Re-ordering / weight sometimes not updated
- #3061620: D8: Multiple forms submit/cancel closes all child forms
- #2702401: Add integration for the user entity type
- #2932492: "This value should not be null." on node preview
- #3189802: Allow to replace the table view by the entity edit form
- #2729333: Can't select a default bundle when using entity reference views in D8
Done
- #3413233: Core requirements for 3.1.x: require D11.3+, PHP 8.3+
- #3592475: Convert @FieldWidget annotation to FieldWidget attribute
- #3195379: Drupal dependency mismatch: composer.json vs. info.yml
- #3080462: "Collapsed by Default" should not collapse on form refresh
- #3149783: Remove hardcoded word 'entities' in EntityInlineForm::getEntityTypeLabels()
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
- Use the
3.xbranch 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. Co-maintainers agree on the requirements for the next release series (11.3.x or 11.4.x, etc)- Agree on scope of changes
- Open sub issues for various aspects of the cleanup
- Decide if it should become 3.1.x or 4.0.x
- ...
User interface changes
API changes
TBD
Comments
Comment #2
geek-merlin+1 for this plan. This is exactly what evolved in my mind over the months.
Comment #3
dwwI 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.xas "main". We can always create a4.xbranch off of that if/when we're ready, and branch3.1.xoff the end of the3.0.xbranch, 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.
Comment #4
solideogloria commentedPHP 8.4 still has 2 years until its EOL, so I think supporting 8.4+ would be a good idea.
Comment #5
dwwYeah, 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+.
Comment #6
joachim commentedOk, 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.
Comment #7
dwwYes, 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.