-
☆ A M B ☆
- 3,141 Posts
The problem was that the form had an action attribute set as "
http://www.anyscreensize.com", which would be redirected to "
http://anyscreensize.com" - that causes the data to get lost.
I can very much imagine that if a multi-context set up is not configured properly in terms of www/no-www that could be a cause of data loss like this..
-
☆ A M B ☆
- 350 Posts
Quote from: markh at Dec 07, 2011, 07:44 AM<meta name="description" content="[[*introtext:empty=`[[*content:strip_tags]]`:limit=`200`]]">
^ that meta tag is not closed, could be a cascading error causing a form not to post properly, perhaps? Can you see the actual post request with Firebug / dev tools?
I think this is what caused my problem.
Glad you guys have been having fun fixing the other issues... Great to see the activity so quickly
Helen Warner
Number one pixel!
Proud to be linked with MODX at
Crimson Pixel
-
☆ A M B ☆
- 350 Posts
Well I don't know if I would call it FUN... but hey! it is fixed!
-
☆ A M B ☆
- 350 Posts
Ok may be not fun sorting a problem - but very satisfying when you solve it!
Helen Warner
Number one pixel!
Proud to be linked with MODX at
Crimson Pixel
Quote from: markh at Dec 07, 2011, 08:28 AMThe problem was that the form had an action attribute set as "http://www.anyscreensize.com", which would be redirected to "http://anyscreensize.com" - that causes the data to get lost.
I can very much imagine that if a multi-context set up is not configured properly in terms of www/no-www that could be a cause of data loss like this..
That can also cause the Login snippet to fail. When you have a rewrite rule in .htacces that forces www or no-www, you need to create a correct site_url context setting for each front-end context.