HartleySan

If you're new, you should start with chapter 1 and go in order. I prefer phpMyAdmin, but I recently learned that phpMyAdmin cannot execute stored procedures for testing purposes from the SQL CLI. In that case, you'd have to use the command line, I think. Other than that though, phpMyAdmin is quicker.

To be honest, I don't know all the details behind formatting dates in databases. I'm sure it can be done, though. However, from a logical standpoint, it makes the most sense to me to use the default date format for the database, and then when you retrieve the date, style it in your query. I believe Larry does the same thing in the book, but don't quote me on that.

I would recommend using the default DATETIME/TIMESTAMP format for the database, and then format data when pulling it from the database.

Certainly, using UNION is a possibility, but if possible, it might be best to join your tables instead, and then search on those results. If anything, I find it odd that you need to search three tables, all separately. If that's the case, then you may want to consider redesigning your database. I mean, just at first glance, I would imagine that there is a connection between your categories and products tables, in which case, a join shouldn't be a problem. If you'd like to provide more specifics regarding what you want, maybe we can help. Thanks.

I suppose the best bet would be to actually download a CMS, like WordPress, and see how they do things. One thing that is probably a prereq is some sort of built-in WYSIWYG editor, which makes it easy to format text. A more broad CMS would probably also contain features for easily creating all-new pages, not just news.

I don't have the book in front of me, nor do I recall this example specifically, but I can make the following general statements: If any of the strings in $very_bad are found in $value passed to this function, then a single empty string is returned once. In other words, if anything bad is found, the following $result variable is set to an empty string: $result = spam_scrubber($someValue); I'm assuming that $result is probably the body of the email, but I don't know. If that's the case, then the body is set to an empty string if any of the "bad" things are found in the body. And like Larry said, as soon as a return statement is hit, the function is always immediately exited from, even if the return statement is in a loop in the function, as is the case above. The array_map function is a built-in PHP function. I recommend checking out the array_map page on PHP.net for more information. Also, in the code snippet provided above, array_map is not used, so I don't think that array_map has anything to do with the above function (at least, not that I can see). In general though, I think what Larry is trying to say is that if you have an array within an array, and then use the array_map function, the array within the array might be "lost". In other words, only the first value in the array within the array will be retained, while the rest of the array in the array will be completely erased (as if the "non-first" values never existed), so that the end result is a single array (without any arrays in it). Well, hope that helps.

At this point, I imagine Larry and Matt are the only ones viewing this post, but here's an update: After discussing the site in more detail with Matt, we decided that it would be best to create the galleries from the index.php pages directly, and not via a separate function being called. With that said, we created the index.php files so that if changes ever need to be made, we don't need to edit the index.php files. Here's the flow of the index.php files (the pseudocode): <?php // Include config file. // Include DB connection. // Make DB query. The appropriate DB query is automatically constructed when the index.php file is made. // Include header file. The header file is equipped with the logic to handle a failed DB query as well. (This more or less equates to handling the page title, etc.) // If the DB query is successful, include the HTML page that loads the content based on the query results. // Otherwise, load an error HTML file. // Outside of the if statement, include the footer. ?> That made the most sense to us, and it's very similar to the view files you use for your second example site in the book, Larry. Any thoughts are appreciated, but at this point, it more or less seems fine to us.

I can't answer all your questions, but #2 is definitely an encoding issue. Somewhere along the line, you're probably not using UTF-8 or something. As for the dates, make sure that they're in the database first, and if they are, make sure you're actually retrieving them properly. If that's okay, then check the displaying of them. I haven't gone through the message board script, so I cannot comment on #3. Sorry.

Thank you all for sharing your points of view. It's good to bring multiple ways of thinking about something to the table (pun intended); it gives me a more holistic view. Also, for the record, I'm American, and English is my first language. Japanese is my second, and I live in Japan, thus the handle. Anyway, I agree that joins aren't really "filtering" data (at least, not in the sense that WHERE is). But still, with an inner join, some filtering is going on. For example, if I have a customers table and an orders table, and a customer has never made an order (which is a bit odd to think about), then that customer will not be included in an inner join with the orders table. I mean, again, it's not a lot of filtering, as the tables should more or less match up for all entries, assuming that the database is properly normalized and foreign keys are used properly. I also found the following interesting excerpt from MySQL's reference pages: (Source: http://dev.mysql.com/doc/refman/5.0/en/join.html) This is right on track with the statement that Matt made a week or so ago in a related post. It's all starting to come together now. Also, similar to what Matt said in his above post, the following are noted on the same page as was referenced above:

That makes sense. Thank you very much for clarifying that.

I will admit that one of my weaker points is comprehending SQL queries, especially ones with multiple inner joins (as is the case with a lot of the queries for the second example site in the book!). With that said, I'm trying to get better, but I want to confirm some things. Let's use the following query as an example (please refer to the book for details on the database structure, etc.). This example comes from page 196: SELECT gc.description, gc.image, CONCAT("C",sc.id) AS sku, CONCAT_WS(" - ",s.size,sc.caf_decaf,sc.ground_whole,sc.price) AS name, sc.stock FROM specific_coffees AS sc INNER JOIN sizes AS s ON s.id=sc.size_id INNER JOIN general_coffees AS gc ON gc.id=sc.general_coffee_id WHERE general_coffee_id=<some_category_id> AND stock>0 ORDER by name ASC; My first question is, with inner joins, how important is the order? Does the order matter at all? If so, why? Sorry if that's too broad a question, but at the moment, I am having trouble imagining the whole situation. Next, the first inner join is the following: FROM specific_coffees AS sc INNER JOIN sizes AS s ON s.id=sc.size_id So this is going to find all instances where id in the sizes table is equal to size_id in the specific_coffees table, and then pull the appropriate data for those rows, right? Is my thinking correct here? Okay. So here's where it gets interesting. Is the second inner join acting off the results of the first inner join? In other words, the first inner join is performed, and then among those (filtered) results, we are running a second inner join that is further filtering the results. Or perhaps, are the two inner joins independent, and the results from both are being concatenated together? This is where my understanding is weak. I tend to believe that from a logical standpoint, the former is more likely, but I really don't know. Could someone please clarify this point? In the end, I suppose I want to clarify whether the following two inner join statements would produce the same results or not: FROM specific_coffees AS sc INNER JOIN sizes AS s ON s.id=sc.size_id INNER JOIN general_coffees AS gc ON gc.id=sc.general_coffee_id FROM specific_coffees AS sc INNER JOIN general_coffees AS gc ON gc.id=sc.general_coffee_id INNER JOIN sizes AS s ON s.id=sc.size_id And lastly, once the two joins have been performed, then the results are limited one more time by the WHERE clause, right? In essense, after the joins, we only want the results related to one type of coffee and for coffees in stock, right? Sorry for the long post, but any help is appreciated. As a random side note, the book uses the notation "ORDER by" at the end of the query, but I've always used "ORDER BY". I suppose it doesn't matter though.

Sorry for giving a somewhat incomplete answer before. Apparently relative URLs are perfectly acceptable for window.open. (Source: http://www.tizag.com/javascriptT/javascriptpopups.php) As such, the URL itself is probably the issue. I'd start playing around with various values until you can debug it. I'm still not sure whether ./ and ../ are supported though. Again, I recommend playing around with the values for the URL.

Can't you store different pieces of the URL in strings in a config file, and then just add the different pieces together. For example: var sBaseURL = 'http://www.example.com/'; var sUsersScript = 'users.php'; var sAdminScript = 'admin.php'; var sURL = sBaseURL + sUsersScript; window.open(sURL,...); What do you think?

We were saying that you don't need to use the user agent information. Just use session_regenerate_id().

Ron, now that I have more time, I will try to better reply to your questions. There are a few things going on. First off, in regards to your first question: I did some research, and amazingly, you're right. The second one returns the same value. The fact of the matter is, this is always referring to the select HTML element. That's not debatable. What I didn't know is that if this refers to an element within a form, then this.form refers to the parent form. Similar to how this.parentNode would (in most cases) refer to the parent form. I did not know this, and learned something new. With that said, this.form.seasonid is the same thing as this. Kinda the whole "This man's father is my father's son." Anyway, from this.form.seasonid, you can access options just fine. And again, this.form.seasonid in the brackets means the same thing as before, after which you add the index value of the selected element, and then the value of that. Basically, the second method is super, super inefficient, but in the end, you get the same thing. That was a bit of a brain teaser. For practical uses though, stick with the first one. As for your second question: This issue is a result of me being a newb. When I posted my original code, I did a couple of things wrong. One, I used single quotes to surround the HTML attribute values, when I should have used double quotes. More importantly though, there was no ID attached to the select element, so getElementById won't work. Duh! Obviously, there was a name attached, but no ID. Basically, if you give the select element the same ID as the name, it'll work. My bad! As for question #3: This I can't really comment on without seeing your code. My only assumption is that you've made a mistake somewhere. If you don't mind posting your code, then maybe I can better help. So, with all that said, what it adds up to is mistakes on my part, not browser incompatibilities. If you fix the things I mentioned, then I guarantee it'll work in all browsers that support JS. And on that note, in regards to Ajax, in this day and age, you should be fine using Ajax. The truth is, yes, if someone is using a browser that does not support JS and the XMLHttpRequest object (i.e., pre-IE5 browsers), or if a user has intentionally disabled JS, then Ajax will not work. However, that type of user is very rare these days. So yes, the truth is that you could potentially deny service to some people, but in all cases, I can't imagine the user not being able to upgrade to an able browser, if they really wanted to. And really, if you start assuming that users can't use JS, etc. these days, you're really denying all users a lot of great features you could add to your website. In conclusion, don't shy away from Ajax because a super small, and ever-decreasing number of people's browsers don't support it. Also, the "browser incompatibilities" you mentioned were merely human error on my end. Sorry. I'll try and double check my code next time before posting. Anyway, here's a revised version of the code, which *should* work in all browsers that support JS: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"> <html lang="en"> <head> <title>onchange event test</title> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> </head> <body> <form method="post" action="reporthandler.php"> <select name="seasonid" id="seasonid"> <option value=2>2011-2012</option> <option value=1>2010-2011</option> </select> </form> <script type="text/javascript"> document.getElementById('seasonid').onchange = function() { alert(this.value); }; </script> </body> </html> Also, feel free to ask any other questions and post your code regarding the purch issue.

Andrew, you're absolutely right in your suspicions of where the problem is. It's in the following line: <input type="hidden" name="page_id" value="<?php if (isset($_POST['id'])) echo $_POST['id']; ?>" id="page_id" /> //This is the problem code in my opinion The problem is that when you first load the page, nothing is set for $_POST['id'], therefore nothing gets set for value. Essentially, value remains undefined (or perhaps it's NULL). The point is, no ID is ever set, therefore one is never sent via the POST method. Try putting in a static value for value, and test whether that gets sent properly. I can almost guarantee it will. Anyway, to resolve your issue, when the page loads the first time, you need to be fetching an ID from a database, and either via the GET/POST method or Ajax, you need to take that ID retrieved from the database and set it for the hidden value. Unfortunately, I cannot comment much beyond that, as I don't have the book in front of me, and I don't know exactly what you're aiming for. Regardless, that's the gist of it. Hope that helps.

In the context you're referring to, the user agent more or less equates to information about the browser being used. In other words, the browser name, version, etc. You cannot confirm any of the things you want to confirm from JS. As Larry said, that poses a huge security risk to give JS access to a user's local machine. Basically, just do what Larry suggests.

If you're jumping to an anchor on the same page, then all you need is the following: echo '<a href="#' . $row['anchor_name'] . '">Link name here</a>'; And if the anchor is on another page: echo '<a href="otherscript.html#' . $row['anchor_name'] . '">Link name here</a>'; Hope that helps.

Thanks for replying, Ron. I'm at work and stuck on IE6 at the moment, so when I get home, I'll play around with my recommended code a bit more in different browsers, and then report back with answers to your questions. Initially, just reading your post though, I suspect there are things other than browser incompatibilities causing the issues, which I'll explain when I get home later.

Hmmm...perhaps I need to start thinking of the W3C specs more as recommendations than law. I do try to stick with them whenever in doubt. Anyway, regarding proxy PHP scripts for accessing images outside of the web root, I honestly could not think of any other way to do it, so I guess it'll have to be fine. Not to mention the fact that it just plain works, which is indisputable. Larry, if you don't mind me asking, if you use a proxy PHP script to load images outside of the web root, is it pretty straightforward to load a lot of images from one script, and then place HTML all around those images? Thanks.

Sorry for taking so long to respond. I created the following sample script to show how JS should be separated from the HTML: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"> <html lang="en"> <head> <title>onsubmit test</title> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> </head> <body> <form action="http://en.wikipedia.org/wiki/Wiki" method="post"> <p><label for="firstname">First name: </label><input type="text" name="firstname" id="firstname"></p> <p><input type="submit" value="Submit"></p> </form> <script type="text/javascript"> document.forms[0].onsubmit = function() { window.open(this.action,'','width=1000,height=700,left=500,top=5') return false; }; </script> </body> </html> Also, if you do use the inline defintion, which I do not recommend, then you shouldn't use return false. You need to return a JS function/method. Please Google this for more info. I'm not going to explain it here though, because you shouldn't be using inline definitions anyway. Also, the first argument for window.open is the URL, and URLs cannot contain relative paths (i.e., ./ and ../). As a more minor point, the default for scrollbars and resizeable is yes, so you don't need to specify those. Also, top is only supported in IE, so you need to consider that. Lastly, if you don't want to use forms[0] in the JS, you can assign a name to the form and use that. For example: <form action="http://en.wikipedia.org/wiki/Wiki" method="post" name="homer"> ... document.homer.onsubmit = function() { That help?

Good lord! Somehow, I feel so old. I really try not to waste my posts though (with the exception of this one, of course!).

All good thoughts, Larry. Thanks for sharing them. I haven't spoken with Matt for a while about it, so I will see what's going on. Also, I like your idea of passing the DB connection as an argument. Makes sense.

Some browsers won't accept onSubmit; it needs to be onsubmit. That might not be the problem though. Your action link could also be the problem, but can't confirm that from here. Also, you really should try separating your JS from your HTML. It's late here, so sometime tomorrow, I'll try and code up a simple example to demonstrate what I mean. Hopefully, in the meantime, I can also find the issue with your code.

Oh, you meant you wanted to jump to an anchor on a page? I see. Well, if that's the case, then you probably need to completely restructure your URL. I thought you were clicking on a subject link, and then loading all the details of that subject onto a separate page. Actually, bahaa, I'm confused now. If you get it working, then great, but if you have the time, could you please explain exactly what you want. Thanks.