Create contact form block

+++ b/core/modules/contact/contact.pages.incundefined
@@ -44,10 +45,9 @@ function contact_site_page(Category $category = NULL) {
+    $message = entity_create('contact_message', array());

This is a problem for the NG conversion as entities with bundles need the bunde from the beginning, otherwise we can't fetch the correct field definitions.

Can we maybe default to the default category (or first entry if not set) and provide some sort of flag to the form to display the category selection or not? Maybe a different form mode?

+++ b/core/modules/contact/lib/Drupal/contact/MessageFormController.phpundefined
@@ -75,10 +75,28 @@ public function form(array $form, array &$form_state) {
+      if ($message->category) {
+        $form['category'] = array(
+          '#type' => 'value',
+          '#value' => $message->category,
+        );

Because I don't think this works anyway? For example on form rebuild, $message would have a category?

As I mentioned in #1849158: Expose contact category-specific forms and/or their URLs somewhere better expose a kind of jump menu. Anyway we need to reload page when changing category because of different fields on each category

Thought about a bit more... suggested approach is wrong - each category have different set of fields so page re-load is needed anyway.

So if no default category we can simply theme('item_list') while tabs approach from #1849158: Expose contact category-specific forms and/or their URLs somewhere rejected because site can have a lot of categories.

Also postponing #1477802: Shorter description for contact category weight about help text

EDIT added related and dependant issues to summary

Not sure what feedback is expected here

http://drupal.org/node/1427826 contains instructions for updating the issue summary with the summary template.

Is it really required to have category in the contact form?

  $items['contact'] = array(
    'title' => 'Contact',
    'page callback' => 'contact_site_page',
    'access arguments' => array('access site-wide contact form'),
    'menu_name' => 'footer',
    'type' => MENU_SUGGESTED_ITEM,
    'file' => 'contact.pages.inc',
  );
  $items['contact/%contact_category'] = array(
    'title' => 'Contact category form',
    'title callback' => 'entity_page_label',
    'title arguments' => array(1),
    'page callback' => 'contact_site_page',
    'page arguments' => array(1),
    'access arguments' => array('access site-wide contact form'),
    'type' => MENU_VISIBLE_IN_BREADCRUMB,
    'file' => 'contact.pages.inc',
  );

Contact module is already providing a way to call different contact category forms.

Yeah I agree with @andypost in #8 that different categories can now have different fields in Drupal 8, so you cannot just pick a category, you need to reload the page. So a categories menu or tabs on the contact forms or something along those lines should be used. So sounds like a duplicate of #1849158: Expose contact category-specific forms and/or their URLs somewhere?

This really needs usability review because holds #599770: Clean up the contact forms listing UI: Allow to set the default category and weights on the listing page

So the ux question is how to provide category selection now that we need to do a page load when a category is chosen?

@yoroy Yes, because each contact form could have own set of fields

iirc this was a known regression when the original patch went in. It's possible for site admins to make menu links to the forms or expose this in some other way so it didn't seem worth blocking the patch (or indeed release). Downgrading to normal since the feature was deliberately removed.

If we can find a nice way to to do this in core I'd be fine adding it back, but we don't provide visitor-facing mechanisms for navigating to all nodes either.

On the create form, we could have something like "[ ] Create a menu link to this contact category". Or if we'd generalize the menu thing on nodes with an menu link entity reference, we could just use that here as well.

Or, something else that I've been thinking is that the main URI of a contact category shouldn't be the edit form like all other config entities but contact/$category. Unlike a image style or action, they actually have a publicly displayed page. The only problem is then the personal contact category, which doesn't have a static URI. Then you could simply click on the category on the overview and it's easier to find.

And all of that is actually #1849158: Expose contact category-specific forms and/or their URLs somewhere, so we might not even need this issue?

Another way is implement a configurable block to allow choose categories so allowing to have navigation element specific to category set

When testing the contact form, with the new "Form modes" I expected to be able to expose a specific "form mode "somewhere. Such as making a "mini" contact form, and placing into the sidebar. I looked into the Custom blocks library expecting to be able to find it there.

I noticed that my categories created their own URLs.
E.g., example.com/contact/feedback or example.com/contact/help

So, I also wondered if the form modes would allow me to specify the URL of a specific form mode, or if these paths could be assigned through the menu system.

I think this is something that would be worth testing out.

In this issue, they proposed tabs: #1849158: Expose contact category-specific forms and/or their URLs somewhere
That is interesting, since you could assign form modes for example, into the menu system and have "menu tab" entries as we do with views.

I don't know if we want to bring Views into the display of a contact form, but the pattern of controlling tabs with the menu system is consistent at least.

I think a drop down menu does make sense in some cases, but not all.

added dependent and related issues

Maybe better to provide a configurable block to display a list of related categories so this will allow users to place this block contextually

So, is there any consensus on a solution? Is a block the next step?

Let's start from block as easiest and most configurable aproach

block settings

block placed

Another round and re-roll

Added ordering of categories and implemented current cache render

interdiff

Hm. When I read "block", I thought of 1 block per category, exposing the contact form itself. @heather also mentioned that as a concrete use-case. But I guess that's a slightly different purpose, and thus probably different issue.

I'm not sure I can see the use-case of a block that shows links to all (or selected) contact forms. — But in any case, that's a list, and lists are the domain of Views. So instead of implementing a custom block, we should ensure that the contact categories are exposed to Views. That way, you can simply build that block/view yourself, if you happen to have that use-case.

Aside from these points, there actually hasn't been much feedback on the claimed regression here yet. My impression is that we've jumped on the technical/development path very early, without validating the use-case.

The original issue removed the category selector in favor of resolving the much more common + desired use-case for having category-specific input fields on each contact form. At least my experience on 100% of real world sites that are using Contact module with multiple categories (and which didn't resort to Webform module due to Contact module's limitations in D7 yet) is that the former category selector functionality worked against the site owner:

By just taking the most common categories, Sales/Support/Other, it's immediately apparent that each form needs custom fields, and on top, it doesn't make sense to funnel all possible contact requests through a single contact page. The effective result of doing that is that you receive plenty of wrongly categorized contact requests, which is a general sign that end-users were not guided into the right contact channel (upfront).

Just to continue the example set of categories (which is just one example of many possible), the UX + funnel problem is (typically) resolved by placing a "Contact Sales" link somewhere in the header, a "Get Support" link somewhere in the footer, and a link to a general/other contact form somewhere deeper in the "About" section. That ensures the right discovery/entry paths for end-users, without a confusing "category" selector deeper in the funnel.

So IMO, the usability issue is about "making it easy to place a link to a particular contact form" only.

Since I'm generally skeptical of all the in-place menu link creation/editing interfaces (as they're lacking essential context that is required for editing a list/tree of menu links), I'd rather consider that a general weakness of the Menu module UI though — the menu UI should allow you to pick an entity type + autocomplete/select an entity that you want to link to. Thus, you'd choose "Contact category" and select the "SomeCategory form" to place a link to that form, without having to know its internal/system path.

Ok would like to help with this and other Contact Form issues. After reading through I believe the following should probably happen and will roll patches accordingly.

1. Block - While I can see the utility of having the specific forms in blocks, I also think the patch by @andypost would be useful and adds functionality that would not be possible by core views alone. Specifically, the individual block drag and drop and selection of which "categories" to display.
2. Admin UI - The title of each category should at least be a link to the form display. I personally setup multiple "categories" and could not figure out how to access them. A link would make this easy to find and access for everyone. Also, if needed controlling the default ordering via drag and drop might be useful here as well.
3. UX - Based on using this on a site of my own, I feel the "categories" terminology might be confusing. I really see each of these as distinct "forms" and not "categories" since they are fieldable. Another UX item is that each form should be able to have a custom URL path set.

Comments welcome!

Admin UI - I've linked to the specific "category" via the label.

Currently working on a issue summary.

The related issue is blocked on that, so can we get conclusion here?

Vast sections of the Core contact module's UI are completely confusing and useless if this functionality is not working, so I think this is more of a "Major" issue. Either the UI for categories needs to be removed, or this needs to be fixed.

#27.3 is spot on.. What we have now are contact *pages* and not categories. Would be nice to rename to that, but that would be quite a change that we would need to be signed off by the core maintainers.

#27.2 is also very useful, +1 to that.

I'm not really sure how the block is helpful, didn't look at it yet but can't you just create a menu with links to the various contact pages? We could even define a new default menu with defaut menu links for each category, then users can easily customize it to show the ones they want? Or a "Create link" entity operation that makes it easy to create a new menu link to category page?

If you want to have a category selector then add a list field or taxonomy term reference to the contact page. The only problem that core currently can't do to replace the old behavior with that is having different e-mail recipients based on the selected category.

We do have usabilities issues/bugs here, but I don't see this as a major regression or anything being useless here.

Instead of customizable URL's, it would be easier to add path aliases for a page, if you want to show it somewhere else.

The create link operation sounds confusing. Eg. when you create a view, the menu item creation is part of the process. For contact categories, it would be a separate operation but an integrated action link.

Suppose absence of consensus here caused by different usage of contact module.

IMO d7 version of contact is useless and confusing because most of sites I've seen or build are used webform or entityform modules to provide "feedback" or to gather data from user.

sun's idea and implementation #1825044: Turn contact form submissions into full-blown Contact Message entities, without storage in d8 actually brings contact module to new era and makes it a great starting point for this kind of functionality.
Also #1849158: Expose contact category-specific forms and/or their URLs somewhere gives ability to have each form own URL, so now we just need a way to link this pages from other site's pages.

Menu links does not help IMO because mostly I need to provide a set of contact links that are different for different pages that's why #23 approach allows this blocks to be reused for different pages (and suppose panels)

I agree with crowdcg and andypost that having the block available will make it easy to set this up for sites and makes it rather more obvious what's going on and it also simple enough to implement here that it's reasonable for core.

While you could achieve the same effect with menu links, I don't think it's useful to e.g. make this depend on menu_ui module.

filed #2285083: Rename contact category to contact form

Working on an updated patch for this today.

Still probably going to fail, but now at least it will apply after the PSR4 change. Also, made a change to not apply a link the "Personal contact form" as this posed more challenges than were worth the benefit.

Ok, this should pass now. Thanks to @pwolanin for pointing me in the right direction!

For inline comments like:

/** @var $category \Drupal\contact\CategoryInterface */

Should the variable name come before or after the type? I see examples of both in core I think.

By default @var data-type var-name

Adjusted the inline comments.

So only tests left here, and #2285083: Rename contact category to contact form

Another point re category vs. page.

We're missing just one feature to be able to replace the 7.x-style category selection with a list or taxonomy reference field, and that is the ability to change the e-mail address by category. If we could find a way to support that, then we could very easily migrate the 7.x contact categories to a single page with a field. Then switching the category would just work as we don't need to do crazy stuff like switching the bundle/displayed fields.

Maybe a custom field type that can store a label and recipient(s)?

I'm not really sure how the block is helpful, didn't look at it yet but can't you just create a menu with links to the various contact pages? We could even define a new default menu with defaut menu links for each category, then users can easily customize it to show the ones they want? Or a "Create link" entity operation that makes it easy to create a new menu link to category page?

I agree with this comment

> we should ensure that the contact categories are exposed to Views.

You can already build Views querying pretty much anything in CMI http://cgit.drupalcode.org/sandbox-chx-1857558/log/?h=viewsception refactoring this into the D8 version of efq_views is a trivial exercise (which I will do in the next few months).

here the reroll.

+++ b/core/modules/contact/src/ContactFormListBuilder.php
@@ -58,7 +59,7 @@ public function buildRow(EntityInterface $entity) {
    */
   protected function l($text, $route_name, array $parameters = array(), array $options = array()) {
-    return $this->linkGenerator()->generate($text, $route_name, $parameters, $options);
+    return $this->linkGenerator()->generate($text, new Url($route_name, $parameters, $options));

Should we instead adjust l() to accept a Url, so it is the same as e.g. \Drupal::l() ?

Thanks for the reroll! A screenshot of what's being changed/added would be helpful, I'll review for UX.

A quick look with simplytest.me shows that the table listing the categories is broken:

Also, I don't see a category selector on the contact form but maybe that's intentional? So yes, there's a block listed for the contact categories on /admin/structure/block, but the link doesn't work, I don't get a modal window for its configuration to show up.

@yoroy The patch is not yet complete.

Ah, ok, I'll wait a bit then. Thanks.

Fixed patch, ready for UI review

minor improve :)
@yoroy ready for the action ;)

re-roll after #2351847: Rename getCacheTag() to getCacheTags()
Still needs UX approval and then tests

Ok, had a first look at things. First off, I think the general approach is a useful reinterpretation of having contact form categories (yay for the renaming of categories to forms btw). We do get yet another place where you create "content" for a block which you then have to discover somewhere to show it else but that's a systemic issue.

1. Very good to have the titles linked to the actual forms.
2. Lets rename the 'Selected' column to 'Default' because that's the wording used on the checkbox that sets this.
3. The help text needs to be updated to reflect this new implementation

Current help text:

Add one or more forms on this page to set up your site-wide contact form.

A Contact menu item is added to the Footer menu, which you can modify on the Menus administration page.

If you would like additional text to appear on the site-wide contact page, use a block. You can create and edit blocks on the Blocks administration page.

First stab at rewriting. The first sentence could be shortened:
Create seperate contact forms for different purposes.

Then, with the new contact menu block, do we still need the single 'Contact' menu item in the footer menu?

The last bit is a rather specific site building suggestion. It is important though to have a link to the blocks page so people may find the new Contact forms block. Maybe:

Each form gets a link in the [link]Contact forms menu[/link]. You can enable this menu on the [link]Block layout[/link] page.

---

With the menu enabled, the menu links seem to be missing an active state when viewing one of the linked contact forms

---

Probably unrelated to this patch, but it's weird to edit the provided default 'Website feedback' form and see a required field without a value.

1. Very good to have the titles linked to the actual forms.

Marked #2359857: Link each row in contact form list controller to the form as duplicate of this. ++

Probably unrelated to this patch, but it's weird to edit the provided default 'Website feedback' form and see a required field without a value.

See #2349651: Default contact form does not send email as email recipient is not set during the installation.

With the menu enabled, the menu links seem to be missing an active state when viewing one of the linked contact forms

This will need to be done in a cache-safe manner, possibly #post_render_cache

1. +++ b/core/modules/contact/src/ContactFormListBuilder.php
   @@ -32,13 +36,14 @@ public function buildHeader() {
   +      $row['form'] = $this->l($this->getLabel($entity), Url::fromRoute('contact.site_page_form', ['contact_form' => $entity->id()]));
   

   $entity->link() would be simpler

2. +++ b/core/modules/contact/src/Plugin/Block/ContactNavigationBlock.php
   @@ -0,0 +1,231 @@
   +      '#type' => 'table',
   ...
   +      $rows[$contact_form->id()] = $row;
   

   couldn't we use #type => 'tableselect' here instead?

3. +++ b/core/modules/contact/src/Plugin/Block/ContactNavigationBlock.php
   @@ -0,0 +1,231 @@
   +        '#url' => Url::fromRoute('contact.site_page_form', ['contact_form' => $id]),
   

   again $entity->link() would be enough here

Then, with the new contact menu block, do we still need the single 'Contact' menu item in the footer menu?

Yes that can go, because that only happens in standard.profile

Fixes everything from the reviews except tests and questions about tableselect - left as is for now

About default/selected that was discussed in #599770: Clean up the contact forms listing UI: Allow to set the default category and weights on the listing page
@yoroy the pointed issue is another UX one, that blocked by that.

What we have in D7:

• A single contact form to which different ‘categories’ can be added.
• For each category, a different recipient address and auto-reply message can be configured

• The contact form has a link in the ‘Navigation’ menu that must be enabled manually.

What we have in D8

• Allow for the creation of multiple contact forms, with different recipients, auto-reply plus now with different fields for each form. Flexible!
• There is only one generic ‘Contact’ link added to the Footer menu. Both this block and menu item are enabled by default (in Bartik at least). This way, the one contact form that was set as the default is discoverable, the other ones are not, you’d have to manuall set up a link to them but I don’t even think the path to a non-default contact form can be (easily) found.

What this patch does

• Allow for the creation of multiple contact forms, with different recipients, auto-reply plus now with different fields for each form. Flexible!
• Instead of a single form with a select list for who to send the form to as in D7, each form is a seperate one, with each own path
• For each form, a link to it gets added to a new ‘Contact forms’ block. This block is not enabled by default, so you have to find out via the help text on /admin/structure/contact that you have to enable this block

About this solution

Creating multiple forms was already possible in D8. What this patch does is enable discovery of and linking to each individual form, which was not yet possible (because of just one generic ‘Contact’ link)

Ability to configure different contact forms with customised fields etc. is a nice feature. We still had to fix making those forms findable. Adding a ‘contact forms’ menu block for this seems right.

Review of the latest patch

/admin/structure/contact

• First line of help text ‘Create seperate contact forms for different purposes’ can be removed, because “Duh” :)

• Swap the remaining two lines. How to link to the forms is more important to know about.
• Why not enable the Contact forms block automagically? Would solve the discoverability issues of having to go via the blocks page to make those links to the contact forms visible.

/admin/structure/contact/manage/feedback/form-display

• Each drag-drop action on form display duplicates the save button :)

Other, unrelated

• It’s confusing that the personal contact form can not be edited.

Needs work

• Update help text
• Stop the Save button from duplicating itself after drag-drop actions
• Discuss enabling the Contact forms block automagically

The duplicating of UI elements is tackled in #2384545: $element['#ajax']['callback'] is broken, hence breaking e.g. inserting images in CKEditor

We have an open issue about updating the main help page for the contact module, which is the top part of hook_help(). Whether #2091395: Update hook_help for Contact module or this issue gets done first, this patch does need to update the main module help page to describe the new functionality being added in this patch. This patch is currently only updating the help on route 'contact.form_list' (the page-level help on the admin page for contact forms); it is not updating the main help text, and it needs to do that.

Meanwhile I am about to make a patch for #2091395: Update hook_help for Contact module to at least get the help there updated to the current functionality of the Contact module (without this patch, since I am not certain this patch will be done, it looks like it's not all that active and it is a bit buggy as of the last review by yoroy).

Also, as a minor note on the patch, in the hook_help() in contact.module:

       $output .= '<p>' . t('If you would like additional text to appear on the site-wide contact page, use a block. You can create and edit blocks on the <a href="@blocks">Blocks administration page</a>.', array('@blocks' => \Drupal::url('block.admin_display'))) . '</p>';
+      if (\Drupal::moduleHandler()->moduleExists('block')) {
+        $output .= '<p>' . t('Each form gets a link in the Contact forms block. You can enable this block on the <a href="@block">Block layout</a> page.', array(
+          '@block' => Url::fromRoute('block.admin_display')->toString(),
+        ));
+      }

That previous line needs to be inside the if( module exists 'block' ) test as well.

Discuss enabling the Contact forms block automagically

Good question for separate issue OTOH do we need to add newly created forms to all placed blocks?

It’s confusing that the personal contact form can not be edited.

There's nothing to edit there, but probably ability to change name makes sense (changing machine name should be always disabled)

Cleaning out the "needs usability review" tag. The usability review is in #75

Reviewed all comments on the issue. After discussing with yoroy, consensus is that this issue is of ‘normal’ priority and should no longer be classified as ‘major’ because the bug is related to a misunderstanding of the way in which contact form has been changed from Drupal 7 to 8.

In Drupal 7, the contact form was really only ‘one form’ to which multiple categories could be assigned. Each category would have different settings pertaining to mail recipients, and different receipt email settings. However, the form itself was always displayed on the same page and additional fields were not available to it.

In Drupal 8, contact forms have moved towards a more webform/bundle based form system, where each new category is a fieldable bundle of the contact form entity type.(Or something like that.) Because of these changes, there is no longer a ‘valid’ need for a dropdown-based contact form selector. This functionality could be added back in to the basic contact form by adding a simple dropdown field, for example.

The issue summary should be updated to reflect the fact that this change is trying to provide some of the older D7 contact form functionality in a way that would be familiar to users of the D7 contact functionality.

Updated IS

(Saving proposed issue credit for discussion and triage participants at LA.)

After #2513396: There is no link, anywhere, to a contact form once a user creates it.

Now contact forms are linked to their routes from UI

rerolling

patch #73 is rerolled wrongly - block is not included

Updated patch #85 with block included.

Thanx for re-roll, now new block needs tests

Hello,

I found that contact navigation block wasn't working:

1. ContactNavigationBlock's blockAccess() method was returning boolean instead of AccessResult instance
2. $contact_form links where using nonexistent link template

Last patch #87 was posted 6 months ago so it needed a reroll.

I did a reroll for latest 8.0.x branch, fixed bugs described above and created another patch.

So this comment includes 3 files:

1. Reroll contact-regression-reroll-to-8.0.x-1997692-89.patch
2. Fixing bugs after reroll contact-regression-1997692-89.patch
3. Interdiff between reroll and bug fixes contact-regression-reroll-fix-contact-navigation-block-interdiff.diff

My previous patches failed because I had reroll and bug fixes in separate patches, now this is merged patch.

interdiff.txt contains diff between my previous reroll and new patch.

I can confirm that this reroll and block fixes (#88) works as expected.

+1 RTBC

This still needs tests

1. +++ b/core/modules/contact/src/Entity/ContactForm.php
   @@ -7,8 +7,11 @@
   +use Drupal\Core\Cache\Cache;
   ...
   +use Drupal\Core\Config\Entity\ThirdPartySettingsTrait;
   +use Drupal\Core\Entity\EntityStorageInterface;
   

   not sure this needed

2. +++ b/core/modules/contact/src/Plugin/Block/ContactNavigationBlock.php
   @@ -0,0 +1,245 @@
   +   * The contact form storage.
   ...
   +   *   The contact category storage.
   

   contact form!

3. +++ b/core/modules/contact/src/Plugin/Block/ContactNavigationBlock.php
   @@ -0,0 +1,245 @@
   +      $container->get('entity.manager')->getStorage('contact_form')
   

   entity_type.manager

4. +++ b/core/modules/contact/src/Plugin/Block/ContactNavigationBlock.php
   @@ -0,0 +1,245 @@
   +  public function defaultConfiguration() {
   ...
   +      'cache' => ['max_age' => Cache::PERMANENT],
   

   not sure that needed

interdiff

1. +++ b/core/modules/contact/src/Plugin/Block/ContactNavigationBlock.php
   @@ -79,12 +79,15 @@ public function defaultConfiguration() {
   -    if ($forms = array_keys($this->configuration['forms'])) {
   +    $forms = array_keys($this->configuration['forms']);
   +    if ($forms) {
   

   useless change

2. +++ b/core/modules/contact/src/Plugin/Block/ContactNavigationBlock.php
   @@ -103,7 +106,11 @@ protected function getRequiredCacheContexts() {
   -    return $account->hasPermission('access site-wide contact form');
   +    if ($account->hasPermission('access site-wide contact form')) {
   +      return AccessResult::allowed();
   +    }
   +
   +    return AccessResult::forbidden();
   

   should be return AccessResult::allowedIfHasPermission('access site-wide contact form');

Still needs tests for new block

Hello, I made changes according to @andypost's suggestions. Here is updated patch.

@otarza please provide interdiff to follow your changes

Any news on this bug? I am using Drupal core 8.2.4. I have the same BUG as OP

I Regret that this issue is still pending on D8.4.4

Have contact form categories been removed? I see in the docs it's claimed different categories can go to different email addresses but I can't find that feature anywhere.
https://www.drupal.org/docs/8/core/modules/contact/overview

You can set up "categories" for the site-wide contact form, to allow for multiple recipient options. For example, one category might be "website feedback," and another might be "product information." For each category, you can specify one or more email addresses to which the form will be sent. You can also specify whether or not the user will receive an automatic reply.

Can someone tell me where this option is? Sorry if this isn't the right place to ask about this, having trouble finding docs on this feature.
Thank you!!!!

Re-rolled #99 patch.

Looks like there is an issue with the patch.

Rectified Custom Commands Failed errors.

Rectified Custom Commands Failed errors.

test passed.

Still no tests added

So ignored patches 120, 123, and 124.

There were no interdiffs after 120 so didn't know what was being changed.

The reroll should have been tested before uploading. Adding the block and visiting the page broke the page because ->link() is not a function.

So starting at #99

Created tests for the block form and verify it's rendering

Tried creating an interdiff from 99 but it was so long ago the interdiff command returns
1 out of 2 hunks FAILED -- saving rejects to file /var/folders/z8/ym9ls3bj01x19hd8xfvsyk_40000gn/T//interdiff-1.1trJ2r.rej
interdiff: Error applying patch1 to reconstructed file

The Needs Review Queue Bot tested this issue. It either no longer applies to Drupal core, or fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

Apart from a re-roll or rebase, this issue may need more work to address feedback in the issue or MR comments. To progress an issue, incorporate this feedback as part of the process of updating the issue. This helps other contributors to know what is outstanding.

Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.

Fixed CS errors

Think this is ready to go. I worked on the tests #127 but not the solution.

Question for the committer is if this will need a change record.

At this point, I think this is a feature request, and the presence of 'Create' in the issue title reinforces that.

I think its a good addition, but there's a bit to go still before I think its ready

1. +++ b/core/modules/contact/config/schema/contact.schema.yml
   @@ -49,3 +49,11 @@ contact.settings:
   +      type: mapping
   +      label: 'Form'
   

   for a mapping the keys must be known, so should this instead be a sequence where the keys are the contact forms and the values are the weights?

2. +++ b/core/modules/contact/contact.module
   @@ -37,6 +37,16 @@ function contact_help($route_name, RouteMatchInterface $route_match) {
   +      $output = '<p>' . t('Create separate contact forms for different purposes.') . '</p>';
   +      $output .= '<p>' . t('If you would like additional text to appear on the site-wide contact page, use a block. You can create and edit blocks on the <a href="@blocks">Blocks administration page</a>.', ['@blocks' => Url::fromRoute('block.admin_display')->toString()]) . '</p>';
   

   The remaining tasks says 'UX review' has that occurred for these new strings?

3. +++ b/core/modules/contact/contact.module
   @@ -37,6 +37,16 @@ function contact_help($route_name, RouteMatchInterface $route_match) {
   +      if (\Drupal::moduleHandler()->moduleExists('block')) {
   +        $output .= '<p>' . t('Each form gets a link in the Contact forms block. You can enable this block on the <a href="@block">Block layout</a> page.', [
   

   i'm not sure why we check for the block module here when outside the if we already link to the block display page? Shouldn't both links be inside the if?

4. +++ b/core/modules/contact/src/ContactFormListBuilder.php
   @@ -18,7 +18,7 @@ class ContactFormListBuilder extends ConfigEntityListBuilder {
   -    $header['selected'] = t('Selected');
   +    $header['default'] = t('Default');
        return $header + parent::buildHeader();
      }
    
   @@ -30,7 +30,7 @@ public function buildRow(EntityInterface $entity) {
   
   @@ -30,7 +30,7 @@ public function buildRow(EntityInterface $entity) {
        if ($entity->id() == 'personal') {
          $row['form'] = $entity->label();
          $row['recipients'] = t('Selected user');
   -      $row['selected'] = t('No');
   +      $row['default'] = t('No');
        }
        else {
          $row['form'] = $entity->toLink(NULL, 'canonical')->toString();
   @@ -40,7 +40,7 @@ public function buildRow(EntityInterface $entity) {
   
   @@ -40,7 +40,7 @@ public function buildRow(EntityInterface $entity) {
            '#context' => ['list_style' => 'comma-list'],
          ];
          $default_form = \Drupal::config('contact.settings')->get('default_form');
   -      $row['selected'] = ($default_form == $entity->id() ? t('Yes') : t('No'));
   +      $row['default'] = ($default_form == $entity->id() ? t('Yes') : t('No'));
   

   these changes feel out of scope.

5. +++ b/core/modules/contact/src/Plugin/Block/ContactNavigationBlock.php
   @@ -0,0 +1,235 @@
   +    return ['cache_context.user.roles'];
   

   shouldn't this just be user.permissions?
   also I don't think the cache context is cache_context.user.roles, it should be just user.roles, so that indicates missing test coverage I think

6. +++ b/core/modules/contact/src/Plugin/Block/ContactNavigationBlock.php
   @@ -0,0 +1,235 @@
   +      '#empty' => $this->t('There is no contact forms yet. Create one.'),
   

   Should this be 'there are no contact forms yet'?

   Should the 'create one' text link somewhere for users with appropriate permissions?

7. +++ b/core/modules/contact/src/Plugin/Block/ContactNavigationBlock.php
   @@ -0,0 +1,235 @@
   +      if ($id == 'personal') {
   

   nit ===

8. +++ b/core/modules/contact/src/Plugin/Block/ContactNavigationBlock.php
   @@ -0,0 +1,235 @@
   +      $form_state->setErrorByName('forms', $this->t('At least one category should be selected.'));
   

   We don't seem to have tests for this

9. +++ b/core/modules/contact/src/Plugin/Block/ContactNavigationBlock.php
   @@ -0,0 +1,235 @@
   +      $links[$id] = $contact_form->toLink($contact_form->label(), 'canonical', [
   +        'set_active_class' => TRUE,
   +      ]);
   

   We can make use of named arguments here and avoid the first two arguments which are just the default

10. +++ b/core/modules/contact/tests/src/Functional/ContactSitewideTest.php
    @@ -53,6 +53,8 @@ protected function setUp(): void {
    +    // cspell:ignore contactforms
    +    $this->drupalPlaceBlock('contact_navigation', ['id' => 'contactforms']);
    

    why not use something that doesn't trigger cspell instead of adding the ignore? `contact_forms` would probably do?

11. +++ b/core/modules/contact/tests/src/Functional/ContactSitewideTest.php
    @@ -220,6 +223,21 @@ public function testSiteWideContact() {
    +    $this->assertSession()->statusCodeEquals(200);
    +    $edit = [
    +      'settings[forms][' . $name . '][display]' => TRUE,
    +    ];
    +    $this->submitForm($edit, 'Save block');
    +
    +    // Test that the contact form block appears.
    +    $this->drupalGet('contact');
    +    // cspell:ignore contactforms
    

    there's nothing here that is testing the quite involved logic around ordering of disabled items at the bottom etc that's present in the block form, so I think we should add tests, or simplify that logic

Thanks for working on this again, let's keep up the momentum!

Also we're missing calculateDependencies and onDependencyRemoval here

i.e. the block should depend on the contact form, and should remove it from the selected options when the contact form is deleted

And yes to a change record to trumpet the new addition 📣