The intent of this issue is to help the maintainer(s) coordinate community efforts in the creation of a stable release. Community involvement is only intended as a suggestion; it is up to maintainers to ultimately decide the creation of, and what goes into, a stable release. If you are not interested in using this issue, please mark the issue as Fixed or Closed (works as designed).
As of the creation of this issue, this project presently does not have a stable release compatible with Drupal 9+. There are many benefits to publishing a stable release for a module. Project Browser uses stable releases as a recommended criteria for module discovery (#3240314-16: Decide on algorithm for "recommended" modules).
We already achieved a lot of things in D8 port of IEF, but there are still plenty of issues to resolve before 8.x-1.0. The purpose of this issue is to have a general discussion about the direction. Let's focus on that only and leave technical discussion for individual sub-issues.
Must-haves
- #3144002: Field permissions access override
- #3413044: Get PHPStan level 1 passing and enable automated test job
- #3362087: Fix the issues reported by phpcs
- #3413233: Drop PHP7 support to help with code cleanup
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 make an optional IEF (erroneously) required
- Any other issue concerning data integrity or access
- #3195379: Drupal dependency mismatch: composer.json vs. info.yml
- Update documentation (README.md) to reflect changes that happened in D8
- and...
- #2875716: Widget settings to control removing & deleting existing references
- #2472769: [META] Port 7.x commits to 8.x
- #2913571: Add a setting to enable/disable inline editing of existing entities
- #2979075: Use dropdown for entity operations (edit/dup/remove)
- #2787969: Compatibility with Paragraphs module
- #2901158: Changes are lost when collapsing a paragraphs subform including an inline_entity_form
- #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
- #3080462: "Collapsed by Default" should not collapse on form refresh
- #3176429: Empty media entity reference is being created
- #3136514: IEF complex widget: Re-ordering / weight sometimes not updated
- #3061620: D8: Multiple forms submit/cancel closes all child forms
- #3149783: Remove hardcoded word 'entities' in EntityInlineForm::getEntityTypeLabels()
- #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
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.
Do you have resources you'd like to contribute to this template? Have feedback on the stable release request issue template? We want your feedback: #3239062: 'Stable Release Request' Issue Template
Comments
Comment #2
slashrsm CreditAttribution: slashrsm as a volunteer commentedComment #3
bojanz CreditAttribution: bojanz at Centarro commentedI don't see a way to do this without limiting our use cases. We can only have one active modal. That means no nested IEFs, and no modals used inside the subform for any other purpose (adding a taxonomy term, etc).
In general the code feels very ugly. You and the others have done a good job in untangling my D7 mess, but a large part of that mess still remains, all around the Multiple/Complex widget. I've been looking into readding the clone button, and saw how unnecessary hard it was. Would help if we could figure out an API for the different buttons & matching subforms.
Comment #4
slashrsm CreditAttribution: slashrsm at Examiner.com commentedYes, I am aware of that. I remembered that we discussed this in LA, so I wanted to put it on the list mostly for record purposes. This feature is not priority at all and I'd also argue it is unlikely to become one.
Hey, it is a complex module. Of course it comes with some pretty complex code. :) Could we create a list of clean-up tasks that we want to do? That would also assure we are all on the same page about the approach to code organization.
Having API for buttons would be nice indeed. At Examiner we use IEF on a project with slightly specific needs and we needed to alter some things. Having clear API for buttons/subforms would probably make that could much smaller and nicer.
Comment #5
slashrsm CreditAttribution: slashrsm at Examiner.com commentedComment #6
slashrsm CreditAttribution: slashrsm at Examiner.com commentedComment #7
slashrsm CreditAttribution: slashrsm at Examiner.com commentedComment #8
slashrsm CreditAttribution: slashrsm at Examiner.com commentedComment #9
slashrsm CreditAttribution: slashrsm at Examiner.com commentedComment #10
slashrsm CreditAttribution: slashrsm at Examiner.com commentedComment #11
slashrsm CreditAttribution: slashrsm at Examiner.com commentedComment #12
bojanz CreditAttribution: bojanz at Centarro commentedLet's release a beta1 first, then update this issue to reflect post-beta work: #2674060: Release 8.x-1.0-beta1.
Comment #13
heddnDoes this still need to be postponed? Reviewing all the listed tasks, most of them are complete.
Comment #14
bojanz CreditAttribution: bojanz at Centarro commentedNah, we're not blocked on anything.
Comment #15
Martijn de WitThis is already implemented, right? https://github.com/drupal-media/d8-guide/blob/master/modules/entity_brow...
Comment #16
badrange CreditAttribution: badrange at Digia commentedI just created this issue: https://www.drupal.org/project/inline_entity_form/issues/2962651
Comment #17
badrange CreditAttribution: badrange at Digia commentedGiven the nature of the SA-CORE-2019-003 security issue I really hope we can get a stable release of IEF, even if it is full of known bugs.
I would sleep much better at night knowing that the maintainers would have been informed behind the scenes if the module was affected by this issue (and future ones).
Right now our site may or may not be exposed to a security risk, and neither you nor us knows before the security team reveals more information publicly, by which time our site may already be under attack.
Thank you for your efforts!
Comment #18
joachim CreditAttribution: joachim as a volunteer commentedComment #19
Chris Matthews CreditAttribution: Chris Matthews commentedIt looks like a -rc2 release might be in order...
Fixed since -rc1:
RTBC:
Comment #20
joachim CreditAttribution: joachim as a volunteer commentedGood idea. I'll try and get round to it in the next few days.
As for the RTBCs and other future work, as far as I'm concerned, everything is blocked on #2974544: Convert tests from Simpletest to FunctionalJavascript.
Comment #21
oknate#2974544: Convert tests from Simpletest to FunctionalJavascript is in. We need to go through the RTBC issues and any with tests need to be updated. Those without tests should probably have them.
Comment #22
oknateI went ahead and committed #2786597: Do not render fieldsets when no there is no data, or the user lacks crud permissions, but didn't mark it fixed, since I think we should have test coverage. But the fix was simple enough, I felt it was worth committing.
Comment #23
Chris Matthews CreditAttribution: Chris Matthews commented@oknate, are you able to advise which of the remaining issues need to be fixed before a full 8.x-1.0 release?
Comment #24
geek-merlinClosed #3017849: Plan for next Inline Entity Form release as dup.
Comment #25
geek-merlinAdorers of the sun, we have quite some traction these days and a rc6.
EDIT: Updated to rc6 and learnt a lesson...
Comment #26
rszrama CreditAttribution: rszrama at Centarro commented@geek-merlin Are you tracking any of the remaining issues linked above that aren't fully closed? Reviewing them, it doesn't seem like any would be release blockers in the sense that yes, they may represent bug fixes, but they don't change the schema or API such that they can't be fixed in a minor release.
I'm inclined to push for a full 1.0 after the resolution of #2875716: Widget settings to control removing & deleting existing references and a quick rewrite of the README to reflect the D8 feature set.
Comment #27
geek-merlin@rszrama: Cool you are pushing this forward. I scanned over some of my good friend issues and found no blocker too. We have #3176753: HOOK_entity_presave() not being called in IEF which, if confirmed, raises some resistance in me to call it stable, but tbh not enough.
No objections. We're out of alpha anyway, and gaining sec team coverage is due for this widely used module.
Comment #28
rszrama CreditAttribution: rszrama at Centarro commented@geek-merlin Cool, I'll take a look or have someone else on the team take a look at that issue, too! Don't mind adding it to the scope, as yeah, skipping the presave step really could skip critical entity data manipulation.
Comment #29
geek-merlin@rszrama: Ryan, after looking into it, i deem that one unlikely, but found another one that scares me. You and bojan grok that better than me, so your eyes on this may help: #2721349-18: Nested inline entities must be saved in "inside-out" order, #3189205: Leverage EntityReference::preSave to save IEF entities
Comment #30
geek-merlinComment #31
geek-merlinComment #32
geek-merlinWorking on IS. First, removed fixed issues.
Comment #33
geek-merlinComment #34
geek-merlinComment #35
geek-merlinThe dup is worked down too, yay. And triaged some more issues.
Comment #36
geek-merlinComment #37
geek-merlinComment #38
geek-merlinMade a sprint on #3197038: [Plan] Make nested IEFs "work". From that issue:
So feedback and testing appreciated.
Comment #39
geek-merlinhttps://www.drupal.org/project/inline_entity_form/releases/8.x-1.0-rc9
🎉
Comment #40
apadernoI am fixing the used tags. I apologize for bumping this issue.
Comment #41
alexpottWe're on 8.x-1.0-rc12 - is there any chance of a stable release? Stable releases are important because they allow you to have sensible stability flags in your root composer json and makes things easier for dependencies too. See https://www.sullice.com/posts/2021/07/08/please-publish-a-stable-release/
Comment #42
back-2-95Please for the love of God make 1.0 release 🙏
In addition to comment by @alexpott I can say Renovate bot wants to downgrade all alpha|beta|rc releases with 2 digits back to 9.
Comment #43
geek-merlinThanks for bumping this. After the ugly nested IEF bugs are resolved (except a very special case involving paragraphs), i have no objections anymore. Other objections?
Also i wonder whether to move to Semver (which means bumping to 2.0.0), but tend to leave that for later.
I'll wait for feedback on this for a few days, and schedule this for monday. So the release party can be in prague (where I'll unfortunately not be).
Comment #44
jsacksick CreditAttribution: jsacksick at Centarro commented@geek-merlin +1 for a stable release.
Comment #45
geek-merlinNot forgotten it, but there is one issue that i need to cross-check first.
Comment #46
WebbehIs the nested IEF issue (bugs?) the only real blocker to a 'stable' release? I'm happy to fix the issue summary update to reflect this, since we're so close.
Removing 'Media Initiative, D8Media' tags, as I suspect they've been resolved or are no longer applicable?
Given the age of this issue, I'd say stick with 8.x-1.0 and leave any real big semver change where a major version bump for that.
Comment #47
Chris Matthews CreditAttribution: Chris Matthews commented@geek-merlin Re: ...
What issue are you referring to?
Comment #48
geek-merlinNow finally getting back to this. This is what i don't want to take into a stable release:
#3144002: Field permissions access override
Someone to review would be great, someone to write a test gorgeous.
Comment #49
Chris Matthews CreditAttribution: Chris Matthews commentedIf anyone is interested our nonprofit would be happy to sponsor the time to help get #3144002: Field permissions access override across the finish line so that Inline Entity Form can move to a stable 8.x-1.0 (or 2.0.0) release.
Comment #50
Chris Matthews CreditAttribution: Chris Matthews commentedNice to see #3144002: Field permissions access override get in 🎉
Comment #51
DamienMcKennaWith no stable release for 8.x-1.x available there's already work on a 2.0.x? Can someone please explain what's going on with the module? Sites that use Commerce can't (easily; I know it's possible via some hackery, but it shouldn't be necessary) use v2. Thank you.
Comment #52
Chris Matthews CreditAttribution: Chris Matthews commentedMaybe the switch to 2.0.x was purely to switch to semantic versioning 🤷♂️, but it would be good to have clarification on the difference between 8.x-1.x and 2.0.x.
Comment #53
deviantintegral CreditAttribution: deviantintegral at Lullabot commentedI'd also appreciate notes on the differences between the major versions.
We're looking at this because we have a project where the client requires that all contributed modules have Drupal security team coverage, or we have ourselves audited the module. We haven't participated in or applied any patches from the "must-have" issues. I don't know if this is a shared experience, but given there's already a 2.x branch that could host compatibility-breaking code, I would encourage the module maintainers to tag a stable release of the 1.x branch so it can get security team coverage.
Comment #54
aleksipI too would very much appreciate a stable release and notes on the differences between the major versions. The current situation makes it very hard to decide which version to use for new extensive and critical functionality.
Comment #55
Chris Matthews CreditAttribution: Chris Matthews commentedFrom @podarok via Slack:
Comment #56
podarok2.0 version created in order to add new major functionality ( Inline Entity Menu Form ) while 1.0 work in progress. 2.0 team is doing code pull from 1.0 version from time to time in order to be aligned.
1.0 still has own roadmap which will be merged in 2.0 after getting stable
Comment #57
geek-merlinUnfortunately i have been afk for quite some weeks and did not notice what is going on with that 2.x branch. According to the last comment, that branch was created as sort of personal playground or feature branch. This was contrary to the strategy agreed here, and ignoring basic semver and drupal.org maintainership rules, created that branch, and added numerous unreviewed commits, some of which added regressions, or did not contain automated tests, contrary to needs-tests tags. Which causes substantial harm to the ecosystem. I do not assume bat faith, but Dunning-Kruger is worse than bad faith. After thinking quite a while about what action is adequate, and speaking to some fellows, i marked that 2.x branch unsupported, added an explanation on the project page, revoked said person's privileges and notified them, opened #3401656: Clean up problematic 2.x branch to coordinate further actions on this, and notified all other mainteiners and co-maintainers. Any help with the cleanup appreciated. No hard feelings.
Comment #58
geek-merlinNow to the thing i really wanted put my enegy into: I updated the IS with a ultra-minimal roadmap to a stable release (which may or may not need to be 3.0.0 now), and will stick to that until done. Any help is appreciated a lot.
Feel free to PM me if if can unblock any needed steps, but also bear with me if my reaction time is more like a week than a day, because i have s super tight schedule these days.
Comment #59
geek-merlinHabemus 3.0.0-rc18.
Comment #60
dwwNote, I think we should open a
3.0.x
branch ASAP so that the3.x
branch can be used as the "main" branch for new features (towards a future 3.1.x release), while we cherry-pick / backport any bug fixes or non-disruptive tasks to3.0.x
as we move towards the 3.0.0 stable release.Thanks!
-Derek
Comment #61
geek-merlinVery good point!
Comment #62
geek-merlinComment #63
geek-merlinComment #64
geek-merlinComment #65
geek-merlinComment #66
heddnI love the updated (and clearly stated) IS updates. Is there any specific timelines for the first 3.0.0 stable release?
Comment #67
heddnTo expand on #66, I've got a client who is looking at this project and their security posture is to use code/modules that have security support. Since this project is still a non-stable release, they feel a little uncomfortable to use it. From reviewing the must-haves, this looks really close to a stable release. It would be nice to see #3413044: Get PHPStan level 1 passing and enable automated test job land (it is rtbc) and #3413233: Drop PHP7 support to help with code cleanup as well (only NR, but easy to get to RTBC). That only leaves #2683125: Allow select widget for "Add existing items" from what I can tell as blocking release. Am I reading that correctly?