Problem/Motivation

The ability to select a contact category form is missing from the site wide contact form.

To reproduce:

  1. Install standard profile
  2. Add an additional contact category
  3. View /contact

What the will look like

Screenshot_17_05_2013_15_47.png

What's missing

Screenshot_17_05_2013_15_42-2.png

Proposed resolution

Introduce a block with a configurable list of contact forms

Remaining tasks

Update help text according UX review
Discuss enabling the Contact forms block automatically
Add tests

User interface changes

New block with a configurable set of links to other contact forms

API changes

no

Depends on the issue

#1477802: Shorter description for contact category weight
#599770: Clean up the contact forms listing UI: Allow to set the default category and weights on the listing page

Originally was:
Suggests to use tabs #1849158: Expose contact category-specific forms and/or their URLs somewhere

CommentFileSizeAuthor
#99 contact-regression-1997692-99.patch10.32 KBotarza
#93 contact-regression-1997692-93.patch10.51 KBotarza
#93 interdiff.txt3.3 KBotarza
#89 contact-regression-reroll-fix-contact-navigation-block-interdiff.diff3.3 KBotarza
#89 contact-regression-reroll-to-8.0.x-1997692-89.patch10.39 KBotarza
#89 contact-regression-1997692-89.patch3.3 KBotarza
#87 contact-regression-1997692-87.patch10.61 KBSharique
PASSED: [[SimpleTest]]: [PHP 5.5 MySQL] 98,801 pass(es). View
#85 contact-regression-1997692-85.patch3.59 KBjgeryk
#75 Drupal8-patched-B.png51.56 KByoroy
#75 Drupal8-patched-G.png129.46 KByoroy
#75 drupal7-D.png77.16 KByoroy
#75 Drupal8-patched-C.png66.55 KByoroy
#75 Drupal8-patched-A.png80.58 KByoroy
#75 drupal8-A.png89.56 KByoroy
#75 drupal7-C.png62.66 KByoroy
#75 drupal7-A.png107.17 KByoroy
#73 Screenshot 2014-10-22 13.56.37.png50.87 KBlarowlan
#73 Screenshot 2014-10-22 14.52.23.png44.07 KBlarowlan
#73 contact-regression-1997692.73.patch11.84 KBlarowlan
PASSED: [[SimpleTest]]: [PHP 5.4 MySQL] 79,537 pass(es). View
#73 interdiff.txt5.04 KBlarowlan
#70 1997692-contact-form-review-3.png95.4 KByoroy
#70 1997692-contact-form-review-2.png115.4 KByoroy
#70 1997692-contact-form-review-1.png57.54 KByoroy
#69 1997692-contact-nav-69.patch9.07 KBandypost
PASSED: [[SimpleTest]]: [PHP 5.4 MySQL] 79,495 pass(es). View
#69 interdiff.txt733 bytesandypost
#68 1997692-interdiff.txt826 bytesrpayanm
#68 1997692-68.patch9.07 KBrpayanm
PASSED: [[SimpleTest]]: [PHP 5.4 MySQL] 79,512 pass(es). View
#67 1997692-contact-nav-67.patch9.11 KBandypost
PASSED: [[SimpleTest]]: [PHP 5.4 MySQL] 79,503 pass(es). View
#67 interdiff.txt13.61 KBandypost
#63 1997692-contact-categories.png70.04 KByoroy
#62 1997692-interdiff.txt1.51 KBrpayanm
#62 1997692-62.patch10.43 KBrpayanm
FAILED: [[SimpleTest]]: [PHP 5.4 MySQL] 79,475 pass(es), 32 fail(s), and 0 exception(s). View
#60 1997692-60.patch10.44 KBrpayanm
FAILED: [[SimpleTest]]: [PHP 5.4 MySQL] 79,444 pass(es), 79 fail(s), and 0 exception(s). View
#60 1997692-interdiff.txt1.52 KBrpayanm
#56 1997692-interdiff.txt967 bytesrpayanm
#56 1997692-56.patch10.45 KBrpayanm
FAILED: [[SimpleTest]]: [PHP 5.4 MySQL] 79,461 pass(es), 80 fail(s), and 0 exception(s). View
#54 1997692-54.patch10.2 KBrpayanm
FAILED: [[SimpleTest]]: [PHP 5.4 MySQL] 79,461 pass(es), 45 fail(s), and 34 exception(s). View
#45 interdiff.txt1.01 KBcrowdcg
#45 1997692-45.patch10.27 KBcrowdcg
FAILED: [[SimpleTest]]: [PHP 5.4 MySQL] Unable to apply patch 1997692-45.patch. Unable to apply patch. See the log in the details link for more information. View
#42 interdiff.txt478 bytescrowdcg
#42 1997692-42.patch10.27 KBcrowdcg
PASSED: [[SimpleTest]]: [PHP 5.4 MySQL] 72,644 pass(es). View
#39 interdiff.txt1.06 KBcrowdcg
#39 1997692-39.patch9.68 KBcrowdcg
FAILED: [[SimpleTest]]: [PHP 5.4 MySQL] 72,602 pass(es), 16 fail(s), and 1 exception(s). View
#28 increment.txt1.7 KBcrowdcg
#28 1997692-28.patch9.42 KBcrowdcg
FAILED: [[SimpleTest]]: [PHP 5.4 MySQL] 71,693 pass(es), 16 fail(s), and 1 exception(s). View
#25 interdiff.txt8.28 KBandypost
#24 contact-nav-3.png26.73 KBandypost
#24 1997692-contact-nav-24.patch7.72 KBandypost
PASSED: [[SimpleTest]]: [PHP 5.4 MySQL] 70,621 pass(es). View
#23 contact-nav-2.png4.51 KBandypost
#23 contact-nav1.png30.05 KBandypost
#23 contact-nav-23.patch4.59 KBandypost
PASSED: [[SimpleTest]]: [PHP 5.4 MySQL] 66,355 pass(es). View
#1 1997692.1.contact-categories.patch5.92 KBalexpott
PASSED: [[SimpleTest]]: [MySQL] 55,794 pass(es). View
#1 1997692.1.contact-categories.tests-only.patch3.23 KBalexpott
FAILED: [[SimpleTest]]: [MySQL] 55,748 pass(es), 10 fail(s), and 0 exception(s). View
Screenshot_17_05_2013_15_47.png30.71 KBalexpott
Screenshot_17_05_2013_15_42-2.png45.19 KBalexpott
Members fund testing for the Drupal project. Drupal Association Learn more

Comments

alexpott’s picture

Status: Active » Needs review
FileSize
3.23 KB
FAILED: [[SimpleTest]]: [MySQL] 55,748 pass(es), 10 fail(s), and 0 exception(s). View
5.92 KB
PASSED: [[SimpleTest]]: [MySQL] 55,794 pass(es). View

Here's a patch

Status: Needs review » Needs work

The last submitted patch, 1997692.1.contact-categories.tests-only.patch, failed testing.

alexpott’s picture

Status: Needs work » Needs review

#1: 1997692.1.contact-categories.patch queued for re-testing.

Berdir’s picture

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

alexpott’s picture

Hmmm.... ok we need to re-think the site wide form then... allowing people to create categories but then giving sitebuilders no functionality to pick between other than creating a custom block or menu with links to each contact form for each category seems like quite a big regression.

+++ 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,
+        );

This code is not new to this patch :)

alexpott’s picture

So digging into this some more... this seems to be a dupe of #1849158: Expose contact category-specific forms and/or their URLs somewhere BUT the image on that issue is completely misleading as the menu tabs are not there!

In order to providing ordering and default site wide contact form category selection, convert all this routes we need this issue to be solved as how do we know that the conversions are working? There are no tests for how contact categories are exposed or ordered...

Also what the Drupal 7 functionality has that we seem to have missed is that is was possible to configure the contact form with no default category and then the drop down category selector would have a "Please select" option added... forcing people to make a choice. I think this type of interaction can be important when you have few contact categories and you want people to actually think before submit a contact form...

andypost’s picture

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

andypost’s picture

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

Bojhan’s picture

Not sure what feedback is expected here

Status: Needs review » Needs work

The last submitted patch, 1997692.1.contact-categories.tests-only.patch, failed testing.

dcam’s picture

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

mandarmbhagwat78’s picture

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.

Gábor Hojtsy’s picture

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?

andypost’s picture

yoroy’s picture

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

andypost’s picture

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

catch’s picture

Priority: Critical » Normal

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.

Berdir’s picture

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?

andypost’s picture

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

heather’s picture

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.

heather’s picture

Issue summary: View changes

added dependent and related issues

andypost’s picture

Issue summary: View changes

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

pwolanin’s picture

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

andypost’s picture

Status: Needs work » Needs review
Issue tags: +Needs tests
FileSize
4.59 KB
PASSED: [[SimpleTest]]: [PHP 5.4 MySQL] 66,355 pass(es). View
30.05 KB
4.51 KB

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

block settings


block placed

andypost’s picture

FileSize
7.72 KB
PASSED: [[SimpleTest]]: [PHP 5.4 MySQL] 70,621 pass(es). View
26.73 KB

Another round and re-roll

Added ordering of categories and implemented current cache render

andypost’s picture

FileSize
8.28 KB

interdiff

sun’s picture

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.

crowdcg’s picture

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!

crowdcg’s picture

FileSize
9.42 KB
FAILED: [[SimpleTest]]: [PHP 5.4 MySQL] 71,693 pass(es), 16 fail(s), and 1 exception(s). View
1.7 KB

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

Status: Needs review » Needs work

The last submitted patch, 28: 1997692-28.patch, failed testing.

KayGridley’s picture

Currently working on a issue summary.

andypost’s picture

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

jhodgdon’s picture

Priority: Normal » Major

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.

Berdir’s picture

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

Gábor Hojtsy’s picture

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.

andypost’s picture

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)

pwolanin’s picture

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.

andypost’s picture

crowdcg’s picture

Assigned: Unassigned » crowdcg

Working on an updated patch for this today.

crowdcg’s picture

FileSize
9.68 KB
FAILED: [[SimpleTest]]: [PHP 5.4 MySQL] 72,602 pass(es), 16 fail(s), and 1 exception(s). View
1.06 KB

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.

crowdcg’s picture

Assigned: crowdcg » Unassigned
Status: Needs work » Needs review

Status: Needs review » Needs work

The last submitted patch, 39: 1997692-39.patch, failed testing.

crowdcg’s picture

Status: Needs work » Needs review
FileSize
10.27 KB
PASSED: [[SimpleTest]]: [PHP 5.4 MySQL] 72,644 pass(es). View
478 bytes

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

pwolanin’s picture

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.

andypost’s picture

By default @var data-type var-name

crowdcg’s picture

FileSize
10.27 KB
FAILED: [[SimpleTest]]: [PHP 5.4 MySQL] Unable to apply patch 1997692-45.patch. Unable to apply patch. See the log in the details link for more information. View
1.01 KB

Adjusted the inline comments.

andypost’s picture

andypost’s picture

Berdir’s picture

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

larowlan’s picture

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

chx’s picture

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

mgifford’s picture

Status: Needs review » Needs work
Issue tags: +Needs reroll

mgifford queued 45: 1997692-45.patch for re-testing.

The last submitted patch, 45: 1997692-45.patch, failed testing.

rpayanm’s picture

Status: Needs work » Needs review
FileSize
10.2 KB
FAILED: [[SimpleTest]]: [PHP 5.4 MySQL] 79,461 pass(es), 45 fail(s), and 34 exception(s). View

here the reroll.

Status: Needs review » Needs work

The last submitted patch, 54: 1997692-54.patch, failed testing.

rpayanm’s picture

Status: Needs work » Needs review
FileSize
10.45 KB
FAILED: [[SimpleTest]]: [PHP 5.4 MySQL] 79,461 pass(es), 80 fail(s), and 0 exception(s). View
967 bytes
Berdir’s picture

+++ 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() ?

Status: Needs review » Needs work

The last submitted patch, 56: 1997692-56.patch, failed testing.

yoroy’s picture

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

rpayanm’s picture

Status: Needs work » Needs review
FileSize
1.52 KB
10.44 KB
FAILED: [[SimpleTest]]: [PHP 5.4 MySQL] 79,444 pass(es), 79 fail(s), and 0 exception(s). View

Status: Needs review » Needs work

The last submitted patch, 60: 1997692-60.patch, failed testing.

rpayanm’s picture

Status: Needs work » Needs review
FileSize
10.43 KB
FAILED: [[SimpleTest]]: [PHP 5.4 MySQL] 79,475 pass(es), 32 fail(s), and 0 exception(s). View
1.51 KB
yoroy’s picture

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.

rpayanm’s picture

@yoroy The patch is not yet complete.

Status: Needs review » Needs work

The last submitted patch, 62: 1997692-62.patch, failed testing.

yoroy’s picture

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

andypost’s picture

Status: Needs work » Needs review
FileSize
13.61 KB
9.11 KB
PASSED: [[SimpleTest]]: [PHP 5.4 MySQL] 79,503 pass(es). View

Fixed patch, ready for UI review

rpayanm’s picture

FileSize
9.07 KB
PASSED: [[SimpleTest]]: [PHP 5.4 MySQL] 79,512 pass(es). View
826 bytes

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

andypost’s picture

FileSize
733 bytes
9.07 KB
PASSED: [[SimpleTest]]: [PHP 5.4 MySQL] 79,495 pass(es). View

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

yoroy’s picture

Status: Needs review » Needs work
FileSize
57.54 KB
115.4 KB
95.4 KB

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.

larowlan’s picture

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

larowlan’s picture

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

larowlan’s picture

Status: Needs work » Needs review
Issue tags: -Needs reroll
FileSize
5.04 KB
11.84 KB
PASSED: [[SimpleTest]]: [PHP 5.4 MySQL] 79,537 pass(es). View
44.07 KB
50.87 KB

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

andypost’s picture

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.

yoroy’s picture

Status: Needs review » Needs work
FileSize
107.17 KB
62.66 KB
89.56 KB
80.58 KB
66.55 KB
77.16 KB
129.46 KB
51.56 KB

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
yoroy’s picture

jhodgdon’s picture

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.

andypost’s picture

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)

yoroy’s picture

Issue tags: -Needs usability review

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

phillamb168’s picture

Priority: Major » Normal
Issue tags: +Triaged at DrupalCon Los Angeles 2015

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.

andypost’s picture

Issue summary: View changes
Issue tags: -Needs issue summary update
Related issues: +#1866998: Introduce tab expansion facility for local tasks that are based on configuration, +#2285083: Rename contact category to contact form

Updated IS

andypost’s picture

Issue summary: View changes
xjm’s picture

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

andypost’s picture

Issue tags: +Needs reroll

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

jgeryk’s picture

Issue tags: -Needs reroll
FileSize
3.59 KB

rerolling

andypost’s picture

Issue tags: +Needs reroll

patch #73 is rerolled wrongly - block is not included

Sharique’s picture

Status: Needs work » Needs review
FileSize
10.61 KB
PASSED: [[SimpleTest]]: [PHP 5.5 MySQL] 98,801 pass(es). View

Updated patch #85 with block included.

andypost’s picture

Status: Needs review » Needs work
Issue tags: -Needs reroll

Thanx for re-roll, now new block needs tests

otarza’s picture

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
otarza’s picture

Status: Needs work » Needs review

Status: Needs review » Needs work

The last submitted patch, 89: contact-regression-1997692-89.patch, failed testing.

otarza’s picture

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.

otarza’s picture

Status: Needs work » Needs review
andrewsuth’s picture

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

+1 RTBC

andypost’s picture

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');

andypost’s picture

Version: 8.0.x-dev » 8.1.x-dev

Still needs tests for new block

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.0-beta1 was released on March 2, 2016, which means new developments and disruptive changes should now be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

otarza’s picture

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

otarza’s picture

Status: Needs work » Needs review

Status: Needs review » Needs work

The last submitted patch, 99: contact-regression-1997692-99.patch, failed testing.

andypost’s picture

@otarza please provide interdiff to follow your changes

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.0-beta1 was released on August 3, 2016, which means new developments and disruptive changes should now be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

etron770’s picture

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

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.0-alpha1 will be released the week of July 31, 2017, which means new developments and disruptive changes should now be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Manuel Ferreira’s picture

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

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.0-alpha1 will be released the week of January 17, 2018, which means new developments and disruptive changes should now be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

plato1123’s picture

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