Needs work
Project:
Contact
Version:
1.x-dev
Component:
Code
Priority:
Normal
Category:
Feature request
Assigned:
Unassigned
Reporter:
Created:
17 Jun 2016 at 06:10 UTC
Updated:
24 Feb 2026 at 03:22 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #2
zserno commentedFirst stab at this.
Comment #3
zserno commentedMinor code cleanup needed to use variables from above instead of hard coded values.
Attached patch does this.
Comment #4
zserno commentedMeh...patch file got lost somewhere in the tubes...attached now.
Comment #5
balagan commentedComment #6
balagan commentedThe previous patch used methods that are gonna be deprecated, I changed them for the new ones.
Comment #7
balagan commentedComment #8
balagan commentedI forgot to mention, but except for the deprecated methods everything was fine, I could select Rendered entity as the display format, and the contact form displayed properly rendered in the containing content type.
Comment #10
balagan commentedOk, I have changed the patch to load entity_view_display and entity_form_display from storage.
Comment #11
balagan commentedComment #12
andypostLooks great, there's only 2 weeks before beta
Comment #14
berdirWhat about using this in \Drupal\contact\Controller\ContactController::contactSitePage or even replacing it completely at least for the route with an explicit contact form? Then we could change that method to only care about the case for showing the default.
Comment #18
rgpublicHmm. Any progress on getting this into the main contact module? I really think that the rendering of a contact form shouldnt rely on the contact storage module. First, it's totally unexpected. Second, I don't want to store any form data. It's not even allowed under the new EU GDPR law.
Comment #19
berdirYou're welcome to work on it :)
> Second, I don't want to store any form data. It's not even allowed under the new EU GDPR law.
I'ts not that simple, actually. GDPR does not prevent you from storing the data, just that you explain what you are doing with that data, that you keep it save and control who can what with that data.
Which is actually much easier to do *if* you store in on your secure and protected Drupal site as opposed to sending that personal data around in unprotected e-mails.
Comment #20
rgpublicYes, Berdir, you are right of course. I took a shortcut in my explanation. But: If a customer wants to get a mail with all information sent e.g. via a contact form it is much better for us (as an IT provider) from a legal POV if we don't have a copy of that mail anymore. That's what I tried to convey :-) Nevertheless, I think this connection between the contact storage module and the bare necessity of being able to render a form is really strange and should be abandoned.
Comment #31
quietone commentedThe Contact Module was approved for removal in #3476879: [Policy] Move Contact module to contrib.
This is Postponed. The status is set according to two policies. The Remove a core extension and move it to a contributed project and the Extensions approved for removal policies.
The deprecation work is in #3520460: [meta] Tasks to deprecate the Contact module and the removal work in #3520466: [meta] Tasks to remove Contact module.
Contact will be moved to a contributed project after the Drupal 12.x branch is open.
Comment #33
andypost