HartleySan

I apologize, as I don't have the book in front of me, but one thing I can say for sure, you're using POST to send the data, but trying to receive it with the GET superglobal, which won't work. As for the SESSION superglobal not containing a user_id entry, etc., it's hard to comment on, because we don't know the exact configuration of your server. That doesn't mean you have to tell us, but what I would do is change the POST/GET issue, and then start echoing statements like mad throughout the script until you can locate the error. Hope that helps.

On page 550 of the 3rd edition, Larry states: "The first time the administrator runs this script, there will be no existing artists. In this case, there won't be any options in this pull-down menu, so an indication to add an artist is made (FIgure 17.15). This otherwise-basic code is complicated by the desire to make the pull-down menu sticky. To make any select menu sticky, you have to add selected="selected" to the proper option. So the code in the while loop checks if $_POST['existing'] is set and, if so, if its value is the same as the current artist ID being added to the menu." On the same page, Larry uses the following code, which can easily be adapted to your needs: while ($row = mysqli_fetch_array($r,MYSQLI_NUM)) { echo "<option value=\"$row[0]\""; if (isset($_POST['existing']) && ($_POST['existing'] == $row[0])) { echo ' selected="selected"'; } echo ">$row[1]</option>\n"; } Well, hope that helps.

Perhaps I never understand well what you wanted to do, but this seems unnecessary. Nevertheless, good work!

Yeah, I was just trying to boil the query down to the essentials, so that it can be built on from there. Also, I completely understand what you mean by starting out with things in one table, and then breaking them up at a later time. Also, if I could figure out how to list my email address in my profile for people to contact me, I would do that, but I cannot figure out how to do that! Larry, how the heck do you add your email address to your profile for people to see?

Granted, the database I created to try this out is much simpler than yours, but the concepts are the same, and I got an INNER JOIN to work fine using the following: SELECT schedules.schedule_id, t1.team_name, t2.team_name FROM schedules INNER JOIN team AS t1 ON t1.team_id = schedules.visitor_id INNER JOIN team AS t2 ON t2.team_id = schedules.hometeam_id Matthaus definitely hit the nail on the head in regards to using multiple joins on the same table to return all the desired results in one query. Thanks, Matthaus. I will definitely remember that. EverettG, if you don't mind, there are a couple of things I noticed with your database design that you might want to consider for better normalizing everything: 1) the date and time fields could probably be combined into one DATETIME or TIMESTAMP field, which could be parsed on the MySQL side as necessary. 2) You should probably have a separate table for stadiums. And then link the stadium ID back to the teams tables, so that you know what the home fields are for each team. 3) You misspelled "Invesco Field". 4) You could have an algorithm on the PHP side to figure out the season and the week, so that you can grab the appropriate data from the database using the DATETIME/TIMESTAMP field. Well, anyway, just some suggestions. I'm glad you solved your problem though, and I think we all learned something from this post, so thanks. Also, Matthaus, thanks again for your expert knowledge. That was very helpful.

It's late, and headed to bed now, but thank you for the compliments and the detailed post. I will look into it tomorrow when I have more time. I think we are close to what you are looking for, so don't fret.

Larry covers this in detail in his PHP 6 and MySQL 5 book. The E-Commerce book is somewhat more advanced, and assumes you have these "basics" down. In order to handle pagination though, you basically need to use the LIMIT statement in the MySQL query, and then display the results accordingly using PHP. If this is all new to you, I highly recommend going through Larry's PHP 6 and MySQL 5 book first. It's an excellent primer for the two.

Without seeing the entire table structure, I can't guarantee the following will work, especially considering my weakness with JOIN statements. Anyway, please try something like the following: SELECT schedules.schedule_id, team.team_name FROM schedules INNER JOIN team WHERE schedules.visitor_id=team.team_id OR schedules.hometeam_id=team.team_id My rationale for this query is that you'd want to display the results as follows: _____Visitors_____Game____Hometeam_____ visitors-team-name...1...hometeam-team-name visitors-team-name...2...hometeam-team-name visitors-team-name...3...hometeam-team-name visitors-team-name...4...hometeam-team-name visitors-team-name...5...hometeam-team-name If that's the case, then the above query should work. I mean, test the query out using the SQL tab in phpMyAdmin, and see if the results are satisfactory. If they are, great, if not, let us know. Anyway, there are a lot of different ways to write JOIN statements, but I went with the most verbose one I could think of, since it's the easiest to understand. Also, thanks for your query (pun intended) about JOIN statements. It really forced me to sit down and actually try to write it out, which is always good practice.

xcrider2, I would set the base URI to C:\xampp\htdocs\, but you get the idea. If you have the base URI set up like that, you can better simulate the structure Larry recommends in the book, which is putting the MySQLI connect file outside of the Web root directory, etc. Actually, you might be able to set the base URI even to just C:\xampp\, but I am not sure if localhost can access files outside of the htdocs folder by default. Well, regardless, I think you have the right idea. It is tricky, and I ended up having to play around with it a bit myself until I figured it out in Windows using XAMPP as well.

Sorry for the incomplete answer at this juncture, but I am in a bit of a hurry. I am almost sure that you'll want to use a join between the two tables though, although I'm rather weak at joins myself, and would require a bit to come up with an appropriate one. If someone else answers the question before me, than great. Otherwise, I'll try and answer it later.

I have a feeling that this issue is related to something that you're not showing us. Given the other post (that you made alongside this one) in which you were using grave accent marks in your query, I'm betting that that may be the issue. Try it out, and see what happens.

Wow! This was a tricky one. I was looking at your query, and then thinking about it...and then looking at your query again. Finally, I saw (what I think is) the issue. In your query, you are using grave accent marks for $dn and $d. Change those to single quotation marks, and you're good. $q = "INSERT INTO profiles (user_id, first_name, last_name, directory_name, description) VALUES ({$_SESSION['user_id']}, '$fn', '$ln', `$dn`, `$d`)"; Please let us know if that solves the problem. Thanks.

Paul, the reason for the two functions for closing the DB connection is because only one of them will actually be executed each time. The exit() function after the first one will terminate the script (i.e., not execute anything after it), and if that the if statement that the first DB-closing function is in is not satisfied, then after the else statement, the other DB-closing function will be executed at the end. Hope that helps.

This is not really related to the book, but something I have always wondered: How is data in a database actually stored on the server, etc.? Is the data stored in CSV format, or perhaps some sort of special object notation, or something completely different? Does anyone know? I imagine that it depends on the database software, but to some degree, there must be similarities.

Paul, it is most likely your browser settings. I get the same thing, because I want Chrome to remember my email address and password for logging in, but the browser is too "dumb" to know the difference between normal login forms and registration forms containing fields for an email address and password. Most likely, if you disable the auto-fill setting in the browser, you'll be okay.

Matt, we have already discussed the various issues with your site outside this forum, but I will respond to your questions here as well, in an effort to create a more open discussion and atmosphere. First off, I think the idea for two tables in the database is a good one. However, I think my idea for how to implement the site slightly differs from yours. As we discussed before, I think there should be a login DIV at the top of every page, which will be within the header file. If a user is not registered, they can click the appropriate link for a registration form, which I think should require the following information: User name First name Last name Email address Desired folder name Along with this data, the users table would also contain a field for the record ID (the primary key) and a registration date. I also strongly feel that the folder name should be chosen when a user registers their account, and the folder name must be tested for uniqueness. I understand your car description/license plate analogy, but in the end, if you test to make sure that the specified folder name is a valid server folder name and unique, there shouldn't be any issues. Anyway, after the user has registered and verified their registration via email, I would not automatically jump them to the gallery setup page. I would instead include a link in the registration confirmation email that provides an explanation on how to setup a gallery, if/when they choose to do so. That's the imperative phrase: "if/when they choose". Also, I would place both that link and a link to their actually gallery page in their login DIV when the user is logged in. Next, when the user decides to set up their gallery, they should be able to simply go to their gallery page, and if the creator of that page matches the person visiting the page (according to the database), then the user should be given the necessary options to edit the page. If the are not logged in/are a different user, then they should only be able to view the gallery. It's also worth noting that when a user registers and confirms an account, I would take that opportunity to create a new entry in the gallery table that contains an auto-incrementing ID value, and a foreign key to the folder name in the users table. Again, if the folder name is truly unique, this should pose no problem! And like you mentioned before, if you decide to place all the images for a gallery within the created folder for that user, you don't even need any image info in the database. You can simply scan that folder for images everytime someone goes to that page. So, in the end, I think all you need in the gallery table is the following: id folder_name (the foreign key to the users table) gallery_name gallery_description country hobbies last_updated I think that's more than enough. Maybe I missed something, but I digress. Also, if you wanted, you could set default values for the gallery database to signify that a user has been registered with a gallery, but the gallery has not yet been set up. You could set default values like the following: gallery_name='Your gallery name goes here.' gallery_description='Your gallery description goes here.' Sorry, I'm just spitballing ideas, but I think you get the point. I suppose, in the end, it wouldn't hurt to have a gallery_active flag, but since the gallery is essentially active as soon as a user is registered, then I don't think that would be a problem. Or what I mean to say is that any customization beyond that is up to you, but I think the essentials are already there. Any thoughts?

Yes, you're right, Larry. I recall making a similar topic, and Larry getting rather annoyed with my persistence to handle multiple file downloads in one script. It cannot be done, in the sense that header information can only be sent once per page.

I'm not too familiar with outputting files, but I think once you output a file like that, you cannot echo any new information out to the screen. I could be wrong about that though. Either way, a good way to test it would be to first remove all the header info used for downloading the file, and just try to output the content to the screen. Once you have that working, try adding the download layer on after the content is output to the screen. Please let us know how that goes.

I've never used prepared statements before, so not 100% sure about that syntax, but I do not get the 'ssssssssssisisss' string. Also, I think you need to insert NULL for an ID value, assuming you have an auto-incrementing ID in the table. We can't see your database (and you don't need to show us), but I am wondering whether the users are even being registered in the database. Check out the content of the database, and make sure that the users are being registered properly in the first place. Please let us know what the situation is.

What exactly do you want to do? Do you have extire text files stored as blobs in the database? If that's the case, just echo the appropriate information that is grabbed from the database. Otherwise, you'll need to use functions like fread() to actually read external text files, and display the content on the screen.

Paul, it looks like for your original (no password) password, you have double quotation marks within single quotation marks. That won't work. If you truly don't have a password, just use two single quotation marks. Remember that single quotation marks interpret everything literally, so doing '""' (double quotation marks within single quotation marks) will make PHP think that the password is two double quotation marks, which I don't even think is a valid password. Also, remember that DB_PASSWORD is the constant, not the value set for it. Semantics, perhaps, but a constant can be changed at any time by simply changing the value in the DEFINE statement. Also, it can be erased by erasing the whole statement. It is not set on the server anywhere but the script where you define it. All I can say, without knowing more about your environment and what's in the script is that if your password is mypassword, then DEFINE ('DB_PASSWORD', 'mypassword'); "should" work. Please let us know if we can help anymore. Thanks. I imagine that there's a conflict between your phpMyAdmin password settings and what's being used for your script.

That makes sense, in the same way that a proxy server might be used to hide the actual IP address, etc., but...well, okay. I suppose if you really need that level of security, sure. Thanks, Jonathon.

Hey, it's cool, man. I seem to recall that part not being 100% clear in the book, so who knows. Good luck, and please let us know if you get it working.

Larry, if you don't mind me asking, what do you mean by a proxy script? I get the .htaccess thing, but I'm not sure what you mean by a proxy script. Also, you make a good point about having to edit all the index.php files if there is a change. That being the case, would you recommend having an index.php file in each folder that simply includes (in the programming sense) a top-level script? And then maybe, you would have a function in that top-level script that each index.php file calls and supplies the necessary information as an argument to get the correct data from the database? I mean, I suppose that's what you already said, but just want to clarify. On another note, I have been wondering about this for a while, but if you have an .htaccess file controlling access to a Web folder, why do you recommend placing the files outside of the public Web directory? Does it really add extra security? If, for example, all the images for a particular gallery where in a Web folder, and that folder also included an index.php script and an .htaccess folder, wouldn't that be plenty secure? Also, when you use the mkdir function in PHP, the default permissions are chmod 755, which would prevent the writing/deleting of files by non-admins, right?

chris, as I mentioned before, you are getting that error because you have not created a file called show_image.php. And like I said before, go to the index of the book, find show_image.php, go to that page number, and write that script. Then, make sure you put the script in the right folder, and it "should" work, although I have not tested this at all. Actually, I really wish Larry would comment on this, as I am not sure why the show_image.php script is not in the same chapter/section as the 10.4 script. Anyway, I'll look into this a little more thoroughly, but what I can guarantee is that if you don't have a file called show_image.php, you will continue to get this error. Please try what I am recommending, and then let us know what happens.