Inline Entity Form stable release plan

Ability to display IEF in a modal. We discussed this few times already but it seems it would be very hard to implement it. Can we give it another round of thinking? Could we use Entity browser here which will come with modal display (when it is mature enough)?

I 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.

Let's release a beta1 first, then update this issue to reflect post-beta work: #2674060: Release 8.x-1.0-beta1.

Does this still need to be postponed? Reviewing all the listed tasks, most of them are complete.

Nah, we're not blocked on anything.

Ability to display IEF in a modal. We discussed this few times already but it seems it would be very hard to implement it. Can we give it another round of thinking? Could we use Entity browser here which will come with modal display (when it is mature enough)?

This is already implemented, right? https://github.com/drupal-media/d8-guide/blob/master/modules/entity_brow...

I just created this issue: https://www.drupal.org/project/inline_entity_form/issues/2962651

Given 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!

It looks like a -rc2 release might be in order...

Fixed since -rc1:

• #3033713: Fix typo in InlineEntityFormSimple
• #3040327: Wrong plugin_id type cast in Field Widgets?
• #3051927: expand documentation of 'type' in getTableFields()
• #3042577: Drupal 9 Deprecated Code Report
• #2830328: Required IEF forms for existing entities don't work
• #3051926: s/fields/columns/ in getTableFields()

RTBC:

• #2913571: Add a setting to enable/disable inline editing for existing entities
• #2786597: Do not render fieldsets when no there is no data, or the user lacks crud permissions
• #2770809: Add Hook validate hook_inline_entity_form_entity_form_validate_alter
• #2855627: Quick Edit not working for Inline Entity Form - Complex
• #2797215: Overriden labels should be translatable
• #2653574: Unable to keep nested IEF data separate with multivalue fields.

Good 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.

#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.

I 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.

@oknate, are you able to advise which of the remaining issues need to be fixed before a full 8.x-1.0 release?

• Active all 8.x-1.*
• Needs work all 8.x-1.*
• Needs review all 8.x-1.*

Closed #3017849: Plan for next Inline Entity Form release as dup.

Adorers of the sun, we have quite some traction these days and a rc6.

EDIT: Updated to rc6 and learnt a lesson...

@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.

@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.

@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.

@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

Working on IS. First, removed fixed issues.

The dup is worked down too, yay. And triaged some more issues.

Made a sprint on #3197038: [Plan] Make nested IEFs "work". From that issue:

I tend to leaving this coordination issue open this week, collect some feedback, and if things turn out well (no major regressions), roll a release at the end of this week.

So feedback and testing appreciated.

https://www.drupal.org/project/inline_entity_form/releases/8.x-1.0-rc9

🎉

I am fixing the used tags. I apologize for bumping this issue.

We'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/

Please 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.

Thanks 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).

@geek-merlin +1 for a stable release.

Not forgotten it, but there is one issue that i need to cross-check first.

Is 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?

Also i wonder whether to move to Semver (which means bumping to 2.0.0), but tend to leave that for later.

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.

@geek-merlin Re: ...

"there is one issue that i need to cross-check first."

What issue are you referring to?

Now 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.

If 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.

Nice to see #3144002: Field permissions access override get in 🎉

With 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.

Maybe 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.

I'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.

I 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.

From @podarok via Slack:

2.0 was created by me in order to introduce menu reference module
I didn't want to confuse long run with 1.x branch in order to keep your pace
We fixed a bunch of issues in 2.0, but mostly related to menu reference, which is part of the YMCA Website Services distribution ( formerly Open Y ) now
It is safe to merge 1.x into 2.0, because basic functionality is not changed in 2.0
Sorry for the confusion

2.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

Unfortunately 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.

Now 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.

Habemus 3.0.0-rc18.

Note, I think we should open a 3.0.x branch ASAP so that the 3.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 to 3.0.x as we move towards the 3.0.0 stable release.

Thanks!
-Derek

Very good point!

I love the updated (and clearly stated) IS updates. Is there any specific timelines for the first 3.0.0 stable release?

To 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: Update module compatibility statements 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?

@geek-merlin @heddn @volkerk Should #3271293: Changes are lost when collapsing a paragraphs subform including an inline_entity_form maybe also added to 3.x stable release plan because it seems not be fixed in 8.x-1.x yet.

Hi team! any plans for a stable release?

(wrong issue)

The must decide list is long.
Since D10 will be unsupported soon, sites need to be testing for D11 before that, maybe time is out of deciding, and maybe they are all gonna be tasks in D11, not blockers for D11.

Does that sound ok like a path forward to an actually supported D11 release?

Since D10 will be unsupported soon, sites need to be testing for D11 before that, maybe time is out of deciding, and maybe they are all gonna be tasks in D11, not blockers for D11.

Does that sound ok like a path forward to an actually supported D11 release?

Sounds good to me. Only the must-haves really seem compelling.

I'll re-iterate what I said at #60 nearly 2.5 years ago. 😅 I think we should call 3.0.x "stable" ASAP. I'm going to commit #3413044: Get PHPStan level 1 passing and enable automated test job today. Then, let's open a 3.0.x branch immediately. Let's tag 3.0.0 stable. Let's do #3413233: Update module compatibility statements in the main branch for a forthcoming 3.1.x new feature series. I don't think we're going to do all the massive code changes to take advantage of newer versions of core and PHP before the 3.0.0 stable release. We're already at RC22 or something. 😂 If the code cleanups require API changes, we can always do 4.0.x. But let's stop delaying a 3.0.0 stable release over all of this.

+1 to #73

Likewise, +1 to #73.

I'm a very dormant co-maintainer, and I don't know the current state of the codebase at all. But RC 21 is surely ready. RC means 'we think it's ready but we'd like other people to try it and report back'. For some reason 3.0.0 started with 3.0.0-rc15, but that's still 6 RCs.

#3593387: Add CI coverage for all supported core versions is now done, which gives me more confidence to proceed. We’ve got green pipelines on all major branches of core on both supported branches.

I opened a plan to start organizing the next release. #3593827: 3.1.x / 4.0.x roadmap Would love to hear from other co-maintainers over there, too. Thanks!

@dww +1 for getting this out finally. If you need sth PM me.

https://www.drupal.org/project/inline_entity_form/releases/3.0.0
https://www.drupal.org/project/inline_entity_form/releases/8.x-1.0

The IEF project page looks a lot better now! 🎉😂

I moved the unfinished business from this plan to #3593827: 3.1.x / 4.0.x roadmap.

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.

We should do everything in 3.x-dev first, then backport/cherry-pick to 3.0.x as appropriate.

If someone wants to open a plan for 3.0.1 and priorities, feel free.

Thanks everyone!
-Derek

FYI: Also opened #3595605: 3.0.x (stable release series) roadmap to plan/prioritize bug fixes that are (potentially) eligible for backport to 3.0.x series.