A simple and useful addition to the contact module would be a nice theme for a link direct to the contact page. The attached patch provides an option for either a text link or a nice icon link, and it tests whether access should be allowed and displays nothing if there is no access.

Once there is a theme for the contact page link it can be used in several ways:

1) As an optional link on nodes to make it easy to contact the author.
2) As an additional link on the user profile page to make it easier to contact the user.
3) Displayed after the user or author name in custom templates and views.

The current contact process is to click on a link to go to the user page. Look around and try to figure out how to contact the user. If you notice that there's a tab (if you're not used to Drupal you may not), click on the tab that will get you to the contact form. We found in the usability studies that people don't 'see' tabs, so it's pretty easy to miss. On a site where you want to encourage people to contact you or your staff, this is harder than it should be. On a site where you don't want any contact, you can leave things the way they are :-)

In searching whether anyone had already proposed this, I found a lot of threads where people were trying (unsuccessfully) to figure out how to do it, so I think this might be useful.

This is shamelessly ripped from code created by Zack Rosen and joshk in a proposed Views patch #154865: Add field to 'contact' node authors.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Status: Needs review » Needs work

The last submitted patch failed testing.

KarenS’s picture

I don't have any idea why that failed testing, so I don't know what to do with it.

asimmonds’s picture

The patch is not rolled from Drupal's root.
ie contact.module should be modules/contact/contact.module

yched’s picture

The bot is also giving me a hard time on #370480: Field form cleanup and #369562: Field: Trivial cleanup
Issues seem to be focused around test slave 4.

KarenS’s picture

Status: Needs work » Needs review
FileSize
1.51 KB

I'll try again, rolling it from the top this time.

Status: Needs review » Needs work

The last submitted patch failed testing.

KarenS’s picture

I give up. Maybe someone else can figure out how to create a patch out of that that will pass testing. It's a very simple patch.

NancyDru’s picture

"Contact_theme" is not correct for the code.
'arguments' => array('account' => NULL, 'display' => NULL),
should be:
'arguments' => array('account' => NULL, 'text' => NULL, 'display' => NULL),

And, I think the space in if (! _contact_user_tab_access($account)) { may not be standard.

NancyDru’s picture

Status: Needs work » Needs review
FileSize
1.61 KB

Try this one.

Status: Needs review » Needs work

The last submitted patch failed testing.

NancyDru’s picture

It sure would be nice if "Detailed results" actually told us something.

KarenS’s picture

Yeah, I don't know what invalid PHP syntax it could mean. However as I look at this more I think we can simplify it (and maybe that will make the bot happy).

I wonder if we really need the second test, _contact_user_tab_access() will probably catch all the reasons why the link should not be displayed. So if we remove that test, the patch becomes really really simple and maybe that will work.

+  // Does this account use a contact page?
+  if (!_contact_user_tab_access($account)) {
+    return;
+  }

// The following part might be redundant and unneeded.

+  // Is the current user allowed access?
+  if ($account !== FALSE && $account->contact && $user->uid > 0) {

You're right about the arguments, I forgot I added another after defining the theme. At least your patch applied, I didn't even get that far. If you want to do that clean up and take another stab, maybe it will work right this time.

NancyDru’s picture

FileSize
1.48 KB

I believe you are correct, that "if" is not required. But there was no PHP syntax error.

Is there ever a case where the $account object would be "FALSE?" I also have a question about whether t($text) is valid.

NancyDru’s picture

Status: Needs work » Needs review

Status: Needs review » Needs work

The last submitted patch failed testing.

KarenS’s picture

I have noticed a bunch of people complaining that patches that should be OK are failing testing. Maybe it's a problem with the bot?

Something like t($text) is not invalid PHP syntax. There's an unsettled debate about whether it's the right way to handle user-provided variables that need translation, but we have code like that in CCK. We can remove that and just hard-code the text, but I doubt that's the problem.

The only other thing I can think of to do is reverse the condition to get rid of the !, like:

 if (_contact_user_tab_access($account)) {
    // Build the correct link.
   if ($display == 'icon') {
     return l(theme('image', 'misc/forum-new.png'), 'user/'. $account->uid .'/contact', array('html' => TRUE, 'attributes' => array('title' => t('Contact %user', array('%user' => $account->name)))));
  }
  else {
    return l(t($text), 'user/'. $account->uid .'/contact', array('attributes' => array('title' => t('Contact %user', array('%user' => $account->name)))));
  }
}
NancyDru’s picture

That seems more straight-forward to me. I didn't think that "t($text)" was invalid syntax; the "unsettled debate" can be confusing to those of us who can barely handle English let alone more languages.

Dave Reid’s picture

Status: Needs work » Needs review
FileSize
1.6 KB

Revised patch that's a little more flexible and just has a $text parameter that could be passed any image instead of hardcoding ourselves to one. The third parameter is a boolean $html which should be TRUE if $text is already HTML.

Dave Reid’s picture

Version: 7.x-dev » 8.x-dev
Status: Needs review » Postponed

This is an actual API addition, we can't accept this for D7. Would love to get this into Drupal 8 as soon as we can.

NancyDru’s picture

Since it is an ADDITION, rather than a true change, perhaps it can actually be considered for 7.1 (remember 6.2 that actually broke things)? It won't break anything, just provides admins with a better presentation for end-users and makes Drupal more valuable.

Dave Reid’s picture

Based that no-one had helped on this from Feb until now is why I based my postponed judgement. If someone wants to help review the patches that would be great and I'd be more confident, but a patch can't be committed and reviewed by just one person.

NancyDru’s picture

I didn't get D7 until quite some time after Feb. 7 because I hadn't updated to PHP 5.2.5 at that time. Had a usable patch come along and reminded me of this issue, I might have tested it. Now my biggest problem with testing is that I have to clean out the database every time I update to HEAD. That means everything has to be set up all over again, including adding content.

mattyoung’s picture

.

andypost’s picture

Status: Postponed » Needs work
andypost’s picture

Version: 8.0.x-dev » 8.1.x-dev
Status: Needs work » Postponed
Issue tags: +Usability, +Needs usability review
Related issues: +#1997692: Create contact form block

It makes sense to have special field for user to navigate his contact page.
Views exposes contact link for user, so configurable extra-field could be great

Bojhan’s picture

Issue tags: -Needs usability review

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.

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.

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.

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.

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

Drupal 8.6.0-alpha1 will be released the week of July 16, 2018, which means new developments and disruptive changes should now be targeted against the 8.7.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.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.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.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.