Contact module roadmap: 80% usecase of webforms in core

Created on 8 October 2015, about 9 years ago
Updated 23 August 2024, 4 months ago

Background

Now that we have a new release cycle, we have the possibility of new features in minor releases, i.e. although we are in RC1 for 8.0, that doesn't mean we can't add new features until 9.0. Provided they are backwards-compatible, we can add new features in 8.1 and 8.2.
After recently taking over maintainer-ship of the core contact module @andypost and I, in consultation with@berdir have formulated a draft roadmap for the features we'd like to see in contact module in the future.
Why not make this the guinea pig for how these initiatives and features might work in future versions of D8.

High-level goal

To provide the 80% use-case of webform. i.e. allowing creation and submission of feedback forms from site-users; and providing editing, listing and administration of submitted form values.
Webform contains lots of features, we're only after expanding contact module slightly to add storage and administration and in the process meet the basic use-case of webform in core.
Note that some of these items have been developed in contrib as the contact storage module . They can continue to mature there during 8.0 with the view to include in point releases eg 8.1, 8.2.

  1. The proposal: phase 1

    1. #1856562: Convert "Subject" and "Message" into Message base fields
    2. #2289063: Change contact message entity to behave more like a normal entity
    3. #2285083: Rename contact category to contact form
  2. The proposal: phase 2

    Bring in features from contact_storage and finalise those missed in D8.0.

    1. #306662: Add redirect option to site-wide contact forms
    2. Add option to store messages from contact forms Closed: outdated
    3. #2750617: Add views integration and listing page for contact module Message entity.
    4. #2750621: Add bulk delete action plugin for contact module Message entity
    5. #2750629: Add view builder for contact module's Message entity
    6. #2750627: Add Edit and Delete forms for contact module Message entity
    7. #2750633: Add view builder for contact module's ContactForm entity
    8. #2689265: Allow changing the 'Send message' contact form string and optionally hiding the preview button
    9. #2750649: Add option to disable form submissions for contact forms
  3. The proposal: phase 3

    Future features

    1. Support for file-fields attached to emails - requires formatter for file-field.
    2. Ability to edit format of messages bodies including tokens
    3. #2325801: Abstract contact module mail delivery out of form into a service
    4. #2325805: Make email sending optional on a per-contact form basis
    5. Path integration to allow simple alias management of contact categories
    6. #2325799: Add per contact-form permissions for contact module.
    7. Provide a menu-link per category in a custom menu - auto builds menu of contact category links leveraging the menu link API to solve the category selector regression.
    8. Ability to set submission limits
    9. Per form access controls
    10. Ability to configure mail recipients based on form values
    11. Change default value of 'send me a copy' field.
  4. The team

    @larowlan
    @andypost
    @jibran
    @naveenvalecha
    ... more to come

    The process

    The plan is to get this issue to RTBC to get product-owner/manager approval of the plan. Then to start work.

    It is still early days for 8.0, there are still some major bugs open in contact. Tending to those is obviously the priority. But getting sign-off/buy-in on the future features and building a cross-functional team in preparation can all happen in parallel to fixing bugs so that when feature development recommences, we're ready to go.

    If you're interested in getting involved, please let me know. We're looking to build a multi-disciplinary team as follows:

  • Backend developers
  • Frontend developers
  • UX/design
  • Reviewers
  • Project management
  • Manual testers

The other 20%

So if we're aiming for the 80% use-case of webform, what's the other 20%. Webform does these exceptionally well:

  • Lots of discrete webforms (100,000s in case of webform.com)
  • Lots of fields on a form (100+)
  • Multi-page forms (although fieldgroup might enable this for Field API and therefore contact messages.
  • Faster loading (although a custom storage handler might enable this for contact messages too).

Cheers

🌱 Plan
Status

Closed: won't fix

Component

Proposed Plan

Created by

🇦🇺Australia larowlan 🇦🇺🏝.au GMT+10

Live updates comments and jobs are added and updated live.
  • Usability

    Makes Drupal easier to use. Preferred over UX, D7UX, etc.

  • Needs issue summary update

    Issue summaries save everyone time if they are kept up-to-date. See Update issue summary task instructions.

Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • 🇦🇺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
  • 🇫🇷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
  • 🇦🇺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.

Production build 0.71.5 2024