Daniel0

Sure

Yes, it resembles an if-else statement. It's called the ternary operator. See: http://php.net/manual/en/language.operators.comparison.php#language.operators.comparison.ternary

For the last option, this would probably be better: echo "<td bgcolor=\"$color\" width=\"12.5%\">" . (isset($info[$a]['telephonenumber']) ? $info[$a]["telephonenumber"][0] : ' ') . "</td>";

This is how I would do it: <?php $items = array('apple', 'chocolate', 'milk', 'hotdog'); $userItems = array(); echo str_repeat('=', 36) . PHP_EOL . 'Daniel\'s awesome preference selector' . PHP_EOL . str_repeat('=', 36) . PHP_EOL . PHP_EOL; while (count($items)) { echo 'Which of the following items do you like the most?' . PHP_EOL; foreach ($items as $num => $name) { $num++; echo " {$num}) {$name}" . PHP_EOL; } echo 'Enter choice: '; $num = trim(fgets(STDIN)) - 1; if (!key_exists($num, $items)) { echo 'Incorrect choice. Try again!' . PHP_EOL; continue; } echo "You choose: {$items[$num]}" . PHP_EOL; $userItems[] = $items[$num]; unset($items[$num]); sort($items); echo PHP_EOL; } echo PHP_EOL . 'You choose the items in the following order: ' . join(', ', $userItems); ?> Try to save it and run it like this from a console: php filename.php (needs the PHP executable in PATH) Your task: Change it from being a CLI script into being usable on a web server

Why does it matter which order they're in? Anyways, you can just sort them alphabetically.

<?php $string = '<A HREF="http://www.teng.com" onclick="startRequest(6467)" target="_blank" ><img src=img/pilner.gif class=img alt="Genv?g till nedladdning"></A><A HREF="http://teng.com" target=_blank ><img src=img/trailer.png class=img alt="Genv?g till Trailervisning"></A><a href="http://teng.net "target=_blank ><img src=img/trailer.png class=img alt="Genvg till Trailervisning"></a></TD>'; preg_match_all('#<a href="([^"]+)"#i', $string, $matches); print_r($matches[1]); ?> Array ( [0] => http://www.teng.com [1] => http://teng.com [2] => http://teng.net )

Seeing as the methods are related to the products, logically they should be put in the Product class.

We use Google Analytics.

If you don't want them in the users table, then you can add another table called contact_information, or something like that, with the following fields: contact_id (primary key; auto increment), user_id (references the id in the users table; has index), type, data. Then to get a users contact information you could do: SELECT type, data FROM contact_information WHERE user_id = 1234;

It could be that the file you are sending is large and a) your upstream speed is slow or b) the servers downstream speed is slow.

Try if (isset($_GET['name']) { instead. Same goes for the sort_by index if it's similar to the one with name.

Great job repeating me...

Something like this? <?php $db = new PDO('mysql:host=localhost;dbname=something', 'username', 'password'); $stmt = $db->prepare('SELECT iqid, cost, stotal FROM table WHERE userid = :userid ORDER BY stotal'); $stmt->execute(array('userid' => $_GET['userid'])); echo <<<EOF <table> <tr> <th>iqid</th> <th>cost</th> <th>stotal</th> </tr> EOF; foreach ($stmt->fetchAll() as $item) { echo <<<EOF <tr> <td>{$item['iqid']}</td> <td>{$item['cost']}</td> <td>{$item['stotal']}</td> </tr> EOF; } echo '</table> '; ?>

The equivalent for $PHP_SELF is $_SERVER['PHP_SELF']. The difference between PHP_SELF and REQUEST_URI is that REQUEST_URI includes the query string whereas PHP_SELF doesn't.

You should do quite fine. There is no reason why you would store the password in the sessions... What are you going to use that for? Also, the lines like this: session_unregister(error); and similar won't work. It has to be session_unregister('error'); but that's useless when you after that call session_destroy() which will unregister all sessions.

Which extension is "Mozilla's Extension"?

Just record the time the sale was made and sort the statistic results accordingly.

$query = "SELECT COUNT(*) AS received FROM messages WHERE receiver = '$user' AND received = 1"; if (($result = mysql_query($query)) && mysql_num_rows($result)){ $data = mysql_fetch_assoc($result); echo $data['received']; }

Try SELECT COUNT(*) AS received FROM messages WHERE receiver = '$user' AND received = 1;

What browser are you using and what content type is the file being sent as?

Tell your "web design" (right... ) teacher from me that he is a noob. Not only does it look hideous, but he just broke every "rule" I just pointed out above. That plus what Nightslyr just said.

I figured I should explain why I believe what I said above. I think I've said all those things before, but here you go... 1. Separation of concerns A webpage can be split up into three layers: content, presentation and behavior. The technologies used in these layers are HTML, CSS and Javascript, respectively. You can imagine these as a ladder, the higher you go up, the richer the user experience. For instance, while an unformatted HTML document works quite well, it will be much nicer to look at if you style it using some CSS. Moreover, if you use Javascript correctly then you can further increase the user's experience. There are plenty of examples of that. For a simple one, check out my example in the "Is Javascript Crap?" poll in the polls forum. Note that Javascript shouldn't be overused or it will probably just annoy your users. With separation I mean that the those three things shouldn't ever appear together in the same file. All Javascript and CSS should be in external files. This means: no inline styles, no styles in the <head>, no Javascript directly in the HTML document. Humans often don't do things unless they personally benefit from it, so what are the benefits? First and foremost, your code will be much easier to maintain. You are always certain where the different things are stored and everything isn't all mashed up together which makes it much more easier to cope with. Furthermore, seeing as the HTML will be the only often changing data (seeing as it's the content layer), you'll want to keep as less data as possible together with that. The rest can be stored in other files which can be cached so they do not have to be downloaded every time by the user. This means that a) you'll save bandwidth, and b) the page will load faster for the user because s/he has to download less data. In other words, it's a win-win situation. You benefit, the user benefits, so there is absolutely no reason why you wouldn't do it. What does this have to do with the tables? If you are using tables for layout, then you are mixing up the first (content) and second (presentation) layer. 2. Semantics Semantics is the study of meaning. Therefore, it's an important aspect to consider. As an analogy, imagine that you decided that every time you wanted to use the word "table" you would use the word "dog" instead. You would understand it, but everybody else would probably get a bit confused. It's the exact same thing concerning the usage of tables for non-tabular data. If you are using a table then you are explicitly declaring that the contents of the table is, well... tabular, and that's perfectly fine if it actually happens to be so. However, if it's not tabular, then you are using semantically incorrect markup. You might think that it doesn't really matter, because at the end of the day the output on the screen would probably be the same anyways. The problem is though, not everybody browses web pages using their eyes, some people use their ears and are dependent on screen readers, so if you are lying about what the content is, then the screen reader might not be able to interpret the markup correctly and that will probably just frustrate the users that use screen readers. Not only is semantically incorrect markup stupid, but your website is for your users so you must make sure that it's accessible for your users. Therefore, only use tables when you are displaying tabular data. It's also the exact same reason why you wouldn't write an essay in a spreadsheet such as Microsoft Excel. 3. Bandwidth I touched this in point one. Using tables will often generate more HTML markup which means that you will have to transfer more data which leads to slower loading pages. So, separation of concerns, semantics and bandwidth. I'm sure one could find additional reasons why utilizing tables for layout is bad. Remember and use what was just explained and you'll score some easy geek points, but if you use tables for layout, then you'll have a bazillion geek points deducted.

Because table-less works better. My signature works for displaying the text "hello world" as well, but it would work better if you just echoed it regularly.

But not always, sometimes the use of div's AND tables or sometimes just divs are easier/faster. Easier and/or faster for you is not necessarily the best solution.

Oh, maybe I should start reading the entire topic before replying...