[MGNLSTK-764] Contact Form doesn't work in Magnolia 4.4.2 Created: 02/Mar/11 Updated: 19/Dec/11 Resolved: 13/Apr/11 |
|
| Status: | Closed |
| Project: | Magnolia Standard Templating Kit (closed) |
| Component/s: | None |
| Affects Version/s: | 1.4.2 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Critical |
| Reporter: | Diana Garcia | Assignee: | Philipp Bärfuss |
| Resolution: | Workaround exists | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
Windows (XP), Linux (Debian 5) |
||
| Attachments: |
|
||||||||||||||||
| Issue Links: |
|
||||||||||||||||
| Template: |
|
||||||||||||||||
| Acceptance criteria: |
Empty
|
||||||||||||||||
| Date of First Response: | |||||||||||||||||
| Description |
|
Dear Sirs, The contact form of the public instance of Magnolia 4.4.2 doesn't work: it gives (randomly) a "session expired" error. This is critical for production because if the contact form doesn't work properly customers can't contact us. My observations: Connect to the public instance (not authoring) of online demo of magnolia-cms.com. Go to the contact form. Don't fill any field, it's not necessary. Just click the Submit button. The first times maybe you get the normal error messages about empty fields. Ok, this is fine. But try again from different windows, different sessions, different computers. Soon the contact form will be broken and you will start to get the "session expired" error. If you enter the fields (email, subject, etc) of the contact form the result is the same. I have tested a lot of things of the servers. Nothing fixed it. After several hours, I disabled caching system of public instance (just by putting enabled=false in /configuration/server/filters) and flushed the caches.... and wow, it worked again! but at the price of a very sloooowww website. I migrated to 4.4.2 from 4.3.6 only to get multilingual contact forms. And this migration broke the contact form in the mentioned way! It seems that 4.4.2 manages contact form in a different way. If cache is enabled, contact form stops working after several attempts from different windows/sessions/computers. So, now, I need first a workaround to disable cache only for the contact page. Maybe this way a get again a fast website and a contact form that works. Which is the way to achieve that? I have read the bypass configuration option, but don't have much documentation to know how to use it. Please confirm if this observations are right and provide a fast workaround to solve this. Thanks, David G. |
| Comments |
| Comment by Diana Garcia [ 02/Mar/11 ] |
|
Also noticed that after clicking in the submit button of the contact form in 4.3.6 the path didn't change but in 4.4.2 a ?<some_text> string is added at the end of the path (.../contact.html?<some_text>) some_text is like a strange ID (maybe a session ID?) Maybe this is related with the caches working (see first report). 4.3.6 works well but 4.4.2 doesn't work after several attempts. In my server, in your demo server, in local, whatever. |
| Comment by Tobias Mattsson [ 02/Mar/11 ] |
|
Hi David, As of version 4.4 of Magnolia forms keep internal state on the server. It is kept in session keyed using a unique id for each user interaction. This is the id you see in the URI. It makes it possible to have simultaneous form interactions in one session. For instance in multiple tabs. The unique id is rendered within the page as a hidden input field and therefor the page needs to be excluded from caching. Otherwise different users will use the same id that was used when the page went into the cache. For excluding content from the cache please consult the documentation on the cache module. // Tobias |
| Comment by Diana Garcia [ 02/Mar/11 ] |
|
Hello Tobias, Thanks for your quick response. It explains the issue I had with the contact form. However, the severity of the consequences on the contact form in 4.4 and above (the new technique breaks its working) should be very well documented in the Form documentation page (critical) and in the link you refer above (I think, at less from my experience, that this page is less frequently read than the previous one). That said, I think that also it's important to attach an example of how to disable caching on contact forms. I have read that executor/bypass is suitable for doing this, but I haven't found any example. PLEASE: show me an example of what nodes must I enter below the content node "bypass" to disable for example a page named /service/contact. Thanks for your help, David PS. I find Magnolia a great product! |
| Comment by Diana Garcia [ 02/Mar/11 ] |
|
Also I have found that the deny node of the cachePolicy would be an interesting place to disable cache on a page. Please could you confirm if this would be enough doint this for a contact form? In the affirmative case, also please attach an example (concrete content nodes and nodes) of how to disable for example a page named /service/contact by using the deny procedure. Thanks again. |
| Comment by Diana Garcia [ 02/Mar/11 ] |
|
First results with deny procedure: I have added the following content node below the deny content node of the cachePolicy: contacForm I suspect that this is not enough because Mozilla seems to make some caching on the client side and eventually a session expired error is found again after several attemps of clicking the Submit button from different sessions!!! This leads to me to think that the best procedure to solve this issue is disabling completely the cache system for the contact form, supposely by including it in the bypass node. However, I didn't find any example of how to do this. PLEASE provide an example (content nodes and node) of how to disable the above contact page caching via the "deny" node. I hope this info helps. Thanks and regards, David Garcia |
| Comment by Diana Garcia [ 02/Mar/11 ] |
|
Sorry in the last post I mean to "provide an example for the BYPASS method", as deny seems not enough. Thanks. |
| Comment by Diana Garcia [ 02/Mar/11 ] |
|
I have been playing with your own 4.4.2 online demo site. It should be noted that currently the contact form of your own demo site is failing due to the issue comented in this tickect. This is not acceptable because the contact form is a critical point for a website. If customers can't contact the owner of the site from the contact form then opportunities are lost and the website is almost completely useless. This is not for criticizing (on the contrary, Magnolia is a very nice work), just for highlighting the importance of this issue for a website. Well, as you say it's a matter of caching. As far as I know, this configuration FIXES the contact form in your website: In cachePolicy > voters > deny add the following content node and data nodes: + contactForm
That's all. I have tested it and works. I have used the URIRegexVoter instead URIStartsWithVoter because the regex one also works for multilingual sites. Please confirm if this configuration is good practice for contact forms in Magnolia 4.4 and above. My knowledge of Magnolia is limited so it would be nice to know your master opinion. If that's true, I find that it's critical that you document very clearly this way of configuring contact forms in Magnolia 4.4 and above. It seems that the contact form needs this configuration to work so users need to know that. Thanks for your fantastic product, I look forward to hearing your comments about this issue. David Garcia |
| Comment by Philipp Bärfuss [ 08/Mar/11 ] |
|
That has to be fixed, at least by adding the necessary cache configuration in the demo project. We should allow templates to define them as not cacheable. The cache might exclude URL if it sees the Cache-Contro: no-cache header. So a template could influence the cache if needed. |
| Comment by Philipp Bärfuss [ 09/Mar/11 ] |
|
You can exclude pages from caching as shown in the screenshot: |
| Comment by Philipp Bärfuss [ 09/Mar/11 ] |
|
Idea: should we generate the id only after the first post? so that the first form is cacheable? |
| Comment by Tobias Mattsson [ 13/Apr/11 ] |
|
This issue is solved by excluding the page from caching. In the upcoming 1.2.2 release of the form module it will no longer be an issue since |