Users will enter information on 4 separate pages and click a 'continue' button that takes them to the next page.
I know I shouldn't prevent users from going back and entering information again, but I also need to set up something that doesn't allow users to do something like this:
www.page.com/setup1 -> www.page.com/setup3 -> www.page.com/setup4 -> www.page.com/setup2
Right now they could possibly go in any order they want if they just enter the URL.
$URL = $_SERVER["HTTP_REFERER"];
if($URL == "http://page.com/setup1") { blah blah }
I have a variable that handles the page that they came from, displaying certain information based on that. Is there a way to use that variable to handle my issue? If not, what is the best way to tackle this issue that might arise?
Instead of using four pages, write one and work with JQuery which enables you to show and hide successive fields etc. Use Ajax calls to provide any dynamic information such as selectors based on previous answers. Those can populate DIVs or SPANs which carry hidden default responses . There is at least one excellent Validate plugin that works with JQuery so you ensure all fields are correctly completed.
The advantages are an enhanced user experience, faster responses with reduced server load. It also means that if they want to change earlier data you can handle it all via Ajax and a good plan.
Before adopting the above approach, I used to use one framework page to post back to itself using hidden fields to control the flow, passing data with increasing numbers of post variables and nested if's. I made it managable with lots of include files to do the updates and new fields
My issue was solved through session variables. Each page has a session variable called 'steps'. Each step has a number associated with the page that they are on. If they previous session 'step' was not the correct one, it redirects them to the appropriate 'step' page.
$steps = $_SESSION['steps'];
$_SESSION['steps'] = 3
For example, this must be the 3rd page, or 'step' in the sign up process.
If $steps isn't == 3, I have code that redirects them to the start of the sign up process, destroys the session and they must sign up properly.
Related
I'm working on big site and it has filtering of cars in it. I'll explain how the form filtering works:
so the user chooses filter options, car number and so and presses go, which makes GET request to server (php) i've changed every variable from $_GET to $_POST and changed form submission method, the problem is that when form returns big number of items it might have more than 2 pages, so when the user clicks on second or third page all this code does is add page number to the request like this: www.example.com/GET_REQUEST_VARIABLES -> www.example.com/pagenumber&GET_REQUEST_VARIABLES. that way server returns second page items and so.
but when i send post request, it isn't saved in the url so server doesn't know what to return,
can you help me solve this problem?
i can explain better if you ask questions i don't know if i explained clearly here
Is there a reason you are using POST instead of GET? Using GET is more SEO friendly in this case. And since you aren't sending sensitive data in the form submission, I don't see a reason to use POST. Another advantage of using GET is that you can directly link to search results. (For instance, if I search for a Honda Fit, and want to show my wife, I have a direct link to the page)
(Look HERE for a bullet-point explination of the difference bewteen POST and GET).
To answer your other question, POST does not use the URL. Only GET does So if you need the form data to be serialized into the URL, you'll need to use GET. Since you changed the form submission method to POST, you'll need to change the server side logic as well to accommodate. I can't be of much use without knowing what server-side technology you are using. Assuming you are using PHP, you could start here
If you aren't much for MAN pages, just change all the $_GET['fieldName'] calls in PHP to $_POST['fieldName']
You could always POST the first page, and use GET ONLY for the page number. In the form you would just do this
<form method="post" action="www.foo.com/search?page=1">
Then you can store your POSTed variables into the $_SESSION super-global. BOOM. POSTed pagination. It would be a breeze to render it on the fly with PHP
$nextPageURL = 'www.foo.com/search?page=' . $_GET['page'] + 1;
if($_GET['page'] !== '0'){
$lastPageURL = 'www.foo.com/search?page=' . $_GET['page'] - 1;
}
This is the situation, I've got a big array ( 280 items ) which creates a really big form by going trough loops.
I want the user to be able to disable certain items, so they can 'pre make' their form ( and skip the not used ones ), You are probably going to say i can just remove what's not needed. But they need different items from the array every time they use it.
So how would i make a page where they can just use checkbox to 'change' the form. ( if possible at all.)
Thanks,
Mike
edit:
Did not think of sharing code, here:
The array : http://pastebin.com/EnwHsqtK
the form : http://pastebin.com/y2XSFBG4
the page which makes a .txt file from the given answers. http://pastebin.com/UaUcsj2z ( not sure if anyone would need this. )
Might be a bit messy. I'm new in PHP, and only programming for a year. Also dont mind the language please.
If you want to permanently record form preferences/settings for each user, you'd want to create an additional table or column(s) in your database for this, give the users additional checkboxes on the form to indicate their preferences, receive this input and store it in the database, and of course finally disable certain fields based on their settings.
But if you just want to give the users a temporary way to disable certain fields (with no preferences saved permanently), you would use JavaScript in your output. You would add more form controls (checkboxes or buttons or whatever) to the HTML and then add JavaScript code snippets into that HTML to disable form elements when the user clicked on the controls. This kind of making changes when users click is called "triggers that fire based on events". The most commonly-used event is called "OnClick()" and the JavaScript code for it will execute when a user clicks on something.
Many folks who use JavaScript also find it helpful to use the functions in the jQuery library instead of raw JavaScript. To do this, you just add one line of HTML to the top of your page to include the JavaScript libraries from a publicly-hosted server, then you can use jQuery commands in your page.
The only thing to remember when you first start using JavaScript/jQuery is that it only runs on the client browser - its code cannot talk directly to the server, the database, or many things you can access in PHP. JavaScript/jQuery is specifically used for making your HTML pages more interactive. Plain HTML doesn't have much razzle-dazzle. JavaScript allows users to do things like enable and disable form fields on-the-fly.
Potentially silly question, but I'm looking for the most sensible mechanism by which to maintain and "resubmit" POST variables. Basically the workflow is as follows:
STEP 1) Select charges to pay, and enter payment info
STEP 2) Display confirmation/summary page with option to "PROCEED WITH PAYMENT" or "EDIT INFO"
STEP 3) Return to "edit" form or send data to be processed.
I'm currently using a single page for all actions (just one giant SWITCH based on an "action" var) and submitting the information. The problem I'm having is that between the "confirmation page" and either option, I'm losing my POST data (which I understand). What I need now is a way to preserve that data without duplicating the input fields in each SWITCH section. Below are a few options I've considered. Feel free to comment on the merits or stupidity of each:
1) serialize it to a SESSION var then unserialize it?
2) simply key/value it into a SESSION array?
3) recreate every INPUT for each "form" presented and refill the values
4) put the SWITCH inside a single form and only display relevant portions
5) I would handle it all with Javascript (sort of a faux submission technique), but there is currently processing that occurs between the initial form and the summary and ajaxifying that would be a beast atm.
What's the recommended course of action for the classic INPUT->CONFIRM->PROCESS process? It'd be amazing if I were just missing something über obvious/simple.
FYI: Currently using PHP 5.1.6
Best!
EDIT 1
Clearly using individual pages for the various functionality is desired. The only reason I'm not using separate pages is because other pages are dependent on this one page and management won't allow a clean break at this point in time. It was poorly constructed over 3 years ago and is just now being partially addressed.
At this point I'm using:
foreach($_POST as $key=>$value)
<input type="hidden">.......
...in order to achieve the desired goal.
serialize it to a SESSION var then unserialize it?
simply key/value it into a SESSION array?
Very bad. Clicking "Confirm" should always confirm what is being displayed on the page, not what happens to be in some nebulous session stored on some server somewhere (which may not be the same server that served the previous request if you have a load-balanced cluster).
There are plenty of websites out there which will try to detect when you press the back button and display an error page, probably for related reasons.
recreate every INPUT for each "form" presented and refill the values
You need to do this anyway for the "go back to editing" page.
What's hard about <input type="hidden" ... /> in a loop on the confirmation page?
put the SWITCH inside a single form and only display relevant portions
You mean stick all the inputs in display:none for the confirmation page? That feels ugly too.
Firstly, breaking it up into multiple pages might be a good solution but I don't know your specific needs.
1 and 2 are bad ideas. That being said, I don't know what you gain out of serializing and unserializing to a session variable that you don't get with simple key value pairs in the session. Session management gets pretty hairy if you are running multiple servers behind load balancers
4 Just sounds odd. I don't know what the switch gives you here. If you ever have to use conditional logic to display a completely different functionality to the user, it is probably better of being on a separate page.
5 Faux submission? Just sounds like a kludge. You mean send the data back to the server and return the same data back and display the confirmation div? Why not just use Javascript and manipulate the DOM at that point? Nevertheless bad idea.
Just repost the parameters to the confirmation form and populate the confirmation fields accordingly. (Standard process). I think that is what 3 is but I suggest you use a different page for each step. Just keeps things clean.
I actually ended up using
<?$forward_post_data = base64_encode(serialize($_POST));?>
<input type="hidden" value="<?=$forward_post_data?>"/>
...I then decode it as necessary. It works perfectly.
How do I create a form that spans over multiple pages? I would like to ask a large amount of questions, and based on the answers of previous questions, new specific questions will be asked.
Traditional method: store all the previous answers to questions in <input type="hidden"> fields on subsequent pages, so that the last form contains the entire submission (only not all visible). Drawback: file uploads are annoying to remember, amount of data can get large.
Common method: throw answers-so-far into the session or cookies as you go along, picking them out at the end. Drawback: concurrent operations end up with unpredictable conflicting results. File uploads still annoying. I would avoid cookie/session storage solutions for this.
Modern method: have a simple (long) single form, but use JavaScript to show only part of it at once. On clicking ‘Next’ you simply hide the previous page worth of content and show the next. The last button is the real submit button.
There are several ways to do this:
Incrementally populate a database, submit by submit
Keep all form fields on every page, but hide (<input type='hidden' ...>) the ones that shouldn't show up (as #Trufa suggests in another answer)
Accumulate an object that's persisted implicitly in the session (depends on your server architecture)
Accumulate stuff in one or more cookies (seems icky by I list it for completeness)
If you wanted to be super-trendy, you could accumulate information in HTML5 client-side storage. Of course that'd rule out older Microsoft browsers.
There isn't such a thing as a single form spanning multiple pages: each page/form is independent of the others.
If you somehow keep track of what has already been entered (possibly in session variables), then you can just display the new questions in a new form until you have all the data you want.
I'm assuming that by your question, as there is no such thing as a multiple page form, you mean how do you build up a set of answers from a user by using multiple pages, each containing a form.
The mechanism PHP supplies for such things is the session mechanism. You'd build up the set of answers in the session as the user submits each page, and when you have a complete set the full set of answers in the session gets committed to the database.
This isn't the only approach of course, you could also incrementally add the data to the database on each page submit, but then you will end up with partial answer sets where people have only done the first page or first few pages and then abandoned it. You'd have to write code to handle these partial submissions.
I am trying to develop a registration page which involves three separate information.
First Page will get contact details
Second page - working details
Third page - study details.
How to keep the form data of the previous pages before posting the form?
You could do it with Ajax - multiple divs and hide/show the appropriate ones.
Or you could POST each page and save the data in the $_SESSION global variable until all pages are complete. Then save it all to the database.
While the other answers are certainly good ideas, you may also want to consider persisting the intermediate data to your database between each page. So, submitting the first page would create the new row, with the columns relating to contact details populated, and a status column set to a value indicating that the submission is not yet complete.
The second page would update that record in the database. The third page would also update the record, as well as the status flag to indicate the submission is complete.
The main benefit to this is that the user can walk away after the first (or second) page, and then return to it later, even if he had closed his browser and his session had expired. (As long as he has a unique URL to return).
This approach might not have a lot of benefit if you are only collecting three pages of data, but if you had many pages, the ability to leave and return later might be more important.
You should take a look at http://jqueryui.com/demos/tabs/, it should be able to do what you need.
While shifting to another page, you just put the values of first page variable in sessions, then you can access the value of previous page at any page, then post the value to the database query. In this way, you can use the use the value of first page at third page, up to when browser is open. As the browser close then variable lost their values.
Back in the day, I would've put hidden fields for all of the previous pages in each subsequent page, so the final submit would have everything... i.e.
Now, I would probably only have one actual page.. with multiple steps implemented by showing/hiding div's and collecting all of the data in one big form, broken up visually for the user... and if I was feeling especially frisky, with frequent validation and final submission through ajax.