roopurt18

I'm hooked on Chrome; the JavaScript implementation is lightning fast compared to other browsers. I only bring up FF to test new pages or debug JavaScript and I only use IE for compatibility testing.

Sounds like a user_behavior_preferences table to me with a bunch of columns in it and one row per user. I don't see why you'd use XML; databases are almost always better for persistent storage.

Replace your #3 with either of our solutions and outside of any loops.

The username hash is completely useless; get rid of it. i create a unique session key, which also gets stored in the db with a time_expired field and an ip_address All you need to create a unique session key is: session_start(); $key = session_id(); Since each user has only one session, each session id will automatically be unique. You don't have to generate anything. If the information is that sensitive, then I recommend: 1) using HTTPS 2) automatically logging users out after 5 to 15 minutes of inactivity 3) do not implement any sort of "remember me" feature

As far as the database is concerned you only need columns for username and a hashed password. When the user logs in you set a $_SESSION var as coupe-r recommended. On every page (or filter all requests through a single index.php using mod_rewrite), you check for that $_SESSION var; if it's not set redirect to the login page. The server and client negotiate the session by passing around a session identifier. The client will store the session identifier in either a cookie or or as part of the URL; you really don't get a choice in the matter. Neither is inherently more secure than the other since they're both controlled by the client. What you read about using the database and the session together has to do with how the session saves it's data on the web server. By default the sessions will be saved as files in a sessions directory. What this means is someone who has sufficient privileges into the web server can browse and view these files. If you want to save session data in another form of permanent storage, such as a database, you can overwrite PHP's default session handling capabilities. But no matter how the server saves the session data (file, database, something else), the client and server still pass back and forth the session identifier, which will always be sent as part of the URL or as part of the request body (from the cookie).

Well AFAIK all session_name() is change / set the GET or COOKIE variable name. Regenerating the ID does exactly that. It takes the current session id and mangles it into a new one. All of the existing session data comes along with it. There is no way to give a user more than one session (AFAIK).

Haha. I swear I looked for that but I guess my poor brain managed to transpose the letters anyways.

It means exactly what it says. You're calling a member function, query, on an object, $mysqli. Except the object is not an object (the error message says non-object) so it has no member functions and the code crashes. I suggest adding a var_dump( $mysqli ) right before the bad line; then you'll see what type of variable $mysqli really is.

From a practical standpoint your exercise is wasted effort. In the 4 or 5 years I've been programming PHP I've never had a reason for one user to have multiple sessions. Why on Earth are you doing this?

<?php echo <<<EMAIL The following computers have been repaired and are ready to be picked up at the IT Center between the hours of 8:00am - 11:00am and 12:00pm - 4:00pm. Click on the computer name to be taken to the corresponding Helpdesk ticket. EMAIL; foreach( $bpe_arr as $v ) { echo $v . PHP_EOL; } echo PHP_EOL; ?>

You call mysql_real_escape_string() before inserting into the database. You call htmlentities() before displaying database content in the browser. I do not recommend calling htmlentities() before inserting to the database.

You could make Users a singleton.

When you run matlab from a command prompt, does it work? Or does it tell you that matlab is not found? If it tells you matlab is not found you either: 1) Need to specify the absolute path to matlab.exe on your machine when you invoke it 2) Use PHP's putenv() function to modify your environment PATH variable 3) Modify the environment PATH variable for the whole machine

There is nothing you can do to track with 100% certainty who opened or read the newsletter. As you've pointed out yourself, they or their mail client can ignore or choose not to load images. You can add things to headers, such as receipt notices that tell the users mail client to send a response message when the user reads the e-mail. But mail clients are free to ignore these headers as well. MJ's idea of a document with an external link may or may not work. I know I wouldn't be using any mail client that automatically opened PDFs or MS Word files without prompting me first. You have to assume in the worst case that your newsletter will be read by the reader as plain text, which provides no tracking mechanisms. What you can do is entice the reader from the newsletter back to the main site. This can be done a number of ways depending on the site. If you place article summaries in the newsletter intended to grab the reader's attention and then include a URL to the full article, on your site, you can track that way because they'll follow the URL back to your site. Or you can include a URL back to a special promotion offer, coupon, or something else consumers would want that is hosted on the main site.

This is the one I was thinking of. One of my favorites. http://www.transbuddha.com/images/uploads/lotr2.gif

"they're taking the hobbits to isengard" I hope that's the one where they make Boromir go get the ring off the mountain or whatever. And I saw it as PO-TA-OWNED what is lazytown? Are you talking about that kid show with the pink girl and blue guy? That be it. Actually there's only two of their things that I like. Bake a Cake You Are A Pirate <-- http://www.youtube.com/watch?v=ZLsJyfN0ICU

Great. Thanks to this thread I'm wasting all sorts of time. http://www.youtube.com/watch?v=6FAuJod1XmY&feature=related

I will always have a soft-spot for badgers and hamsters. All your base too. (edit) And leek spin. (editx2) And lazytown.

Optimization is a tricky subject. You could spend hours optimizing code and / or algorithms that have a negligible measurable impact on your site's performance. Performance is also closely tied to hardware and / or software settings. So optimizations that work well on one machine may or may not carry over to another machine. The most practical and realistic solution is to do the work in the simplest manner possible. Test your work in an environment that replicates exactly, or as close as possible, the production environment. If you notice certain parts of your site (i.e. a particular query, a particular segment of PHP code) are causing performance draining spikes then optimize those things only. Finally deploy your work to the production environment and then continue to monitor things such as slow page loads, failed requests, long database queries, etc. In short, do the work in the simplest manner possible and then optimize when and where you find it necessary. (And remember that "optimization" could be as simple as upgrading the server memory, hard drives, changing the working memory of the database server, Apache settings, installing ram disks, or any other of non-programming tasks.)

To clarify: it was always showing the nickname and just the nickname. So if they had a nickname, that's what it showed. If the nickname was empty, then it showed that (and if you're viewing it in a browser, browsers ignore extra whitespace, so you only saw one space). That's why it showed the nickname or nothing (nothing happened to be the nickname on some of your rows). In the future, remember that you can control the order in which PHP will evaluate expression with parentheses. <?php echo $firstname . (strlen( $nick ) > 0 ? " '{$nick}' " : ' ') . $lastname; // ^- close paren // ^- open paren // That excludes $firstname and $lastname from the ternary operator's test and result // (but it also makes your code slightly more difficult to read) ?>

It's called the ternary operator. expr ? true_part : false_part If expr is true, then the code in true_part runs, else the code in false_part runs. Now let's look at your statements: expr: $row['firstname']." ".$row['nickname'] true_part: $row['nickname']." " false_part: "".$row['lastname'] I want you to think long and hard about why your expr will always be true, thus your false_part will never, ever execute.

It's overflowing twice because something is pushing the containing HTML element beyond the browser's width, so the browser is adding a scroll bar for that. Then you are telling it the body element always has a scrollbar as well. Try taking the overflow out of your CSS above and apply it to the HTML tag instead: /* css */ html { overflow-y: scroll; } body { font: 10pt Arial, Helvetica, sans-serif; background: url('background.jpg') repeat; } Or fix the issue that's causing the html element to be wider than the browser. Just educated guesses by the way.

Been a while since I used setTimeout, but I think you can leave off the parens: setTimeout("rePosition", 1500); Or you could possibly just pass the function reference: setTimeout(rePosition, 1500);

While this probably won't happen because of various reasons, I'd be all for it if it did show up.

You should mysql_real_escape_string() the inputs anyways. It's best to assume everything is faulty and / or compromised in terms of security. Any variables going into a query should be escaped, regardless of what populated the variables. Likewise any data coming out of the database for display in a web browser should have striptags() or htmlentities() called on it, regardless of how you think the data was put into the database in the first place. If your site someday has a problem and you fail to do these things, then you just have more possibilities to chase down on how your site became compromised. If, on the other hand, you know that 100% of the time you use mysql_real_esape_string(), then you know your site was probably not attacked with SQL injection. Now you have less things to think about in terms of "How did my site get attacked?"