The code in the contact module shows a difference in behaviour between users who haven't saved their personal contact form preference when the setting for 'Enable the personal contact form by default for new users.' is set to "true".

Users created before the module was enabled will have their contact forms disabled, even when they didn't make a selection. Users created after the module was enabled will have their contact forms enabled, also when they didn't make a selection yet.

The current behaviour is very annoying when the module is first enabled on a site with a large number of existing users. There is no easy way to go in and enable the form for all users aside from writing a custom PHP script. It makes more sense to use the default value when the user hasn't explicitly made a choice. The attached patch does that.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Peter Bex’s picture

This also applies to Drupal 6, but I don't know how to make this bugreport apply to multiple versions. Here's the same patch for D6, in any case.

Peter Bex’s picture

Come to think of it, possibly the insert hook should be removed altogether. This would allow the administrator to change default behaviour for all users, except those who have explicitly made a selection in their profile.

pfrenssen’s picture

This can indeed be an annoying issue but I disagree with #2. Currently it errs on the side of caution, which is usually the sane way to do it. I can think of cases where it would be acceptable to enable this by default for new users but unacceptable to force this onto the existing user base without asking permission.

A good solution would perhaps be to add another option to the settings:

pfrenssen’s picture

Status: Active » Needs review
FileSize
2.73 KB

Here is a patch that implements the proposal in #3.

Everett Zufelt’s picture

Version: 7.x-dev » 8.x-dev
Category: bug » feature

All issues are resolved against 8.x, and then are considered for backport to earlier versions.

I agree that contact forms should not be enabled by default for existing users, in fact, to do so, is an expensive task. It currently requires a user_load and user_save for each user in order to enable the contact form for existing users, it may also conflict with privacy settings that have been established on the site.

It is a relatively simple task to write a module to enable the contact form for all existing users if a site builder requires this.

thedavidmeister’s picture

Status: Needs review » Needs work
error: modules/contact/contact.install: No such file or directory
error: modules/contact/contact.module: No such file or directory

patch no longer applies.

@Everett Zufelt - there is no user_load() and user_save() in the patch in #4 and no conflict with existing privacy settings, it appears to simply extend the logic at the point the contact form is deciding whether to display itself to check if the user's preference is empty and if the site admin has elected to display the form for existing users with no preference.

pfrenssen’s picture

Updating tags.

reszli’s picture

Assigned: Unassigned » reszli
Issue summary: View changes
Alumei’s picture

Issue tags: -Needs reroll

If I'm not mistaken the patch from #4 was made against 7.x.
I'm afraid it can't be re-rolled against 8.x.
If it's still an issue in 8.x maybe you should start from scratch rather that re-rolling.

andypost’s picture

Assigned: reszli » Unassigned
Category: Feature request » Bug report
Issue tags: +Needs reroll, +Needs manual testing

This is a bug, and really needs re-roll or new patch

All users that never saved contact setting (profile form) should inherit default setting

rpayanm’s picture

Status: Needs work » Needs review
FileSize
2.47 KB

Please review.

Status: Needs review » Needs work

The last submitted patch, 11: 1191464-11.patch, failed testing.

andypost’s picture

nice idea, missing schema for new config and integration test

lokapujya’s picture

@@ -94,7 +94,7 @@ public function access(UserInterface $user, AccountInterface $account) {
     // configured default is disabled.
     $contact_settings = $this->configFactory->get('contact.settings');
     $access->cacheUntilConfigurationChanges($contact_settings);
-    if (!isset($account_data) && !$contact_settings->get('user_default_enabled')) {
+    if (!isset($account_data) && !$contact_settings->get('user_default_enabled') && $contact_settings->get('contact_default_scope')) {
       return $access;
     }

The comment preceding the condition should be updated to explain the additional contact settings check.

lokapujya’s picture

Status: Needs work » Needs review
FileSize
3.07 KB
606 bytes

Adding missing schema.

Status: Needs review » Needs work

The last submitted patch, 15: 1191464-15.patch, failed testing.

Studiographene’s picture

This is a updated Patche

lokapujya’s picture

what changes did you make? It seems like unintended changes got added because the patch is really big. If something was changed, you should include an interdiff that shows the changes.

lokapujya’s picture

Noticed that the standard profile includes contact installed by default now in 8. Does anyone know if that is intentional?

madhavvyas’s picture

+++ b/core/modules/contact/contact.module
@@ -220,10 +220,24 @@ function contact_form_user_admin_settings_alter(&$form, FormStateInterface $form
+      t('For new and existing users.')

The comma at the end of the last array element

rajeevk’s picture

Status: Needs work » Needs review
FileSize
3.07 KB
616 bytes

Created patch from #15 & added suggested comma !!

Patch in #17 doesn't seem to be in sync.

Status: Needs review » Needs work

The last submitted patch, 21: 1191464-21.patch, failed testing.

The last submitted patch, 21: 1191464-21.patch, failed testing.

lokapujya’s picture

Status: Needs work » Needs review
Issue tags: -Needs reroll
FileSize
2.89 KB
625 bytes

Added code to the submit handler to save the new form value.

Status: Needs review » Needs work

The last submitted patch, 24: 1191464-24.patch, failed testing.

lokapujya’s picture

Status: Needs work » Needs review
FileSize
4.43 KB
1.54 KB

Oops, adding back schema.

Added the start for a new test.

The last submitted patch, 24: 1191464-24.patch, failed testing.

Status: Needs review » Needs work

The last submitted patch, 26: 1191464-26.patch, failed testing.

The last submitted patch, 26: 1191464-26.patch, failed testing.

lokapujya’s picture

Status: Needs work » Needs review
Issue tags: -Needs tests
FileSize
4.68 KB
1.3 KB

Updated the test.

Status: Needs review » Needs work

The last submitted patch, 30: 1191464-30.patch, failed testing.

The last submitted patch, 30: 1191464-30.patch, failed testing.

lokapujya’s picture

Status: Needs work » Needs review
FileSize
1.2 KB

This might not be a bug in D8. Let's check.

Status: Needs review » Needs work

The last submitted patch, 33: 1191464-33-test-only.patch, failed testing.

The last submitted patch, 33: 1191464-33-test-only.patch, failed testing.

lokapujya’s picture

Status: Needs work » Needs review
FileSize
871 bytes
1.17 KB

Minus the default scope.

Since this test passes, then the bug isn't in D8. We might want to add the test? Then, it can be moved back to a D7 bug.

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

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should 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.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should 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.

crashtest_’s picture

If I am reading this correctly, the behavior should be that if I enable the setting after users have been created, and they had no preference set (which I don't see a way in 8 to set a pref per user) then their forms should also be enabled.

So, I personally am seeing two problems, number 1, the above doesn't happen for me, and number 2, there is no setting per user that I can see.

crashtest_’s picture

In my case the form field display for Contact Settings at admin/config/people/accounts/form-display was hidden when I enabled the site-wide setting for turning on personal contact forms. Just FYI.

lokapujya’s picture

Confused. Is the test added by this patch sufficient?

andypost’s picture

I think we can try same test for d7 and it should fail, if not then test is wrong

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

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should 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.

jibran’s picture

Status: Needs review » Needs work

NW as per #43.

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

Drupal 8.3.6 was released on August 2, 2017 and is the final full bugfix release for the Drupal 8.3.x series. Drupal 8.3.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.4.0 on October 4, 2017. (Drupal 8.4.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.4.x-dev branch from now on, and new development or disruptive changes should 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.4.x-dev » 8.5.x-dev

Drupal 8.4.4 was released on January 3, 2018 and is the final full bugfix release for the Drupal 8.4.x series. Drupal 8.4.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.5.0 on March 7, 2018. (Drupal 8.5.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.5.x-dev branch from now on, and new development or disruptive changes should 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.5.x-dev » 8.6.x-dev

Drupal 8.5.6 was released on August 1, 2018 and is the final bugfix release for the Drupal 8.5.x series. Drupal 8.5.x will not receive any further development aside from security fixes. Sites should prepare to update to 8.6.0 on September 5, 2018. (Drupal 8.6.0-rc1 is available for testing.)

Bug reports should be targeted against the 8.6.x-dev branch from now on, and new development or disruptive changes should 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.6.x-dev » 8.8.x-dev

Drupal 8.6.x will not receive any further development aside from security fixes. Bug reports should be targeted against the 8.8.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.9.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: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.7 was released on June 3, 2020 and is the final full bugfix release for the Drupal 8.8.x series. Drupal 8.8.x will not receive any further development aside from security fixes. Sites should prepare to update to Drupal 8.9.0 or Drupal 9.0.0 for ongoing support.

Bug reports should be targeted against the 8.9.x-dev branch from now on, and new development or disruptive changes should 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: 8.9.x-dev » 9.2.x-dev

Drupal 8 is end-of-life as of November 17, 2021. There will not be further changes made to Drupal 8. Bugfixes are now made to the 9.3.x and higher branches only. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

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

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

Drupal 9.3.15 was released on June 1st, 2022 and is the final full bugfix release for the Drupal 9.3.x series. Drupal 9.3.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.4.x-dev branch from now on, and new development or disruptive changes should 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.4.x-dev » 9.5.x-dev

Drupal 9.4.9 was released on December 7, 2022 and is the final full bugfix release for the Drupal 9.4.x series. Drupal 9.4.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.5.x-dev branch from now on, and new development or disruptive changes should 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: 9.5.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. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.