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?

Do you want to show 'other related articles' or do you want to show links to 'other related articles'? Have you decided how you want it to look? How many related articles you want to show? Perhaps start by attempting to rough out what you think should happen to show related articles and what type of information you would require to be able to link one article to another in such a manner. Have you written any code at all yet? If so, maybe you could post it here.

Hi, I think (though could be wrong) that this may be the reason. I found an issue somebody was having with preg_match on stackoverflow that seems similar and could explain your issue. Here's the link: http://stackoverflow.com/questions/21063742/greater-than-and-less-than-symbol-in-regular-expressions The answer by boris the spider - at the top when I looked - is the one you're looking for. Good luck.

On php.net - http://php.net/manual/en/function.session-save-path.php I realise CroNIX has already conveyed that to you...just thought I'd reinforce that and Jacque1's advice regards understanding sessions.. Let us know if the fixes suggested here have worked when you have applied them. Good luck.

It's kind of pointless as pointed out by Jacques1, as users will just add other types of characters, but you could create a function that adds and removes spaces and then compares the results to the database. This would be quite db intensive though as there would be a lot of variations to compare. You could force users to only use a comma, space, and an alphanumeric character (I.. a-z, 0-9) when entering the address which would minimise some of the variations they can use. Another option I've just thought of, would be to count the spaces in each line of the address and any line exceeds a certain number (6 ?) then the user is told that the address is invalid (and why). This would also limit the no of variations a user could create. I don't think you are ever going to get a perfect solution - just by the nature of the issue - but even minimising the no of extra free products you have to send out will save you (or your client) some money in the end. Ok, nothing else springs to mind currently, but if I think of anything else I'll post it here. Good luck.

Cool. Yep, I understand you are new to the language and going for the simplest scripts to aid understanding etc - just thought if I poke you now regards security then you will hopefully be thinking about it in regards to scripts you view or use - even if you don't yet use it just yet. Good habit to form early - it should be ingrained :-) Have to agree with you regards php.net and new php coders - but one day it will be one of your dearest (even if still slightly incomprehensible) friends. Good luck with your learning. Glad you solved your issue.

echo"</table>"; is possibly another error. (requires space after echo) It's never a bad idea to view the source of the html that is produced by the php. Most modern browsers will allow you to right-click and view source (or in one of the menus on the standard toolbar - if you have it enabled). It's worth running through and seeing if what is produced makes sense i.e. that all the tags/elements that are open are closed etc.. The script above for instance, doesn't close the <tr> tag on each loop. I also have some issues with where the <form> tags are placed - but I'd have to check the validity of my belief and it's late You can always copy the html you find using 'View source' and use a validation service like http://validator.w3.org/check to check for obvious mark-up no-no's. It's not the 'be all and end all' of validators - but it will help a little with creating well-formed html and 'bug' hunting. Hopefully, any further tutorials you read/use will also introduce and strongly persuade you to very carefully think about the concept of security. In the case of the script above, it is taking a user's input and then without validation is inserting it straight into a database. Who knows what the user has just sent you - could be some disguised MySQL command that deletes all your records?! http://php.net is a great place for checking out functions available to you through php. I'm sorry if I'm telling you stuff you already know, but I had 5 minutes and thought I'd attempt to pass on a few (hopefully) useful bits of info. Good luck

Also I believe you need a space between echo and string containing the form element here: echo"<form action=mydata3.php method=post>"; Good luck

Could you clarify please. Please describe what is happening and what you expect to happen a bit more if you can. You say the problem is with AJAX calling. Is it returning the wrong info or no info etc Or do you mean it isn't even calling the other page? Are you getting an error like 'page not found'? Is it getting to the alert(). Can you give us a little bit more to go on. edit: just had a quick read through...can't spot anything obvious at error on first run through. Only thing I can think of and this may not make any difference at all (and correct me if you know better - js not my strength)is: have you tried using the filename in the filepath the ajax is loading rather than just using the path and assuming it will automatically use index.php? In the code above it looks like you haven't named the file it should be loading. LIke I say I don't know if this will make a difference. Let us know the result either way. More info would be great. Good luck.

You appear to be referencing the username ($userID) as an integer in your SQL: $query = "SELECT * FROM meal_info WHERE username = $userID"; //our SELECT statement whereas it should presumably be a string/text? so your sql should probably be more like this: $query = "SELECT * FROM meal_info WHERE username = '$userID'"; //our SELECT statement Good luck. p.s. wrapping your code in the <code></code> tag or clicking the <> button on the textarea controls would make it a LOT easier to read your code etc.

Yes, it's definitely possible to turn it into batches. Various methods available to do so, but you will probably have to change the structure of your code a little to accommodate that. I suppose it depends on how many messages you are likely to send. If it's only a few multiples of 500 then you could probably store each batch in a separate array and then loop through the arrays and then loop through the content. If you're talking serious no.s though you may want to find a less memory intensive manner of achieving this I'd imagine. Good luck.