[solved] problem with form submitting, FEU + CMS1.6.5

[mcDavid]

I recently updated my site from cmsms 1.6.4 to 1.6.5 using the diff-packages.

This resulted in a breakdown of all forms used by the FEU (and dependent) module. The POST-submit does take place, but there is no reaction at all, I just got returned back to the (empty) form I came from.

The bug appeard in the following forms (and maybe more):
- FEU Login form
- FEU Change Settings form
- SelfRegistration regristration form

I tried to reproduce this with a fresh cmsms 1.6.5 installation, with no success (the login form worked perfectly).

For now I went back to 1.6.4 and everything works perfectly again. I'll try to update again tomorow to see if it  appears again. Anyone else having the same problem here?

some more version information:
CMSMS: (1.5.4 -> ) 1.6.4 -> 1.6.5
FEU: 1.6.9
SelfRegistration:    1.2.5
CustomContent: 1.5.3

[ajprog]

Can you provide a link to the problem site, so we can look at the form?

[mcDavid]

login form: http://zcflevo.nl/ledenpagina
Selfregistration form: http://zcflevo.nl/aanmelden
_{(note: the forms are working now, because I downgraded to 1.6.4)}

The edit settings form is only reachable for logged-in users.
It might have something to do with CustomContent as well, as I have this code in the template:

Code:

{if $ccuser->loggedin() && $ccuser->memberof('Leden')}
  {content}                                          <<<< Here the "edit settings" form will appear
{elseif $ccuser->loggedin() && $ccuser->memberof('Nog_te_bevestigen')}
  <h2>Beste {$customcontent_loginname}, </h2>
  <p>Je verzoek om toegang tot de ledensite moet nog door een administrator bevestigd worden. De administrators zijn hier via email van op de hoogte gesteld. Nog even geduld dus!</p>
{else}
  {cms_module module=FrontEndUsers form='login'}       <<<< login form
{/if}

BTW, I saw a forum post (Forum 0.9.3) made yesterday, so the forum module wás working while the other forms did not. The forum is in the same template shown above.

The upload-form of the uploads-module wasn't working either, but this form doesn't work in 1.6.4 as well. I'm still working on that one...


-edit-
I just found a user on the Dutch board having similar problems:
http://forum.cmsmadesimple.org/index.php/topic,37135.msg175891.html#msg175891

[ajprog]

I can't take a look at the problem if you reverted back to 1.6.4.

[mcDavid]

The only difference is that in 1.6.5 there is no reaction on the form-submit. The scripts just ignore the POST-request (form action is still the same, e.g. the adress of the current page), and send you back to the form you just submitted. Not logged in, no error-message if you use a wrong password. No registration-email is send by the selfregistration form. Nothing happens.

[ajprog]

Since I can't reproduce it and you can't provide a site to look at, there is nothing that I can do to help.

Form variables controls what the CMSms does with the form, since there is no example with them not working it is impossible to fix.

[RonnyK]

Do more people have links to forms that stopped working.... I'd like to see if there are similarities....

F.e. mod_rewrite/internal URLs., Captcha, JS-errors on page etc.....

Ronny

[bob_basli]

Hi all,

I updated tom 1.6.5 yesterday the same way McDavid did with the base-diff package.
I'm having the same problems using FrontEndUsers and Formbuilder forms.

CMS Version 1.6.5
FEU 1.6.9
Formbuilder 0.5.12

[Signex]

I have the same problem, and found this;

With mod-rewrite I force a "/" behind the url. So if you visit www.domain.com/form you will get www.domain.com/form/

But the form action still says "www.domain.com/form" 

When I remove the forced "/" from my htaccess, and visit domain.com/form, the form action is identical.

Submit does work now, but I end up with an smtp error, i've never had before in 1.6.4 

[bob_basli]

I have the same problem, and found this;

With mod-rewrite I force a "/" behind the url. So if you visit www.domain.com/form you will get www.domain.com/form/

But the form action still says "www.domain.com/form" 

When I remove the forced "/" from my htaccess, and visit domain.com/form, the form action is identical.

Submit does work now, but I end up with an smtp error, i've never had before in 1.6.4 

By removing the

Code:

Rewiritebase /

from the .htaccess file the FEUsers and Formbuilder forms are working again.
@ Signex: I don't get the smtp error

I would say, problem solved but that's up to McDavid

[Signex]

I have the same problem, and found this;

With mod-rewrite I force a "/" behind the url. So if you visit www.domain.com/form you will get www.domain.com/form/

But the form action still says "www.domain.com/form"  

When I remove the forced "/" from my htaccess, and visit domain.com/form, the form action is identical.

Submit does work now, but I end up with an smtp error, i've never had before in 1.6.4  

By removing the

Code:

Rewiritebase /

from the .htaccess file the FEUsers and Formbuilder forms are working again.
@ Signex: I don't get the smtp error

I would say, problem solved but that's up to McDavid

That smtp problem was a dumb serverside error on my part, i've fixed it now, and everything works.

[mcDavid]

I have a rewrite-rule that's adding a trailing slash indeed. This 301-redirect could be a good explaination indeed, but then I still wonder why it did work before...
Anyway I've commented it out and am updating to 1.6.5 again at the moment. Lets see what happens.

[mcDavid]

And tatah, all forms are working like a charm!  

For me, that's enough. I even think the url's look better without the trailing slash so I'll leave it like this.

Thanks everybody for helping!

[calguy1000]

I have yet to find a definitive answer to this, but I did find a hint of an explanation here:

http://www.webmasterworld.com/forum92/4118.htm

It means that form data submitted via post, to a URL that has to be rewritten (like to add or subtract a trailing slash) will lose the POST data, and the redirect will be done via GET.  It's a 'browser security thing' I guess.

I've tested with the following configurations:

Stock .htaccess file
   url_rewriting = mod_rewrite
   page_extension = ''
   result:  works

Stock .htaccess file
   url_rewriting = mod_rewrite
   page_extension = '.html'
   result:  works

Stock .htaccess file + the trailing / stuff
   url_rewriting = mod_rewrite
   page_extension = ''
   result: fails

The next question is:  Why did this work in 1.6.4 and not in 1.6.5?
Because in 1.6.5 the CreateFormStart method was changed so that the URL of the destination page was used for the action attribute in the form.   This was actually started in the 1.6 release, but there were other problems with it, so I changed it again in 1.6.5 to rectify that problem. It's actually the proper solution, rather than redirecting to index.php?page=23  when you have mod_rewrite and pretty urls properly setup.

Work continues...

[calguy1000]

This solves the issue (using the sample case where you are rewriting URLS to have a trailing slash)

#
# 301 Redirect all requests that don't contain a dot or trailing slash to
# include a trailing slash
# except for form POSTS
RewriteCond %{REQUEST_URI} !/$
RewriteCond %{REQUEST_URI} !\.
RewriteCond %{REQUEST_METHOD} !POST$
RewriteRule ^(.*) %{REQUEST_URI}/ [R=301,L]