- 🇦🇺Australia pameeela
Same as 🌱 Formal approval for Phase 2 of 80% usecase of webforms in core Closed: won't fix -- this lost steam once Webform for D8 came out.
There may be a case for reviving something like this for Starshot but I think that we are better off starting fresh as there is a lot of outdated info here.
- Status changed to Needs review
4 months ago 7:51pm 22 August 2024 - 🇫🇷France dqd London | N.Y.C | Paris | Hamburg | Berlin
this lost steam once Webform for D8 came out.
Hm, I think this has been closed a little bit too early (no offense) and I rather would say that issues in general "loose steam" sometimes (even for years) especially after long discussions before activity comes back with new insides or motivations. It is not an indicator for a general lack of interest. As one of those who was involved in the link module into core initiative I would like to recommend not to "kill" the conversation about such things too early. I think the title of this issue is not appropiate regarding the motivation of people I have seen lately to vote for extending the contact module. Maybe this is the reason for missing +1s here.
"80% of Webform" in the title is far too much to start a discussion about extending contact to get community momentum working on it. 80% of Webform is very much! And why using Webform as the point of departure when it is actually about to extend contact it's functionality a little bit to prevent people installing complete large module suites just for some parts of it needed. I think I know why it has been reasonably titled like this initially. But I think we should take another look on it today from other angles. Especially since core has extended so much since day one of this issue that many things combined in core "could" actually make it already almost (despite of some missing parts).
Another voice from here including co-workers and clients that Webform is too overblown in many not form centric scenarios. Especially regarding all the libraries and info popups in the system and the "feeling" it creates for UI admins, seeing another system inside the system. Which it is far too much for more than 70% of most use cases where people actually just wanted one thing: a fieldable contact form (already in core) and for some bigger projects maybe another simple storage possibility (like with comments) with the option to (bulk) delete them. I would bet this is more than 70% the reason for the use count of Webform in the last 2-3 years. Which would mean that less of 10% of Webform's features are used in many many of its installs. The rest is possible with core today anyways (statistics, views, filters, etc.).
If we need to keep this title for historical discussion reasons maybe we need another issue to start this discussion from scratch (maybe not by starting from Webform). I am sure there are at least 5-6 core contributors interested to write up some thoughts, which I have spoken with about this issue in the last years. I'll put it temporarely to "Need review" for some more thoughts again, if it is OK for you all. Feel free to close again if we agree that it needs to be revamped in another issue.
- Status changed to Closed: won't fix
4 months ago 10:55pm 22 August 2024 - 🇦🇺Australia pameeela
Thanks for posting and your interest in improving this!
"80% of Webform" in the title is far too much to start a discussion about extending contact to get community momentum working on it.
Exactly, which is why this issue is closed. At the time of this proposal, there was no Webform for D8, so the scope of this was to fill a gap that no longer exists.
I don't think anyone would object to getting momentum on contact, but as you suggested, that is better done in a new issue with up-to-date information and a more realistic goal.
FWIW I agree with you about webform being too complex for may use cases, but for me the better option would be a simple version of webform rather than trying to make contact work, which also has many complexities, including that it's already in core.
Possibly of interest to you is the Contact form recipe work track → for Drupal CMS.
- 🇫🇷France dqd London | N.Y.C | Paris | Hamburg | Berlin
Thanks for coming back on this so quick. I agree with that this issue can be closed (sorry for the noise) since I've found already more or better suited issues already covering my points in the time I tried to think about creating an issue for this thoughts I thought which need to be layed out. What indicates that my assumptions are not missing the community interest in extending Drupal core contact module. So we all can agree the underlying topic is fully covered in other issues → and there is nothing left I need to worry about to be missed here or elsewhere for those people.