Hi,
I solved multiple page problems for my postcards plugin, fairly simply, but it requires a change to add.cgi. The suggestion posted here won't work, because add.cgi doesn't know to just pass the data back out to a "confirm" page. You need to modify add.cgi to check the "submit" parameter and do something different if the form is not on the last page. ( "confirm" pages can be set up the same way, just pass in an add_confirm page and allow a user to confirm/preview the results. This can go on as long as a user presses "preview". Once they press "confirm" they get the "add_success/fail" page.)
There is an option to use one page, or follow a form through step by step.
What you need to do, basicly, is to have a script just pass all the data it got in, back to the next template page, until it gets a "done" or similar command.
Make sure you write out all the tags, and while it's extra coding, it's _best_ to hard-code the tags you expect to get back into each template (that prevents users from trying to do nasty things).
On the first page, you get something like "add1.html" as the template, and when the user submits this, a "doNextPage=add2.html" tag is passed back.
The add.cgi script just looks for "doNextPage" and if it's not empty, it passes the data in %IN to the SiteHTML::display routine with the template set as what is in "doNextPage". If it's equal to "submit" then go on to the "add" routines. (actually you test for this before you jump to the next template).
Links will give you errors if the template doesn't exist, etc. so you don't need to worry about it -- unless you want to do something like track hack attempts.
add2.html _should_ have hidden tags for all the data it just passes through, "text" or whatever fields for data you want the user to still be able to change or add. You should *not* use a routine that takes what's in %IN and generates a hash -- this is a security hole.
Each successive template will have more and more hidden tags (and/or visible ones).
You can do this as many times as you like, the script _doesn't_ care as long as it gets a valid template name to pass it on to. Once you get to the last page, just pass in 'submit' and the script will process as per usual.
It's a minor "pass through" change to add.cgi. *everything* else is pretty much built into links.
Postcards.cgi does some extra checking to validate fields, check dates, etc. but it's add routine is just a glorified add.cgi with multiple page pass throughs.
If you don't want to modify add.cgi, you can write a short script that you call instead of add.cgi, which just passes the data back to the next template, then on the last template, just call add.cgi with 'submit'.
PUGDOG� Enterprises, Inc.
The best way to contact me is to NOT use Email.
Please leave a PM here.
I solved multiple page problems for my postcards plugin, fairly simply, but it requires a change to add.cgi. The suggestion posted here won't work, because add.cgi doesn't know to just pass the data back out to a "confirm" page. You need to modify add.cgi to check the "submit" parameter and do something different if the form is not on the last page. ( "confirm" pages can be set up the same way, just pass in an add_confirm page and allow a user to confirm/preview the results. This can go on as long as a user presses "preview". Once they press "confirm" they get the "add_success/fail" page.)
There is an option to use one page, or follow a form through step by step.
What you need to do, basicly, is to have a script just pass all the data it got in, back to the next template page, until it gets a "done" or similar command.
Make sure you write out all the tags, and while it's extra coding, it's _best_ to hard-code the tags you expect to get back into each template (that prevents users from trying to do nasty things).
On the first page, you get something like "add1.html" as the template, and when the user submits this, a "doNextPage=add2.html" tag is passed back.
The add.cgi script just looks for "doNextPage" and if it's not empty, it passes the data in %IN to the SiteHTML::display routine with the template set as what is in "doNextPage". If it's equal to "submit" then go on to the "add" routines. (actually you test for this before you jump to the next template).
Links will give you errors if the template doesn't exist, etc. so you don't need to worry about it -- unless you want to do something like track hack attempts.
add2.html _should_ have hidden tags for all the data it just passes through, "text" or whatever fields for data you want the user to still be able to change or add. You should *not* use a routine that takes what's in %IN and generates a hash -- this is a security hole.
Each successive template will have more and more hidden tags (and/or visible ones).
You can do this as many times as you like, the script _doesn't_ care as long as it gets a valid template name to pass it on to. Once you get to the last page, just pass in 'submit' and the script will process as per usual.
It's a minor "pass through" change to add.cgi. *everything* else is pretty much built into links.
Postcards.cgi does some extra checking to validate fields, check dates, etc. but it's add routine is just a glorified add.cgi with multiple page pass throughs.
If you don't want to modify add.cgi, you can write a short script that you call instead of add.cgi, which just passes the data back to the next template, then on the last template, just call add.cgi with 'submit'.
PUGDOG� Enterprises, Inc.
The best way to contact me is to NOT use Email.
Please leave a PM here.
