Larry
-
Posts
5413 -
Joined
-
Last visited
-
Days Won
155
Posts posted by Larry
-
-
As for point 2, yes, exactly. What I'm saying is that you'll see the effect if the quantity is greater than 1 and you set it to 0: it becomes 1. If the quantity is 1 and you set it to 0, it also becomes 1 but you can't tell that because it looks like no change occurred. I'll debug this and see why it's failing.
-
I haven't personally seen these problems but I'm looking into it. For the first problem, for seem reason the filter_var() function is converting quantities of 0 to 1, which you'll see if the quantity of an item is more than 1, and you attempt to set it to 0: it comes back as 1. I'll have to look into this further. As for the second issue, it's possible the merchant ID has expired. I'll confirm that, too.
Also, just to confirm, the demos are on DMCInsights.com, not LarryUllman.com. Thanks for pointing out the problem!
-
In terms of performance, there's also this new mysqlnd: MySQL Native Driver. I believe it performs better than the old MySQL driver. If installed, MySQLi will take advantage of it; I'm not sure if PDO will or not.
In terms of employment, surely there's an argument to learning PDO, even if you don't regularly use it.
In terms of OOP, MySQLi can be used either procedurally or OOP; PDO can only be used with OOP.
I'm always a advocate of learning new things and learning more, so I wouldn't want to suggest that people shouldn't check it out, I'm just not convinced it's The Next Big Thing that everyone should use all the time.
-
Sorry for the delay. I was out of town for the long (US) holiday weekend. I've read this entire thread again, in sufficient detail, I think, and I'm still standing by my previous answer. if you need to use a database connection, or any variable, inside of a function, the preferred way is to pass it as an argument to that function. That being said, I kind of don't like what you're doing with your create_gallery_index() function. To me it's way too much logic within a function call. Moreover, you're including the configuration file, which I would think the script that calls the function would have also included, and you're including the MySQL connection script, which I would again think that the parent script would have included. You're also doing a lot of HTML within the function, which can be a red flag.
My inclination, then, would be to rethink the logic. I would be inclined to either make this functionality an includable script, without its function definition and call (i.e., you include the script that creates the gallery when it's necessary) or you create a separate script that does what this function does: the user clicks this to create a gallery, the gallery script runs (without the user seeing it) and the script redirects the user back to another page, passing along a flag variable (indicating success of the operation) in the URL.
That's my thinking. Let me know if this doesn't help or if I missed something or whatever.
-
Yes, you are correct: it should be $_POST, not $_GET. Thanks for catching that and for the nice words on the book! And for your interest in buying more!!
-
Thanks again for the nice words. I'm reviewing what I wrote and if I understand you correctly, you seem to have a good grasp of the topic. I wouldn't say, however, that all code wants to check if a cookie has already been set. That's just too blanket of a statement and certain situations imply alternative approaches.
Let me know if you have any other questions.
-
No, I've definitely used a PHP script as the src of an image tag. I forget where and when, but I have, and would definitely recommend it as a best practice in some situations (such as serving images stored out of the Web directory or stored in a database). I also disagree with the interpretation that the W3C definition doesn't allow for using a PHP script or that it advises against so. And, arguably, even if the W3C spec DID advise against using a PHP script as a src attribute, I think of the W3C as theoretical recommendations, which don't always mesh with how things are really done or how browsers really work.
If HartleySan, or anyone, doesn't care for a practice, just because it rubs you the wrong way, that's completely understandable and certainly okay, and there are always 12 ways of doing things, with very few clearly better than others, but I definitely believe it's fine to use this approach when the need arises.
-
Hey Matt,
I just want to say up front that you ask excellent, worthwhile questions, but I find that you do so a bit too bombastically (I'm also thinking of your other post regarding hosting). These two posts seem that much more excessive to me as it seems (to me) that you are missing the point, and emphatically so. Just look at some of the terms and phrases you use: "Why in the hell", "someone else's glorified api", "what is the point", "ranting and raving". Clearly there's a less aggressive way you could raise the same issues. So perhaps you could tone down your rhetoric a bit when you post questions like these? I appreciate the questions and alternative viewpoints, but a little less "Is everyone else an idiot?" would be for the best.
The first thing to understand is that it's not an either/or situation: learn and use PHP and MySQL from scratch OR use a framework. Realistically, you can't use a framework without having a solid understanding of the underlying technologies. Second, understand that I'm a "gray area" kind of person: trying to see the arguments for both sides, trying to avoid thinking of things as always whatever or absolutely whatever. That being said...
The clear benefit of using a framework is speed of development. In very few cases will using a framework NOT be faster than coding from scratch. Once you've learned the framework, that is. A framework-based site may or may not be more secure, easier to maintain, and less buggy than a scratch-based one, depending upon the site, the framework, and the programmer. Finally, a framework-based site is likely to have more features than a scratch one, unless you put in the extra effort. For example, Yii uses jQuery by default and enables Ajax and some other stuff out of the box, so a Yii-based site that I write will likely have an extra bell and whistle or two than one I create from scratch. And, again, have those extra features in far less of my time.
The clear downside of using a framework is extra overhead, in terms of both extra files and poorer performance. That may sound terrible but the counterpoint is that it's much, much easier to make a poorly performing Web site perform better than it is to get hours back in your life that you spent developing a project. Also, frameworks have built in caching to rectify this problem whereas most developers never get around to adding caching to the scratch sites they develop.
So are frameworks a better way to go? Sometimes yes and sometimes no. Personally, I've worked on maybe 8 or 9 sites in the past two years and used a framework (specifically Yii) on maybe 5 of them. For those projects, the benefits I get from using the framework outweigh the negatives. For the other sites, the benefits of using a framework didn't merit going that route. But the most important thing to know is that frameworks are sometimes a better solution and I think the intelligent thing to do would be to pursue and try using a framework before you dismiss them outright.
-
Yes, I recommend getting it working in a non-JavaScript method, then applying JavaScript. If you go the "unobtrusive JavaScript" route, as HartleySan suggested, you'll not only have cleaner code but have a more reliable always works/always fails scenario (as opposed to working-ish in some browsers and not working-ish in others). Although I'm comfortable handcoding JavaScript, I find that a framework such as jQuery helps a lot in terms of providing consistent browser behavior.
-
I generally think that trying to limit the number of database queries is a good thing, within reason. My rule would be to cut out unnecessary queries, and I don't think you have any unnecessary queries here. Moreover, you have two fairly straightforward queries. To combine these into one complex query, as HartleySan already suggested, might be a net negative, because of the extra logic and effort required. Using caching for the queries you do have is always a good solution, though, especially on busier sites.
-
I have not explained how to create any of those, nor do I intend to in a book. Each is to complex and specific to make a good book example. Moreover, with PHP, you can find free, good programs that do all of those for you already.
-
Thanks for the good questions. I don't consider MySQLi to be a best practice overall, but it's something everyone is going to need to learn to use, which is why it's in the book and PDO isn't. Also, PDO uses an OOP interface, which the book does not, prior to the 4th edition.
PDO is wonderful and very useful. However, and I'm probably in the minority here, but I don't see a lot of benefit to using a data-access abstraction layer (or a database abstraction layer) unless you know the application will be ported to different database applications. I've been doing this for 12 years now and I've never once switched the underlying database. If you're creating something intended to work with multiple database applications, or you want that capability, fine, but for about 95% of all applications, it seems that we're using MySQL and we're going to use MySQL and I don't see the benefit of adding an abstraction layer in there. But, as I said, I'm probably in the minority on this one.
-
First, I would confirm whether the onSubmit() is taking effect at all. For example, you could change the onSubmit() to call an alert() or just return false. Off the top of my head, I don't know what the limitations are on submit event handlers, so my suspicion is that's the problem, not the specific code for opening a new window.
-
It's just for storing XML data. Presumably this is supported by database applications that have native XML functionality because, for example, you could store XML in a MySQL database in a text column, then manipulate that XML as XML using PHP.
-
If you're using a MyISAM table, there is no advantage as MyISAM does not support foreign key constraints.
-
I disagree. I don't think you can get the user's PC name using JavaScript (or at least I hope not, as that'd be terribly insecure) and the screen resolution will not have as many common values as the user agent. Also, if it's something detectable by JavaScript, it could easily be faked.
Another technique for preventing session fixation is to use session_regenerate_id() after a person logs in to automatically change the session ID.
-
Happens to us all. Just to confirm, was the problem the space before the ++ or that the code should actually just be:
$taxrate++;
without assignment?
-
I've heard good things about CodeIgniter, among others, but Yii seems to be fitting my needs for now.
-
In the other forum, the one that chop references, I explicitly state that you can call stored procedures using phpMyAdmin, but how you do so depends upon the versions in use and seems to change.
-
And thanks for the nice words on the books!
-
Hello Brooke,
Thank you for the nice words. Very much appreciated. And to confirm, the PHP 6 and MySQL 5 is the 3rd edition (it doesn't say third edition, confusingly enough, because of its specific title). As I believe it says at the top of the SQL file, you shouldn't try to import that entire thing. It's not meant to be used that way; it's intended for readers to copy and paste the commands as needed (there's no point in creating an import-able file, as some of the commands change the structure of the databases, so you'll need to be able to have both "before" and "after" versions).
As for the SQL for Chapter 15, in order for me to send you just that, I'd open the big SQL file, find those commands, copy them, paste them into a new file, and save it. I'm literally leaving the house right now (after I post this response), so I wouldn't be able to do that until Tuesday. It'd be faster if you just did that yourself (open the big SQL file, find those commands...).
Thanks again for the nice words!
-
Hey Sharon,
You can certainly suggest this, but I don't have anything on hand to post or make downloadable. Pretty much all of the answers to review questions are found in the book. Most of the pursue prompts either require that the user do something like confirm their version of PHP or look something up in the manual, neither of which I can post as an answer. The same goes for a lot of the recommendations of specific things to try: often they would differ based upon the user.
That being said, if there is a specific prompt (either review or pursue) that you'd like help with, please just post that as a new thread in this forum and I'll be happy to assist.
-
I like the Yii framework quite a bit. For starters it requires PHP 5 and uses jQuery natively. Then I like how it auto-generates a lot of code and folders for you. From there, it just kind of works and makes sense to me.
I've used the Zend Framework some, but didn't like using it as the basis of a site. I use pieces of it as needed, which is nice.
That's about it for PHP frameworks that I've actively used.
-
Perhaps, depending upon the version of MySQL and the storage engine in use, neither of which do you mention.
I Need Help On Limiting The Login Attempts
in PHP 6 and MySQL 5 for Dynamic Web Sites: Visual QuickPro Guide (3rd Edition)
Posted
Add a wrong_logins column to whatever users table. For each wrong login, increase this by 1. Add a wait_logins column of type TIMESTAMP. When wrong_logins gets to 5, update this column to NOW() plus 15 minutes. When the user properly logs in, set wrong_logins to 0 and wait_logins to NULL. Add a check to the login process that wait_logins must be NULL.
That's the basic idea.