Want to learn PHP


I am Fobi R. Tamfu.I have done training in Java and know i want to learn PHP. Is it will easy to learn PHP?

Fobi R. Tamfu

Yes, it is, probably. If you’ve learned Java you could probably pick up PHP as well.

How up to date is the PHP section at w3schools?

The JavaScript section is about 15 years, presumably PHP isn’t quite so bad.

One thing to keep in mind, assuming you’re intending to use MySQL as a database server, there are three “extensions” which can be used to have PHP interact with MySQL

All function names for this extension begin with mysql_ it was deprecated in version 5.5 of PHP and was removed in version 7 of PHP. If you see a tutorial that uses it, steer well clear of that tutorial.

MySQLi (Improved)
All (procedural) function names for this extension begin with mysqli_ note the i in the start of the function. There’s the option of either procedural or object-orientated functions.

This only has object-orientated functions.

Whether you go for the MySQLi or PDO extension when dealing with any variable in a query, no matter what the source of the value in the variable, ALWAYS use prepared statements, having first validated the data that you intend to use. PDO has an advantage over the MySQLi extension in being able to use named placeholders with prepared statements.


So the main issue that may be faced dealing with PHP can be due to database connectivity?

I wouldn’t say it’s the main issue, though it is an important one. It’s worth keeping in mind that if you learn, don’t learn how to access the database using the old-style functions such as mysql_connect() and mysql_query().

PHP is today the most widely used language for development of web based applications and websites. To learn PHP you need to read some material, to do some researches, start freelancing, build an application, etc! Anyway, if you have a desire to get these skills you will do everything possible to reach this! I wish you good luck!

Prepared statements are not for security; they are for re-using queries that you want to execute multiple times. It amazes me people use PDO because it’s (more) injection-resistant. By that logic maybe we shouldn’t echo HTML in case someone tries XSSing the site.

For a single-use query non-prepared statements are more efficient and are the correct tool. Why do in two steps what you can do in one?

If the OP is learning PHP and MySQL go with mysqli and use non-prepared statements, at least to start with, so you can learn why it’s important to sanitise data go through a HTTP request to PHP and then to MySQL. I learned PHP in the magic_quote days and it did me no favours…

1 Like

because then I don’t have to worry about how to correctly sanitise the data I need to put into the query. For me that is worth way more than the few milliseconds a regular query would run faster.

DrQuincy is right when the query is a static string. It is useless to use prepared statements for queries lacking variable bindings. That just reveals a complete a misunderstanding of how things work. Similar to saying when PDO and/or MySQLi is used injection is eliminated. Not true in the least.

I would agree with that.
But are you saying that prepared statements are of no use as an extra safeguard against injection, when you use bindings for user input?

No, not all all. When data that is part of the code execution life cycle needs to be included in the query string than you SHOULD ALWAYS use prepared statements w/ variable bindings. The exception to that rule would be if the value(s) being included are known to to be safe but that can be subjective. For example, concatenating a known integer value into the query string without using a prepared statement.

It was maybe more DrQuincy suggesting that:

The improved security of prepared statements was the reason I made the switch from mysqli to pdo. The ability to re-use them was something I saw as an added bonus which I also find useful.
So I’m using them for re-used statements and any query with user input, for anything else I use a straight query.[quote=“oddz, post:11, topic:218002”]
Similar to saying when PDO and/or MySQLi is used injection is eliminated. Not true in the least.
That’s why I choose to have multiple lines of defence when it comes to databases. If no single method is 100% watertight, a belt & braces approach should reduce the odds.
First the organisation of databases, public and private data are in separate databases. Scripts run by users have very limited database privileges. Any data that can be manipulated by a user is sanitized and put in a prepared statement. Plus I have functions that detect attempted attacks, block the ip and notify me so I know what they are trying (a common one is 'A=0 added to the end of urls).

I thought the 2 steps of prepare and execute happen internally anyway:-

To understand parameter binding and its benefits, we must first look more deeply into how PDO works. When we called $statement->query() above, PDO internally prepared a statement, and executed it, returning the resulting statement to us.

I am fairly new to pdo, so correct me if I’m wrong.


That method can used to execute a query immediately without prepared statements.

If you need to make the same queries multiple times (which is the primary reason for prepare) then not having any variables to bind to it makes it even MORE beneficial to prepare it than when you need to use variables.

Which makes no sense since both offer the same prepare statements tghat have nothing to do with security - you can fill your database with junk equally easily with either variant of what is effectively the same command.

Which is the correct way to do it since sanitiizing is what provides the security to hopefully eliminate most of the junk that might otherwise be inserted (except when the values are user input when they should be validated instead).

Yes, with that exception.

The primary reason for a call can’t really be called an exception even if most people are more concerned with a side effect that doesn’t even achieve what most think it does.


This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.