NOTICE: We are now using the Mura CMS Developer's Google Group for our Forum. While you can no longer post messages here, this forum will remain archived but unmonitored. Other support options are available here.

Next Page

Page: 1

Previous Page

Thread: Forms module bug (Version 5.1) (#3702)

Created on: 09/16/09 09:19 AM

Replies: 2

8riaN



8riaN's Gravatar

Joined: 07/17/09

Posts: 66

Forms module bug (Version 5.1) (#3702)
09/16/09 9:19 AM

I couldn't make the forms module work - Posting to a form ends up sending me to http://mydomain.com/?nocache=1 and no data is recorded for the form and no email is sent to the recipient specified in the forms manager. As you can see, I'm using SEO-Friendly URLs worked out with help from Jamie & Matt in this thread (Thanks!):
http://www.getmura.com/forum/messages.cfm?threadid=4EE1B98E-BA4E-4A2D-8CCACFD78269E26C

So I figured I'd just track down forms and see how they work, and fix whatever the funky urls broke. What I find is confusion about how they could EVER work. What I see is:
*Responses get stored in the dbase in two tables, both with names that start with tformresponse
*Those tables only get new records inserted into them by the dataCollectionManager.cfc
*dataCollectionManager methods are only called by templates that live either in \admin, or in one of the display_objects\datacollection subdirectories, esp. act_add.cfm
*Templates in the display_objects\datacollection subdirectories are only loaded if the contentRenderer encounters an object that it recognizes as a "form"
BUT
*The processing page, that is the action attribute of the <FORM> tag is always set by javascript emitted by the form renderer to be: #variables.configBean.getIndexFile()#?nocache=1

Why doesn't this mean that forms can't ever process if there doesn't happen to be a form on the home page? I thought, so the obvious question became - does it work from the home page? The answer was yes, but only if you are processing the form that's actually on the home page - forms on other pages don't work. So now I'm thinking that the javascript is the only problem, so I comment it out and viola! Forms work again! I get the email, and the responses show up everywhere they are supposed to.

So all these many, many hours of digging and forum posting boil down to:

Comment out line 297 (which is emitting javascript)
// frm.setAttribute('action','#variables.configBean.getIndexFile()#?nocache=1');
of
requirements\mura\content\dataCollection\dataCollectionManager.cfc

Maybe there's a better solutions which preserves the intent of the nocache line, like ##?nocache=1 or something, but this is working for me, so I'm putting it down for now.

So I posted the above in the bug tracker, here:
http://trac.blueriver.com/mura/ticket/3702

I'll keep you posted with any new developments
* Last updated by: 8riaN on 9/22/2009 @ 10:54 AM *

Link | Top | Bottom

mjones



mjones's Gravatar

Joined: 09/17/09

Posts: 47

RE: Forms module bug (Version 5.1) (#3702)
09/17/09 10:08 AM

That's odd. The forms work fine for me on non-homepages. Could this have something to do with URL rewriting? I'm not currently using any as I'm just getting my feet wet.

I have a form on /contact-us/. When submitted, the URL is /siteid/index.cfm/contact-us/index.cfm?nocache=1

That in itself could be done better in some way, but doesn't seem to break anything, in my setup at least. For the record, the HTML output shows <form action="index.cfm?nocache=1"> which will just append the index.cfm to the URL you're currently on. If I try to go to "/contact-us" I'm redirected to "/contact-us/", so that's all consistent. If URL rewriting was in place to drop the siteid and "real" index.cfm, I could see this causing issues, though.

I'm assuming your change results in the form tag just showing action="", which would submit back to the same page, query string and all. That's how I write 99% of my own forms. If you say action="?nocache=1" you'll submit to the same page but overwrite the URL variables, which might be closer to what this is trying to do.

Link | Top | Bottom

8riaN



8riaN's Gravatar

Joined: 07/17/09

Posts: 66

RE: Forms module bug (Version 5.1) (#3702)
09/22/09 3:52 AM

I get it now.

Of course it is related to the SEO friendly URLs. I had not understood the intent of configBean.getIndexFile(). I had mistakenly assumed it meant the main site default file, and so followed advice to change the indexfile attribute of config/settings.ini from

indexfile=index.cfm

to:

indexfile=/

which lost context information about the current page from the path - I changed it to

indexfile=./

and I was able to put back the original javascript - protecting forms from people doing strange things in the forms manager, and incidentally solving a bunch of other problems I had encountered along the way.

I'd like to pull the bug tracker post http://trac.blueriver.com/mura/ticket/3702 since this thankfully wasn't a bug, but I can't as it posted anonymously. If I could, I'd help them by cleaning out all the Cialis spam in there...
* Last updated by: 8riaN on 9/22/2009 @ 11:00 AM *

Link | Top | Bottom

Next Page

Page: 1

Previous Page