scootstah

Currently, I have: Adblock Plus BetterPrivacy Cookies Manager DOM Inspector DownloadHelper Execute JS Extended Statusbar FasterFox Firebug Firecookie Ghostery Greasemonkey HackBar Image Zoom Live HTTP Headers NoScript Regular Expressions Tester Stylish Tab Mix Plus Tamper Data User Agent Switcher Web Developer Toolbar YSlow I could probably live without a few, but I use the majority quite a bit. I haven't really looked if there are Chrome equivalents because I honestly don't care that much.

It doesn't use prepared statements all by itself. You need to prepare them yourself. Just calling the query() method will not do anything to of the sort. Right, I'm just saying that escaping is a needless step since you can use prepared statements. EDIT: And if that's not an option, extend PDO and add an escape function.

PDO uses prepared statements, you don't need to escape anything.

It's probably an anti-CSRF measure, pretty much to prevent what you're doing. Do you have to be logged in on the end site to do whatever you're doing?

There you go, that's a lot better. A couple of things though: 1. If you want to call your render method statically, you need to make it static or else you will get the warning Strict Standards: Non-static method View::render() should not be called statically . You can do that by adding the static keyword after the visibility keyword (public). 2. You should be checking if the template file exists before requiring it, and handle it accordingly. To build a design around the template you can use includes in your template files to include other stuff, like headers and footers. include 'header.php'; ... some template code include 'footer.php';

In short, your original problem is that you are not hashing the password when you compare it in login.php. When you register, you do $enc_password = md5($password); When you login, you do $password = $_POST['password']; Since you inserted a hash, when you return the row from the database (in login.php) that password will be hashed. As it is now, you are comparing a plaintext password to a hashed password. I see several things wrong with your code. There's some very bad practices going on there. I'm feeling a little bored tonight so I decided to whip up a quick and dirty login script for you. There is a login, logout, register, and membersonly pages. Some of the improvements are: - using the MySQLi extension instead of the MySQL extension. The MySQL extension is very, very old. There is literally no reason to be using it anymore. In my scripts I have used the Object-Oriented style but all of the same functions exist in procedural if you're more comfortable with that (although I'd recommend just using the OOP version). - Escaping data to prevent SQL injection. I am using the MySQLi extension (as I stated above) which supports prepared statements, but I figured that might be a little over the top for you at this point. I do however recommend you look into it, because prepared statements help to secure your queries from attackers. - Minimally separating presentation from business logic. It's very hard to read and maintain code when you have HTML mixed in everywhere. Not to mention the fact that you are outputting HTML before your session_start calls, which throws a warning. Note that to keep things simple, I only used the sha1 function to hash the password. This function (along with md5) is not made for password hashing and as such is very bad at doing so. Anyway, I've attached the files to this post. Hope this helps. 17838_.zip

That's not going to work. Since it's .html, you have no dynamic capabilities. You would have to use placeholders and search/replace the placeholders with real values. What you should do instead is have .php templates and then send the data to the template to loop over. See this post. I made a small function to load a template and to optionally send it some data. You could then loop over the data in your template. It was a really basic example so you will have to tweak it a bit.

and you can get addons with Chrome I know, but Firefox has a lot more addons. It's just because Chrome is still young. Eventually I might switch.

I would like to know what "programming concepts" require a template parser.

You need to use ungreedy quantifiers. <div class="15ma">(.+?)<\/div>

It's pretty much impossible if you use .html files. The only way to do it is to file_get_contents the html file and then search/replace, which is pretty stupid IMO. Instead, use .php files. This way you can loop over stuff in your template files.

Meh, I still use Firefox 100%. Chrome is getting there, but the addons for Firefox just make it unbeatable.

A template parser (like Smarty, Twig) is generally frowned upon. They are usually very large libraries (Smarty), and cost a lot of overhead to use. Besides that, they are completely unnecessary. Probably one of the biggest arguments I see in favor of template engines is something along the lines of: "well I want my designers who don't know PHP to be able to make templates". This is a load of crap. Smarty's syntax is nearly identical to PHP, if they can do that they can definitely use PHP. You shouldn't have logic in templates anyway, just conditionals, loops, and variables. Another big reason I see for using stuff like Smarty is the separation of the presentation. This is a good argument, but has nothing to do with template parsers. The same thing can be achieved using pure PHP in the templates. This is going to cripple you as a developer. Don't be so stubborn, libraries exist for a good reason.

That's correct, boolean TRUE is not the same as the string "TRUE". One is a boolean, one is a string. Boolean is not the same as an integer either.

There's no conceivable reason to use 1 or 0 if you actually want a boolean. Since PHP is loosely typed they may appear to do the same thing, but they are not the same thing.

I don't see how any savvy internet corporation would purposely bring about these insane bills. It's only going to hurt them in the end. My personal belief is that those corporations supporting the bills are doing it for their image. If they were to oppose them I'm sure the general public would be like, "Hey, they condone piracy?!"

So what's the problem?

Hopefully this illustrates the difference... $foo['bar'] = 'bleh'; var_dump($foo); // array(1) { ["bar"]=> string(4) "bleh" } $foo['bar'] = ''; var_dump($foo); // array(1) { ["bar"]=> string(0) "" } unset($foo['bar']); var_dump($foo); // array(0) { }

Huh?

Well, that's boring...

I just wanted to point this out, because I tend to use it a lot for debugging. With print_r you can add a second parameter to return the output instead of echoing it. Therefore you can use it in <pre> tags to make it look pretty. Like, if you have big arrays or objects you will be able to have one item per line instead of all garbled together. With var_dump you can't do that. Instead, though, you can capture the output in a buffer and then do the same thing. Something like this: function var_dump_pre() { ob_start(); call_user_func_array('var_dump', func_get_args()); return '<pre>' . ob_get_clean() . '</pre>'; } $arr = array(range(0,5)); echo var_dump_pre($arr); Which changes the output from: array(1) { [0]=> array(6) { [0]=> int(0) [1]=> int(1) [2]=> int(2) [3]=> int(3) [4]=> int(4) [5]=> int(5) } } to array(1) { [0]=> array(6) { [0]=> int(0) [1]=> int(1) [2]=> int(2) [3]=> int(3) [4]=> int(4) [5]=> int(5) } }

Wow, I think it's time to go to bed. It took me way too long to figure out what was different, haha. For the record: you omitted the second strlen.

The purpose of an HTML Email is something that is pretty and formatted. So when I use that term that is what I am talking about, and no, it isn't "trivial'... Debbie I'm pretty sure any browser or email client can handle a simple HTML table. It is trivial. All you have to do is add two headers. I already showed you how to do that above. I'm not going to continue to argue. You have been given code, you have been given answers.

You don't actually need to echo it, it will output on its own.