DavidAM

What exactly does that mean? Did the message NOT get sent? Did it get sent and land in the "Junk Mail" folder? Did it get sent, but the HTML is missing? Did it get sent but the message looks wrong? ... ? ? ? Add an IF test to see if the mail() function succeeds // now lets send the email. if (mail($to, $subject, $message, $headers)) print json_encode( "Message has been sent....!"); else print json_encode("Failed to send message"); Your server may not be configured correctly for sending emails. Have you ever used the mail() function on this server successfully (for a plain text message)? I don't see where you are including any HTML in the $message variable, unless you typed all of that into the form? We need more information if we are to have any chance at helping you. The From: header needs to be an email address that the server is authorized to send mail for. Typically, this is an address related to your website; definitely not the address of the user filling out the form (use the Reply-To: header for that). Be consistent with the end-of-line sequences in the headers. After the From: header you have \n, it should be \r\n (like all of the rest).

I assume you cut and pasted that filename. I notice a space inside the double-quote, before the "s". It is possible the first "character" of the name was an ANSI escape sequence designed to change the font color or otherwise hide the name from the command line. Since the browser does not interpret ANSI escape sequences, you could see it from the PHP script and that sequence rendered as a space. rm *injectedbywvs should have removed it/them (assuming you don't have any other files you want to keep that end with that string).

And if they are floats, you will run into problems testing for equality. You should use the same formatting function on both sides of the test. That way you will be comparing strings on both sides. After all, the call to money_format() using the %i formatting code is returning 'USD 0.15' NOT 0.15; which is probably what xyph was trying to tell you in his first response.

That would mean that $_FILES['tmp_name'] is empty; which would imply that the upload failed. You really should check that ['error'] is zero (or UPLOAD_ERR_OK) before you assume that a file was actually and successfully uploaded. Suggested reading: PHP Manual - Handling File Uploads The variable $headers does not exist in that code

Glad to help. And, thanks for (1) marking the topic solved; and (2) providing the final solution for future searchers.

That is the one thing I don't like about var_dump, there is no way to capture the output and send it through htmlspecialchars(). Unless I need the type and length, I generally use: function debug($value) { printf('<PRE>%s</PRE>', htmpspecialchars(print_r($value, true))); } // Then debug($something);

Did that upload succeed through the resize? Those numbers are a lot smaller than the 32M you reported earlier. Was this the same file? Start: 648 K After LoggedIn(): 1,838 K (incease 1,190K) After checks: 1,842 K (increase 4K) After resize: 1,898 K (increase 56K) I don't see these numbers as excessive at all. A site I am working on now, showing the list of Blog Topics, reports about 2,902 K once the page is finished loading. But, again, these numbers are very much smaller than the 32M that earlier error message reported. If the upload succeeded, maybe start commenting out the debug code and see if the thing will work now.

There is a visible blank space between the first value and the closing double-quote. There is something else in that string. It also says it is 157 bytes long, so there is definitely something else there. If you dumped it in the browser, use the "view source" feature of your browser to see if there are non-rendering HTML values in there. You are going to have to figure out what is after the "2" and the strip it out.

I don't see anything in either of those scripts that should be chewing up that much memory. I can't see assets/member.inc.php so we don't know what that is doing. Line 45 is in the openImage() method, which is called by the constructor, so the error was thrown when you instantiated the object: $resizeObj = new resize($newPath); I would echo the memory_get_usage() value at the very beginning of the script, then again after the call to $member->LoggedIn(), and again just before instantiating the resize object. I would be looking for where it jumped up. The first one will give you a "baseline" since it is the start of the script. The second one will tell us if the $member object or that include file is grabbing a bunch of memory (my favorite suspect right now), and the third one will tell us if all of the checks you are doing are using lots of memory (I don't think they are). Then we can proceed from there.

Use var_dump() to see what they actually contain (there may be a new-line on one) Type juggling may be converting them to floats, and you can never trust == when comparing floats

Sorry, I have not been available today. I suspected the problem was with one of those imagecreate*() statements. The setting for maxium memory allowed is in the php.ini file. You should be able to see it with the phpinfo() output. That error message indicates about 32M. The manual currently says the default is 128M, so you need to check what value you are set at. You might check with your host and see if it can be increased. There may be a memory leak somewhere in your script. I might have time tonight to read through that class file and see if there is a problem in it. You're trying to process a 1.5 M image file, and to tell you the truth, I don't know if 32M is a reasonable amount of memory use for that or not. You can put echo memory_get_usage() . "<BR>\n"; statements in various places and see where the memory is jumping.

Well, you only need one per page request. I suspect the "@" was put on it to "make that error go away" when it said there was already a session. Wow, I really thought I was getting lost OK. Sometimes you get some output like "<junk", but since it is not a complete or valid HTML tag, the browser doesn't show anything. Whenever you get a blank page, it is worth it to check the source. Well, again, the header errors are because of the debugging output we printed, so ignore it for now. But now your "Undefined Index" errors are back. The "cancel" code was correct, we just need to figure out what else is happening. Here $newPath = '' . basename($_FILES['image']['name']); (move_uploaded_file($_FILES['image']['tmp_name'], $newPath)); You have not specified a path to move the file to. So it is moved to the current directory (where the script is). Something must be going wrong in the resize object that prevents you from getting a valid image so the save does not work? Maybe there is some error suppression ("@" operator) in there that is preventing us from seeing the error message. The image in the script directory is your original sized image, right? Not the resized one? So this one worked, eh? Well that's good news. These two error messages are because we dumped the two arrays to the output. They will go away when we take those printf's out of there. That's 2 megabytes for the file, not 2 GB as you said earlier. The post_max_size is fine, basically it just has to be a little more than the maximum filesize you want to upload.

Since you gave both fields the same name, one is overwritting the other. You can use a different name or post them as an array. By the way, the name should be in quotes (just like you did for the id). To post to an array change them both to: <select id='mainselection' name='Preparations[]'> --- notice the empty square-brackets at the end of the name. You can then reference the fields separately as $_POST['Preparations'][0]; and $_POST['Preparations'][1];

// Check if coming from a POST command and if($_SERVER['REQUEST_METHOD']=='POST' && $_POST['submit']=='Upload' && ($_FILES['image']['error'] == UPLOAD_ERR_OK)) { // File Size Check session_start(); I just noticed your session_start() is inside the IF test. If the test fails and the ELSE is executed, there is no session for the message you are applying there (in the ELSE). I would move the session_start() out of the IF (just before it). If I am following the thread correctly, all of your outstanding issues leave you with a blank screen. First, check the "View Source" feature of the browser to see if there is any output at all; it may be broken HTML that the browser cannot render. Second, add some debugging statements. I would put the following two lines right at the top (after turning on the errors): printf('<PRE>%s</PRE>', htmlspecialchars(print_r($_POST, true))); printf('<PRE>%s</PRE>', htmlspecialchars(print_r($_FILES, true))); This will show you exactly what is being sent with the form, so you can see the data. Also, use phpinfo() to check the upload_max_filesize and post_max_size values. Both of these have an impact on uploading files.

Hashing does not guarantee uniqueness, and is not designed to provide unique results. I think I would avoid that. Are you looking for anything in particular, as far as characters go? The uniqid() function will provide a unique value, mostly. It is based on the underlying server's timestamp (in milliseconds). Here are a few from my system generated in a loop, one right after the other. 5064d63e03753 5064d63e03789 5064d63e037bf 5064d63e037f6 5064d63e0382c 5064d63e03863 5064d63e03899

You seem to have posted your code (#7) while I was typing my response [#8]. Have you reviewed my comments and made those changes? The else is from this if($_SERVER['REQUEST_METHOD']=='POST' && $_POST['submit']=='Upload' && ($_FILES['image']['error'] == UPLOAD_ERR_OK)) which means the file did not upload successfully. The php.ini file sets the maximum upload file size. The default is apparently 2MB. If a file is uploaded that is larger than this setting allows, the upload fails, the file is not stored and you get UPLOAD_ERR_INI_SIZE for the error value. The name of your cancel button is "cancel" (in your form). If you click that button, the "submit" index does not exist. You should try using isset() before checking the value: if($_SERVER['REQUEST_METHOD']=='POST') && isset($_POST['cancel']) && $_POST['cancel']=='Cancel / Return to site') { The header error is because you tried to use a header() call, but there had already been output (the error messages). Once you fix the errors, the header problem should go away.

Take out the error suppression ("@") here, and anywhere else that you have it. It does not fix errors, it just hides them. Add error reporting at the top of all scripts. For development: error_reporting(E_ALL); ini_set('display_errors', 1); Then fix any errors that you get --- IMO, WARNINGS and NOTICES are errors. $file_size = filesize($_FILES['image']['name']); $_FILES['image']['name'] returns "The original name of the file on the client machine." not a path on the server that you can reference. You can get the filesize from $_FILES['image']['size']. (see http://php.net/manual/en/features.file-upload.post-method.php) Try that, and report back any problems. If you have trouble with new error messages, post the entire error message.

NO!!! You should (almost) NEVER have multiple columns in the same table that carry the same data. The best-practice for this would be 2 tables: -- Questions Table ID UNSIGNED INTEGER AUTO_INCREMENT PRIMARY KEY Question VARCHAR(###) -- Answers Table ID UNSIGNED INTEGER AUTO_INCREMENT PRIMARY KEY QuestionID UNSIGNED INTEGER FOREIGN KEY TO Questions TABLE Answer VARCHAR(###) IsCorrect BOOLEAN DEFAULT 0 If you want to control the sequence, you can add a sequence number to either or both tables. Depending on the total number of questions and total number of answers, I might use SMALLINT rather than INTEGER, but it makes little difference. Relational databases are optimized for handling multiple-table relationships. As long as you design your tables well, and build your queries well, MYSQL will handle this type of data very well.

HTTP status codes are three digits. The first digit gives the "overall" status: 2xx codes indicate success (at some level), 3xx codes indicate a redirect (the resource is available somewhere else), 4xx codes indicate the WEB server refuses to provide the requested resource, 5xx codes indicate that the server encountered a serious problem. If the server is offline, then it will not respond at all --- offline means not available to the Internet. So, I don't think you get any status code back from curl. If you really want to know, try a url with a domain that does not exist and see what you get. Note that the function you are using to get the status code will return the "Last received HTTP code", which means if you successfully retrieved another page before the one that timed-out, you may get the status code from the first one, instead of the last one (since the timed-out request will never receive an HTTP code). If you check the PHP Manual for curl_errno(), you see how to check for a TIMEOUT condition.

Instead of showing snippets, you should show all of the code that is pertinent. If your latest code comes before the code in your first post, then it is: mysql_select_db($database_main, $main); $query_userfriends = "SELECT * FROM friends WHERE `friend` = '$uid' LIMIT 9"; $userfriends = mysql_query($query_userfriends, $main) or die(mysql_error()); $row_userfriends = mysql_fetch_assoc($userfriends); while($row_userfriends = mysql_fetch_array($userfriends)) { echo '$row_userfriends['user']'; } If you look at that, you are fetching the first row just before the while. Since you don't do anything with $row_userfriends before the while statement, you are effectively thowing away the first record. Remove the fetch statement (before the while) and you should be golden.

You don't need to do "another query" to get the description of an item. You use a JOIN and get it all in the original query. If the items (i.e. eye color) are optional, you can use a LEFT JOIN. If the tables are properly structured and indexed, the performance will be better than multiple queries.

The responsible thing to do is to refuse to do it, and tell them why. Then find out what their needs actually are, and offer a solution that will both solve the problem and protect them. If a credit card is compromised because of one of these emails, they can be held responsible for losses and face big fines. At the very least, you need to tell them what you have learned about the dangers and legalities of sending CC info in an email: Official PCI Security Standards Council Site

First: Sending credit card numbers in an email is a very, VERY bad idea! It may even be illegal. Emails are not secure and may be intercepted. Second: The CC message is always going to be the same as the TO message. There is no way around that. The CC stands for Carbon COPY; and a copy is the same as the original. Third: Sending credit card numbers in an email is a VERY BAD IDEA. To send different messages, you will have to invoke the mail() function separately. P.S. Did I mention that sending credit card numbers in an email is a VERY BAD IDEA? If I ever found out that a company I dealt with was doing that, I would definitely report them to the Credit Card Company, and would NEVER do business with them again. That makes no sense. It is the customer's credit card number anyway, why would you not want him to see it. Unless, you don't want the customer to know that you are being careless with their credit card number so you want to hide the fact that you put the data in an insecure email.

Use an array ... $optTypes = array( 1=> 'Normal', 2=> 'Staff-only threads/topics', 3=> 'New threads hidden', 4=> 'Mod Forum', 5=> 'Administrator Forum' ); echo '<tr><td>Type</td> <td><select name="type" class="button">'; foreach ($optTypes as $index => $optType) { echo sprintf('<option value="%d" %s>%s</option>', $index, ($index == $type ? 'selected="selected"' : ''), $optType); } echo '</select> </td> </tr>';

The 'id' is never a good choice in determining the "first" post. In the beginning, yes, the AUTO INCREMENT field will be, well, auto incrementing; and lower id's will come before higher id's. But this is an arbitrary situation. If you ever have to reoganize the table or re-sequence the id's or delete older entries (with lower id's) and re-start the numbering; then the lower id will not be "first". You must first define what "first" means. If the definition of "first" is "earliest in time", then a DATETIME field should be used.