Adam

There's too many different ways of writing dates to reliably convert it. Can you tell me what date this is: "01/02/03"? Use select boxes.

Depends what you have at home.. but very unlikely.

It's the same as almost any "unlimited" offer in this world. There will be some terms of use stating it can't be over x amount and/or you have to follow their fair usage policy. It's just a gimmick that probably 99.9% of users will never put to the test. You paid extra for a dedicated server because you have a dedicated server. You're not sharing it with anyone else and will have root/admin access to do what you want on there. You'll still be restricted to the bandwidth they can provide though.

Well I don't really get why you're passing it in the first place?

The main benefit is that code placed within the body is executed as the page is loading, instead of after it's finished loading. I wouldn't worry about really old browsers to be honest, just write the code so that it isn't dependant on the JS (which you should anyway), and be aware that the DOM tree will be incomplete. One possible issue to watch out for would be delaying the page draw. If a script hangs nothing else will happen until it's done, so I'd be cautious with third-party scripts that could otherwise be loaded within the head.

$value is taken from the post data and used within the query as the table name, but you're not posting it as a hidden input when you submit the form so you will have a blank table name. By the way, blindly using a variable as your table name is a very bad idea. I could put any table in there, or worse, a malicious SQL injection. I know you run it through mysql_real_escape_string(), but I wouldn't need quotes in that situation. Check the value is within an array of allowed table names.

The whole point of sessions in PHP is to retain data between requests. PHP is stateless, meaning the variables you define only exist for that request. At the end of the request, PHP destroys everything (except for the session, which is stored in a file) and then starts from scratch on the next.

Compare the first and second numeric characters to... what? Why two? Why not just develop one secure method?

You wouldn't store the user's "postings" within the session, only the user's actual data like their username.

CSV isn't Excel specific, essentially it's just a plain-text file. Excel is reformatting the date according to your preference when you open it... Just don't open it in Excel before you import it into the database.

Getting/setting session variables is just like any other array, but PHP then saves the serialised contents into a file at the end of each request. Personally I would store the user data returned from your database within an array (excluding the password), within the $_SESSION array: $_SESSION['user'] = $row; That would create a session variable called 'user', populated with the user's data. On the edit profile page you're then able to access this data: First name: <input type="text" name="first_name"<?php if (isset($_SESSION['user']['first_name'])): ?> value="<?php echo htmlentities($_SESSION['user']['first_name']); ?>"<?php endif; ?>> Although you'd probably be better off storing the data within a variable to make the code more readable: $user = $_SESSION['user']; First name: <input type="text" name="first_name"<?php if (isset($user['first_name'])): ?> value="<?php echo htmlentities($user['first_name']); ?>"<?php endif; ?>> Note the use of htmlentities.

None of those would work. What's in your code is ".$_POST['username']." - double quotes either side as to break out of / re-open the string that is opened / closed with double quotes (mysql_query("INS...")). The dots are the 'concatenation' operator that joins strings (literal or within variables) together. The single quotes are part of the actual SQL. Often people find it more readable to use curly braces to concatenate the strings: '{$_POST['username']}' Read the manual for more information. Also have a read up on how to prevent SQL injections.

Can you show us all the code involved?

$list_output = ''; foreach ($sub_pages as $sub_page) { if ($sub_page->post_status=='publish' && $sub_page->post_parent== $page->ID && !empty($sub_page->guid)) { $list_output .= '<li><a href="'.$sub_page->guid.'">'.$sub_page->post_title.'</a></li>'; } } if (!empty($list_output)) { $output .= '<ul class="sub">' . $list_output . '</ul>'; }

It looks/functions great, but thinking practically I'm not sure when it would come in useful? Forums are categorised and ordered for a reason. What happens when there's a lot more posts, are older ones hidden? You'd loose out on sites with large user bases if there's only a small window of visibility. I would build on the idea, you have a great little prototype to work with. Perhaps go more in the direction of instant chat, as opposed to message boards though?

Store the HTML in a separate variable, and if it's not empty after the loop then concatenate it onto $output wrapped in the UL tags.

That's a better idea.

If you provide the mark-up, there's almost always a better way to do this using just CSS.

I don't see how typing code is a tutorial? A tutorial needs to explain things- would be quicker just to show them the source.

I don't go on Facebook very often (or are even able to access it at this moment), but somewhere in the URL they will have a hash. The hash allows you to alter the address without actually navigating away from the page. Only newer browsers support an event to to detect said changes, but there's a jQuery plug-in available that will make it all effortless, and also allow you to support the back-button navigation. Just note that whatever appears in the hash is not sent to the web server - i.e. you can't get the value of it within PHP.

You would be best off running it from the command line, as then you won't run into time-out issues or require a browser to be left open running it. Although I'd check your host's terms of use because they might not want you running spiders on their servers.

Check the contents of $body_message with var_dump - it may just be that you're not actually sending anything. As 9mileshq pointed out you're missing some headers, more importantly the content-type header, which if not set it's likely that the email client will just display the HTML as plain-text. Also I wouldn't use JavaScript to display the result. You can't rely on the user having it enabled, which means they wouldn't be redirected and you just display a blank page breaking the navigation. PHP allows you to pass a location header with the response that will tell the browser to redirect to another page: header('Location: index-4.html'); You will probably never encounter a situation where this method doesn't work, where as users with JS disabled is somewhat more common.

This tutorial may help: http://sixrevisions.com/tutorials/javascript_tutorial/create-a-slick-and-accessible-slideshow-using-jquery/

With jQuery objects you need to use the val() and html() methods: $('clickscost').html($('clicks').val() * 0.05);

'fraid so. There's no way for you to prevent them getting the source code, because at the end of the day the browser needs it to display the web page. If the browser has it, the user has it. You can obfuscate it, but not prevent them getting it. Of course, if someone's paying for you to develop them a website you would assume they can't do it themselves and wouldn't have a clue how to "decrypt" the encoded string. I'm also guessing you don't complete an entire website for them before they even agree to purchase it, so a design complete but "lorem ipsum" filled type site would probably put them off trying to rip it anyway, because they're only going to have to pay for it to be finished. I wouldn't worry too much to be honest.