wezhind

Ensure you have set the correct email address in the $to variable. It's difficult to know what your issue is unless you post your current code though. http://php.net/manual/en/function.mail.php http://email.about.com/od/emailprogrammingtips/qt/How_to_Send_Email_from_a_PHP_Script.htm http://www.w3schools.com/php/func_mail_mail.asp Every one of the above pages explains how to use the mail() function. I advise care regards security once more. 'Popups' are achievable by several means - again, a short trawl through the first page of results from your favourite search-engine will provide you with examples on how to achieve this. However, it would be worth bearing in mind from a UX point of view, that the method of displaying an item the user has to dismiss before they can access the page's content, should be used only at apposite times. i.e. if a user is about to delete something that will be irretrievable. Why can't you just show the 'Thank You' on the page in a highly visible manner? Anyway, it's not for me to dictate your strategy, I merely offer information. If you do continue the 'popup' route, you might consider jQuery or some other javascript library. Good luck.

Hi. Been away for a while. Not sure of the status of this issue. However, if as CroNiX mentioned a couple of posts back, the $_GET variable is being manipulated, you could 'cheat' and send your info serialised in some manner. Rough example: I don't know the maximum value that your team variable will reach, but say it's under a thousand then you could format the team to be a 4 digit string and add that to your nameFull info i.e. '0016EvanBorger' and then use substr() to split the string into the 2 values you require. I know hardly anything about the workings of WordPress, but is it possible that it only allows one 'value' in the $_GET variable. Does it use a serialise type method to pass variables using the $_GET itself? I don't know... it just popped into my head as a possibility.

Regards session_unset() and session_destroy() make sure you have called session_start() before you use them. http://php.net/manual/en/function.session-unset.php http://php.net/manual/en/function.session-destroy.php - generally both are used. Here is a simple rundown of sessions, including session_unset() and session_destroy() usage. http://www.w3schools.com/php/php_sessions.asp

I'll have to think about your second post, but regards the site logging you out on an android phone and not on the others, this may be due to the way that Chrome (which I presume is the browser they are using on the android phone) has issues with absolute filepaths for links on pages that use sessions, I only discovered that myself this week when I was told that my navigation bar (which had absolute paths i.e. http://www.mywebsite.com/somefolder/index.php) wasn't working for logged in users - they were being booted out when they clicked one, BUT only on Google Chrome (no problems with Safari, Internet Explorer etc). I can't categorically state that it IS the issue, but it might be why your friend's android phone is kicking them out. Are you using absolute paths or relative paths for your links between page A - page B and page C? Just a thought. Good luck.

Yeah definitely read Jacques1 comments. I am aware that closing a browser doesn't necessary kill the session - it's the session timeout that does that - but that's why I included the words (if they come back a while later) - also I didn't want to add more confusion. ( I was a teacher once and am acutely aware that too much information can destroy ones ability to learn or understand as quick as too little can). Regards the 'Remember me' option - as Jacques1 stated, they are difficult to implement correctly - so I also would advise that you just forget about them for now, I was merely giving an example of 'cookie' use as opposed to 'session' use. I wasn't suggesting you used it for that purpose. Regards 'standard' being a colloquialism, no it's not. I was using it to highlight the difference between a cookie (the type saved on the users machine) and a session. They both use what are referred to as 'cookies', but act differently. So I was using 'standard' cookie to signify that I wasn't talking about a 'session' (or session cookie). Also, I don't understand why you need to use different methodologies for a mobile and one for a desktop! I have got approx. 50 websites that work on both, without a change of session code. I could be wrong, but a session is a session regardless of whether on mobile or desktop browser. Anyway, DO take note of Jacques1's concerns. Good luck. p.s. until you understand what you are doing I WOULD NOT start changing things in your php.ini file just yet - despite Jacques1's mention that you can change session settings (timeouts etc) through it. Understand what you've got already before adding more layers of complexity.

Note, though the code above from chriscloyd should work as a contact form that sends you an email - you MUST apply some form of security to the data posted by the user otherwise you'll swiftly find your database corrupted or your contact form becomes used for sending spam mail. ALWAYS, always validate the user somehow - even if its just one of those annoying captchas. Good luck.

I've got a little bit of time, so I'll try and explain, BUT you really should do a tutorial on sessions. A simple one to begin with just to get the basics. I'm going to ignore the 'standard' cookie approach for now and just try and explain session cookies. I personally only use 'standard' cookies for things like when a user checks a 'Remember me' checkbox when they login, so next time they return to the site - the site looks for a 'standard' cookie previously saved (when they logged in with the 'Remember me' checkbox checked) and if it finds it, it bypasses the login procedure and they are automatically logged in). For the purposes of determining if somebody is still logged in from page to page, I use the appropriately named 'session' cookies. This seems like what you are trying to do, so I will explain this side. Firstly, EVERY page that a user will visit between logging in and logging out should have session_start() at the top of the page. There should be no output to the screen before this (i.e. no echo statements, no html). So your first line of every page should look similar to this... <?php session_start(); //this resumes an existing session if it exists or starts a new one if it doesn't ...UNLESS you want to configure something about the session i.e. where on the server the 'session' cookie should be stored. This is usually unnecessary, but if configuration is required then those settings must be made before the session starts and would therefor look like this: <?php session_save_path('/home/admin2/public_html/sesh'); session_start(); Note: the path you used would mean that the 'session' cookie would be stored in the public part of your site, which I wouldn't advise. I believe the default would be safer. So that's the first part. For now, I would just stick with session_start(). Do not configure the session in any way. You now need to determine if this is a new session or a continuance of a currently existing session. This can be done by checking to see if there are any variables stored in the session - if there are, then this is a continuation of currently existing session. If there aren't then a new session has been started and doesn't have any variables set. This can be achieved firstly by using the isset() function. SO, so far we would then have: <?php session_start(); if ((isset($_SESSION['user'])) && ($_SESSION['user']!='')) //checks if session variable 'user' is set and not empty { At this stage it is only fair to tell you that if you want to allow a person to exit from their browser (i.e. close the program) and then re-open it a while later and still be logged in if they visit the page - then you will have to use 'standard' cookies. Research setcookie() for PHP 'standard' cookie handling. A 'session' cookie will most likely be lost under such circumstance - whereas a 'standard' cookie won't. So the next thing is to grab the session variable 'user' (which could be checked against a database to ensure it exists - but we'll leave that for the moment). So, the code so far, will check for a session and if it exists will assign the value of it to a php variable. <?php session_start(); if ((isset($_SESSION['user'])) && ($_SESSION['user']!='')) //checks if session variable 'user' is set and not empty { $username=$_SESSION['user']; //save the value of the session variable 'user' in the PHP variable $username $user_session_lives = true; //set a flag to say that session is still 'live' } else { $user_session_lives = false; //set a flag to say that session has expired OR doesn't exist } SO that is the basics of sessions. The other parts you were using - specifically the last access stored in the session - don't apply unless you are then storing that information in a database and checking it when the user returns OR if you are storing it in a 'standard' cookie. You are storing it in a 'session' cookie which is a bit pointless as if the session is lost (expires or user clears/exits browser) then that information is destroyed - so you can't use it to determine how long ago they were logged in for instance, but as with the $_SESSION['user'], it can tell you whether they still have an active session. However as you can already tell this by the fact that $_SESSION['user'] exists this isn't serving any purpose as a 'session' variable - but would/could as a 'standard' cookie - set with setcookie() (http://php.net/manual/en/function.setcookie.php). I was going to explain a little more - but it's late now and I'm feeling a little sleepy. However, I hope I've managed to help you understand the use of sessions, understand the two types of 'cookies' and which is applicable for what. I'd advise (as other contributors to this page have already done so) that you learn to work systematically. Start with the foundation blocks and then slowly increase the complexity once you've thoroughly understood the core you have built. Adding random bits of code just gives you more issues to sort, but doesn't necessarily solve the issue you originally added them for in the beginning. Start with the simple session management, then add the 'standard' cookie stuff. Good luck.

p.s. I didn't dislike the idea - and I can see what you were trying to do. Don't stop having ideas mate - no matter how much value you think another places on it. Everything starts from some 'crazy' idea. Good luck with yours :-)

Say somebody using your web-page decides to use it to load a webpage that does automated attacks on somebody elses site (i.e. loads the webpage 10000 times a second or something). That means YOU are responsible for allowing that person making the attack to hide behind YOUR website/IP address.... which means the FBI/NSA or whomever are going to coming to YOU first when they track back from the attack. You're also in danger of creating infinite regression... what happens if somebody opens the page they are already using (your page) inside the browser on your page, and then open it again in the browser on that page ad infinitum....? Can you write code to handle that kind of potential issue? No offense, but from what I've read here, I am assuming that you aren't even approaching that kind of coding level. Go ahead and try if you want, but you are basically just willingly walking into a field after having been told it's full of mines and quicksand. Like I say, I'm all for experimentation, just to find out what will happen....but that's up to you now. I think you've had all you need regards our opinions/expertise on the subject. Good luck with whatever you decide to do.

So what happens when you echo $_GET['nameFull']; and echo $_GET['team']; What info does it show? Also what does the $query look like? Perhaps echo $query also to see what SQL is being created? Are you certain team isn't being passed and the query has another type of error? edit: sorry just noticed you echoing $team already. but would be interested to see what is in nameFull when echoed.

Use the method I supplied to create the correct date+1mnth (the first 2 steps) and then just include the variable you've created in your output. Let me know if that works. edit: like this $query = sqlsrv_query($conn, $sql);if ($query === false){ exit("<pre>".print_r(sqlsrv_errors(), true));} while ($row = sqlsrv_fetch_array($query)){ $thedatetouse = $row['start_date']; $dateplusamonth = strtotime(date("Y-m-d", strtotime($thedatetouse)) . "+1 month"); echo "<tr> <td><a href='view_invoice.php?meter_id=$meter_id&subaccount=$subaccount&start_date=$row[start_date]'>$row[meter_id]</a> </td> <td>" . date("F Y", $dateplusamonth) . "</td><td>$row[invoice_no]</td> <td>" . date_format($row['invoice_date'],'Y-m-d') . "</td> <td><a href='approve_payment.php?meter_id=$meter_id&subaccount=$subaccount&start_date=$row[start_date]'>Pay Invoice</a></td> </tr>";} sqlsrv_free_stmt($query); ?> http://php.net/manua...nction.date.php http://php.net/manua...n.strtotime.php

Basically what it means is Google are actively attempting to stop you doing what you want to do by using response headers to tell your browser (Internet Explorer, Chrome, Firefox or whatever) not to show external content in iFrames/frames etc. There are many sites that attempt to block their content from being shown on another in the same way. However, they often supply APIs to allow you to still use their services (i.e. Google search, Google maps etc). Here's a link to an explanation of the x-frame response header (on Mozilla Developer Network), worth having a quick look if you want to know why your currently proposed methodology for your project will cause you problems: https://developer.mozilla.org/en-US/docs/Web/HTTP/X-Frame-Options?redirectlocale=en-US&redirectslug=The_X-FRAME-OPTIONS_response_header I think I understand what you are trying to do. I must tell you that there are already several 'snippet' plugins/extensions for browsers available that in some sense already do what you are attempting. I'm not saying don't do it (experimentation is a wonderful thing ... mostly), but you are kind of re-inventing the wheel. Good luck.

This should do it. $todayDate = date("Y-m-d"); $dateplusamonth = strtotime(date("Y-m-d", strtotime($todayDate)) . "+1 month"); echo date('F Y', $dateplusamonth); http://php.net/manual/en/function.date.php http://php.net/manual/en/function.strtotime.php Good luck.

You're running the query twice. YOU need to go and learn how this works from either the manual (php.net) or do a tutorial. Most of the issues you raise are debugging issues - not coding issues. Most of your errors are simple, obvious errors, which if you understood what you are doing, would be obvious to you also. SO, go take that tutorial or read the manual, there are plenty of examples of this on the net. Your issue is with the following line s you don't need to run the mysql_query twice. If you understood what you were doing you would know this and would be sorting these obvious issues out yourself. $query0 = mysql_query("SELECT username FROM Users WHERE mxitid=$mid", $conn); $result99 = mysql_query($query0); Good luck.

Have you made the changes suggested? Do you have a better understanding of sessions now? Perhaps you could post what code you now have for us. edit: does session_start() exist on each of the pages you are visiting?