PFMaBiSmAd

This is some information from the php.net documentation under the mysql_fetch_xxxx statements that might help you -

There are only .zip and .msi php packages for Windows.

Your goal for any select query is to query for just the information that you want. You would never select all rows from a table (unless you wanted to display everything at once from your table) and then use php to loop through them trying to find if a value exists. Php is a relatively slow parsed, tokenized, and interpreted language. The database engine uses compiled code to perform searches and is significantly faster at finding and filtering information than using php code. A generic answer to your question would be to add a WHERE clause to your query to match row(s) that have the "mytexthere" for a value. If you only need to know if a match was found, you can either use mysql's COUNT() function in the query or form a query not-using mysql's COUNT() function (in case you actually need to retrieve other column values form the table) and use mysql_num_rows to find how many row(s) are in the result set. Also, if you only expect a query to return at most one row, such as for a something like a log in username/password check, you would not use a loop to retrieve the result form the query.

You are not using any alias names, so the 'right' meta_value still wins and is the only meta_value key in the fetched array. You are also not looking at the var_dump output or what I wrote in reply #3 and #8, because you are still trying to use the wrong index name in the $line array. Do you have php's error_reporting set to E_ALL and display_errors set to ON? I'm pretty sure unserialize($line['um1.meta_value']) will be producing an undefined index error message.

You are not getting the 'left' meta_value from the joined result because the result contains two meta_value columns and your SELECT term is not specifying which one you want (the last - 'right' one wins) and if you happen to need both you will need to specifically list them in your SELECT term with appropriate alias name(s) to reference them by.

The error message, occurring at the time you are trying to execute an UPDATE query, means that you don't have a database connection at that time. You would need to troubleshoot why the actual logic responsible for creating a database connection isn't doing so. The quickest way of pinning down what is and is not working would be to set php's error_reporting to E_ALL and display_errors to ON so that all the php detected errors will be reported and displayed. Just a few wild guess, but the configuration file either has short open tags in it or it didn't actually get written to due to a file/folder permissions.

Also, the value='x' attributes in your month select list need to be the month number.

The root user should only be used for administrative purposes. You should already have a general purpose database user/password that only has SELECT, INSERT, UPDATE, and perhaps DELETE privileges that you use in actual applications.

An upload error value of 1 indicates - In your previous thread, someone kindly suggested - Since you got an upload error, the upload didn't work and the ['size'] value you are testing in your program logic is a zero, so of course it passes your if ($_FILES['file']['size'] > 262144000) test. Have you tested using a phpinfo statement that when you change the php,ini upload_max_filesize setting that it actually got changed, in case the php.ini that you are changing is not the one that php is using or you used syntax in the setting that is not valid (i.e. actually putting the 'b' in 250mb is invalid and does not work)? Did you also change the php.ini post_max_size setting to at least the same value?

The variable - $Event_ID contains the id. Using $Event_ID["ID"] is attempting to treat the id number as an array and while it probably should not work, php is a loosely typed language and that is treating the id number as a string and is getting just the first character of the id. Just use $Event_ID

WHERE your_column REGEXP '^[^a-zA-Z]'

The error log is simply append to when additional messages are added. However, if its size it at the limit of what the operating system supports for one file, there are likely errors occurring when the operating system attempts to append to it. At this point, past information in the error log is probably not doing anything to help you. You might save it as a different name and start a new empty log file.

Some other suggestions. Make sure that php's error_reporting is set to E_ALL, so that all the php detected errors will be written to the error log. You could be missing fatal runtime errors and notices that would help find the cause of the problem. The code itself needs to have error checking (check if function calls work or not), error reporting/logging (output a user message and log all the information about any errors that are occurring), and error recovery (take an appropriate action for the seriousness of the error that occurred) logic in it. For example, if the database server is down or you have exceed all the available connections to the database server, when the code attempts to make a database connection and it fails - 1) Test the return value from the statement making the database connection, 2) Output a user message - 'Sorry, an error occurred that prevents this page from working at this time!' 3) Write your own application level information to your own Log file (you want to use a file because if the server/php/page is working at all, the file system is working, but the database itself might not be) with all the available information about - who the user is that requested the page (assuming you have a log in system) and/or the IP address (in case it is a hacker triggering errors), what happened ("DB connection failed " . mysql_error()), when it happened (date and time), where it happened (the file name and line number), anything else that is relevant to the error that would help find what is causing it. 4) Don't continue executing the code on that page. For something like a database connection that is required for the page to do anything useful, you might as well use an exit/die statement to prevent the remainder of the code on the page from running or you might want to at least display a minimal page with some navigation link(s). In step #3, for something like a query that failed with an error, you would also want to log the actual query. For something like a file operation that failed, you would want to log the filepath/filename that could not be accessed.

You can continue to use that exact same logic when magic_quotes are removed. get_magic_quotes_gpc() will still be present, but will always return a FALSE value.

If calling mail() fails, repeatedly doing it will likely also fail. Typical error messages are - invalid/missing/malformed address, authentication required/relaying attempt, no sending mail server (it's down or off), blacklisted addresses/domains,... If you have php's error_reporting set to E_ALL and log_errors set to ON, any returned error message will get logged to the error log file. You can also use error_get_last (php5.2 or higher) or $php_errormsg (if you set track_errors first) to get any error message that is produced when the mail() call fails.

Everything to do with Wordpress is vile and reviling. CSC (Clairvoyant Spell Checker) should have known the correct word to put in there.

Once you add the mail function returned status to the logged information, you will be able to determine if you can do anything on the php/sending side. The php mail function only returns the status that the sending mail server passes back to it at the time the email is given to your sending mail server. That's the end of php's involvement in the process. The status basically means that your sending mail server accepted the email from your php script. It does not mean that the mail server will even attempt to send it or that it was actually sent or that it was successfully received. About the only thing that comes to mind that you can do is to put a valid email address into the Return-path: mail header and then check that mail box for messages sent back from the receiving mail servers.

Unfortunately, this thread is really a continuation of the previous thread where the relevant information was reviled.

The point of having you use var_dump was so that you could see what the array index names are so that you could correct your code. $line['um1.meta_value'] does not exist in the fetched array.

If this problem has existed for some time, it's long past the point where someone with sufficient php programming and troubleshooting skill should have looked at it. It won't fix itself and it will only get worse if it is due to things like a database design that is inefficient.

Code should not normally produce any kind of php error, warning, or notice during its normal execution. ONLY for abnormal things, like an actual error occurring, a legitimate visitor doing something that your logic didn't take into account, or a hacker trying to break in. Those are the only time you should see messages in the log file, so that you can find and fix the condition and the logic to address those errors. Note: HIDING the errors by altering php's error_reporting and/or display_errors/log_errors settings does NOT fix anything. In fact, the message from the reporting and display/logging of the error is just the step in the error response code. Php must still detect and handle each error as it occurs every time the script runs, even if the final message is not reported and displayed/logged. It sounds like the code needs a complete audit.

I seriously doubt that is a var_dump of the $line variable. Looks like a var_dump of $region.

The mysql query cache would allow repeated/exact same queries to immediately return data, where as a new and unique query would need to wait for the actual query to execute. This could give the appearance that it works OK for a group of visitors, but not others. When multiple clients behind a router make requests to the same server, the requests are actually being made using a different remote port number (see the $_SERVER['REMOTE_PORT'] value) for each client. The server sends the response back to that same port number. About the only things that would be communication related would be any caching of content (or lack there of) and the amount of content that is being output on each page request (i.e. large images, huge amounts of html/content.) Other than the time it takes to generate the page on the server, about the only thing that comes to mind that causes php produced pages to 'hang' are when you are using session variables on a page and content (images, ajax) on the page is also making http request for the same session and because of file locking on the server, the requests hang until the specific session data file can be accessed. I would add a calculation of the page generation time and either display that or log it to see if the actual pages are taking a long time to generate or if the problem is somewhere else.

Use var_dump($line); inside your while(){} loop so that you can see exactly what your query is returning (it is only the column names.)

mysql_query("delete from cart where cookieId = '" . GetCartId() . "'");