HartleySan

Hello and welcome to the forums. It sounds like you're not posting a field with the name "year". Please double-check the HTML for your form.

Hehe. I'm sure you will. You seem like a pretty darn good developer already.

I had a big issue with absolute URIs for the longest time too. For whatever reason, they can be a royal pain to fully understand, even though they aren't that hard to understand conceptually. In other words, I feel your pain. Taking the time to understand them so that they can be properly utilized is quite beneficial though, I think.

Emilie, I think your advice is really good, but there are a couple of things I like to do differently, so I will mention those things here just to provide another perspective. For one, I don't like to check $_SERVER properties to try to programmatically figure out which environment I'm in. I've seen that go wrong so many times, and there always seems to be something that you cannot control / account for that causes the whole thing to break. As such, I generally define a $prod variable and set it to true in production and false in my dev environment. Furthermore, you can put the $prod variable in a separate file and include it in your config file so that you don't have to edit your config file every time you move it from dev to production. Basically, you create the prod.php file once for each environment and never touch it again after that, and it just works... always. Also, I much prefer absolute paths for includes over relative paths. While absolute paths require a bit more typing (most of which is just copy-and-paste), they are, by their very nature, absolute, and not subject to change. Again, I think they provide a more rigid structure in a place where it's good to have that rigid structure. By using absolute paths, you can define everything once for each environment and be done with it. Of course, I understand the benefits of relative paths, etc., but after having worked on many projects, I have found that absolute paths almost always work better.

In that example, yes, target will point to the same DOM object as is assigned to the username variable. However, something important to note is that if you set up an event handler for a DOM element that contains subelements, then that event will fire for any of the subelements as well. For example, if you set up a click event handler for a div that contains p elements, then clicking on any of the p elements will cause the click event for the div to fire, and in that case, target will refer to the p element that was clicked on, not the parent div. That make sense?

Oh, good to hear. Thanks.

No, you cannot pull out sections of an include file. As you suggested, you need to either put the code within functions, or put the code in separate include files.

Yes, writing require(MYSQL) will take the contents of the mysqli_connect.php file and dump them in that exact location of the file including the MySQL DB connection file. Also, yes, having require(MYSQL) more than once will cause the error you are seeing with attempting to redefine already defined constants. In order to help you beyond that though, I need to see the code for the script that is including the other two PHP files. Please show us that code too, and we should be able to help. Thanks.

Hi, Ray, and welcome to the forums. To answer #1, we will need to see your actual code. Could you please post the relevant parts of your code (minus the connection credentials), and when you do, could you please use the "<>" button in the WYSIWYG editor to better format your code? Thanks. As for #2, PHP is run on the server, and as such, PHP code is not output to the browser. Naturally, anything you echo will be output to the browser, but so long as you don't echo your constants, etc. (which you should never need to), that information would never be displayed in the browser, and no one would ever see it (save those that have access to the PHP files on your server). For question #3, there are a variety of ways to handle config files, but my personal favorite is to define a file called prod.php that is simply the following: <?php $prod = true; That's what it would look like in my production environment. In the development environment, $prod would be set to false. After you create that file once and have it properly set to true or false for each of your environments, you never have to edit it again. From there, I include prod.php at the top of my config file as follows: include('prod.php'); // Note that prod.php is in the same folder as the config file. Then, any time after that that I want to know whether I am in production or not, I just check the $prod variable. I generally also have the following towards the top of my config file (but below where I include prod.php): if ($prod) { // Set up production DB connection. // Set production environment constants. } else { // Set up development DB connection. // Set development environment constants. } By doing things that way, you can easily copy all of your files over from the development environment to the production environment (including your config file) at will, and so long as you never touch the prod.php file, you're fine. You don't have to edit any of your files, ever. Hope that all helps.

$_POST['subject'], $_POST['grade'], and $_POST['year'].

Yes, you basically need to use a proxy script to display your image. Here's a good link that explains it simply: http://foundationphp.com/tutorials/image_proxy.php

Try echoing out your query to the screen to make sure it's valid. Also, try running the query directly on the DB to make sure it actually works. Lastly, I would recommend using mysqli_query instead of mysql_query. If you're still stump after doing all of that, please let us know. Thanks.

No problem. Glad you were able to get to the bottom of the problem.

Hello and welcome to the forums. Could you please explain in more detail what is incorrectly occurring? Thanks.

Above the if conditional for $_GET['s'], write the following, run the script and see what happens: echo '<pre>'; print_r($_GET); echo '</pre>';

You should not use strings that have to be modified to query the DB. Going that route, there are too many exceptions and too many what ifs that you have to account for. Instead, add a number to the URL that serves as a primary key in the DB, and then you can make the rest of the URL whatever you want, and you don't have to worry about the problems you are currently facing.

Yes, you are right. I'm sorry. I didn't have the book readily available when I asked the question, so I just wanted to make sure. Anyway, to answer your question, unless there is a mistake in your code, calculator.js should be doing all the calculations when you click the "Calculate!" button. As you mentioned, the return false statement at the end of the event handler suppresses any actual form submissions. As such, calculator.php is never being called and none of the code in it is used for anything. The code on line 66 on page 477 is what is causing the total to be displayed on the screen. With that said, it's beneficial to keep the form pointing to calculator.php and to keep that file around in the event that JavaScript is not supported or is intentionally disabled in someone's browser. While the percentage of people nowadays that browse the Internet without JS enabled is quite low (reportedly around 1%), if you want to reach the widest audience possible, then keeping the PHP backup there in the event that JS cannot be used is good. With that said, for the 99% of people that have JS enabled, using the JS solution instead of the PHP one will lead to a more responsive and fluid experience. In short, providing a JS solution will generally lead to a better overall experience, but having a PHP solution as well as a backup will help you reach a wider audience (as well as potentially help increase the SEO of your site, etc.). That help at all?

What's an example of the URL parameters sent to the script?

eonfloyde, you are referring to pages 473-478 in the Modern JavaScript book, not the 4th edition of the PHP/MySQL book, correct?

Chris, a 500 error means that there is a syntax error in your code. Use comments to isolate the error and fix it. It would probably also help to have error reporting enabled.

I agree with Larry. You should separate the different types of data into separate select elements / radio buttons / checkboxes, and then go from there.

What line is the error on, and what is the corresponding line of code?

Different page titles are good, but at the same time, some sort of hierarchy and logic to the naming of pages helps better tie your site together (both for people and SEO), so I would aim for that.

Go Bucks! You can do any number of things, but I think there may be a bit of a misunderstanding on your part. If the user just closes their browser, the next time they go back to the page, the session will still be active and contain the last action time of the user, thus everything would still work fine. As such, I don't think you need to do anything special to handle the case you suggested (unless I'm missing something or misunderstanding your question). As for logging them out without the user taking an action, yes, you absolutely can do that, but you will have to use JavaScript, as Larry suggested. Personally, I don't feel that doing all that is necessary though because as far as I'm concerned, if a user just sits on the same page all day, it doesn't bother me because they're not seeing any new content, so I don't feel the need to automatically log them out of the system. You can go either way on that though, and it really depends on the sensitivity of what you're displaying. If you require a JS solution though, let us know. Otherwise, I think you're fine.

I have two comments: I wouldn't restrict people to a particular page based on their location. Users generally don't like that. It sounds to me like you need to practice the basics a lot more before you can do what you want. I highly recommend going all the way through the book this board is for, and then coming back for advice once you have the basics. Thanks.