ginerjm

I agree with Psycho's response and the idea of saving on the delete. Just add the token field to your one table, along with a time field for it to limit the amount of time the user has to respond to his/her activation/reset email.

The php loop will happen on the server so the mouse over effect is moot at that point. The script will do its thing and return whatever to the client. At that point your html/css can hide the div if you want and a little JS can 'show' it upon mouseover. Two separate processes.

Not sure what record you would be deleting in the database. A 'user' record, once established, should remain so that it doesn't have to be re-created with the user's help. Doing an account activation and a reset are similar as you suspect and no, the passwords would never be in clear text, if done correctly. Why do you think google is doing something like that? One doesn't submit a hashed password. The script receiving it does the hash before querying the db.

ONe solution might be to isolate your login code to a separate login script that when successful saves a token for the session. This script (upon success) would re-direct you to some other script that does whatever function is needed. That script would only need to check for the existence of the token (or more stuff) to allow it to operate. In this way you remove any possible conflict (unresolved) between the two pirated code samples you have.

Having used the php mail() function for awhile I have found that you really don't get any feedback from it. Even the response (true/false) isn't to be trusted. Many people here will tell you to seek out another mail program such as phpmailer, but I haven't attempted to install it as it seems rather complicated and not necessary for my uses. It may however be something that you want to explore if your need to ensure delivery is strong enough.

Loop thru the results storing the values into an array that holds the values for each month. $ar['mth1']['val1'] += (amt); $ar['mth1']['val2'] += (amt); (rough code and un-tested) Then output your $ar values as you want them. You'll have to check for things like if either date falls in your desired months before saving its value. PS - couldn't you simplify your query by just looking for a start date and end date instead of all the functions?

Does $column contain any spaces? One should really wrap associative indices in quotes to ensure there is no problem in determining the correct element of the array it is used on. $row["$column"] would be correct. BTW - you are doing a query that selects all rows but only returning the first row's value. Is that what you want?

I would have expected you to actually show us the LINE IN QUESTION instead of talking about some function working "fine". Your line numbers (a PIA when you cut and paste your code!) - are they really the line numbers that the error message refers to or just some editor lines numbers that you pasted here? The line: $id = $row['id']; certainly doesn't have any problem so the " in the error message must be located somewhere else. Does the error message refer to another file perhaps?

That code doesn't really show us anything. A session is not just for a form - it is everything that you specifically save as a session variable, regardless if it has anything to do with a form. Assuming that you have the session start at the top of THIS script, what does your following script have for code? And just what is that little snippet (poorly placed IMHO) doing for you? Is that the 'following' script? Why aren't you just using a header command from php?

That is part of the beauty of retirement.

I don't write for nor expect to appeal to international users. If you want to use my apps learn English. My apps are designed to work just like all of the code I have written for the last 40 years. Yes - the web environment is newest to me, but that doesn't mean that the same principles can't apply. Furthermore this learning process has taught me that you need to be careful about what you get from the user. Well - if I don't get the exact input that I am expecting then all is suspect. How can you dispel my logic on this point Jacques? If someone wants to somehow, someway send me input via ajax when I didn't design for that - it is their problem to deal with and not mine. Yes my browser and other experiences have been limited by what I have tried in a few different environments. Yes - I have experienced problems with my code for some older browsers but that has only been with the JS portions - and never with the PHP. Despite some people's research results, I have not had a problem with testing for a submit button value in IE8, nor in the later versions of that as well as Safari and Chrome.

Kicken, Thanks for your reasonable response. It appears that I am not doing anything wrong in my current style, although I have yet to experience any 'missing button' phenomena. Should the future alter the current behavior of browsers, I am in a load of trouble!

To answer your questions: 1 - never had to use ie8 2 - just tried it with the IE emulation mode set to 8 3 - my test properly recognized the submit buttons that I clicked on and acted accordingly. 4 - there is no reference to REQUEST_METHOD in my code. I will say that the js code sure popped up with a lot of errors! And not even my js code.

I have no idea what IE8 would do with my scripts. Are you saying that the following if (isset($_POST['Return'])) would not return a true value if my users clicked on a type=submit element with that name attribute?

If the incoming data stream doesn't match EXACTLY what my script was written to expect, then I don't care at all what the input is, nor do I care that the user is doing something different. My script; my rules. If you are using my appl then you use it as I designed it. If I use post only then I will expect only post values; likewise if I only use Get. Should I have a script that takes advantage of both at separate times, again my script will expect things exactly as designed. A pretty simple approach IMHO.

So it is simply a matter of how one codes? Personally I learned from my initial readings that one designs a form with expected inputs (and names) and to use a submit button to cause the script to perform what you want it to do. So if I output a form that has several fields in it and a couple of buttons, say a Save and a Cancel button, I know what to expect in my script and to act accordingly. If I don't see either a Save element of a Cancel element in the post array then the form was not submitted properly and I dispose of the input and re-send my form to the user. To me checking the request method is a needless operation if one has designed their script properly to only look for and accept the 'expected' things. And as for those who write about accepting elements from the $_REQUEST array, those people are entirely too loose in their acceptance of input. If one designs a form to do a post, then only accept input from the $_POST array. Same for a GET. In my design style a check for request_method would still necessitate the check for the button name attribute and then the proper input names for the data that I expect. So why check for it? Same goes for those that do a check for $_POST and acting on the True/False condition that they get. Your script should EXPECT certain things and only act upon those same things and anything else should be rejected, just like expected but invalid inputs are rejected. Am I way off-base here?

The topic title is sure to get some attention and that's what I'm looking for. I have seen a couple of posts from one of this forum's members concerning recognizing valid input. It is a different method that he says is a better approach than simply looking for an existing element of the $_POST array. Here's the code he suggests we should all be using: if ($_SERVER['REQUEST_METHOD'] == 'POST') So - is this true? We should check the REQUEST_METHOD rather than simply look for the existence of a submit button's name attribute in the $_POST array? I have been only coding in PHP for 4-5 years now and have seen this line used but have only recently seen anyone say it is a better approach. In my mind it seems accurate to check for the 'expected' named elements of my html in the proper incoming array, so long as it is the 'expected' POST or GET or even REQUEST (rarely) array. Contributions? Validation?

What is the purpose of the counter? Is it simply to post to the db table?? Does it have anything to do with the input screen, or the order in which the input elements are to be handled? If itis to simply put one into the db, then set the counter in the posting loop and increment it before each inset query.

Array1 as you call it is simply an element of a bigger array. What is the correlation between the named 'array1' element and the un-named element that is the sibling to it? I don't see it. You do realize that you have a multiple level array with elements ( the [0] and the [1] ) that have no identifiers to help any program to recognize what it is dealing with. As for merging the latest post with the second(?) array you have in your original post, how is the script suppose to connect those completely separate arrays? From your original post again - you have array1 that has one element. Period. Then you have array2 that has one element. In each of them you have arrays as the values of those single elements, except array1 has only one array under the child, while array2 has 3 arrays under its child. What is the purpose behind this? They don't have names so why are they are not simply all elements of the topmost array?

No. Doing the hard work to read and LEARN something and then applying that helps you to LEARN. If you have a problem during that LEARNing process, the forum will be happy to provide the help you need to get past that LEARNing hurdle. If you want examples then you can google to your heart's content, but reading a manual or finding a beginner's tutorial (cause that is what this is) will get you on the right track. And if you are one of those who uses the excuse that they don't learn well from reading, then you are in the wrong business. Programming is all about reading (and comprehending) manuals.

Yes! One seems to have real "value" oriented data as the values while the other seems to use those "values" as keys. Pluse your one array has arrays an extra layer deeper and neither of your two arrays identify the different child arrays separate from the others. Why such a blind structure? And if this is the entire set of data, you could have manually created the desired result by now.

Have you looked at all of the array-related functions in the php manual? An excellent resource - you should bookmark it. Of course you need to look at the structure of your arrays closer. One is a 2-deep array and the other is 3-deep. What exactly do you want to merge and what kind of an array do you want to end up. Plus - you don't have like values between the arrays. One has rather unique values as the keys and the other has them as values.

Again - it makes no sense to separate the handling of this form amongst two scripts unless the form is huge and the bulk of it is already being handled by a previously written script. Chris - as for your request to 'provide an example of "set some session vars and do a header to the other script"?' - uhh, you have the wrong approach to coding, and to the purpose of this forum. What good would it do you to have us write your code? You would learn nothing from that and besides - we're here to help you learn. If you need to ask how to set session vars, you shouldn't be attempting to do what your whole post is asking about.

Why do you need to do that? Your one script can handle all the inputs for you. If you need to do this thing, set some session vars and do a header to the other script. But - it seems like a needless complication of a very simple process.

Such a simple solution. Using an anchor tag solved this problem for all. Have to wonder tho why the android device didn't respect simple html. PS - Who is 'HPierce'?