HartleySan

Hello kamaboko, and welcome to the forums. A property is a number, string, Boolean, array or object attached to a higher-level object; a method is a function attached to a higher-level object. Really, it's just a semantic difference made to differentiate functions attached to objects from other properties attached to objects. That make sense? By the way, you a big fan of kamaboko? I quite like it myself.

And by "Jon", Antonio (Thomas?!) meant me. But yes, "FrontEndDev" is an interesting screen name. Are you hoping to become one someday?

Hello Ojo-sama, and welcome to the forums. It's hard to offer advice without more information, but I can offer the following pointers: You should have one table that contains all your product info, minus the stock info, as you described above. You should then have a second table that contains the product ID as a foreign key, and then the size and stock information. Please note that this table will likely contain the same product ID multiple times. In other words, every size/stock combo for a given product will have the same product ID foreign key. You will then use a query similar to the following to get the size/stock info about a product: SELECT * FROM products, product_sizes_and_stock WHERE products.id = product_sizes_and_stock.product_id AND products.id = ?; Given the nature of your question, it seems like you might need some more knowledge on database normalization and how to perform joins before you go much further, but that's the basic idea. If you have any further questions, please don't hesitate to ask. Thanks.

Given the nature of your questions, I get the feeling that there is a bit of a disconnect with how JS and the DOM interact. I will do my best to explain what's happening (and I apologize if I say a bunch of things you already know). The DOM is an API that is separate from JS. JS interacts with it, but in reality, the DOM is not a part of JS. This is done so that other languages can also interact with the DOM. And when I say the DOM, I'm referring to a virtual tree structure that mimics the current state of the HTML document. Given that HTML is hierarchical in nature, it's probably not too hard to imagine what this virtual tree structure would look like (with the html node at the top, and then branching down to the head and body elements, etc.). With all that said, when you use the JS built-in document.getElementById method (read "function"), you are telling JS to search through the DOM for an element with the specified ID (which is specified in string format). If no element with the specified ID exists, then null is returned, but assuming an element does exist with the specified ID, then the getElementById method returns a special JS object that contains a bunch of information about that element. The easiest way to think of this special JS object is that it is the JS representation of the element in the DOM (i.e., the actual element displayed on the page in your HTML). Given all that, when you call the setText function, you are passing the ID of the element you want to place the text in and the actual message to the function. Since both of these arguments should be strings, the function first validates that they're both strings, and assuming they are, Larry then using the document.getElementById method to find the element in the DOM with the specified ID. The corresponding JS object is then stored in the output variable. From there, Larry then tests if the JS object returned by the document.getElementById method supports the textContent property. He does this because not all browsers support this property, so you need to test for its existence before you just assume it's okay to use. If the property is supported, he then assigns the message string to that property. This causes the message to appear on the screen immediately by rendering the message text within the element whose ID you specified. In other words, the message is output to within the element stored in the output variable. If the textContent property is not supported by the browser, then Larry uses the innerText property instead, which essentially does the same thing. I think Larry explains in the book why textContent is preferable over innerText. That all make sense and answer your questions/confusion? Edit: Antonio and I responded at the same time, and I didn't see his response before posting mine. Sorry.

Nice find, and thanks for sharing the solution.

Please read Antonio's post and respond in kind. Thank you.

The file you're pointing to doesn't exist. You're outputting whitespace or something to the browser before the header function calls. Fix both of those, and it should work (or you'll at least be close).

A lot more information would be helpful, but if you're not getting any errors in the code, then very likely, your upload folder does not have the proper permissions to allow writing to it.

Good eye, Larry. I didn't even notice that. Thanks.

Well, that will only work in some cases (i.e., depending how your .htaccess file is structured). Still, glad you found a solution.

So, what's the deal? Is the DB query okay? Is the value in the markup before submitting the form? Is the hidden element actually within the form tags? Please provide more info.

You always need an outline (even if it's just five minutes thinking about the problem before you start), but in my experience, no matter how hard to try to predict everything, something will always come up that you don't expect, and you will have to change something around as a result. With that said, having made all the mistakes you have made at one time myself, you eventually learn, and the culmination of those experiences leads to more or less knowing how to solve most problems out of the box.

So you solved the problem then?

Having the whole form on one page, while it will slightly increase the PHP logic for that page, will ultimately be easier to handle than a multipage form. The basic logic would probably be something like the following: if (form-submitted) { // Validate initial inputs. if (input-that-dynamically-creates-additional-inputs-is-selected) { switch (dynamic-input-value) { // Generate whatever you need for further inputs. } if (dynamically-created-inputs-are-selected) { // Validate. // Rinse and repeat as necessary } } } // Render form with sticky values if not yet completed.

Load the form, and in your browser's element inspector, check out the hidden field. See if the expected value is there. If it isn't, then something is probably wrong with retrieving your DB query.

Even if you are creating a form with dynamic fields without JS, you do not need multiple pages. Resubmitting and repopulating the same page would be a better solution, I think... easier too.

For starters, I wouldn't use the $_GET array. The only time I would use the $_GET array for a form is for a search form in which you want the resulting query to be "bookmarkable". For a standard registration form though, I wouldn't use the $_GET array, as it exposes all that data in the URL, which, if nothing else, is bad form. (After all, would you feel safe and secure if the password you just entered was openly displayed in the URL?) With that said, I would instead post all three pages of the form, and then store the data from the previous page(s) in either the session (as you mentioned) or hidden input fields. With all that said though, my personal favorite solution is to have the whole form on one page to begin with. While I acknowledge that there're times in which you need a multipage form, in general, I really don't like multipage forms. And if you really do require a multipage form though, you could always use JS to power the whole thing, in which case, you wouldn't have to worry about losing data from "page" to "page".

Here's the official Apache explanation of RewriteBase: http://httpd.apache.org/docs/current/mod/mod_rewrite.html#rewritebase And here's a more understandable explanation of RewriteBase (I'd read the various answers for a more holistic view): http://stackoverflow.com/questions/704102/how-does-rewritebase-work-in-htaccess And another possible solution: http://michael.orlitzky.com/articles/avoiding_rewritebase_with_mod_rewrite.php Please look all of those over, and lemme know if you need additional help.

If you're using mod_rewrite, the best solution is to use an absolute path to all CSS/jS files. For example: http://www.example.com/css/styles-for-page.css

Hello and welcome to the forums, bem. Could you please provide us with the relevant code so that we can better assist you? Thanks.

You can just tack a number onto the end for pagination. For example: http://www.mystore.com/France/Paris/2/ And just like regular pagination, no number would be the same thing as "1". And yes, you can move all this logic to your .htaccess file with mod_rewrite, but you can't do looping, etc., so you instead need to use a regex. For example: RewriteRule (\w+)/(\w+)/(\d+)/? index.php?country=$1&city=$2&page=$3 Now, please keep the following in mind: The above line of code is not the only thing required for mod_rewrite, but it's the main part. Please see Larry's advanced PHP book or online resources for mod_rewrite for details. You probably should add to the above regex, as it's not robust enough to handle the optional page parameter, etc. That all make sense?

No problem. While there are exceptions to every rule, in general, one-to-one relations can go in the same table, one-to-many relations can go in two tables, and many-to-many relations should be spread across three tables, with the intermediary one between the other two.

You're welcome. Please note though that in the future, you can save us a lot of headaches by giving us all the information we need from the very start. Thanks.

Yes, Larry's 100% right. I thought there was an error, but there is not. You're getting an empty set because the string 'larry's forum' does not exist in the forum_name column, which is perfectly understandable.

What's the error message? If you change the name string to something more standard, does it go through okay?