Larry
-
Posts
5413 -
Joined
-
Last visited
-
Days Won
155
Posts posted by Larry
-
-
The first error has to do with mysqli. I tried using mysqli_connect then mysql_connect and things are only working for mysql_connect. Is there a reason why it's not working for mysqli?
Most likely because your PHP installation doesn't support the Improved MySQL extension. You can confirm this by running a phpinfo() script. For debugging purposes, it'd also help to know the versions of PHP and MySQL in use, per the forum guidelines.
The second is that I'm getting an error on the require statement on line 15 of index.php. See error belowAn error occurred in script '/Applications/MAMP/htdocs/ex1/html/index.php' on line 15:
require(/ex1/mysql.inc.php) [function.require]: failed to open stream: No such file or directory
Is there a reason for this?
Yes: there's no such file or directory. it'd help to know what operating system you're using, per the forum guidelines, what Web server you're using, etc., but the problem is likely because your use of /ex1 means to start looking in the root of the computer (I assume you're using a Mac?), whereas your files are in /Applications/MAMP/htdocs.
Also, just to be clear, the book does assume comfort with the basics of PHP and MySQL. Although the book teaches new and useful applications of these two technologies, it does not teach either of them per se.
-
Also, be very careful as mSQL, as in msql.so, refers to an older database system, which is a precursor to MySQL. MS SQL, as in mssql.so, is what you're looking for.
-
Well, your PEAR installation failed, so any use of that PEAR class will also fail. This is likely a permissions issue and perhaps caused by the fact that you're trying to install PEAR into C:\php5 when PHP and everything is within C:\wamp.
-
If the name of the form element is storetype[], then $_POST['storetype'] will be an array not a string. In this code here:
$storetype = $_POST['storetype'];
you're losing all the data the user selected anyway, so you need to fix that.
In the HTML form, to make it sticky, you need to check if $_POST['storetype'] (or a local variable) is set and, if so, if the value in question, such as "fashion", is found within the array.
-
There's conflicting information online as to what Virtual Directory Support does and I don't know what the right answer is myself. But just open the active PHP configuration file for MAMP, edit that setting, and restart MAMP.
-
How about posting the updated code so we can help?
-
Yes, to be clear, this book assumes complete comfort with basic to intermediary PHP and MySQL. It teaches some advanced application of these languages, but doesn't teach these languages in themselves.
-
My inclination would be to use BASE_URI to help you create a constant and then include that constant in every file.
As for your second question, the first option is ALMOST an absolute path, it's just missing the initial /. The second option is a relative path. When you have a site with lots of subdirectories, there's a big advantage to using absolute paths.
-
(1) I have a book that briefly mentions "PHP's Superglobal Variables" that are prefixed by $_SERVER that have environment data. On page 93 you assign 'user_id' and 'username' to similar variables and on page 96 an entire array to $_SESSION itself. Are these like HTML's session variables and can you rely on the data safely being there during a session?
Superglobal variables are not prefixed by $_SERVER. $_SERVER is an example of a superglobal, as is $_SESSION, among others. I have no idea what you mean by "HTML's session variables".
(2) User accounts and logging in are kind of related. On page 5 you say "because you'll be storing information about customers, there are other laws involved . . . [and] the U.S. also has precise rules." I looked ahead and on page 266 it says "checkout.php behaves like register.php from Chapter 4." On page 169 there is a Customers table which must be present because the Orders table on the next page needs the customer_id. But it doesn't have a password column like the Users table has on page 52. That means that managing passswords is not possible as on pages 96-103. In fact, once the user has entered personal data, maybe he can't even go back and correct a mistake. Is that because the rules mentioned on page 5 limit what a user is permitted to do?No, it's because the second example site does not require (or allow) the user to log in. if you want that feature, you'd apply the information from the first site to the second, as I explain in the book.
Also, you seem to come from an ASP background. Just so you know, this book does not teach fundamental PHP and MySQL. It assumes that the reader already knows the key concepts.
-
You're quite welcome. Apologies again for the confusion and for not catching this myself earlier. And, of course, I'm the idiot that made that mistake in the first place.
For what it's worth, I'd say it's a good thing that you feel the need to make sure you figure it out: it's the sign of a good programmer! In hindsight, do you understand now why the single equals sign makes the error go away but why it also introduces a bug?
-
Your $pn variable has no value. You'll need to change your query so that it selects the product name as well as the price (e.g., SELECT price, product_name FROM...). Then you change the list() function call to
list($price, $pn) = mysqli_fetch_array...
-
(1) My email accounts require username and password to log in. In the book's database there is a username field but logging in requires the email address instead. Wouldn't it be more logical to require the username as long as it exists and email systems seem to use it?
I don't know that one solution is more logical than another. It's just a matter of how you want to do it. Arguably, I would imagine that usernames would be publicly visible, whereas email addresses would not be, thereby making it more secure to use the email address to log in. Six of one, half dozen of the other, really.
(2) Page 89 shows all the responses to the add-account insert. It seems that step 12 handles the "both" option of existing username and password and step 13 handles both being taken again. Is that because you have to distinguish between duplicates being in the same record or in different records? Also, the error messages are reported as literals again and again. Is that repetition required because of PHP?Not exactly. Step 12 handles both being taken, in two different records (i.e., this user has already registered this email address and another user has already registered the username). Step 13 handles one or both begin taken, but in a single record. As for the question about the error messages as literals, I'm not following what you're asking there.
(3) On page 92 it says "database queries are expensive." On page 93 it says "for security purposes, the script doesn't indicate which of the two values is incorrect, or if the email address has been registered at all." I have a login page created when learning ASP scripts and about session variables which still works after adding ASP2.Net to it. Queries work fast for validation using stored procedures. Also username and password are treated individually and not bundled together losing the detail possible in a response. Since the user is only allowed a few tries for each field it doesn't seem like security would be compromised. But there may be things hackers do so you don't want to help them at all with anything.You don't ask any question here, so I don't have an answer. You seem to be suggesting something about queries being quick for validation using stored procedures in ASP.NET. That may or may not be true, but regardless, the point I'm making is that any file input/output, including a database query, will be the most taxing thing a PHP script does, so you should limit those occurrences as much as possible. If you do have a question here, let me know and I'll try to address it.
-
Actually, my apologies, there is an error in the text, it's just not the error you think it is. First of all, the code should technically be just
if (!isset($_POST['terms'])) {
The second condition was suggested on page 136, but not formally added to the script. So it shouldn't appear in subsequent scripts.
But as for the error, the first clause is true if $_POST['terms'] isn't set. The second part of the clause needs to check the value $_POST['terms'] should have. Since we're trying to identify problems, the second clause should actually be
OR ($_POST['terms'] != 'Yes')
because the corresponding actions should be taken if $_POST['terms'] is not set or if it does not have the value of Yes. (If we were trying to find a positive match, the code would be isset($_POST['terms']) and ($_POST['terms'] == 'Yes').)
Apologies again for the confusion. I think I was confused by your switch to a single quotation mark, which, as I've said before, doesn't actually solve the problem and does, in fact, introduce a bug into the system.
Let me know if any of this is still not clear.
-
I agree with your original assessment, and with HartleySan's concurrence. However, Antonio has a point and it's always best to err on the side of normalization. If a client is almost always going to use one of a handful of values, I would be inclined to create those in a separate table. Then, on the user interface side, you present those existing options as a drop-down menu, or give the client the option of entering a new value. This would be both faster for the admin user and more foolproof.
In cases like this, where the database design could reasonably go either way, I use the UI considerations to help make my decision.
-
That's a pretty good article, discussing the developments, pros, and cons, well. In a newsletter a couple back, I posted about MongoDB, which is another non-relational database (I don't think the article uses the term "NoSQL", which is for the best as it's a misnomer).
I think the key is that non-relational databases scale better than relational ones but there's a higher risk of data corruption. In my experience, and this may sound blasphemous, most sites don't need to worry about scaling at all. In 12 years, I've worked on maybe one project that I really had to develop with scaling in mind. Only maybe 1-2% of all Web sites will ever see the traffic where not being scaled properly will impact them. I'm not saying developers should be indifferent to this criteria, but it's like buying a car because it can go 140 MPH instead of 120: it's not likely to matter. The New York Times, for example, is using MongoDB for part of their site, but the NYT is probably a top 100 or top 300 site.
Conversely, data integrity is an issue for every site. I would be very, very hesitant to compromise data integrity for any reason.
I'm not saying that these non-relational databases aren't useful, and I do think they're worth watching and perhaps learning about, but I'd think carefully, about 20 times over, before embracing a non-relational database over a relational one.
Good article. And thanks for sharing!
-
Sorry for the confusion. The keywords INDEX and KEY are the same in MySQL. And both are optional when using UNIQUE, so UNIQUE, UNIQUE KEY, and UNIQUE INDEX are all the same.
I personally tend to write INDEX and UNIQUE, but sometimes I use the output from phpMyAdmin as the SQL in the book, and it prefers KEY.
-
I'm still not following your database schema, but if you've got it working, that's the important thing.
-
Good, limiting to 80 characters is a smart choice and should minimize the impact on performance. In fact, a UNIQUE index on the first 80 characters is probably better than using PHP to check for uniqueness, because PHP would check the entire string, meaning a subtle difference anywhere in the string would not be caught.
-
This is a bit of a gray area. I believe MySQL will let you put multiple indexes on the same column, but phpMyAdmin, for example, will report that as a problem. The only situation where I ever put multiple indexes on the same column would be in a login example, where the email address or username might be UNIQUE and there's also an index on the combination of the email address or username and password.
FULLTEXT and UNIQUE are two totally different kinds of indexes, so I don't think it's a problem to use both on the same column except that the idea of putting a UNIQUE index on a column that merits a FULLTEXT index is like nails on a chalkboard for me. Putting a UNIQUE index on a column with long text values will be terribly inefficient, so I would re-think your needs there.
-
You would use BASE_URI, because you're including a file on the system, not BASE_URL, which is a URL to a Web page.
As for those more fluid options, the benefit is that they allow you to move the code from one site to another without modification. The downside is that PHP will need to do a bit more of extra work determining the current location or document root or whatever on each page call. Also, what, specifically, you use will depend upon what script has that code in it. If you want simple and reliable, I would just hardcode it.
-
My only thoughts on what you've posted is that I'd use more constants and absolute paths. You include some files as constants (like MYSQL) but then many other things using ../../ When I have a site that I know will have lots of directories and directories within other directories, absolute paths are going to work more reliably. Also, if you define, for example, the gallery script as a constant, you can change the value of that constant in the configuration file and the change will be reflected everywhere.
-
Thanks for sharing your experience. For future reference, a phpinfo() script also indicates the active php.ini file, no matter how many exist.
-
I've been familiar with MySQL ever since it was lumped in with mSQL, and I've never heard of it not being relational. Also, joins are always for relational databases, regardless of the join type.
-
Thanks, Jonathon, for your input. Very much appreciated! And thanks for the nice words.
The consensus from people seems to be that most readers don't really care who the actual publisher is. Which is not surprising, I guess. I agree with your assessment that I could sell some books to people I'm already in contact with but, in the end, sell more using a publisher. But I don't think it's an option to sell it myself and then go to a publisher. I can use Amazon without a publisher, however.
Thanks again!
Arrays And Sessions
in PHP 6 and MySQL 5 for Dynamic Web Sites: Visual QuickPro Guide (3rd Edition)
Posted
Okay, I don't exactly know how to help you here. You've posted no code wherein a product name is stored in $_SESSION['product_name']. In this last bit of code, you're assigning the value of $pn to $_SESSION['product_name'], which doesn't make any sense if you think about it. First of all, $pn has no value in this script. Second, $_SESSION['product_name'] should have previously been assigned and should be retrieved at this point, as the other session values are (I believe that's what you're trying to do). This is what Stuart was trying to say earlier, too.
Also keep in mind that a very basic debugging technique is to do a print_r($_SESSION) to show what values are stored in the session.