PFMaBiSmAd

The parent-folder - saves/".$worldname must exist before you can add a child-folder inside of it.

You will only know what the actual number is after you have inserted the row into the table. Getting the current highest number and adding one doesn't work with concurrent users, unless you lock the table for the duration of the process (which would slow your processing down to a crawl since no one else could do anything until the first person has finished.) If you need to get the actual number for display purposes (this rarely actually ever needed), you can insert an empty row (with the date/time of creation) into the table to 'reserve' the number. Then update the row once the actual information is known. This of course creates additional work since you must now cleanup and delete any rows that don't actually get completed, which is why this is normally not done this way. Why do you need the actual identifying number while the form is being filled in with data? How about just getting it at the end of the process when the data is inserted into the table?

If you execute that query directly against your database or use error checking logic in your php code, you will get an error - Column 'ID' in where clause is ambiguous You need to tell it which id column to use and since this is actually a join, you probably need to include in the where clause a statement to only join together rows with the same id in both tables. Untested, but should work - WHERE a.ID = b.ID AND a.ID = 1

Yes, but what can it be? Can it be missing. Can it be other letters? A number? Will it always be a single letter? Is it always at the start of a new line? Will there always be at least one > character and the > character won't ever appear in the part of the staring that you do want to keep? Will there ever be anything (spaces/tabs/numbers...) after the last > and the start of the string that you do want to keep? Does the part of the string that you do want to keep always start with an alpha (letter) character?

Yes it does. You only give it the name of your single database. A product that does not support the most common usage, i.e. all related data inside one database, would have died off long ago.

@MasterACE14, the logic you posted will fail to work when the '#3#' string is present and starts at position 0 in the variable.

Programming is an exact science. If you couldn't copy/paste the line of code I posted for some reason, at least proof read the line of code you wrote and compare it with the line of code you were given.

http://dev.mysql.com/doc/refman/5.5/en/comparison-operators.html#operator_between

Cannot help you with your latest problem without the relevant code.

What exactly about that query do you need help understanding? Even if you can not write a query, you should be able to read it and get the gist of what it is doing, possibly after you research what the mysql EXTRACT() function does or what the BETWEEN comparison does.

For the lowest, non-zero value - $lowest = min(array_filter(array($sym, $res, $naq)));

See if this post helps - http://www.phpfreaks.com/forums/index.php?topic=351291.msg1658663#msg1658663 Substitute your 'upon return' (which I assume means a redirect back to the form) for the 'the return URL you tell your payment gateway to use' in that post.

See the logic in this post - http://www.phpfreaks.com/forums/index.php?topic=351087.msg1658041#msg1658041

The data you are operating on are, apparently, the name and lastname. Why isn't everything, from your database table column names through your form and your php variables consistently named to match the meaning of the data in them?

In your third piece of code, $_GET['id'] doesn't exist. Your update form is passing the id as a $_POST variable. You need to have php's error_reporting set to E_ALL and display_errors set to ON in your master php.ini so that php will report and display all the errors is detects. You will save a TON of time. The undefined $_GET['id'] variable would have been producing an error message that would have helped you find this simple problem.

There's close to a dozen different things that could prevent your code from working, from invalid HTML in your form all the way to a database field that is not long enough to hold a sha1 value. What have you done to narrow down exactly at what point the code, data values, and query that you posted are doing what you expect and exactly at what point they are not? I can guarantee that the problem lies between those two points. Have you checked if $user and $pass values you are putting into the query statement have the values you expect and exactly match a row in your database table? Have you checked if the mysql_query statement is returning a false value (the query failed due to an error of some kind, such as an incorrect column name) or if it is returning a result resource (the query executed without error)? Have you checked what value the mysql_result statement is returning? Short-answer: we don't have access to all your code, your database table definition, the data in your database, or your server. We cannot even tell if the query statement you posted has the correct table and column names in it. After you narrow down the problem to one section of code, you have to check each individual statement/value/query in that section of code to find out what is failing.

To actually replace your {name} placeholder in the string with the contents of a php variable, you must use the /e modifier.

basename would give you just the filename to use in the Content-Disposition header attribute.

create_function

The filename="..." attribute in the Content-Disposition header is just a string for the destination filename to use in the client. It is not the full path to where the file is on the server.

STOP. You already have a thread for this problem. Don't start another thread for the same problem.

Your mysqli_fetch_array statement is invalid - $singlepage=mysqli_fetch_array($connection, $content) It does not take the connection link as a parameter. It only takes the result resource (mysqli_result) from a mysqli_query() statement as a parameter. Also, you have at least one mysqli_error() statement that does need the connection link as a parameter for it to work.

It's more likely your php code is doing something like testing if the variable holding the value is empty (which zero is considered to be) or is testing if the variable is true/false (zero is considered to be a false value for loose php comparisons.) What have you done to narrow down the problem and determine exactly what your code and data are doing? Have you echoed out your query statement right after the point where it is being formed so that you both know that the code is being executed at all and that the query statement has the values in it that you expect? Are you sure you are executing the query and that the query executed without any errors? What does your error checking logic in your code tell you? It could be that you have a key defined for the column and you are trying to update it to a value that already exists.

I hope your mysql timezone is set correctly and that your mysql timezone/DST database is up to date or you will mess up all your data. I also hope you don't have any dates older than 1970 or plan to use dates later than 2038, because the mysql Unix Timestamp storage and the mysql conversion functions currently only work for that range of years. You took a huge step backwards by going from dates stored as fixed human readable values (i.e. a date/time stored as 2012-01-07 08:39:00 will always be that value) to Unix Timestamps, which are dependent on a relatively slow and ambiguous conversion. Converting a Unix Timestamp to its human readable value is dependent on the timezone setting and any DST offset and is affected by how up to date the timezone/DST database is - mysql and php each have their own timezone/DST database that must be kept up to date as locations have been redefining their DST start/stop dates. Using Unix Timestamps for your data storage also means that you cannot use any day/month/year grouping directly in any queries, so you must execute more/slower queries to manipulate data that is associated with any human readable day/month/year divisions.