vinny42

Well, the major points still stand: don't die, don't redirect. This die() business is only even remotely possible during the initial connection. You simply cannot die() on a query failure because that will completely mess up your page and if you are not extremely carefull; it will mess up your data too. As for the redirect, stop doing that. It just adds a completely useless page into the user's browsing history and when they click "back" to back to the page before they got the error, they actually end up on the page that has the error, and are redirected back to the error message. So again; throw an exception, catch it and print an error. no die(), no redirect, just one script that handles everything.

2:Hijacking is dome by stealing the sessionid. The only think you can do to prevent that is look at the IP, which cannot be spoofed. The problem with the IP is that a proxy can use the same IP for several clients and clients using a phone or tablet can change IP's legally while moving around, so they would have to logon again every once in a while. 3. Use SSL to make the connection unsniffable, and use session_regenerate_id() (http://php.net/manual/en/function.session-regenerate-id.php) to make the sniffed sessionid useless at the next pageview.

One way of doing it is to append each error to the same file, which will be the "most recent errors" log. If you write the errors like this: [2013-10-25 13:08:23] FATAL Could not connect o the database. <more details here> [2013-10-25 13:08:45] FATAL Out of memory <more details here> [2013-10-25 13:12:09] INFO Bad password User xxx tried to login with password yyy. Then you can parse the file and recognise every error individually. That makes it possible to create a list of just the timestamp and the single-line description, which you can then put into an email so the recipient just gets: [2013-10-25 13:08:23] FATAL Could not connect o the database. [2013-10-25 13:08:45] FATAL Out of memory [2013-10-25 13:12:09] INFO Bad password Which is easy to interpret; if there are no FATAL lines in the digest then nothing serious is going on (you may want to add the number of FATAL erros in the subject line so the recipient can see whether poop is flying or not, without reading the email itself) The actual sending of the file can be triggered by either a cronjob if you are on linux/un*x/freebsd, or a windows-scheduler job if you are on windows. After creating and sending the digest you can rename the file to the current date and compress it, so the admin can find it again later to look at the details of the messages. Does that give you enough information to get started?

So your script does include something before getting to the script you posted. Do you know if your server is setup to se "auto_prepend" or something like that? You may be able to find out more about what's going on if you use debug_print_backtrace() (http://php.net/manual/en/function.debug-print-backtrace.php) at the top of server.php. That will print out the lines of code that were executed before the debug_print_backtrace() was called.

Hm.. Have you looked at the page source in the browser to see if anything is visible before the printed error?

The error message says that there is something printed before the session_start(), that's just how it is. Is this file included by another script? Do you have xdebug installed so you can trace the execution of the script to see what it is doing?

Google your errors before you post, because this is an extremely common error; you are sending HTML output before calling session_start(). usually there is an empty line before the PHP tag.

I missed the redirect, or I would have posted a very shouty post about that: Don't redirect when there is an internal error in the page. Google and such will follow that link and could possibly decide that your page has moved. Not only does that remove the orignial liknk from the index, it could also result in a duplicate content penalty. One night of database problems can seriously hurt your ranking if you redirect. A more gentle approach is not to exit and not to redirect, but to throw an exception taht is caught by a piece of code that prints a userfriendly errormessage and sets the HTTP statuscode to "temporarily unavailable". that leaves your logic in tact and stops others from misinterpreting the situation. Still no die() though. :-)

Indeed, sessions have limited practical use and should be used with care, just like any secondary storage method. Sessions are stored as a file on disc when when you call session_start() the file is read, unserialized, and the content is place in the superglobal $_SESSION. So there is no separate storage, it's just part of your script and when the script ends the contents of $_SESSION is written back into the file. (or any other medium if you implement a custom sessionhandler (RTM)) Not right; 128bytes x 10.000=1.280.000 bytes, or 1.2 MB As I recall it can take 2-4MB per process, so you should be able to handle 50 processes realtively easily. But a 500MB server is absolutly miniscule for today's standards. nginx has no issues with php, it's not as easy to setup as for apache but it works just fine. SSL is available got nginx too: http://nginx.org/en/docs/http/ngx_http_ssl_module.html These last few questions fall into the "google first, post questions later" category. :-)

+1 Your code should not die() when the connection fails, because that means your website will show a blank or at least half-completed page. Not good. Also, don't send emails when errors happen, log them to a file. If this error happens on a popular website it will send a few hundred thousand emails per hour, your mail account will break. Mail the logfile (or better: a digest of the logfile) once every 15 minutes or so. As for handling the errors: make it throw exceptions, and let your aplication decide what to do when it catches a database-related exception. Usually you will just want tp display an HTML page telling the user that there is a problem and that you have been notified about it.

It is, when the fat lady sings! :-) Absolutely, but i'm wondering why run both (when using a "stay logged in" system). It's up to you :-) If your stay-loggedin system stores all the data you need, then you dont need sessions. But generally, a stay-loggedin system only authenticates the user and stores no other data, because it is much more convenient to use PHP's sessions for that. Also by storing the data in the server are you not replicating already stored data? Yes, but that by itself is not a problem. The only issue with that is that the data in the session can (and will) get outdated, so if you store accessrights in the session because "it's much faster to get them from the session" then a user can work with an old set of rights for hours; the session will not be updated untill it is destroyed and the user logs i again. (I've seen pretty weird ways to get around this, like looking up the sessionfile and modifying it... yuk). So keep important data where it belongs: in the database. Use the session for volatile data.

Also note that you are using one "=" sign, so you are putting zero into $numrows, instead of checking if $numrows has zero in it. if ($numrows=0){ //nothing here, input data should be if ($numrows==0){ //nothing here, input data and to make prevent this bug in future; teach yourself to always put the constant first: if (0==$numrows) Then, if you forget an "=" sign you will get an error from PHP because you cannot change the value of the constant "0".

Look at the line mentione in the error, you don't close isset correctly.

How about a preg_replace and a callback that holds the array of replacements: echo preg_replace_callback('~NOUN~', function ($matches) { static $intCounter = 0; $arrReplacements = array('cat', 'dog'); return strtolower($arrReplacements[$intCounter++]); }, 'Today I bought a NOUN and a NOUN');

It looks like you are creating a registry pattern. That would mean making the class aware of what you are storing in it, which I feel goes beyong the scope of what a superglobal of registry is supposed to do. I'd feel more comfortable with a "fruitlist" object that you can store in the registry, then you can modify that by getting it from the registry and calling a modifier method on it to replace the element.

I know PgSQL does this, up to a point, but having combatted this in MySQL less than a year ago I didn't think they would have solved that so quickly. This is basically what PDO is when PDO::ATTR_EMULATE_PREPARES is set to true. Under that setup PDO will parse the query and substitute the values itself rather than using the DB's native prepared statements api/syntax. Interesting, more ways that PDO creates inconsistend API behaviour :-)

Prepared statements are very safe, but it is not a magic bullet. A prepared statement is "prepared" without any data in it, which means that the database cannot use the data to compile it's plan, which means the databae may decide that it shouldn't use an index, which can be very bad. A simple solution to this, that apparently ony I know about (given the bizar responses I've received to it) is to create your own databaseclass that just runs queries and returns the output. If you have that, you can create a method like "runquery($pStrQuery, $pArrParameters)" or if you use PHP's ability to have unlimited parameters: runquery($pStrQuery, $pIntParameter1, $intParameter2, ...)" The query can then have placeholders like $1, $2, or simply names like ':userid' and a simply loop can force all parameters to be parsed using the escape function, quote them and paste them into the query. that way you can be safe without having to resort to prepared statements. And before people start complaining about integers; most databases will happily accept quoted integers, there is no performance penalty at all. Where "normal validations" means "the kind of validations that your application does to be able to work with the data. There is no point to validating a date just before you put it into the database, because A) the database will refuse a bad date (unless you are using MySQL, in which case it may or may not work, depending on the IQ of the admin) and B) at that point there is nothing you can do to fix the date anyway.

It looks like you are storing the given answers in a session. Don't do that, put them in the database (after all, you want to know what people filled in, sessions are deleted after a while) When the give answers are in the database you can let the database do pretty much all of the work. Selecting the next question can be done by doing a JOIN between your questions table and user-answer table, the first question that has no answer by the current user is the next question to ask. Counting the total correct answers can also be done by joining your questiontable (or answers table, depending on your datamodel) with the user-answers and counting the number of answers that match, like: SELECT COUNT(*) AS correctanswers FROM answers INNER JOIN user_answers ON answers.question_id = user_answers.question_id AND answers.thisisthecorrectanswer = true WHERE quiz_id = 'wwII' AND username = $username; // dont forget to escape the username.

Actually, the problem is quite simple if you think of these "blocks" as separate templates. If you can render a template then it's allmost a trivial extension to find and parse a subtemplate. The only difference is that a regular template has access to the entire scope of data, and the subtemplate has to use elements of an array etc. But even that comes down to allmost exactly what it says: loop through the array and parse the subtemplate with the elementdata. If you have a deadline then use an existing template system. The reason why systems like Smarty are so large is that you need those functions.

Well I guess you're stuck, mail clients specifically try to prevent this kind of things from being done, to stop spammers and hackers from loading malicious content.

Why don't you just email a link? :-)

Most payment provides provide both methods; when a payment is completed a message is sent to the merchant and the merchant can poll the paymentprovider to ask for the status of a payment. You should always implement both, because the call from the paymentprovider may get lost and it can take a few minutes for the payment to complete. (hours, even days for some creditcards) But this is separate from the OP's problem, which is that he want's to keep the shoppingcart in tact for one more page after placing the order. What he should do of course is move the items from the cart to the order and display the summary of the *order*, not of the cart+address.

The best ways is probably a regular expression. You can remove http:// using str_replace because that can only ever appear at the start of the URL, but the 'www' must only be removed if it appears at the start of the URL and ends with a dot. Otherwise you would break domainnames like 'thisismywwwdomain.com' something like: $strURl = preg_replace('~^www\.~','',$strURI);

Also: don't use session_destroy() when all you want to do is empty the cart. Just emty the sessionvariable that contains the cart. Why: because the session may/should contain much more than just the cart, like the user's address (so he doesn't have to type it twice if he makes two orders, or cancels his first order an re-orders immediately) Never destroy, fix!

It really doesn't matter, both use the scheduler and both will start a PHP script and that is all yo need.