I heard that echo is faster but print enables you to do more things with it?

I'm confused as to which one I should use mysql_* or mysqli_* the more secure one and fastest?

Can MySQL tables store URLs? And if so, can MySQL and or PHP input that URL into the browser so that the user can be redirected?

magic_quotes are being turned off by default in php6. Is there a list I can view (can't find it in php.net) that shows what will be added/taken off(or thinking about it). I'm going to stick with a book I have, but its a little out dated. (edit: or just from the top of your head) so that I dont learn things that are not safe to use.

I've never needed to use print so I haven't really looked into the various differences.

As for mysqli or mysql, you might as well get used to coding for mysqli since by default PHP5+ has mysql turned off. The functions work about the same from the average user's point of view but mysqli offers developers many more options. By the way, the "i" stands for "improved extension".

Yes you can store and use URL in your MySQL tables. To get the stored data out, you'll need a PHP script to send commands (queries) to the MySQL server and display or in your case redirect the user to content.

As for what is and isn't in what versions of PHP, I couldn't begin to try and answer that question. There are some many changes and bug fixes in each release that you'd just about have to be one of the developers to keep track. Unfortunately, it is just as difficult to try and tell you what is safe and isn't safe. Nearly any "unsafe" method of programming can be safe if you write the code to compensate for any exploits. Additionally, nearly any "safe" method can be a security risk if you don't take care during coding.

I hate to be so cryptic but for a PHP newbie, it is difficult to learn the differences between safe and unsafe. My suggestion is to ask an advanced PHP user if what you intend to do is safe or not until you get a better understanding.

I hope that this will offer you enough information to guide you on to your next question.

vujsa

No. print() returns a value, whereas echo() does not, so echo() is slightly faster. I can't think of a valid example to show why returning true/1 from print() would be useful. For all standard code where you simply want to output something to the display, use echo().

You should use the MySQL "Improved" extension if you're using MySQL v4.1 and above. Having said that, you should be using MySQL v5.0 and above.

Yes. A MySQL text type data field will store any plain text you want. You simply need to retrieve that data with a properly fashioned SQL statement and create URL's with PHP. Depending on what you really need to do, this may not be very efficient.

magic_quotes are to be avoided in any version of PHP. I'm sorry I don't have a link to what v6 will include or exclude, but I'm sure you can find it if you review some of the developer notes. Just use good coding practices and you should be fine.

Thanks for the replies.

I'll just continue using the book I have, which is PHP and Web Development Third Edition.

If I code by the examples (in which now there are better ways to code instead of the book) can I just come here for some of the gurus to inspect it, and or show me a better way to code it? There is one example that I can remember from the top of my head that uses magic_quotes, and now I know it should never be used. I would need to figure out which other way I can code it without using magic_quotes(this includes escaping methods).

Can I come back here and post it? Seems like a good community and Respectful

I wanted to go into further details about the MySQL tables holding URLs. I'm going to be creating a member areas(as you have seen around) but the only difference of mine is that it will direct you to your own unique page. Hence storing the URLs so that for example, $user and $pass match, it will trigger the correct table URL and direct you to it.

Seems reasonable. The PHP Manual is really your best resource, though.

I can't speak for the forum admins, but typically when you need help with something, you can post a segment of the script you're having trouble with for critique or just help spotting a bug. It is usually frowned on to post hundreds of lines of code with little explanation or proper comments.

magic_quotes should be avoided because it's not secure and will typically cause your application to have multiple unwanted escaping quotes in your DB data. The best way, regardless of what server you're using, is to do something like this:
Assumes you're using a POST method form to supply data for a script that will interact in any way with the database. Once you've removed all the slashes that 'magic quotes' have injected into your data, you can go ahead and use some other valid escape technique, like mysql_real_escape_string(), or using a prepared statement.

I'll have to post a good example of storing URLs as you've mentioned.

But aren't they removing get_magic_quotes_* ?

I'm also looking for a good editor. Im currently using the Zend editor but I was wondering if there was a better one. Maybe writen in c++?

Yep! They're removing magic quotes thank heavens above and all that. The sooner we see the back of magic quotes the better, it's okay for beginners because it escapes all the data, but it's an undiluted bane for everybody else. We have to add an extra if statement block to check if magic quotes is active, and then act accordingly.

We shouldn't be treated like children! And to be fair, although beginners should definitely be fiddling with PHP, they really shouldn't be releasing applications which they expect to be 100% secure, and so if they're under that illusion, magic quotes isn't going to save them anyway so I say good riddance!

__________________
The man who comes back through the Door in the Wall will never be quite the same as the man who went out.

So then what would we use instead of get_magic_quotes_* ?

There would be nothing. All data will be potentially dangerous when inserting it into such things as MySQL statements. Therefore all programmers need to up their game a little when they remove it as they'll be no more babysitting!

Don't worry, TalkPHP will have this covered addslashes is a good function to start at, but there's also mysql_real_escape_string, too. Although I hear they're removing addslashes from PHP 6. Not that I use it, personally.

__________________
The man who comes back through the Door in the Wall will never be quite the same as the man who went out.

Well the code that I was planning on using used get_magic_quotes_*. So then I had to change it to addslahses with a combo of mysql_real_escape_string. If addslahses gets removed.... My whole program wont work :(

Why use addslashes() and mysql_real_escape_string()? What are you trying to accomplish?

Alright so I'm trying to make a authentication, I'm doing it little by little since I'm still new. I think I'm just confused :)

After it was viewed by another programmer, he recommended using stripslashes.

When magic_quotes are gone, what would you guys recommend to do? I would think there is another way of doing it? The reason I do it this way is because I used to use Visual Basic, and it has a good feel to it and lets me understand it easier instead of having 1000000x different commands/initials/etc.

the $dir is a row that will store URLs for each customer, eventually when I get to it. Sock, the example you were going to provide storing URLs in MySQL would be a great help! :)

Ok, this portion of your code
.. actually doubles up the slashes!! You're checking to see if magic_quotes is On, then taking each piece of data and adding a second set of escaping slashes. In fact, Let's say an original slash '\' was in the data. magic_quotes escapes this with a slash, creating '\\', and addslashes comes along (you guessed it) makes a third '\\\'!!

The idea of using get_magic_quotes_gpc() is to check whether or not magic_quotes exists. If it does, you use stripslashes to undo its evil deeds. If not, you don't have to worry about it. The next sequence of code after this (where you interact with the DB) is where you ultimately want to escape the data.

Here's a general outline of how I run something like this:

• Verify that all required data is present
• Check for magic_quotes, if so, stripslashes
• Validate all data for the proper type / formatting
• Open the DB connection
• Use a native escape function and/or a parameterized query (in this case, use $db->real_escape_string($user) for example)

Take a look at my earlier post and the code example. Notice how I use array_map() to run stripslashes on every POST array index. This is much more efficient than writing separate code for each index value.

YBH: I see you're using the mysqli extension. If you don't want to worry about malicious code, you can use prepared statements as shown here: http://www.php.net/manual/en/functio...mt-prepare.php

Oh I think I get it. From your example sock

So in my Short Variable it automatically adds stripslashes if I use the POST method and I'm using magic_quotes. My question is though, if they plan to remove magic_quotes, what other ways can I do it instead of if (get_magic_quotes_gpc) ?

It seems as prepared statements will save me a lot of time from coding. What I dont understand is the "sssd" I see it says on the table

s - corresponding variable has type string
d - corresponding variable has type double

I understand the "s". But I dont understand what a "double" is from the d.

I see what you're saying. I think the decision to move to v6 and retooling is always a big deal. I wouldn't really worry too much about it; at the most, if you check for magic_quotes now and use the method I've recommended, you'll have to edit only a small portion of your code.

What might be a better way to future proof your scripts is to have an included script that performs some of these basic tasks for you in one location. Then you only need to alter one script.

You need a primer on basic data types. Check out the 'language reference' section on 'types' (in fact, read that entire section). A 'double' is synonymous with 'float' in PHP, e.g. '1.35'. Same precision. NOTE: other languages may discern between these two, but PHP is relatively weakly typed.

The most important lesson I can impart to anyone is to understand the basic data types and the proper way to manipulate and store them. After all, this is what programming is all about, manipulation of data.

As an afterthought, you might take a look at how the functions sprintf() and printf() work. Tinker with that a bit to understand how to interact with different data types.

Ok, to clear it up some more. I'm working on the admin section of my client area script. Currently, I'm working on "adding client" section. Here is the code with the improvements you guys have given me

My HTML form method is POST, that includes the variables listed in the php file. Is there any improvements I could do? Or is it good stuff for a beginner?

I was planning on adding the array_map, that Sock recommended but got confused in the process, hehe :)

I will be adding all the information, so the name, password, etc will be added by me. I don't want just anyone signing up. The $dir will be the where the URLs will be stored.

I do have a question about MySQL. Do I need to completely have a different table for the URLs? Or can MySQL store it the way I'm picturing it. Let me show you want I mean:

Client table as of now:
User names
User1*
User2**
|
|
Passwords
pass1*
pass2**

ETC.

Will they all connect to each other? Or would I need to do a table for usernames, a table for passwords, etc.

YBH: Have you tested that code? Because mysqli's constructor only allows for 6 parameters:
Perhaps you will find this link useful: http://www.php.net/manual/en/functio...li-prepare.php

I'm getting an error

I thought maybe it was DB that was named wrong. So I renamed the db in my php code ybh305_clients (thats the name of it inside PhpMyAdmin). But it still gives me the same error.

Perhaps you don't have the MySQLi module enabled in your php.ini file.

__________________
The man who comes back through the Door in the Wall will never be quite the same as the man who went out.