Add actual contact form display formatter

This patch worked for me. Is it possible to redirect back to the node upon successful form submission, rather than the homepage?

Something to tweak here perhaps?

  drupal_set_message(t('Your message has been sent.'));
  $form_state['redirect'] = $path;

I like this patch,
I support the request of #1, and I found another issue:

After testing some time, the formatter remains blank.
Then I did a dpm() at the following location;

    case 'email_contact_form':
      $ids = entity_extract_ids($object_type, $object);
      foreach ($items as $delta => $item) {
        $element[$delta] = email_mail_page($object_type, $ids[0], $instance['field_name']);
dpm($element[$delta]);  // INSERTED HERE
        // Since email is always sent to first item's email, break after any email address found.
        break;

End then I saw that the $delta was filled with the message
"You cannot send more than 3 messages per hour. Please try again later."

I would also like to have the opportunity to redirect user back to the node after submission rather than the homepage :)

I extended the patch above with the field formatter: you can set the redirection to front, current url or a custom path.

@Denes.Szabo , it seems you have a patch upon the patch from jdelaune.
- Can you provide a patch that include both, so people can just apply the latest one?
- Here is a simpler alternative for the visibility of the custom_path:
change:

+    $form['custom_path'] = array(
+      '#title' => t('Redirection path'),
+      '#type' => 'textfield',
+      '#states' => array(
+        'visible' => array(
+          'input[name="redirection_to"]' => array('value' => 'custom'),
+        ),
+      ),
+      '#default_value' => $settings['custom_path'],

to

+    $form['custom_path'] = array(
+      '#title' => t('Redirection path'),
+      '#type' => 'textfield',
+      '#dependency' => array('radio:redirection_to' => array('custom')),
+      '#default_value' => $settings['custom_path'],
+

@johnv: I not clearly understand you, my patch integrated the first patch by jdelaune, actually based on it, extended it.

Anyway, I am attaching the patch containing only my code, need apply the patch from jdelaune then this.
I fixed my code according to your recommendation about #dependency. Maybe I not understand it, but It does nothing – similar to my #states solution :) It did't worked too…

It would be nice, if the custom_path element appear only if the radio value is 'custom".

@Denes.Szabo,
perhaps I was confused - patch starts are similar. (I did not implement your patch #4).
My #dependency-comment is based upon this analog patch: #1312114: Provide an option to configure a return path if the display is batched
(I think http://drupal.org/project/conditional_fields uses the same technology)

I just could setup successfully the form #status, so the custom url only displays when the custom is selected from the form destination:

The attached patch contains jdelaune patch + my improvements too.

Works like a charm (installation at least - haven't tried to send emails with it yet).
Two steps patching.

1- jdelaune patch
2- Denes.Szabo

I have no luck with patching. Could you please elaborate on what version do you use and what command are you using?

git apply -v [patchname.patch]

I'm rather motivated moving out all the contact formatter functionality into a separate module and keeping the email field module small. Would anyone here be willing to create a standalone email field contact module?

I agree with you, we should add this feature to the separate module. I would like to create this module unless jdelaune, the original patch creator do not want to do it.

Do you have any recommendation to the new module name? email_contact_formatter? email_contact_form_formatter?

@mh86, is a sub-module a possibity, so it will be shipped with email, but enabled separately?
That would mean adding a co-maintainer, i suppose?

Most of the code in the email field module deals with the contact form, and I have to admit I haven't used it in production so far, which makes it hard for me to maintain (and there are some issues with it).
I know some people would prefer it if the email field module would come with many options, and don't have to download additional modules, but as maintainer, I think a little bit different (separate projects makes managing the issue queues also easier).
Would be interesting how many people are actually using the contact formatter. If everyone would use it anyway, I wouldn't force people to download another module, but I don't think so.
Concerning the module name, I'm in favour of keeping it short, something like email_contact, email_field_contact, or email_contact_formatter.

I combined the to patched into one.

I made some changes since calling the page callback to get a form resulted In some really odd behaviours.
An example of odd behaviour would be that the form was replaced with just the number 2 (probably an ID).

Also we cleaned it up a bit since there was some for the non-pages unnecessary checks.

OOPS wrong issue!

Sorry about that...

This patch needs a reroll.

Here is a reroll that works with latest dev.

Denes.Szabo and I separated out the contact form functionality, and created a new module.

Email Contact

There are plans to create its 8.x version as well that would depend on the email field that went into core.

The view function for the formatter shouldn't return the form as this will break the field template system, resulting in incorrect wrappers, missing field label, etc.

Fixed this, and rerolled against the latest dev.

In email_field_formatter_settings_form, the whole settings form is being returned instead of just the elements you'd like added. Change $form to $element and problem solved.

$display = $instance['display'][$view_mode];
  $settings = $display['settings'];

  if ($display['type'] == 'email_contact_form') {
    $element['redirection_to'] = array(
      '#title' => t('Redirection destination after the contact form submit'),
      '#type' => 'radios',
      '#options' => array(
        'front' => t('To the frontpage'),
        'current' => t('To the current page'),
        'custom' => t('To a custom path'),
      ),
      '#default_value' => $settings['redirection_to'],
      '#required' => TRUE,
    );

    $element['custom_path'] = array(
      '#title' => t('Redirection path'),
      '#type' => 'textfield',
      '#states' => array(
        'visible' => array(
          ':input[name="fields[' . $field['field_name'] . '][settings_edit_form][settings][redirection_to]"]' => array('value' => 'custom'),
        ),
      ),
      '#default_value' => $settings['custom_path'],
      '#element_validate' => array('_email_field_formatter_settings_form_validate')
    );
  }

  return $element;

I think this issue should be closed, as it will never be committed, and the email_contact (https://www.drupal.org/project/email_contact) module was created to have this functionality.

It should be fairly easy to change the formatter to the version in email_contact on existing sites.

Any bug report or patch can be posted there if still relevant, as there was some work on the module since the patch in this issue.